171 篇博文 含有标签「rag」

从任何成熟的 RAG 系统中提取一周的检索日志，并按分块（chunks）被返回的频率进行排序。其分布形态几乎总是相同的：一小部分分块出现在数千次查询中，而语料库中的绝大多数内容仅出现几次，甚至从未出现过。系统没有故障。它正在精准地执行索引构建时的预期功能 —— 而这恰恰是问题所在。

这就是向量检索中的流行度偏差（popularity bias），而且随着语料库的增长，这种情况会变得更加严重。少数分块变成了“引力井”，在互不相关的查询中频频胜出，而长尾内容则悄然消失在 top-k 截断值之下。你的 RAG 系统开始让人感觉“平庸” —— 用户提出具体问题，得到的回答听起来却像是为别人写的一样。等到产品部门开始投诉时，这种分布不均的情况往往已经持续数周了。

当检索质量回退（retrieval quality regression）第一次出现在你的值班频道（on-call channel）时，调试路径几乎总是指向一些令人意外的地方。不是嵌入模型（embedding model），不是重排序器（reranker），也不是提示词（prompt）。罪魁祸首通常是对分块器（chunker）的一行改动——比如更换了分词器、调整了边界规则或步幅（stride）——而这行代码是三个冲刺（sprint）前有人合并进预处理 notebook 的。这次修复没有触及任何生产代码。它在夜间重建了索引。而现在，所有租户的准确率都下降了四个百分点。

分块器就是数据库 Schema。你提取的每个字段、划定的每个边界、选择的每个步幅，都定义了存入向量索引的“行”的形状。修改其中任何一项，你就在改变索引的 Schema。而你系统的其他部分——检索逻辑、重排序特征、评估框架、下游提示词——都依赖于这个索引，并假设它是稳定的。但由于分块器通常存在于 notebook 或一个没人将其视为“基础设施”的小型 Python 模块中，这些改动在上线时往往只被当作配置微调，但其爆炸半径却相当于执行了一次 ALTER TABLE。

向用户展示一个带有 AI 答案的界面，且每句话末尾都附有链接，还没等他们读完任何一个引用的段落，他们的信任度就已经飙升。这正是企业级 RAG 的全部营销卖点：“有据可查”、“有源可循”、“可验证”。这也是 AI 工程领域中交付最多、但测试最少的说法。最近的基准测试发现，50% 到 90% 的 LLM 回复并未得到其引用来源的完全支持，有时甚至与来源相矛盾。在对抗性评估集中，最先进模型生成的引用中有高达 57% 是不忠实的：模型根本没有真正使用它指向的文档。这些引用是事后补上去的，目的是为了让模型已经决定给出的答案显得合理。

这不是检索层面的 Bug。即便你拥有完美的检索系统，仍然会得到虚假的引用，因为这种失效是架构性的。生成器先写出文字，然后再缝补链接。这些链接看起来像证据，实则只是装饰。

一张支持工单送达：「你们的 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 流水线与能在生产环境中稳健运行的系统的关键。