171 篇博文 含有标签「rag」

在你的代码库某处，有一行代码看起来像 retriever.search(query, top_k=8)。某位工程师在某个下午写下了那个 8。它从未被团队以外的任何人评审过，从未出现在规范文档中，也从未被重新审视。这一个整数决定了你的上下文窗口中有多少配额分配给了检索到的文档而非对话历史，决定了每次请求的成本，决定了响应速度的感官体验，并且——由于语言模型在长文本下的实际表现——还决定了答案的准确性。

这是一个产品决策。它却被硬编码在一个 f-string 里。

一个支持团队向他们的新 AI 助手提了一个简单的问题：“上周有哪些企业客户提交了工单？”助手给出了一个自信、流利的回答，列出了六个账户。其中五个是正确的。有一个客户在两个月前就已经流失了，而另一个提交了三个工单的企业账户却完全遗漏了。直到一次续约会议谈崩了，才有人发现这个问题。

错误不在于模型，而在于架构。在设计评审的某个环节，一个带有硬性谓词（如方案层级、日期范围、工单计数）的问题被路由到了向量索引。团队因为拥有检索系统，所以就选择了检索。他们将工单记录向量化，将问题向量化，然后试图让余弦相似度（cosine similarity）来完成 WHERE 子句的工作。它做不到，也从来都做不到。

这是生产环境 AI 系统中最常见且讨论最少的故障模式之一：当真正的查询是关系型时，却动用了语义搜索。数据明明整齐地存储在带有外键的行中，答案本可以通过一个 JOIN 轻松获得。结果却经过了嵌入模型，导致精度化为乌有。

一个新的嵌入模型登上了排行榜。它比你 18 个月前发布的模型得分更高，API 只需更改一行代码，甚至维度也一致。有人提了一个工单：“升级嵌入模型”。这看起来就像更换一个日志库一样简单。

事实并非如此。嵌入模型并不是你检索系统的一个普通组件——它就是你检索系统所处的坐标系。更换它并不会改进你的索引，而是会让索引失效。而最残酷的地方在于，系统并不会崩溃。没有异常，没有失败的健康检查。你的搜索只是开始返回微妙不同的结果，而在 RAG 管道中，“微妙不同”意味着不同的文档被喂给了模型，也就意味着不同的答案最终传达给用户。

两个支持用户在短短一分钟内向你的智能体提出了几乎相同的问题。第一个用户问：“我们针对 EU 订单的退款期限是多久？”第二个用户问：“我们针对 US 订单的退款期限是多久？”这两个句子的嵌入向量（embeddings）仅有一丝之差——长度相同，结构相同，只有一个两字母 token 的区别。你的语义缓存经过了相似度阈值的微调（在演示中看起来非常合理），将它们判定为匹配。于是，第二个用户得到了第一个用户的答案。EU 的 14 天冷静期被当作事实，以流利的文字呈现给了一位 US 客户，且没有任何补充说明。

没有人会因此收到报警。缓存返回了 200。延迟表现优异。成本看板显示了一次命中，这正是每个人想要的结果。唯一能说明出了问题的信号是客户根据一项不适用于他们的政策行事——而这个信号在几天后才会通过退款纠纷传来，而不是通过你的监控系统。

正是这种故障模式，让语义缓存与你之前构建过的任何缓存都截然不同。精确匹配缓存可能会过期，但它永远不会 错误——key 要么匹配，要么不匹配。语义缓存则是有意放弃了这种保证。它被设计为能针对从未见过的 key 返回答案，而这种延迟优势的代价是正确性风险，大多数团队从未对这一风险进行过量化。

向量索引感觉就像一个数据库。你向其中写入文档，查询它，它返回结果。但它并不是数据库——它是存储在其他地方的数据的“派生、非规范化副本”。你的事实来源是 wiki、工单系统、CRM 或 PDF 文件夹。嵌入 (embeddings) 是这些事实的投影，冻结在你运行摄取任务 (ingestion job) 的那一刻。

这使得你的向量索引变成了一个缓存。就像所有缓存一样，它会失效。不同之处在于，大多数团队是有意识地构建缓存层，带有 TTL 和失效钩子 (invalidation hook)，而几乎没有人会有意识地将向量索引作为缓存来构建。他们将其构建为“知识库”，然后在它提供三周前就已经过时的知识时感到惊讶。

一个用户询问你的智能体（agent）企业版的当前价格档位。智能体检索了一个分块（chunk），读取并回答：“每月 2,000 美元。” 信心满满，来源明确，格式优美。问题在于价格在四天前已经变了。智能体引用的数字在上周是真实的。它检索到的分块是在变更之前嵌入的，而索引还没有赶上进度。

没人决定让这种情况发生。没有设计评审说“智能体可以根据长达四天前的数据进行回答”。只是有一个每晚或每周运行的重新索引任务，以及一个随心所欲编辑内容的团队，而这两个时钟之间存在一个没人衡量的缺口。那个缺口就是一个服务等级目标（SLO）。无论你是否写下来，它都存在。唯一的问题是你是有意设定它的，还是由于意外继承下来的。

