163 篇博文 含有标签「rag」

某家产品公司的团队为市场部门构建了一款头脑风暴助手。他们在文档语料库——营销简报、品牌指南、竞品分析——上添加了 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 通常只会让回答更显“文采”，而不会让回答更准确。

大多数智能体内存系统将一个四层的问题压缩成两层，然后在出现破绽时表现得大吃一惊。一个是当溢出上下文窗口时会被截断的会话缓冲区（conversation buffer），另一个是旧内容堆放其中的“长期记忆”向量数据库。那不是内存架构。那只是一个队列和一个杂物抽屉。

如果一个智能体连续三个周一向老用户询问同一个新手引导问题，这并不是因为模型不好，而是因为系统中没有一个地方能保存“该用户跨会话告知我的事情”，并且其生命周期不同于“所有用户告知我的关于产品如何运作的事情”。这是不同的记忆。它们有不同的访问模式、不同的隐私契约以及不同的遗忘规则。将它们混为一谈是架构上的错误——而且这是可以修复的。

一个被标记为“无状态”的工具是运行时无法兑现的承诺。在函数签名的背后，坐落着 Redis 缓存、向量索引、嵌入存储、限流表、记忆层、热路径上的 LRU——其中任何一个都是共享的基底层，一个用户的数据可能会落在另一个用户的响应中。函数是无状态的。系统则不然。在 2026 年，这是我在 Agent 系统中看到的最常见的隐私漏洞，因为几乎没有人对此进行测试。

对于任何开发过经典 Web 应用的人来说，这种漏洞的形式都熟悉得令人沮丧。不安全的直接对象引用（IDOR）曾是 Bug 赏金猎人们十年来的家常便饭：一个请求处理程序接收记录 ID 并返回记录，却不检查调用者是否有权查看。AI 时代的版本是同样的漏洞，但影响范围更广：一个工具调用接收查询并返回数据，却不检查调用者的租户是否拥有该数据。查询是用自然语言表达的。缓存键是一个哈希值。检索是近似的。这些都不能免除你的授权责任，但其中的每一项都让漏洞在代码审查中更难被发现。