33 篇博文 含有标签「vector-search」

一个用户问你的助手，“这季度我们的退款政策有什么变化？”系统返回了一个当前退款政策的、格式良好的自信总结。用户点点头，关闭聊天，并根据一个与他们提出的问题完全无关的信息采取行动。你的评测套件（eval suite）没有捕捉到这一点。你的忠实度指标（faithfulness metric）没有标记它。检索看起来很完美——它返回了高度相关的分块（chunks）。合成看起来也很完美——它引用了它使用的每个分块。唯一的问题是，问题是关于 变化 的，而你的索引没有变化的概念。

这是向量相似度检索无法通过调优修复的失败模式。同一文档的两个版本具有几乎相同的嵌入（embeddings）——这就是好的嵌入所 做 的，它们将语义等效的文本折叠到同一个邻域中。因此，当你问“什么改了”时，检索器返回其中一个版本，LLM 总结该版本，而答案在沉默中成为了“什么都没变”的幻觉。用户无法察觉。你的评测集可能也无法察觉，因为你的评测集是围绕“什么是 X”的问题构建的，而不是“现在 X 有什么不同”。

我建议的一个团队花了两个月时间在其 RAG 流水中不断更换 LLM。从 Claude 到 GPT，再到 Gemini，最后又换了回来。每一次更换都能让幻觉率降低几个百分点，但从未在关键指标上有所进展：他们的支持代理找到正确知识库文章的概率仍然不到 60%。他们调优的层级错了。检索器返回的是无关的文本块，而无论 LLM 多聪明，都无法根据检索器从未呈现过的文档来回答问题。

嵌入模型是 RAG 系统中决定 LLM 甚至“被允许”看到什么的部分。它描绘了语料库的几何结构——即在向量空间中，哪些文档会落在哪些查询附近。一旦这种几何结构出错，LLM 就只是一个对错误上下文侃侃而谈的自信叙述者。换一个更聪明的 LLM 通常只会让回答更显“文采”，而不会让回答更准确。

大多数团队在生产环境中第一次更换嵌入模型（embedding model）时，都会将其视为批处理作业。重新运行嵌入器，构建新索引，切换别名，然后部署。延迟保持正常。错误率为零。每个查询都有结果。然而，检索质量会在数周内悄悄下降，而没人察觉。因为症状是“用户抱怨答案感觉不对”，而不是监控面板上的红报警报。

这不仅仅是部署问题，而是一个团队决定盲目进行的架构迁移（schema migration）。旧的嵌入空间和新的嵌入空间是不同的参考系；以前表示“这两个段落关于同一个话题”的余弦几何（cosine geometry）在数值置信度上不再具有相同的含义。以前聚集在一起的文档和查询会以非均匀的方式漂移。在旧分布上训练的重排序器（re-rankers）会开始处理那些不再符合其学习规律的样本。对逐点相关性（pointwise relevance）评分正常的评估套件会漏掉这一切，因为没有任何单个文档移动得太远，但整个图谱发生了旋转。

如果将这种更换视为数据库迁移，几乎所有出错的情况都是可以预防的。如果将其视为批处理作业，那么回归（regressions）就会按照无人负责的进度表悄然降临。

向量索引即便有约 10% 的误差，也没人会惊慌。但知识图谱如果缺失了一条边，就可能导致有人向监管机构提交一份错误的答案。从数据工程组织的架构图来看，这两种故障模式如出一辙——都被归类为“索引陈旧”——并且它们共用同一个变更数据捕获（CDC）流水线，具有相同的延迟容忍度。流水线的规格是根据向量负载确定的，因为向量是更“大声”的消费者。图谱默默地继承了这些默认设置，而这种沉默本身就是 bug。

向量检索和图谱检索在数据陈旧时的失败表现截然不同。将它们视为同一种延迟问题，会导致你构建出的系统虽然在 RAG 基准测试中得分很高，但在多跳查询中却会产生隐蔽的错误——当然，这种“隐蔽错误”往往是用户最后才会察觉到的。解决方案不是更快的流水线，而是要认识到“陈旧”具有两种不同的含义，为每种边类别设计新鲜度分层，并在监管机构发现之前，通过评估机制捕捉到这种差异。

从任何成熟的 RAG 系统中提取一周的检索日志，并按分块（chunks）被返回的频率进行排序。其分布形态几乎总是相同的：一小部分分块出现在数千次查询中，而语料库中的绝大多数内容仅出现几次，甚至从未出现过。系统没有故障。它正在精准地执行索引构建时的预期功能 —— 而这恰恰是问题所在。

这就是向量检索中的流行度偏差（popularity bias），而且随着语料库的增长，这种情况会变得更加严重。少数分块变成了“引力井”，在互不相关的查询中频频胜出，而长尾内容则悄然消失在 top-k 截断值之下。你的 RAG 系统开始让人感觉“平庸” —— 用户提出具体问题，得到的回答听起来却像是为别人写的一样。等到产品部门开始投诉时，这种分布不均的情况往往已经持续数周了。

