1. 先把 Embedding 和向量化这件事想明白
做企业级智能问答系统，你早晚会撞上那一面墙：关键词匹配搜不到同义表述，正则规则写到你手软，明明文档里写了，用户换个问法就答不出来。真正把这个问题拆掉的，不是后面接的大模型有多大，而是 Embedding 与向量化这一层有没有做扎实。我在企业知识库项目里反复验证过，凡是召回效果差的，几乎都能溯源到向量化环节。
很多同学一听到 Embedding 就觉得是“某个模型把文字变成长数组”，这句话方向对，但理解得太浅。Embedding 的本质是把语言映射到一个高维语义空间，让语义相近的句子在空间里距离更近。比如“如何申请年假”和“休假申请流程是什么”字面差异很大，但在语义空间里向量距离很近。这个特性，决定了你在向量库里做相似度检索时，召回的不是“字面相同”，而是“意思相近”。
1.1 Embedding 到底帮你解决了什么问题
我先说结论：Embedding 解决的是“语义召回”的问题，而不是“语义理解”的问题。它不负责推理，不负责总结，只负责把文本变成一种方便计算相似度的数字表示。
在企业问答系统里，用户的问题往往是非标准表达。比如员工会问“我入职一年能休几天假”，而后台手册里写的是“职工累计工作已满 1 年不满 10 年的，年休假 5 天”。两者没有几个共同词，传统 BM25 检索很难把它们关联起来。但如果你把手册按段落切开、逐段转成向量，再把用户问题也转成向量，通过余弦相似度找出 TopN 段落，就能把这条手册捞出来，交给后续大模型生成回答。
这个方案的好处是显而易见的：不需要维护同义词表、不需要写几十条命中规则、不需要人工给每个文档打标签。你只需要分块、向量化、建索引、检索，剩下的语义匹配能力交给模型。换个更直白的说法：Embedding 像是给每个片段做了“语义身份证”，向量数据库则是那个能按语义身份证快速找人的系统。
1.2 一条完整的企业知识库向量化链路
我在项目里沉淀下来的标准链路是五段式：数据清洗、文档切块、向量化、入库存储、检索召回。
数据清洗负责把格式垃圾和语义干扰清理掉，比如 PDF 里残留的页眉页脚、表格里的换行、扫描件的乱码；文档切块负责把长文档切成适合向量化的语义单元；向量化就是把每个文本片段送入 Embedding 模型，得到向量；入库存储要把向量和原始文本、元数据一起放进向量数据库；检索召回则是把用户问题向量化后，在库里做近似最近邻搜索。
这条链路看上去不复杂，但每一段都有坑。后面我会逐个拆开讲，尤其是分块和入库参数这两块，属于“看着简单，实操全是细节”的环节。先把整体框架记住，后面才好对号入座。
2. Embedding 模型选型，别让排行榜替你决策
模型选型是整个向量化实战里最容易冲动的一步。我看到太多同学一上来就去刷 embedding模型排行，直接把第一名下载下来跑，结果在自己的业务数据集上效果并不理想，又回头换模型，反复折腾。这不是排行榜的问题，而是你把它用错了。
2.1 第一件事：先搞清楚自己的文本长什么样
选模型之前，先问自己三个问题：文本以中文为主还是中英混合？文本是短片段还是长文档？有没有明显的垂直领域术语？
如果是纯中文知识库，优先考虑中文本地化做得好的模型。像 BGE 系列、M3E 系列这类中文模型，它们在中文语义上的表现通常比通用英文模型更稳，因为训练语料里中文占比高。如果是代码、公告、技术文档这种中英混杂的场景，那就要看模型是否支持多语言，而不是只看中文榜单分数。
如果文本属于法律、医疗、金融这类专有名词密集的领域，模型有没有在相关语料上做过训练，差距会非常大。泛化模型很容易把“结算”和“清算”当作同义，但在金融文本里这两个词意思是不同的。这时候你需要拿自己的一批真实语料做小规模测试，而不是直接信榜单。
2.2 siglip2 这类多模态向量模型带来什么启发
近期我关注到 siglip2 向量化相关的讨论变多了。siglip2 这类模型的定位是跨模态对齐，它能把文本和图像放到同一个向量空间里，所以它带来一个非常有意思的启发：向量化不一定只是文本的专属。
在企业场景里，很多知识不是纯洁文本，而是包含截图的系统操作手册、带流程图的制度文件、产品界面截图等。如果问答系统只能读文字，这些信息就丢了。如果你引入多模态 Embedding 模型，让图像描述也能参与语义检索，就能做到“用户描述一个界面现象，系统召回对应截图”，这个体验提升是单文本模型做不到的。
当然，我目前的项目主力仍然是文本 Embedding 模型，多模态模型作为补充。原因很简单：多模态模型在纯文本场景上未必比专门的文本模型更准，而且训练和服务成本更高。我的建议是，把 siglip2 这类模型当作一个可选项，在确实存在图文检索需求的场景里去验证，而不是为了追热词牺牲稳定性。
2.3 embedding模型排行 的正确打开方式
排行榜可以看，但要看明白它排的是什么。大多数榜单测的是 MTEB 这类通用基准，覆盖分类、检索、聚类、语义相似度等任务。问题在于，这些基准任务和你的企业问答场景很可能不是一回事。榜单第一只能说明它在通用任务上综合能力强，不代表它在你的垂直领域、你的文档风格、你的分块粒度下同样领先。
我建议的用法是：先用排行榜圈定三到五个候选模型，然后用自己手头的一两百条真实问答对做小范围评测。评测方法很简单——把每条问题的标准答案段落混入一批无关段落，看模型能不能把正确答案召回前三。这个结果比任何榜单都有说服力。我过去就被榜单骗过一次，换上自己数据集测试后，原先排名靠后的一个中文模型反而更适合当时的场景。
选型阶段不要花太多时间，一天以内就该结束。模型迭代速度很快，你需要的不是“选一个最强模型”，而是“定一个评测流程”，之后每隔一段时间用同样的评测集重新验证，有更好模型就换嵌入层。这才是持续受益的做法。
3. 向量化工程落地：清洗、分块、批量与增量
选定模型之后，真正的工程量才开始。向量化不是一个“把文本丢进模型”的动作，而是一个需要严格设计的流程。我在实际项目里最深的感受是：向量化的质量上限，在你做数据准备的那一刻就已经决定了。
3.1 数据清洗比你想象的更重要
很多人忽略数据清洗，觉得文档抽出来就切块，切完就向量化。但脏数据会带来两类非常隐蔽的问题：第一类是格式垃圾污染语义，第二类是超长段落导致信息密度不均。
我遇到过一个实际案例：一份制度文档的 PDF 是从网页导出，每一页开头都带着导航栏文字，比如“首页 / 人力资源 / 员工手册 / 休假管理”，这些内容被切进段落后，导致整个片段里检索关键词被导航噪音稀释。还有一份扫描件，OCR 出来大量“囗”“口”等识别错误，向量化之后语义完全跑偏。
我的清洗习惯是：先统一转成纯文本并去重，再处理页眉页脚和目录页码，最后针对 OCR 文本做纠错。清洗工具不需要多复杂，Python里用pypdf抽取文本、用正则处理常见噪声，组织好一个清洗管道，尽量自动化。唯一的重点是：清洗规则要可配置、可重复运行，不要靠人工一遍遍改文本。
3.2 文档切块：粒度直接决定召回效果
切块在向量化链路里是最容易被低估的一步。切太粗，一个块里塞了太多主题，向量会被平均成“四不像”；切太细，语义不完整，检索出来是一堆碎片，回答没前没后。
我常用的分块策略是：按标题层级做语义边界，同时限制最大块长度。具体落地时，先用 Markdown 或结构化文档的标题层级把文档切成章节，再把超过限制的章节继续切，优先在段落边界切，实在不行才按句子切。
举个例子，我的默认配置是目标块长度 300 到 500 个 token，重叠 50 到 80 个 token。重叠的目的是避免检索命中断句边缘时丢失上下文。这个数值不是拍脑袋定的，它跟具体模型的最大输入长度有关。一般来说，块长度不要超过模型最长输入的 1/10。如果你的 Embedding 模型最长输入 512 token，那切 400 token 左右的块就差不多了；如果模型支持 8192，那可以适当拉长，但不建议直接用满，长块反而稀释主题。
切块这件事很难一次性做到完美，我一般会在上线后结合查不到答案的案例反推，看是切块粒度导致漏召回，还是召回错误片段导致答非所问。这个后面我会再讲。
3.3 批量向量化、并发控制和增量更新
文档量少的时候怎么跑都好，但一旦到几万甚至几十万条文本片段，批量向量化就必须考虑效率和稳定性了。
批量处理我一般用异步任务队列。把切块结果写入待处理表，后台按批次读取，每批 32 或 64 条送入 Embedding 接口，结果回写数据库。加并发时注意模型服务的 QPS 限制，别一次性打满，否则大量超时重试，反而拖慢整体进度。我踩过的坑是：初版用同步方式逐条向量化，一万个块跑了将近两小时；改成每批 64 条并发后，十分钟就处理完了，差别非常大。
增量更新是另一个容易忽略的问题。知识库是会变的，制度更新、新员工手册发布、产品文档改版，都需要同步刷新向量库。我的做法是给每个文档块记录内容哈希，更新时计算新的哈希，哈希变了才重新向量化和入库，哈希没变就跳过。这样可以省掉大量重复计算，也让新增和修改操作变得可以追踪。
4. 向量数据库选型与索引参数调优
向量化只是把数据变成了向量，真正支撑检索的是向量数据库。这个环节里，选型和索引参数决定了两样东西：检索速度和召回质量。很多人只关心检索速度，忘了索引参数会直接影响召回覆盖率。
4.1 常见向量存储方案怎么选
市面上的向量存储方案大致分三类：原生向量数据库、传统数据库的向量插件、以及基于云服务的托管向量库。
原生向量数据库比如 Milvus、Weaviate、Qdrant，它们为向量检索做了专门优化，支持丰富的索引类型和过滤条件，适合数据量大、检索复杂度高的场景。传统数据库的向量插件比如 PostgreSQL 的 pgvector，适合你已经重度依赖关系型数据库、数据量中等、不想额外维护一套存储系统的团队。云托管向量库则胜在省心，但要注意数据出海的合规问题，以及接口锁定的风险。
我推荐中小团队优先用 pgvector 起步，原因很简单：你可以复用现有数据库，事务、备份、权限管理都有现成方案，业务数据在同一个库里关联查询非常方便。等到了百万级向量以上，再考虑迁移到原生向量数据库。我自己的项目就是从 pgvector 起步，后来因为向量规模增长和要接多租户隔离，才迁移到 Milvus。
4.2 HNSW 索引参数别一上来就照抄默认值
HNSW 是目前最常用的近似最近邻索引，它把向量组织成多层图结构，检索时从顶层随机入口逐步向下层搜索。HNSW 有三个核心参数：M控制每个节点的最大连接数，efConstruction控制建索引时的搜索范围，efSearch控制查询时的候选集大小。
很多人直接采用默认参数，这在千万级数据量以下不会有太大问题，但如果你想压榨性能，就要理解它们之间的权衡。M越大，图连接越密，召回率越高，但内存占用和建索引时间也越高；efConstruction越大，索引质量越高，但建索引越慢；efSearch越大，每次查询越慢，但召回越全。
我过去图省事，efSearch设得很小，结果线上问答召回经常漏。后来我把efSearch从 16 调到 64，召回率明显改善，单次查询延迟从 5 毫秒增加到 20 毫秒，在问答场景里完全可接受。如果你追求更极致的低延迟，可以配合量化技术，压缩向量体积，但这会带来一定精度损失。
4.3 向量维度、距离度量和量化
Embedding 模型输出的向量维度从几百到几千不等。维度越高，单个向量占的空间越大，检索时计算量也越大。所以在选模型时不是维度越高越好，而是够用就好。我自己常用模型维度一般是 768 或 1024，在十几万片段规模下性能完全够用。
距离度量上，主流默认是余弦相似度，适合文本语义场景，因为余弦相似度只关心向量方向，不关心向量长度。如果你用的索引只支持欧氏距离也没关系，在向量做过归一化后，余弦相似度和欧氏距离是等价的顺序关系。这里有个操作细节：无论选哪种度量，建议统一在写入前对向量做归一化，这样能减少后续调参的变量。
量化索引是另一个可以关注的点，通过把每个向量从浮点数压缩成低精度整数来大幅减少内存。但量化意味着信息丢失，如果业务要求高召回率，就不要在量化上过于激进。我的建议是：先用无损方式跑通全链路，再根据内存瓶颈决定要不要量化，永远不要为了省内存牺牲掉核心问答效果。
5. 问答链路整合：从 Query 向量化到重排
向量库和向量化都准备好了，接下来就是拼装问答主链路。这一步很多人犯的错是：以为用户输入问题之后，向量检索拿 Top1 就结束了。真正稳定可商用的系统，至少要考虑召回、重排、兜底三层逻辑。
5.1 先定召回策略，再追求精确
在线链路的第一步是给用户 Query 做向量化。这里有一个细节：Query 的表达和知识库文档切块后的表达往往形态不一样。文档是完整句，用户提问经常是短句、口语化、带错别字。直接把这种 Query 向量化，语义容易被带入沟里。
一个实用的做法是给 Query 做轻量改写再向量化。比如“年假怎么算的我今年刚入职”改写为“新入职员工年假计算规则”，改写不依赖大模型，几条规则就能处理大部分情况。另一个做法是召回阶段同时检索多个 Query 变体，把结果合并取并集，再进重排。这样做的好处是提高召回覆盖率，代价是向量检索次数变多，但企业问答 QPS 不高的话，完全够用。
召回数量也值得设计。强烈不建议只召回 Top1，因为 Top1 的相似度未必最高，而且后续重排模型很可能把更正确的片段顶上。我一般召回 50 到 100 个候选，再交给重排阶段压缩到最终给大模型使用的 3 到 5 个片段。这一步从召回数量上就保证了“宁可多捞，不可错杀”。
5.2 重排不复杂，但很值得做
很多项目直接把向量检索 Top5 拼进提示词，这在前几个 Demo 版本里可以，但上线后你会发现：向量检索相似度高的片段，未必就是最合适的解答片段。
重排阶段我推荐两种方案。第一种是轻量方案：用 BGE-Reranker 这类重排模型，对召回片段和用户 Query 逐个打分，分数高的排前面；第二种是规则方案：结合元数据过滤，比如优先返回规章制度中版本日期较新的，或优先返回指定部门文档。实际业务里两种我总是并行用的，先用规则把明显不该出现的过滤掉，再用重排模型精排。
重排阶段要注意延迟。向量召回 50 个候选，重排模型逐个打分，通常会增加几十毫秒延迟。如果你们的接口对首字延迟有硬性要求，就把候选集从 100 降到 30，重排模型用小版本或量化版本，这些都是可以接受的折衷。
5.3 阈值和兜底：没有哪套检索是完美的
向量相似度不是置信度。哪怕相似度只有 0.5，在特定问题上也可能是最优候选。所以不要再幻想设一个 0.8 的相似度阈值就能过滤垃圾。真正可靠的做法是结合多种信号：相似度、重排得分、关键词命中数量、文档来源可信度，综合判断。
兜底策略也要提前设计。检索结果为空或全部低于预期时，系统不能硬答，得有一个降级路径。我一般处理为：如果重排后的最高得分仍低于阈值，则输出“知识库中暂未找到相关信息”，并把原问题送给人工客服或知识库运营人员。这样系统至少不会一本正经地编答案，企业场景里“不瞎答”比“答得多”更重要。
6. 离线评测、线上监控与我的心得
前面讲的都是建设方法，但真正让系统持续变好的，是评测和监控机制。没有这个机制，你换了模型、改了分块、调了索引，都不知道是变好还是变坏。做企业级问答，这一条必须从一开始就建立起来。
6.1 离线评测集怎么搭才够用
我的经验是先用 200 到 500 条真实问题搭建评测集。每个问题配一个或多个标准答案片段，以及这段答案所在文档块的 ID。评测时把问题向量化，从头构建的向量库里检索出 Top10，看标准答案块是否命中。这个指标用召回率，比如 Hit@5。
光有答案还不够，我还会给每个问题标注难度。比如“简单问题：标准答案里包含问题原词”“困难问题：标准答案里没有问题原词，需要同义改写才能匹配”。评测时分开统计这两类问题的召回率。这样做的好处是：如果你换了一个 Embedding 模型，能立刻看出困难问题召回率是否提升了，避免出现“整体指标没变但困难问题变差”的错觉。
评测集要持续维护。每次上线后，把线上答错的问题沉淀进评测集，并补上正确回复。这个动作看起来繁琐，但积少成多，几个月后你就拥有了一套非常贴近业务的回归测试集，之后再选模型、调参数，都有底气。
6.2 线上监控不能只看接口成功率
问答系统上线后，常规监控指标是接口耗时和成功率。但向量化最需要监控的是隐性质量指标：无结果率、低置信率、badcase 比例。
无结果率是指用户提问后，系统因为召回或重排分数过低而走了兜底路径的比例。无结果率突然变高，大概率是知识库导入了一批异常文本，或者模型服务返回了异常向量。低置信率则要结合重排分数看，如果持续走高，说明当前知识库覆盖度和用户需求出现了偏差。badcase 比例最麻烦，需要做抽样标注。
我建议每天捞取一定量真实 query、召回结果、最终回答，做一次人工抽样检查。不用多，每天 30 到 50 条就够了，重点看到底是因为检索失败还是生成失败导致回答不理想。这个抽样机制比任何自动化指标都更能反映真实体验。
6.3 个人经验与后续扩展方向
做向量化这么多次，我的核心体会是：宁可多花时间在数据清洗和评测集建设上，也不要急着把模型换到最新。因为向量化链条很长，任何一个环节掉了链子，模型再好也体现不出来。反过来，只要基础链路扎实，后续换更强的 Embedding 模型，效果提升是水到渠成的事。
后续扩展方向，我目前在做两件事。一是引入多模态向量能力，把系统操作截图和界面录制纳入检索范围，这是 siglip2 向量化带给我的启发；二是做向量库的分区规划，让不同业务线、不同版本的知识文档在物理上隔离，防止跨部门召回相互干扰。这些方向目前都还在验证中，但思路可以给你参考。
最后再分享一个小技巧：每当你看到用户问的问题在知识库里有明确答案但系统答错时，不要急着调提示词，先沿着“清洗 -> 切块 -> 向量化 -> 检索 -> 重排”链路逐层排查。我记得有一次 badcase 排查了大半天，最后发现是某份 PDF 里有一个不常见的全角逗号，导致切块时把整个段落切断了，两句话被分到了相邻两个块里，语义缺了半边。这种问题，再好的大模型也救不回来。
