核心内容摘要
唐心糖：品味心意，传递情怀
引言作为一个Java/Go 后端开发者你肯定非常熟悉传统的关系型数据库MySQL、PostgreSQL和键值对数据库Redis。
它们的核心逻辑通常是精确匹配WHERE id 1或key session_123。
但在这个 AI 爆发的时代我们处理的数据类型变了文本、图像、音频、视频。
这些非结构化数据无法通过简单的“精确匹配”来查询。
详细来说如何让数据库理解“含义”比如用户搜“怎么退货”数据库得能把文档里写着“售后流程”的那一行找出来。
传统的 SQLLIKE或全文检索Elasticsearch在这里往往力不从心因为它们匹配的是字面而不是意思这时候向量Vector和向量数据库Vector Database就登场了。
简单来说它们是为了解决“语义搜索”和“模糊匹配”而生的什么是向量 -- 数据的坐标在数学上向量是有大小和方向的量。
但在 AI 工程中向量Embedding是非结构化数据文本、图片、音频在多维空间中的数值映射因此定义是数据如一句话、一张图经过深度学习模型Embedding Model计算后转化成的一串浮点数数组例如输入苹果输出 (假设 3 维)[
8,
1,
1]输入梨子输出[
7,
2,
1]输入卡车输出[-
9,
5,
3]核心逻辑空间距离代表语义相似度简单来说呢就是在这个多维空间里含义相近的词坐标距离就近如果两个数据在语义上很像比如“猫”和“小猫”它们转换成的向量在数学空间里的距离就会非常近。
如果语义无关比如“猫”和“汽车”距离就会很远后端视角对于后端来说所谓的“语义搜索”本质上就是计算两个数组向量之间的数学距离。
常用的算法是余弦相似度 (Cosine Similarity)similaritycos(θ)A⋅B∥A∥∥B∥\text{similarity} \cos(\theta) \frac{A \cdot B}{\|A\| \|B\|}similaritycos(θ)∥A∥∥B∥A⋅B结果越接近 1表示越相似。
向量数据库 (Vector DB) -- “坐标”的引擎如果只有几千条数据你把向量存在内存里写个for循环算距离也行。
但如果有 1 亿条数据每次查询都要算 1 亿次余弦相似度CPU 直接爆炸。
这就需要向量数据库与关系型数据库的区别它和 MySQL 的本质区别MySQL (B Tree):寻找精确匹配。
利用树结构快速定位到ID100的叶子节点。
Vector DB (ANN):寻找近似最近邻特性传统数据库 (MySQL/PostgreSQL)向量数据库 (Milvus/Weaviate/Pinecone)查询逻辑精确匹配 (Exact Match)近似最近邻搜索 (ANN - Approximate Nearest Neighbor)查询语句SELECT * FROM table WHERE typefruitSearch(vector[
1,
0.
..], top_k
核心算法B Tree, Hash IndexHNSW (图索引), IVF (倒排索引), Quantization (量化)结果确定的行数据最相似的数据列表 相似度得分躲在背后的皇帝HNSW 索引虽然这个小标题有点哗众取宠但是我恰好是想借其来表达HNSW 索引的重要性。
向量库不会真的去算 1 亿次距离。
它通常使用HNSW这种图索引算法。
你可以把它想象成“跳表”“社交网络”分层导航顶层只有少数几个“枢纽节点”底层包含所有数据。
快速收敛查询时先在顶层找到大概区域然后像跳伞一样落入下一层逐步缩小范围最终找到离目标最近的一簇数据向量数据库工作一般流程来讲讲一般向量数据库是怎么工作的Embedding嵌入你的后端服务调用 AI 模型如 OpenAI把用户的 Query 变成向量。
Indexing索引向量数据库使用算法如 HNSW构建索引把向量在空间中按区域划分。
Search搜索数据库快速定位到目标向量附近的区域找出最近的邻居而不是全表扫描。
向量数据库有哪些推荐
纯向量数据库 (专门产品)Milvus:强烈推荐关注。
它是云原生架构核心部分是用Go写的对 Go 开发者很亲切性能极强国内社区活跃。
它有完善的 Java 和 Go SDK。
Weaviate:也是用Go写的开源向量数据库支持 GraphQL不仅存向量还能存对象。
传统数据库的扩展 (插件)Elasticsearch (kNN):如果你的架构里已经有 ES可以直接用它的向量搜索功能。
PostgreSQL (pgvector):非常火的插件。
如果你的数据量不是特别巨大比如千万级以下直接用 PG 存向量是最省架构成本的向量数据库这么火的原因 -- RAG与LLM作为后端你可能听说过RAG (Retrieval-Augmented Generation检索增强生成)。
这是向量数据库最核心的应用场景。
大模型 (LLM) 的痛点它不知道你公司的私有数据比如内部文档、代码库例如它不知道你公司上周发布的《V
0 接口文档》也不知道今天的新闻(不调用任何tool的情况下)它的知识有截止日期导致了幻觉一本正经地胡说八道这个大家应该深有体会向量数据库的解法把你公司的文档切片变成向量存入向量数据库这是“长期记忆”。
当用户提问时先把问题变成向量。
去向量数据库里搜出最相关的几段文档。
把“用户问题 搜到的文档”一起扔给 LLM。
LLM 基于这些文档回答问题。
这让 LLM 看起来像是读过你公司的维基百科一样RAG的标准架构流程阶段一数据入库这是一个离线或异步任务。
加载 (Load):读取 PDF/Word/Markdown 文档。
切片 (Chunking):这是最关键的一步。
你不能把整本书存成一个向量。
你需要把文本按语义或固定字符数如 500 字切成小块。
嵌入 (Embedding):调用 OpenAI API 或本地模型把每个 Chunk 变成向量[]float32。
存储 (Upsert):将(Vector, Chunk_Text, Metadata)存入向量数据库如 Milvus阶段二在线检索与生成这是用户发起请求时的同步流程。
问题嵌入:用户问“V3 接口怎么鉴权” - 调用模型转成向量Query_Vector。
向量检索:拿Query_Vector去向量库搜 Top 3 最相似的 Chunks。
Prompt 组装:你是一个技术支持助手。
请根据以下已知信息回答用户问题。
已知信息
... (检索到的 Chunk
1)
... (检索到的 Chunk
用户问题V3 接口怎么鉴权
LLM 生成:将组装好的 Prompt 发给 GPT得到最终答案潜在踩坑点在 Demo 阶段上面的流程跑得很顺。
但在生产环境你会遇到以下问题这也是后端工程师的价值所在
切片策略 (Chunking Strategy)问题如果切片太小上下文丢失如果切片太大噪音太多且不仅占 Token。
解法使用RecursiveCharacterTextSplitter并设置Overlap (重叠)。
比如每块 500 字块与块之间重叠 50 字保证句子没被切断。
混合检索 (Hybrid Search)问题用户搜具体的“错误码 10045”。
向量搜索可能找出一堆“错误”、“异常”相关的文档但偏偏漏了包含“10045”这个数字的文档因为向量关注的是语义对精确数字有时不敏感。
解法向量检索 (语义) 关键词检索 (BM
同时进行然后使用RRF (Reciprocal Rank Fusion)算法对结果进行加权重新排序。
元数据过滤 (Metadata Filtering)问题你存了全公司的文档。
但“财务部”的文档不能被“研发部”的人搜到。
解法在存向量时写入 Metadata{dept: finance}。
在查询向量库时带上filter: dept finance。
先过滤再做向量近似搜索。
总结❤️从向量到向量数据库再到RAG本质上是我们逃出了结构化思维对数据处理方式的一次升维向量是数据的语义压缩。
向量数据库是语义数据的高性能索引。
RAG是连接静态数据与动态智能的桥梁。
对于 Java/Go 开发者来说现在的机会在于不要只盯着 LLM 的 API 调用而是去建设高质量的数据管道 (Data Pipeline)。
因为在 RAG 架构中检索的质量数据切得好不好、搜得准不准直接决定了最终回答的质量。
学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。
全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取
640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。
无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取
AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。
这些大型预训练模型如GPT-
BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。
那以下这些PDF籍就是非常不错的学习资源。
因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取