178 篇博文 含有标签「rag」

你的 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 有什么不同”。