108 篇博文 含有标签「rag」

一张支持工单送达：「你们的 AI 对我的保险条款给出了完全错误的建议。」你查看日志，找到了时间戳和用户 ID，最终模型响应也原文呈现在那里。但你根本不知道是哪个提示词版本产生了这条输出、检索步骤取回了哪些上下文片段、中间是否调用过工具，也不知道你过去一个月部署的三个模型版本中究竟是哪个处理了这个请求。你能读到输出，却无法解释它。

这就是归因鸿沟——大多数 AI 团队在首次上线模型功能后六到十八个月都会撞上这道墙。问题不在模型或提示词，而在可观测性基础设施。传统日志记录的是请求-响应对，而 LLM 流水线并非请求-响应对，它是一棵决策树：上下文检索、提示词组装、可选工具调用、模型推理、后处理、条件分支。出现问题时，你需要看到完整的树，而不仅仅是叶子节点。

当 100 万 token 的上下文窗口实现商业化时，许多团队悄然认定，他们已经解决了智能体记忆（agent memory）的问题。当你可以把所有内容都丢进去并让模型自己处理时，为什么还要构建检索系统、管理向量数据库或设计淘汰策略（eviction policy）呢？答案就在你的基础设施账单中。在每天 1 万次交互、拥有 10 万 token 知识库的情况下，这种暴力的上下文内（in-context）方法每天的成本约为 5,000 美元。而处理同样负载的检索增强记忆系统的成本约为每天 333 美元 —— 随着用户群的增长，这 15 倍的差距会产生复利效应。

真正的问题不仅仅是成本。更严重的是，更长的上下文会导致答案质量显著下降。研究一致表明，模型会丢失位于极长输入中间位置的信息；当相关的证据被埋没在无关的代码块（chunks）中时，准确率会如预见般下降；且延迟的攀升会使交互式智能体显得反应迟钝。这种“塞进一切”的方法不仅浪费金钱 —— 它还以牺牲准确性为代价换取了简单化的假象。

Phil Karlton有句名言——"计算机科学中只有两件难事：缓存失效和命名"——这句话诞生于语言模型进入生产之前。将AI加入技术栈后，缓存失效不只是变得更难；它在每一层同时变得更难，而且每一层的原因从根本上不同。

传统缓存存储的是确定性输出：数据库行、渲染的HTML、计算出的价格。当源数据变化时，你使该键失效，下一个请求获取新数据。契约很简单，因为答案是一个事实。

AI缓存存储的是不同的东西：对查询的响应，而这些响应的"正确"答案取决于上下文、时效性、模型行为以及模型所获取的源文档。这里的"陈旧"不意味着过时——它意味着在语义上出错，而你的监控不会发现，直到用户注意到为止。

大多数关于 RAG 质量的讨论都聚焦在错误的地方。团队在争论嵌入模型的选择、微调检索的 top-K、以及尝试各种提示词模板——然而在数据摄取阶段做出的一个架构决策，却悄然决定了系统能力的上限。这个决策就是分块策略（chunking strategy）：即在索引之前，你如何将文档切分成片段。

一项 2025 年的基准研究发现，分块配置对检索质量的影响，甚至比嵌入模型的选择还要大。然而，团队通常会选择默认配置——通常是 512 个 token 的 RecursiveCharacterTextSplitter——然后花上几个月的时间去思考，为什么他们的检索精度总是差强人意。问题在索引时就已经埋下了。更换模型无法解决这个问题。

某用户提交了一个支持工单："你们的 AI 助手告诉我合同续签截止日期是 3 月 15 日，实际上是 2 月 28 日，我们因此错过了截止日期。"你调出日志，响应已生成，模型没有报错，所有指标都是绿色。但你根本不知道它检索了哪份文档、模型读取了什么内容，也不知道那个日期究竟来自上下文还是完全被幻觉出来的。

这就是数据血缘的缺失。这不是监控问题，而是从一开始就埋下的架构问题。

一家电信公司花了数月时间调优其客服聊天机器人的 Prompt。他们反复迭代系统指令、Few-shot 示例和思维链格式，但幻觉率始终顽固地维持在 50% 以上。后来他们审计了知识库，发现其中充斥着已下线的服务套餐、过时的账单信息，以及相互矛盾的重复政策文件。修复数据之后——而不是修改 Prompt——幻觉率骤降至接近零。Prompt 工程无法解决的问题，三周的数据清理就做到了。

