163 篇博文 含有标签「rag」

迁移工单只有一行：“将 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）提供商更新了模型。你的整个向量索引——那些费尽心力嵌入的数百万个文档——现在填充的是来自一套坐标系统的向量，而这套系统与你的查询编码器生成的向量已不再匹配。结果不是系统崩溃，而是不可见的垃圾数据。

当你的 LLM 智能体失败时，最诱人的事情莫过于问它为什么。它会给出流畅、具体、看似充满自我意识的回答。它可能会说："我误解了用户的意图，检索了关于 X 的文档，而实际上应该定向到 Y。"听起来就像是根本原因。你把它记下来，打开提示编辑器，然后花四十分钟追查一个错误的问题。

这就是 LLM 自我调试的核心陷阱。模型的解释和模型实际的失败机制是两回事。有时两者重叠，但经常并不重合。在采取行动之前判断自己处于哪种情况，是区分快速调试和昂贵弯路的关键所在。

你的团队刚刚花了三周时间优化推理。你们换成了量化模型，调整了批处理策略，成功缩短了 12% 的首字延迟 (TTFT)，然后上线了。接着你查看了实际的面向用户的延迟，发现几乎没有变化。

这就是“推理陷阱”。它是 LLM 应用中最常见的性能分析失效模式，其发生的原因是工程师们习惯于测量那些容易测量的指标——GPU 利用率、推理吞吐量、每秒 Token 数 (TPS)——而不是真正缓慢的部分。在一个典型的 RAG 流水线中，如果包含所有涉及 GPU 的环节，推理大约占延迟的 80%。但剩下的 20% 通常分布在六七个没人追踪的阶段中。孤立地看，每一项似乎都很小，但它们共同占据了主要的优化空间。