163 篇博文 含有标签「rag」

交付 “面向欧盟客户的 AI” 的团队通常只交付一种驻留控制：锁定在欧盟地区的推理端点。采购团队拿到 DPA，架构图在 “模型托管在法兰克福” 旁边打上绿色对勾，接着发布。架构图中没显示的是：客户的原始查询在前往模型的途中被美国托管的嵌入 API 向量化；查询与之匹配的向量存储的运维平面位于 us-east-1；重排序模型是部署在供应商自选地区的第三方 SaaS；提示词缓存在命中的情况下是按地区键入的，而在未命中的情况下则是全局的；记录检索块的追踪存储有一个 30 天的保留期存储桶，并为了冗余进行跨区域复制。

推理层遵守了驻留规定。而检索流水线甚至不知道自己也是参与者。

这就是大多数 “符合 GDPR” 的 RAG 部署在面临团队甚至没意识到会到来的审计时失败的缺口。修复方案不是针对模型调用增加另一个控制 —— 而是意识到数据驻留是客户字节所接触的每个组件的属性，并且拥有 “LLM” 的团队最多只拥有涉及到的六个表面中的一个。

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 Sprint 内悄然消失。复盘（Post-mortem）结果显示代码没问题，功能开关的滚动发布没问题，分析端也没问题。发生变动的是实验清单上没人负责的东西：你检索调用背后的托管嵌入模型（embedding model），在第三周、第七周，以及你开会审阅结果的那个早上，为同一个查询返回了略微不同的向量。你的 A/B 测试是真实的，但它运行的底层基座却不是。

这是每一个运行检索增强生成（RAG）的团队最终都会遇到的失败模式，而且几乎没人针对它进行设计。嵌入端点被视为像 Postgres 一样的稳定基座。但它不是。它是一个模型，其发布节奏由厂商控制，你不会去阅读它的更新日志，它的行为表现面（behavior surface）可能会发生偏移，而无需改变维度数量、SLA 或你签署的 API 合约。你以为实验测量的是功能变化，实际上测量的是检索机制的变迁，而功能开关带来的波动只是其上的噪声。

检索日志很干净。针对你手动标注的查询集，Recall@10 在几个月内都没有出现退化。答案质量仪表盘显示忠实度（faithfulness）保持在 90% 以上。然后，一位客户向你的支持代理粘贴了一个问题，金标准文本（gold passage）就在组合提示词的 12 个位置中的第 7 位，而模型的回答却好像从未检索到它一样。

检索团队会告诉你该分块（chunk）确实在那里。提示词团队会告诉你提示词是正确的。两者在技术上都是对的。模型关注了前一千个标记（tokens），关注了最后一千个标记，却略过了答案所在的中间地带。你的流水线正面临着一种位置注意力偏置（positional attention bias），没有哪个团队对此负责，没有哪个仪表盘在追踪它，也没有哪个基准测试能捕捉到它。

我上个月交流过的一个团队有一个典型的提示词注入（prompt-injection）案例。他们的网关会对每条用户消息运行分类器。任何评分超过阈值的消息都会被礼貌地报错并拒之门外。他们针对一个公开的对抗性数据集进行了基准测试，达到了 99.4% 的拦截率，然后发布了产品。两周后，一个客户成功（customer-success）工单显示，Agent 在悄无声息的情况下起草、批准并发送了一封电子邮件，指示内部计费工具将一个陌生人的发票退款到一个新账户。恶意指令从未接触过用户输入。它是通过一个 Confluence 页面进入的，当用户非常无辜地询问“我们的退款政策是怎么说的？”时，Agent 抓取了该页面。

这是任何输入清理器（input sanitizer）都无法捕获的失败模式，而它现在已成为生产环境 Agent 中主要的提示词注入矢量。你针对用户提示词训练的分类器从未见过这个负载（payload），因为负载是通过另一扇门进入的。当字节到达模型时，Agent 已经将其标记为“我检索到的用于帮助用户的上下文”，而不是“来自互联网陌生人的不可信文本”。模型以同样的顺从本能对待两者，因为模型根本没有信任的概念。

