向量与向量数据库文字怎么变成可计算的数字作者利威尔xu | CSDN 专栏《RAG 保姆级实战从原理到落地》前言在第三篇《RAG文档切分》里咱把 RAG 的六步流程拆开了讲重点聊了文档切分这个坑最多的环节。切太大检索不准、切太小上下文碎片化切分策略没有标准答案得结合业务场景来定。那切好的文档块接下来怎么变成计算机能检索的东西向量到底是什么为什么文字能算相似度这个专栏一共 6 篇从 RAG 概念、降幻觉武器库、流程与切分、向量与向量库到检索重排与引用溯源、落地坑与评估一路走下来你能完整搞懂 RAG。这篇咱把 RAG 的第三步、第四步拆开来讲——向量化是什么向量数据库怎么选。一、向量是什么在讲 Embedding 之前咱得先搞清楚向量是什么。你可能还记得中学数学里的坐标系。一个点可以用 x 和 y 两个坐标定位比如 (3, 4)。这个点不是随便写的它代表了在平面空间里的一个具体位置。向量就是这个概念的推广。现实中一个地点用经纬度两个数字定位一段文字也可以用一串数字定位——这一串数字就是向量。说白了向量就是高维空间里的坐标。你不用被高维这个词吓住。平面是二维咱眼睛能看到高维只是人脑想象不出来但数学上是一样的道理——每个维度代表一个方向无数个方向叠在一起形成一个空间。Embedding 模型把文字转成向量的时候每个维度代表某种抽象的语义特征。比如第一个维度可能代表正式程度第二个维度代表技术深度第三个维度代表情感正负……具体每个维度代表什么不是人工设定的是模型从海量文本里自己学出来的。768 维、1536 维、3072 维这些数字你可能在Embedding模型的介绍里见过。说白了就是每段文字在这套坐标系里被标注了上千个维度的坐标。维度越高模型能表达的语义越细腻但计算成本也越高。为什么放这段代码让你们看看 Embedding 的基本形态理解输入输出是什么。// 调用 Embedding 模型把文字转成向量funcembedText(textstring)([]float32,error){// 调用 Embedding API把文字转成向量req:map[string]string{text:text}body,err:json.Marshal(req)resp,err:http.Post(embeddingURL,application/json,bytes.NewBuffer(body))deferresp.Body.Close()varresultmap[string]interface{}json.NewDecoder(resp.Body).Decode(result)embedding:result[embedding].([]interface{})vector:make([]float32,len(embedding))fori,v:rangeembedding{vector[i]float32(v.(float64))}returnvector,nil}这段代码在干嘛输入一段文字调用 Embedding API输出一串浮点数——那就是这段文字的向量表示。实际生产中会把请求 batch 化、缓存结果、控制并发这里只展示最基本的数据流。为了代码清晰这里省略了常规的错误处理和相关逻辑实际生产代码中务必加if err ! nil判断。二、Embedding 到底在干什么好向量说完了咱再聊 Embedding。你可能见过这种说法“Embedding 就是把文字映射成向量”。这话没错但有点干巴巴的咱换个更容易记住的比喻。Embedding 就像给每段文字在地图上标一个位置。同一个地图上距离近的地方往往有相似的特点。比如北京市地图里西单、王府井、国贸都是商业区它们在地图上挨得近中关村、上地都是科技区也挨得近。地理位置近说明这些地方在某种维度上相似。Embedding 的地图不是地理地图是语义地图。语义相近的文字在这张地图上的坐标也相近。你问怎么申请退货系统在地图上找到退货流程“退款步骤”售后服务这些文字它们坐标都挨着所以能检索出来。这里有个关键点要讲清楚Embedding 模型不是在理解文字它是在做一种可学习的映射。模型没有真的懂什么叫退货它只是在海量文本里学到了包含退货“退款”售后这些词的句子往往出现在相似的上下文中。所以这些词映射到的坐标就相近。这是一种统计规律不是真正的语义理解——但在实际效果上已经足够用了。再打个口味的比方。川菜馆和湘菜馆在地图上往往挨着因为它们的口味语义相近——都是辣的、重口的。川菜馆和日料店可能隔得远因为一个辣一个清淡口味差异大。Embedding 映射的道理一样语义相近的文字距离近语义相差大的文字距离远。面试官可能追问Embedding 和 one-hot 编码有什么区别答one-hot 编码是给每个词一个唯一编号比如苹果是第 1 号“香蕉是第 2 号。它只管是不是这个词”不管语义。Embedding 是把每个词映射到一个稠密向量语义相近的词向量也相近。one-hot 维度等于词表大小可能几万维Embedding 维度是固定的比如 768 维更紧凑也更能表达语义关系。三、相似度怎么算地图建好了位置标好了接下来要解决一个问题怎么衡量两个文字有多像这就涉及到相似度计算主流方式有两种余弦相似度和欧氏距离。先说余弦相似度。咱把它拆开讲——余弦就是两个向量夹角的余弦值。你可以想象两个点从原点出发指向不同的方向。两个方向越接近夹角越小余弦值越接近 1两个方向越相反夹角越大余弦值越接近 -1。余弦相似度关注的是方向不是长度。一篇长文章和一篇短文章向量长度可能差很多但如果它们讲的是同一个主题方向应该是接近的。再说欧氏距离。欧氏距离就是你初中学的两点间直线距离(3, 4) 到 (0, 0) 的距离是 5。推广到高维空间道理一样。欧氏距离关注的是绝对距离两个点靠得近距离就小。文本检索里余弦相似度更常用。原因是向量的长度受文本长度影响。一篇 1000 字的文章和一篇 100 字的文章向量长度可能差很多但它们的方向更能反映语义。如果你问怎么退货两篇文章都讲退货流程方向应该接近长度不重要。当然这不是绝对的有些场景欧氏距离效果也好。选哪个取决于具体数据和业务场景。面试官可能追问余弦相似度和欧氏距离该用哪个答看场景。余弦相似度关注方向不受长度影响适合文本语义相似度匹配。欧氏距离关注绝对距离适合需要考虑向量大小的场景比如推荐系统中用户和物品的向量。一个经验法则先试余弦相似度如果效果不好再试欧氏距离。为什么放这段代码展示余弦相似度计算的核心思路。// 余弦相似度计算funccosineSimilarity(a,b[]float32)float32{dot:float32(0)// 点积normA:float32(0)// a 的模normB:float32(0)// b 的模fori:0;ilen(a);i{dota[i]*b[i]normAa[i]*a[i]normBb[i]*b[i]}normAsqrt(normA)normBsqrt(normB)ifnormA0||normB0{return0}returndot/(normA*normB)// 余弦相似度}这段代码在干嘛计算两个向量的余弦相似度。核心思路是点积除以两个向量的模的乘积。如果向量方向完全相同余弦值是 1方向完全相反余弦值是 -1正交的话是 0。实际向量库通常有 SIMD 加速的向量计算比循环快得多这里只是示意。为了代码清晰这里省略了常规的错误处理和相关逻辑实际生产代码中务必加if err ! nil判断。四、为什么传统数据库做不了语义检索讲到这儿你可能会问为什么非要用向量数据库MySQL、PostgreSQL 存文本不行吗讲真还真不太行。咱用一个找书的比喻来解释。传统数据库是精确匹配就像按标签找书。你跟图书馆管理员说我要找一本关于退货的书他翻了翻系统找到了标题包含退货的书。但你实际上想问的是退款流程书名叫售后处理指南标签里没有退货两个字。管理员说没有你只能空手而归。这就是传统数据库的局限——字面不匹配就找不到。你搜怎么退钱它找不到退款流程你搜笔记本电脑它找不到手提电脑。中文还有同义词、多义词的问题电脑和计算机是一回事但数据库只会字面匹配。向量检索是语义匹配它找的是意思相近的内容不要求字面相同。你问怎么退钱系统找到的退款流程可能标题里一个相同的字都没有但意思相近向量坐标也相近所以能被检索出来。这个差异决定了为什么需要专门的向量数据库。传统数据库是给人找字向量数据库是给意思找意思。面试官可能追问为什么传统数据库做不了语义检索答因为传统数据库是基于精确匹配的查询条件是包含某个词或者等于某个值。它不理解语义不知道退钱和退款是一回事笔记本电脑和手提电脑指的是同一个东西。向量数据库把文字映射成坐标语义相近的文字坐标也相近通过计算坐标的距离或夹角来找相似内容这才是真正的语义检索。五、向量数据库的作用好现在咱知道向量是什么了也知道相似度怎么算了。但还有一个问题没解决向量太多了怎么办假设你有 100 万条文档每条文档切 10 块就是 1000 万个向量。用户来查询系统要在 1000 万个向量里找最相似的 top-k。如果用遍历算法每个查询都要做 1000 万次相似度计算延迟高到没法用。向量数据库就是来解决这个问题的——如何在海量向量里快速找到最相似的几条。这就像图书馆的索引系统。图书馆的书有几百万册你不可能一本一本翻目录找。索引系统把书按类别、作者、出版社分好类你要找某一类的书直接去那个区域翻几秒钟就找到。向量数据库的索引也是这个作用——把海量向量按某种结构组织好查询的时候不用全量遍历直接在索引里定位最可能的区域。常见的索引结构有 HNSW、IVF、PQ 等等这些名字你可能见过。不用记住算法的细节你只需要知道它们解决的是同一个问题在大规模向量库里快速检索。HNSW 是图索引检索快但内存占用大IVF 是聚类索引先定位到某个簇再细找PQ 是量化索引用近似计算换存储和速度。每种都有取舍实际选型看你的数据规模和延迟要求。这里要特别提一句向量数据库不是替代传统数据库它是补充。元数据还在传统数据库里存——文档 ID、标题、更新时间、作者信息。向量在向量数据库里存。两边配合用检索用向量库找详情用传统库。打个比方向量数据库是图书馆的分类索引系统告诉你你要的书在 A-7 区的第 3 排第 5 本。但索引不告诉你书里写了什么具体内容你还是得去书架上拿书来看。索引和书架各司其职。面试官可能追问向量数据库和传统数据库是什么关系答补充关系不是替代关系。向量数据库擅长语义检索但不适合存结构化的元数据——文档标题、更新时间、作者信息这些存在传统数据库里更合适。向量数据库存向量、计算相似度两边通过文档 ID 关联。实际系统通常是向量库 传统库组合使用各取所长。六、RAG 里向量库怎么配合检索把之前的内容串一下你就明白 RAG 里向量库是怎么工作的了。用户上传一批文档系统先加载、切成小块。第三篇咱讲过这些。切好的每一块经过 Embedding 模型变成一个向量。这就是向量化这一步。向量和原始文本块一一对应存进向量数据库。这就是存储这一步。存的时候向量和文本块是关联的——向量用于检索文本块用于最终生成。用户提问“怎么申请退款”。问题本身也经过 Embedding 模型变成一个查询向量。系统拿着这个查询向量在向量数据库里做相似度检索找到最相似的 top-k 个文档块。这就是检索这一步。检索出来的文档块连同用户的问题一起拼进 Prompt交给大模型生成回答。这就是生成这一步。所以 RAG 的向量化、存储、检索三步就是这么串起来的。切分好的块 → Embedding 成向量 → 存进向量库 → 用户提问 → 查向量库 → 拿文档块 → 生成回答。六步环环相扣向量库是中间的关键枢纽。七、落地常见坑先提一嘴趁这块地盘先给你们打几剂预防针后面第六篇会专门展开。最常见的坑是向量模型选错。Embedding 模型有很多种效果差很多。通用模型在你垂直领域可能表现一般专业领域的模型效果可能更好。选错了模型后面调参都是在坑里打转。还有个坑是维度太高成本爆炸。维度越高越精细但存储成本、计算成本也越高。你 3072 维的向量和 768 维的向量存储空间差 4 倍检索速度也慢很多。不是越高越好够用就行。第三个坑是不归一化导致相似度算错。有些向量在入库前没有做归一化处理导致长度差异大相似度计算结果不准。这个坑很隐蔽容易被忽略。最后一个坑是只靠向量不考虑关键词。向量检索是语义匹配但不是万能的。有些场景关键词匹配更重要比如查订单号、查人名你不能指望语义检索能准确找到。向量检索和关键词检索往往要组合着用。 本章面试要点向量是什么Embedding 在干什么向量是高维空间里的坐标每个维度代表某种抽象语义特征。Embedding 是把文字映射成向量的过程语义相近的文字在向量空间里距离近。Embedding 模型不是真的理解文字它是在做一种可学习的映射让语义相近的文本映射到相近的坐标——这是统计规律不是真正的语义理解但在实际效果上已经够用。余弦相似度和欧氏距离有什么区别该用哪个余弦相似度关注方向不受长度影响适合文本语义匹配欧氏距离关注绝对距离适合需要考虑向量大小的场景。文本检索里余弦相似度更常用因为向量的长度受文本长度影响方向更能反映语义。一个经验法则先试余弦相似度效果不好再试欧氏距离。为什么传统数据库做不了语义检索传统数据库是基于精确匹配的查询退钱找不到退款因为字面不匹配。它不理解语义不知道同义词、多义词的关系。向量数据库把文字映射成坐标语义相近的文字坐标也相近通过计算坐标的距离或夹角来找相似内容这是真正的语义检索。向量数据库的作用是什么和传统数据库什么关系向量数据库解决的是海量向量快速检索的问题——用索引结构如 HNSW、IVF组织向量查询时不用全量遍历。向量数据库不是替代传统数据库是补充——元数据存在传统库向量存在向量库通过文档 ID 关联。索引告诉你书在哪个区域具体内容还是得去书架上拿。向量检索和关键词检索的区别是什么关键词检索是精确匹配字面不符就找不到比如搜退钱找不到退款向量检索是语义匹配搜怎么退钱能找到退款流程即使一个字都不重合。两者各有适用场景查订单号、查人名用关键词搜知识、找相关内容用向量。实际系统往往是两种组合用取长补短。下篇预告第五篇《检索、重排与引用溯源怎么找到真正有用的资料》咱会深入讲 RAG 的第五步——检索。重点聊向量检索怎么调优、Multi-Vector 和 Hybrid Search 是什么、重排模型怎么把检索结果再排一遍、怎么让模型回答时引用原文而不是胡编。如果这篇文章帮你搞懂了向量和向量数据库欢迎点赞、收藏、关注利威尔xu咱们下篇见。你们项目里向量模型用的什么向量数据库选型踩过什么坑评论区聊聊。