向量搜索已成为 RAG 系统的默认检索原语。嵌入你的文档，嵌入查询，查找最近邻 —— 这一过程简单、快速，且对于大多数问题效果惊人。但在生产环境部署中，开发者往往会遇到同样的瓶颈：某些查询尽管相似度得分很高，返回的却是垃圾结果；某些多文档推理任务会无声无息地失败；随着复杂度的增加，某些实体密集型查询会退化为随机噪声。

问题不在于嵌入质量或索引大小，而在于语义相似性对于一大部分检索问题来说是错误的抽象方式。知识图谱并不是向量搜索的替代品 —— 它们解决的是结构完全不同的问题。理解哪些问题属于哪种工具，是区分脆弱的 RAG 流水线与能在生产环境中稳健运行的系统的关键。

当 RAG 系统返回错误答案时，事后分析几乎总是聚焦于同一批嫌疑人：检索查询、相似度阈值、重排序器、提示词。团队会花好几天调整这些组件，而真正的原因却静静地躺在索引流水线里无人触碰。失败早在几周前就已发生——那时有人拍板决定了分块大小。

大多数 RAG 质量问题是架构性的，而非运营性的。它们源于索引时做出的决策，这些决策会悄然塑造 LLM 最终能看到的内容。等到用户投诉时，检索系统正在做它被设计好的事——只是那个设计本身就是错的。

你的RAG管道检索了前10个文档，但LLM的答案依然有误。你将检索数量增加到50，结果还是错的。令人沮丧的是：正确的文档一直都在向量数据库里——只是排在第23位。这不是召回率的问题，而是排序的问题，而余弦相似度正是罪魁祸首。

向量搜索在找到语义相邻内容方面做得不错，但"语义相邻"和"对这个具体查询最有用"并不是一回事。余弦相似度衡量的是嵌入空间中两个向量之间的夹角，而这个夹角只能捕捉粗粒度的主题接近度。它无法捕捉查询中特定词语与文档中特定词语之间的细粒度交互——"如何防止缓冲区溢出"与"缓冲区溢出利用技术"在向量层面差异微妙，但对于你的检索系统来说却至关重要。

你的RAG流水线正在返回自信、格式良好的答案。大模型的响应看起来很好。然而用户却不断提交工单，说系统给出了错误信息。产品经理调出相关文档——信息六周前就已经更改，但向量索引仍然反映旧版本。没有任何错误抛出，没有任何告警触发。系统只是悄无声息、毫无察觉地给出了错误答案。

这就是嵌入刷新问题，它最终会咬到大多数生产RAG系统。对生产部署的分析显示，超过60%的RAG故障可追溯到知识库中陈旧或过时的信息——不是错误的提示词，不是检索算法失败，而是向量索引中的内容与源数据真实状态之间的简单错位。大多数AI工程师都是吃了亏才发现这个问题的，而大多数数据工程师早就知道如何预防它。

大多数团队发现自己需要 GraphRAG 时往往已经晚了六个月——在他们已经向用户解释了为什么 AI 搞错了关系、为什么它混淆了两个具有相似嵌入（embeddings）的实体，或者为什么它言之凿凿地引用了一份与实际答案相矛盾的文档之后。Vector RAG 在其擅长的领域确实表现出色。问题在于，团队把它当成了全能选手，并在底层架构已经达到数学上限时，仍不断堆砌检索补丁。

截至 2025 年，只有不到 15% 的企业在生产环境中部署了基于图的检索。这并不是因为技术不成熟。而是因为纯向量 RAG 的失败信号非常微妙：系统在运行，LLM 在响应，只有经过仔细检查才会发现，检索到的上下文虽然看似合理，但却是错误的。

你的 RAG 系统评估看起来还不错。NDCG 尚可接受，演示也能运行。但有一类故障是单一指标评估无法捕捉的：那些你的检索器从未接近过的查询——持续如此，因为你的整个嵌入空间从一开始就没有能力处理它们。

这就是检索单一化。一个嵌入模型、一种相似度度量、一条检索路径——因此也是一套系统性盲点，这些盲点看起来像模型错误、幻觉或用户困惑，直到你真正检查检索层才会发现真相。

解决方法不是更大的模型或更多数据，而是理解不同的查询结构需要不同的检索机制，并构建一个能够停止将一切都路由到同一漏斗中的系统。

你的 RAG 流水线上线六个月后，某些东西悄然改变了。用户没有大声投诉，但对答案的信任度正在下降。反馈评分从 4.2 跌至 3.7，一些支持工单提到了"过时信息"。你的工程师检查日志，没有错误、没有超时、没有明显的回归。检索流水线在你配置的每一个指标上看起来都很健康。

但事实并非如此。它正在腐烂。

检索债务是向量索引中积累的技术性衰退：不再代表当前文档内容的过期嵌入、污染搜索结果的已删除记录产生的墓碑块，以及索引语料库时使用的编码器版本与当前计算查询嵌入的编码器版本之间的语义漂移。与代码腐烂不同，检索债务不会产生堆栈跟踪，它产生的是带有自信引用的微妙错误答案。