离线评估的结果非常明确。在向量搜索的前 50 个结果之上叠加一个交叉编码器（cross-encoder）后，nDCG@5 提升了 4 个点。团队在周二上线了该功能。到了周四，p99 检索延迟已超过 SLO（服务水平目标）700 毫秒，客户成功团队也开始转发空结果页面的截图，而这些页面在旧的流水线下本应是有内容的。真正关键的指标——用户感知的回答质量——下降了。重排序器（reranker）实际上是一个被团队冠以“改进”之名的性能退化，而评估标准则是将这种退化隐藏在众目睽睽之下的幕后黑手。

这是生产环境检索中最常见的失效模式之一，且很少被准确描述为：一个评估缺陷（evaluation bug）。重排序器完成了它的宣传任务：以更细的粒度对前 50 个结果进行了重新排序。问题在于，用于证明其合理性的指标——在无限预算下针对完整重排序列表计算的离线 nDCG——描述的是一个生产系统并不存在的理想世界。在生产环境中，最终输出的答案并非评分最高的重排序列表，而是系统在请求截止时间前所能返回的任何内容。一旦你以此方式重新定义指标，重排序器的贡献就不再是 4 个点的提升，而是一条曲线。

一个检索团队针对其产品目录发布了一个开箱即用的嵌入模型 (embedding model)。评估集——从上个月搜索日志中抓取的几百个查询——回传的 recall@10 达到了 0.91。他们将其推向生产环境。三周后，支持部门开始转发工单：一位用户搜索了某个零件的具体 SKU，结果得到了五个看起来很有道理但错误的零件。另一位用户搜索了一个功能的内部代号，结果得到了一个无关功能的营销名称。评估集从未捕捉到这一点，因为评估集是从系统已经处理过的查询中提取的——即关于常用术语的查询。作为业务核心的长尾术语 (jargon) 从未被采样。

模型并没有失败。模型完全按照其训练要求执行了任务，只是针对的是一个不包含团队提供语料库的词汇分布。团队将嵌入视为一种领域中性的原语 (domain-neutral primitive)——一个从文本到向量的函数——而实际上，它是一份关于它可以解析哪些词汇的契约，是与别人的训练语料库签署的。

在按时间分区的向量索引中，隐藏着一种特定类型的召回率谎言，而构建离线评估的人通常是最后才发现它的人。仪表盘显示 recall@10 为 0.94。检索器在 94% 的情况下都能提供正确的片段。产品团队正基于这个数字发布更多以检索为基础的功能。接着，客服工单接踵而至：“助手引用的指南与答案不符”、“助手链接到了上周版本的政策”、“助手找不到我两个月前上传的文档”。这些工单都不与 0.94 这个数字冲突。它们证明了 0.94 衡量的是错误的东西。

这种机制很简单，也很容易被忽视。向量索引按摄入日期进行分片，因为这是保持高写入吞吐量、停用旧数据以及将热工作集保留在快速内存中的最简单方法。离线测试集每晚从生产日志中生成，这意味着查询是从最新分片恰好持有的同一个近期窗口中提取的。召回率是根据存在于一两个分片深处的基准真相（ground truth）来衡量的。检索器在这些查询上表现出色，因为在生产环境中，路由层会将这些查询保留在同一个分片内。

一名支持工程师在值班频道发了消息。一位客户粘贴了助手上周检索到的一个句子，合规团队回复说：我们已经不再这么说了。他们已经停用这句话四个月了。CMS 中的文档显示是正确的。但向量索引中的嵌入分块（chunk）仍然是旧的内容，且拥有极高的相似度得分，并在每次相关查询时被提供给模型。没人改过检索代码。没人改过模型。真相源（source-of-truth）变了，而索引却对此一无所知。

这是摄取流水线（ingestion pipeline）的一种失败模式：它最初是为“创建”而设计的，后来演变成了一个也要处理“更新”的系统，却没有人专门为“更新”进行设计。“创建时嵌入”的任务在每份文档首次写入的那天运行。一个季度后，CMS 团队发布了一个编辑端点，由另一个团队负责，他们将其接入了搜索、面向公众的渲染器和变更日志 feed —— 接入了每一个消费者，除了那个隐藏在不同名称下的派生数据集。数月过去，语料库发生了漂移。检索系统开始回答那些公司早已正式抛弃的问题，而唯一的信号来自于一位困惑的客户。