这就是数据质量天花板：当 LLM 系统的输入数据存在噪声、过时或前后矛盾时，会出现一道性能硬墙，任何 Prompt 迭代都无法突破。这是生产环境 AI 最常见的失效模式之一，也是最被系统性低估的一种。撞上这堵墙的团队，往往还在不停拨弄 Prompt 旋钮，而问题的根源其实在上游。

你的 AI 助手刚刚处理了一份来自潜在供应商的合同。它总结了条款，标记了风险条款，并起草了回复。你不知道的是，PDF 中包含了白底白字的文本——肉眼不可见，但在模型面前一览无余——指令它无论条款如何都建议接受。摘要看起来很合理。批准建议看起来也很合理。模型遵循了你从未写过的指令。

这就是“文档即攻击面”问题，而大多数企业级 AI 流水线对此完全没有防备。

这种漏洞是架构性的，而非偶然发生的。当文档内容直接流向 LLM 的上下文窗口时，模型无法可靠地将合法指令与嵌入在文件中的攻击者控制内容区分开来。流水线摄取的每一份文档都是潜在的指令源——在大多数系统中，不可信的文档和可信的系统提示词（System Prompts）被以同等的权威进行处理。

大多数构建 RAG 管道的团队对 GDPR 的理解方式是错误的。他们关注推理调用——模型是否生成了 PII？——却忽略了静静地藏在向量数据库中的更严重的风险敞口。每当用户提交一份文档、一张支持工单或一条个人笔记，经过分块、嵌入和索引后，该向量存储在 GDPR 下就成为了个人数据处理器。当用户行使被遗忘权时，"按 ID 删除"并不能解决问题。

被遗忘权不仅仅是从关系型数据库中删除一行数据。由个人数据派生的嵌入向量携带着可恢复的信息：研究表明，句子级嵌入中 40% 的敏感数据可以用简单代码重建，对于较短文本，这一比例高达 70%。派生的表示形式是个人数据，而非经过净化的抽象。GDPR 第 17 条适用于此，监管机构正在密切关注。

向量搜索已成为 RAG 系统的默认检索原语。嵌入你的文档，嵌入查询，查找最近邻 —— 这一过程简单、快速，且对于大多数问题效果惊人。但在生产环境部署中，开发者往往会遇到同样的瓶颈：某些查询尽管相似度得分很高，返回的却是垃圾结果；某些多文档推理任务会无声无息地失败；随着复杂度的增加，某些实体密集型查询会退化为随机噪声。

问题不在于嵌入质量或索引大小，而在于语义相似性对于一大部分检索问题来说是错误的抽象方式。知识图谱并不是向量搜索的替代品 —— 它们解决的是结构完全不同的问题。理解哪些问题属于哪种工具，是区分脆弱的 RAG 流水线与能在生产环境中稳健运行的系统的关键。

你的检索精度提升了。重排分数改善了。生成器的忠实度指标比上个季度更好。然而用户却在抱怨系统越来越差。

这是生产级 AI 工程中最令人困惑的故障模式之一，而且发生频率远超团队预期。当你构建一个复合 AI 系统——检索结果送入重排器，重排器送入生成器，生成器再送入验证器——你就继承了一个根本性的归因问题。端到端质量是唯一真正重要的指标，却也是最难付诸行动的。你无法修复"系统变差了"。你需要修复某个特定组件。而在一个四阶段流水线中，这件事出乎意料地困难。

大多数RAG团队会花数月时间调整分块大小、尝试不同的嵌入模型、争论混合搜索配置。然后他们上线，宣告成功，转身离开。六个月后，用户开始抱怨系统给出错误答案——团队才发现，当初精心构建的索引已经悄然腐化。

索引新鲜度是最后才被解决的问题，通常是在用户投诉事故之后才被重视，而非之前。与检索质量问题会立即在评测中暴露不同，数据陈旧是无声无息的退化：延迟保持平稳，检索看似正常，上下文召回率和忠实度等标准RAG指标评分良好——直到系统自信地返回几个月前就已更新的政策时，才会东窗事发。

你花了数周时间调优嵌入模型。检索精度看起来不错。分块大小、重叠、元数据过滤器——一切都已调整到位。然而用户不断反映，系统"忽略"了它明明能访问的信息。相关段落每次都出现在 top-5 检索结果中，模型就是不用它。

罪魁祸首往往是位置偏差（position bias）：语言模型倾向于过度依赖上下文窗口开头和结尾的信息，而对中间内容的注意力显著不足。在受控实验中，将相关段落从 20 篇文档上下文中的第 1 位移至第 10 位，准确率会下降 30-40 个百分点。你的检索器找到了正确的内容，但排序毁了它。