一位客户询问你的支持代理如何执行某项操作。代理检索到了三个相关性评分很高的文档分块，合成了一个自信的答案，并引导客户完成一个五步操作流程。然而，这个流程的最后一步是一个在四个月前就已经不存在的按钮。客户提交了工单。值班工程师调出评估套件，发现结果是绿色的；调出检索追踪，发现结果也是绿色的——模型没有产生幻觉，它忠实地引用了描述产品团队在上个季度发布中重命名的功能的文档。

这就是我想命名的失败模式：不是幻觉，也不是检索未命中，而是幻影库存 (phantom inventory) 问题。你的检索语料库是已不存在的产品界面的快照。向量存储不知道产品发生了变化。评估套件也不知道。唯一能持续捕捉到这一点的系统是支持工单队列，而当工单提交时，客户已经被告知去点击一个并不存在的按钮了。

我最近交流过的一个团队向一家财富 500 强公司的内部法务办公室出售了他们的法律 AI 产品，并在系统提示词中增加了一行：“每一个事实性陈述必须包含对检索源的内联引用。”产品路线图为这种新行为分配了 5% 的 Token 预算缓冲。在该受监管租户上线 60 天后，财务部门标记了每月推理支出激增了 34%。没有人搞坏产品。没有人发布新功能。这项促成交易的合规要求，也悄然改写了其背后的单位经济效益。

这就是检索引用税，几乎每个服务于受监管行业——法律、医疗、金融、有审计约束的企业——的 RAG 系统最终都要支付这笔费用。这笔税收是结构性的，而不是 Bug。它源于引用纪律迫使模型进入了一种不同的生成模式，而且它在客户签署的采购规范中无处可寻。

迁移工单只有一行：“将 Embedding 模型从 v3-small 升级到 v3-large。”新模型在公开基准测试（Benchmark）中胜出 12%。流水线代码改动只有六行 Python。团队预计需要两天的开发时间，加上一个周末就能跑完的重嵌入（Re-embedding）任务。两个月后，查重功能的误报率比更换前翻了一倍，“相关项目”栏目悄然变成了废话生成器，语义缓存的命中率更是断崖式下跌，因为在旧空间运行良好的 0.95 阈值在现在几乎匹配不到任何内容。

没人动过这些功能。没人提交过 Bug。这个在迁移计划中被归类为“基础设施”的模型切换，悄无声息地改写了每一个使用相似度得分的业务规则。

一名客服代理告诉用户“根据我们截至今天的最新定价”，并引用了上季度的价格表。系统提示词正确地注入了 today is {current_date}。检索层提取了具有最高时效性评分（freshness score）的文档。模型回答得信心十足。每个组件都严格执行了其规定的任务，但用户得到了一个错误的答案，而值班工程师却无法复现这个问题，因为当他们在晚上 9 点回溯追踪记录（trace）时，“今天”已经变成了不同的一天。

这并不是一个罕见的 Bug。这是一种几乎存在于每一个生产级 LLM 流水线中的失效模式，因为“现在”隐式地存在于提示词的五个不同层级中，而这些层级是由不同的人在不同时间、针对不同的“现在”定义编写的。只要请求是从前端用户会话同步运行的，这些层级通常能达成一致。一旦请求被重放用于调试、在夜间进行批处理、在固定于 3 月的评估框架（eval harness）中运行，或者被排队并在一个小时后消费，各层级就开始产生分歧——模型产生了一个在提示词内部逻辑自洽但在外部环境中错误的答案。

一名用户询问你的助手公司的育儿假政策。机器人返回了 12 周，并附带了引用。被引用的文档是 2023 年的正确答案；而人力资源部门在上个季度发布了更新，将其延长到了 16 周。这两个版本都在你的知识库中。由于旧版页面的表述更简洁且模棱两可的内容较少，余弦相似度给 2023 年版本的评分是 0.87，而 2024 年版本的评分是 0.84。较新的文档以 3 个百分点的差距落败，用户得到了一个看似经过审计的错误答案。

这就是时效性与相关性的权衡（freshness-relevance tradeoff），令人不安的是，这在查询时并没有完美的解决方案。如果你增加时效性的权重，检索结果就会偏向于昨天刚编辑过的任何内容——在大多数知识库中，这些通常是高频变动的嘈杂区域，不应作为事实来源。如果你不增加时效性的权重，你给出的答案将基于几个月前就被取代的文档。没有一个全局按钮能同时搞定这两点，大多数团队只有在一些令人尴尬的答案绕过评估套件泄露出去后，才会发现这个问题。

一个用户询问你的支持机器人退款期限何时结束。机器人带着愉快的自信给出了“60 天”的回答并附带了引用。然而，那个写着“60 天”的策略页面早在三个月前就从 CMS 中删除了。新策略是 14 天。直到有客户投诉，你的团队中才有人意识到机器人出错了。

这就是检索级联失效（retrieval cascade failure）：文档已从事实源中消失，但其嵌入（embedding）仍留在索引中，在余弦相似度排名中依然靠前，不断为模型提供一个“幽灵”。RAG 流水线将向量索引视为源内容的缓存，但大多数团队在构建缓存时并没有构建失效机制。插入操作得到了所有的工程关注，而删除操作只得到了一个 TODO 注释。