121 篇博文 含有标签「rag」

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

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

你的检索器在 94% 的情况下都能返回正确文档。你的 LLM 在给定良好上下文时能正确回答 96% 的问题。可以上线了。能出什么问题？

把这两个数字相乘：0.94 × 0.96 = 0.90。在不考虑任何边缘情况、提示词格式问题、token 截断，以及检索器与正确文档一起返回的干扰文档之前，你就已经损失了 10% 的查询。但更深层的问题不是这个算术——而是你的单元测试永远不会发现这一点。检索器在隔离测试中通过了。生成器在隔离测试中通过了。失败的是两者的组合，而大多数团队对此没有任何测试。

这就是检索-生成接缝：检索器交付内容与生成器实际能够使用的内容之间的接口。它是生产 RAG 系统中测试最不充分的边界，也是大多数故障的根源。

大多数 RAG 流水线都有一个隐形的准确率天花板，而构建它们的工程师甚至不知道它的存在。你调整分块策略、升级嵌入模型、更换向量数据库——但系统对于某些顽固的查询，依然返回看似合理但微妙错误的文档。检索看起来很合理。LLM 听起来很自信。但下游准确率已悄然进入平台期，无论进行多少提示工程（prompt engineering）都无法突破。

这个差距几乎总能追溯到同一个缺失的部分：Reranker（重排序器）。具体来说，是在第二个检索阶段缺少了交叉编码器（cross-encoder）。这一层在技术上是可选的，但在实践中跳过它的代价很高，而且在大多数 RAG 流水线所遵循的经典“嵌入、索引、查询”教程中，它往往被系统性地忽略了。

你的 LLM 功能已经上线。用户开始问那些涉及时间的问题——"最新政策是什么？""帮我总结本周发生的事""这条信息还是最新的吗？"——模型自信、流畅地回答，却答错了。

模型不知道今天是几号。它从来都不知道。你熟悉的聊天界面让你忘了这件事，因为那些界面在背后悄悄注入了当前日期。但你的 API 集成不会。你发布的系统在不知道自己处于时间轴哪个位置的情况下，仍然在推理时间相关的问题——这是一类 bug，会在你还没想到去找它之前就出现在生产环境里。

你的智能体调用了一个数据库工具。查询返回了8000个Token的原始JSON——嵌套对象、null字段、分页元数据，以及每一行都带有时间戳。智能体只需要其中三个字段。你刚刚为7900个噪音Token付了费，并把它们全部注入上下文，让它们与真正的任务争夺注意力。

这就是工具输出注入问题，也是智能体设计中最被低估的架构决策。大多数团队都是在付出代价后才意识到这一点：演示运行顺畅，生产逐渐退化，却没人能解释为什么模型开始对之前能自信回答的问题开始含糊其辞。

一个团队花了三个月时间为他们的知识智能体（knowledge agent）调优提示词。他们尝试了 GPT-4，接着是 Claude，然后是一个微调模型。他们重写了六次系统提示词，还聘请了一名提示词工程师。智能体却一直在产生幻觉——语气自信、表达流利，但内容是错的。真正的问题最后被发现是向量库中存放了一份 2023 年的 Confluence 导出文件，以及一份充满矛盾、随意的 Slack 归档讨论，两者都在讨论同一话题。模型只是在履行它的职责：综合处理给定的信息。而这些信息本身就是垃圾。

超过 60% 的生产环境 AI 项目失败可以追溯到数据质量、上下文问题或治理失败，而非模型限制。然而，当智能体表现异常时，人们的第一反应几乎总是修改提示词。第二反应是切换模型。第三可能是增加一个重排序器（reranker）。而喂给整个流水线的上游数据库，在浪费了数月工作时间之前，很少会出现在排错清单上。

你的 AI 功能在第三季度上线了。评估结果看起来不错。用户很满意。六个月后，满意度评分下降了 18 分，但你的仪表盘依然显示 99.9% 的可用性和低于 200 毫秒的延迟。没有任何地方看起来坏了。从传统意义上讲，也没有任何地方真的坏了。模型在响应，基础设施很健康。只是这个功能在悄无声息地出错。

这就是生产环境 AI 系统中“时间衰减”（temporal decay）的样子。它不会通过报错来提醒你。它以模型所知与现实世界现状之间的差距形式不断累积——等到你的支持队列反映出这一点时，损害已经持续数月之久。

在 AI 工程领域，一直存在一种固有的假设：获得更好输出的路径是更好的模型。更大的上下文窗口、更新的训练数据、更高的基准测试分数。在实践中，交付最强大 AI 产品的团队通常在做一些不同的事情：他们正在构建流水线（pipelines），由多个专门的组件——检索器（retriever）、重排序器（reranker）、分类器（classifier）、代码解释器（code interpreter）以及一个或多个语言模型——协同工作，处理任何单一模型都无法独立可靠完成的任务。

这种架构模式有一个名字——复合 AI 系统（compound AI systems）——它现在是生产级 AI 的主导范式。了解如何正确构建这些系统，以及在构建不当时它们会在哪里失效，是当今应用 AI 工程中最重要的技能之一。

当 RAG 系统返回错误答案时，事后分析几乎总是聚焦于同一批嫌疑人：检索查询、相似度阈值、重排序器、提示词。团队会花好几天调整这些组件，而真正的原因却静静地躺在索引流水线里无人触碰。失败早在几周前就已发生——那时有人拍板决定了分块大小。

大多数 RAG 质量问题是架构性的，而非运营性的。它们源于索引时做出的决策，这些决策会悄然塑造 LLM 最终能看到的内容。等到用户投诉时，检索系统正在做它被设计好的事——只是那个设计本身就是错的。

你的RAG管道检索了前10个文档，但LLM的答案依然有误。你将检索数量增加到50，结果还是错的。令人沮丧的是：正确的文档一直都在向量数据库里——只是排在第23位。这不是召回率的问题，而是排序的问题，而余弦相似度正是罪魁祸首。

向量搜索在找到语义相邻内容方面做得不错，但"语义相邻"和"对这个具体查询最有用"并不是一回事。余弦相似度衡量的是嵌入空间中两个向量之间的夹角，而这个夹角只能捕捉粗粒度的主题接近度。它无法捕捉查询中特定词语与文档中特定词语之间的细粒度交互——"如何防止缓冲区溢出"与"缓冲区溢出利用技术"在向量层面差异微妙，但对于你的检索系统来说却至关重要。

当数据变得嘈杂时，你的梯度提升模型会礼貌地退化。准确率下降，精确率下降，监控告警触发，值班工程师知道该去哪里排查。LLM则不会这样。向LLM输入降级、陈旧或格式错误的数据，它产生的输出流畅、自信、听起来权威——但部分甚至完全是错的——而下游消费该输出的系统根本无从分辨。

这就是数据质量税：当劣质数据进入LLM管道时，你付出的复利代价——不是以低置信度分数的形式，而是以披着事实语法的幻觉来呈现。

你的 RAG 系统运行正常。延迟处于常规水平。错误率为零。但一位询问“加州雇佣法”的用户却不断得到关于房地产的搜索结果 —— 而你的日志显示一切正常。

这就是嵌入漂移（embedding drift）在作祟：这是一种不会抛出异常、不会导致错误率飙升，也不会出现在标准可观测性仪表盘上的检索失效模式。当你的向量数据库积累了在不同条件下生成的嵌入时 —— 比如不同的模型版本、不同的分块规则、不同的预处理流水线 —— 向量开始指向不兼容的方向，这种情况就会发生。系统仍在处理请求，但语义坐标已不再对齐，检索质量在数周或数月内悄然恶化。