141 篇博文 含有标签「rag」

大多数构建 LLM 应用的团队最终都会趋向于同一种临时架构：散乱的计算用户摘要的定时任务（cron jobs），每次请求都要重新查询的向量数据库，因延迟到了令人尴尬的地步而添加的 Redis 缓存，以及三个对“用户偏好”定义略有不同的代码库。通常只有在生产事故发生后，他们才会意识到自己构建了什么：一个特征存储（feature store）—— 而且是一个拼凑出来的劣质品。

特征存储是传统机器学习（ML）基础设施中经过实战检验的最成熟模式之一。当有意识地将其应用于 LLM 上下文组装时，它可以消除困扰大多数检索流水线的延迟、成本和一致性问题。本文将解释其原理。

一个团队构建了一个 RAG 系统。英语检索召回率达到了 94%。他们发布了产品。三个月后，来自法国和德国用户的支持工单堆积如山——聊天机器人不断返回无关结果或根本没有结果。工程师们查看他们的监控仪表盘。整体召回率：91%。看起来一切正常。

语料库是英语。嵌入模型（Embedding model）仅支持英语。用户则不然。每一个法语查询都被嵌入到一个向量空间中，而这个空间的设计初衷从未考虑过与它所检索的英语文档共享坐标。余弦相似度并不低——但它们在几何上毫无意义。而且因为聚合指标掩盖了分布问题，在用户大声抱怨之前，这个问题是不可见的。

这就是多语言 RAG 检索差距，也是服务于非英语受众的生产级 AI 系统中最常见的静默失败模式之一。

某家产品公司的团队为市场部门构建了一款头脑风暴助手。他们在文档语料库——营销简报、品牌指南、竞品分析——上添加了 RAG，认为更丰富的上下文会产出更好的创意。三周后，使用率下降了。定性反馈如下：输出"太安全"、"太可预测"、"感觉只是在重混我们现有的东西"。他们从头脑风暴功能中移除了检索。创意改善了，参与度也恢复了。

这种模式在实践中出现的频率远比人们承认的要高。检索增强生成已成为将 LLM 输出锚定到事实的默认架构，对于事实性任务，它当之无愧。但对于生成类任务——创意构思、创意写作、新颖方案生成——添加检索层可能会悄然压低模型产出的上限。这不是因为检索坏了，而恰恰是因为它按照设计在正常运转。

构建 RAG 系统的团队几乎普遍都会遇到同样的瓶颈：他们花一周时间调整 HNSW 索引参数，添加乘积量化（product quantization），将 recall@100 从 0.81 提高到 0.87 —— 然后发现 LLM 的输出质量几乎没有任何改观。投入数月努力所基于的假设是：更好的索引等于更好的回答。事实并非如此。瓶颈从来不在索引上。

真正的卡点在于候选集与上下文窗口（context window）之间的重排序（ranking）步骤。你喂给 LLM 的内容决定了它的输出，而重排序的工作就是确保那些真正相关的文档，而不仅仅是语义上最相似的文档，能够进入上下文。这种区别比你调整的任何 HNSW 配置都更重要。

大多数团队在设计 LLM 智能体时，会花大量精力在工具选择和系统提示措辞上。而几乎没有人认真思考工具返回什么内容。这是一个后果不断叠加的错误——因为工具响应的结构决定了智能体能否有效推理、消耗多少上下文窗口，以及产生幻觉解读的频率。

工具输出 schema 设计是基础设施，而非管道细节。设计失误，你的智能体将以表面上像推理问题的方式失败，而根源其实是 schema 问题。

大多数向量数据库教程只展示如何插入百万条嵌入并运行查询。但它们不会告诉你六个月后会发生什么——当你的语料库已经超出单节点承载能力，你不得不对整个检索管道所依赖的HNSW索引进行分片时，实际情况如何。答案是：供应商在营销材料中刻意回避的事实是，HNSW图在分区方式上存在特殊阻力，会导致无声的召回率下降，而恢复这一质量所需的运营模式会带来真实的复杂性。

本文将深入探讨HNSW分片失效的技术原因、实际中召回率损失的表现，以及团队在超出单节点容量后用于维持检索精度的运营模式。

这是一个在生产环境中比任何人愿意承认的更频繁出现的场景。用户询问 AI 助手当前的利率政策。你的 RAG 系统获取了一份高度相关的美联储文件——语义相似度评分高达 0.91——模型自信地返回了答案。但这个答案已经过时六个月了。RAG 索引上次刷新是在十月份。参数化知识则更为陈旧。一次实时 API 调用本可在 400 毫秒内返回正确的当前数据，但没有人在路由逻辑中加入这样的判断：这个问题的答案允许有多旧？

这种失败不是检索失败，而是时序路由失败。系统在其技术栈的某处确实能够获取正确信息，只是将查询发送到了错误的层级。

有一种故障模式几乎出现在每一个企业 RAG 部署中：一名员工向内部 AI 助手询问薪酬政策相关问题。系统返回了正确、具体的信息——却是从一份该员工本无权查看的 HR 文档中提取的。由于没有人监控检索层，这件事不会立刻让任何人丢掉工作。但那份机密文档已被索引，用户的查询在语义上命中了它，模型忠实地报告了它所找到的内容。

这个错误并不罕见，它是将公共网络 RAG 模式原封不动地应用于私有组织知识却不做架构适配的默认结果。公共网络 RAG 没有访问控制层，因为公共网络内容本身就没有访问限制。而企业数据有——这一约束从根本上改变了整个系统的设计。

摘要失败往往是隐性的。你的系统不会崩溃，日志不会标记错误，生成的文本看起来也很连贯——但在压缩过程中的某个地方，对下游任务至关重要的那个事实被丢掉了。RAG 流水线返回了一个自信的答案。多跳推理器得出了一个结论。客服代理给出了建议。所有这些都基于一个不再包含原始约束、例外或答案所依赖的数据点的摘要。

这就是摘要有效性问题：即“与原文保持一致”的摘要与“保留下游任务所需信息”的摘要之间的差距。大多数团队并没有针对此进行度量。他们上线的流水线只验证了摘要的存在，而不是摘要的完整性。

某团队构建了一个 RAG 功能，测量端到端延迟后发现慢得无法接受，随即开始优化模型调用。他们尝试了更小的模型、批量请求，并调整了 temperature 和 token 上限。经过两个迭代周期，延迟下降了 15%，但功能依然太慢。他们从未测量过的是：在 LLM 收到任何提示词之前，文本分块和嵌入生成就已经耗费了 600ms。

这种模式在分布式系统中普遍到有了专有名词：优化了错误的组件。在 AI 流水线中，LLM 调用显而易见且易于测量，而其之前的所有环节都是隐形的——除非你主动做埋点，否则根本发现不了——而吞吐量恰恰死在那里。

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

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

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

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