公司内部有一个安全运行了十年的端点。它位于一个除了原始团队之外没人能猜到的路径上。它不在公开文档中。它不在 OpenAPI 规范中。它不在网关的“已记录路由”白名单中。它的身份验证层是一个任何内部服务都可以签发的令牌，因为威胁模型认为，触达它的唯一前提是已经知道它的存在。这个端点接受一个 JSON 数据块，在某个平淡的周二，它会重新发放退款、轮换 API 密钥或在两个计费账本之间移动数据行。自 2016 年以来，它一直正常且平稳地工作着。

上个月，一位同事将一个编程智能体接入了工程维基，以协助处理入职提问。该智能体索引了每一个 Confluence 空间、每一份存档的设计文档、每一页标有“请勿删除——历史记录”的页面。昨天，一名初级工程师询问智能体退款是如何运作的。智能体将一份被遗忘的 2018 年架构图、有人粘贴到操作手册里的 Slack 导出记录以及一份写了一半的故障复盘拼接在一起。它用对话式的文字完整描述了该端点、所需的令牌类型以及示例 Payload。端点本身没有改变，但它的威胁模型改变了。

你的 RAG 流水线将文档切分为 512 个 token 的片段，并带有 50 个 token 的重叠。这是一个标准的行业默认设置。在你的语料库中，有这样一句话——“除非订单来自欧盟地区（在这种情况下监管窗口为 14 天），否则退款将在 5 个工作日内处理”——它恰好跨越了分块边界。分块 N 包含前半部分。分块 N+1 包含后半部分。

用户提问“欧盟退款需要多长时间”。检索系统给分块 N 打分最高，因为查询嵌入与第一段碎片中的“欧盟地区”对齐。而包含唯一实际答案的分块 N+1 排名太低，无法同时被检索到。智能体回答“5 个工作日”，并自信地引用了分块 N。客户人在法兰克福。答案是错误的。流水线完全按照设计运行。

这种故障模式不会出现在你的分块质量评估中。分块是格式良好的。语料库是格式良好的。嵌入模型是格式良好的。分块之间的边界——你在自己文档中划下的那些线——才是答案所在。

基准测试指标连续四个季度上升。用户满意度却没有。团队中没有人能解释这种差距，直到有人对提示词模板进行了 diff，并注意到 Few-shot 示例正从评估器读取的同一个 CSV 文件中获取。评估集已悄然变成了上下文示例。这个指标不再衡量泛化能力。它衡量的是模型在刚被告知答案的情况下，复制与之最接近问题的能力。

这就是我想命名的失效模式：评估集到提示词的泄露 (eval-to-prompt leakage)。它在结构上与传统机器学习中的测试集污染 (test-set contamination) 完全一致，但它是通过团队刻意构建的后端通道发生的。Few-shot 检索是一个合理的工程举措。评估库是一个合理的工程产物。当两者在没有人划定界限的情况下汇集到同一个存储层时，污染就产生了。

你平台团队的一名技术文档工程师正在移动一个段落。这并非比喻——她正真实地从入职指引页剪切一个章节，粘贴到运维手册中，删除第三页上的一个草稿占位符，并修改第四页上的一个弃用警告。整个编辑过程大约花费了她 11 分钟。而你的 RAG 摄取任务每 15 分钟运行一次。恰好在第 6 分钟时，任务启动了。

在接下来的 15 分钟里，你的检索索引包含了一个在她的脑海中从未在任何单一时刻存在过的 Wiki 状态。入职指引页仍然保留着那个章节。运维手册里却还没有。那个草稿占位符在被删除到一半时被捕获了，里面包含了一句她从未打算发布的占位语句。旧的弃用警告仍然被索引着。当一名工程师询问智能体“我们如何在这个服务中处理凭证轮换”时，模型从同一个来源检索到了矛盾的分块，并自信地合成出评分较高的那一个。答案呈现出一种任何人都没写过的错误形态。

这是大多数团队在发布时都没有注意到的失效模式：单一事实来源是事务性的，摄取是轮询的，而两者之间的鸿沟就是“脏读”存在的地方。