141 篇博文 含有标签「rag」

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

这就是我想命名的失败模式：不是幻觉，也不是检索未命中，而是幻影库存 (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 注释。

五份精心设计的文档。260 万条记录的语料库。操纵特定 AI 响应的成功率高达 97%。这是来自 PoisonedRAG 的基准测试结果，该研究发表于 USENIX Security 2025 —— 而且这种攻击不需要模型访问权限，不需要在推理阶段进行提示词注入，甚至不需要与系统进行任何直接交互。攻击者只需向知识库贡献内容即可。

如果你的 RAG 系统允许用户添加内容 —— 服务台工单、Wiki 编辑、客户反馈、共享笔记 —— 那么你已经发布了攻击载体。问题在于你是否也同步发布了防御机制。

你的 RAG 管道在评估集上达到了 80% 的检索准确率。团队将其发布。三周后，一位客户抱怨说，系统在回答关于产品遗留集成的某些问题时，给出的答案完全错误，表现得却非常有信心。你进行了调查，将该查询输入你的管道，它检索到了完全相关的文档——但只是针对一般主题。而那三个涵盖了遗留集成边缘情况的特定文档就躺在你的语料库里，却从未被检索出来。

那 80% 的数字是真实的。但作为刚才所发生情况的信号，它几乎毫无用处。

大多数构建 AI 编程助手的团队都会采用与文档检索相同的现成 RAG 流水线：根据 token 数量对源文件进行分块（chunking），对块进行嵌入（embedding），将其存储在向量数据库中，并通过语义相似性进行查询。这种流水线在处理散文（prose）时表现良好。但在处理代码时，它会悄无声息地失败——而且这些失败很难在聚合指标中显现，因为检索到的代码块看起来似乎合情合理，直到模型生成了错误返回类型的代码、调用了签名错误的函数，或者遗漏了调用图中三层之后才存在的依赖项。

问题不在于嵌入模型或向量数据库，而在于分块策略。代码不是散文。它具有结构属性——依赖图、调用链、类型签名、作用域层级——而基于 token 的分块在检索器看到它们之前就破坏了这些属性。修复这个问题需要重新思考在进入嵌入步骤之前如何分解代码。

同一家公司的两位分析师都问了你的 AI 助手同一个问题："我们 Q3 的客户流失率是多少？"一个人得到的是 4.2%，另一个人得到的是 4.8%。两个答案都没有错——他们只是在不同的时间、不同的会话上下文中进行了查询，检索索引对略有不同的数据块进行了排名。AI 自信地回答了两个问题，没有任何保留，没有标记任何差异。两位分析师带着不同的数字走进了同一个会议，而你的工具刚刚变成了一个负担。

这就是跨用户一致性问题，也是企业 AI 部署悄然失去信任最常见的原因之一。这种失败并非经典意义上的幻觉——没有编造任何事实。失败在于：你的系统在规模上是非确定性的，而这种非确定性在两个用户互相对比结果之前是不可见的。

大多数构建 RAG 系统的团队在第一个月都花在流水线（pipeline）上——分块策略、嵌入模型选择、向量数据库配置、检索微调。他们让系统跑通了。演示顺利通过。利益相关者印象深刻。

六个月后，系统开始悄无声息地退化。支持工单提到了错误的流程。机器人引用了一个已经在第三季度停用的价格档位。客户得到了关于一个在他们注册前就已弃用的产品功能的肯定回答。流水线没问题，问题出在知识库上。

你花了数周时间构建检索流水线。分块策略已调整，相似度阈值已校准，用户反馈看起来很积极。然后，在某个周一的早晨，在你没有任何部署的情况下，检索质量开始下降。以前能搜出正确文档的查询，现在返回的却是关联度极低的噪音。没有错误日志。没有异常。流水线运行顺畅。

发生变化的是你的嵌入（Embedding）提供商更新了模型。你的整个向量索引——那些费尽心力嵌入的数百万个文档——现在填充的是来自一套坐标系统的向量，而这套系统与你的查询编码器生成的向量已不再匹配。结果不是系统崩溃，而是不可见的垃圾数据。