163 篇博文 含有标签「rag」

大多数生产环境中的 AI 失败都是“响亮”的。模型返回 5xx 错误。模式验证抛出异常。评估套件在发布前捕获了回归。但还有一类失败是完全无声的——没有错误，没有异常，没有警报触发——因为系统正完全按照设计运行。它只是在处理一个来自 18 个月前的现实快照。

你的 LLM 存在知识截止日期（Knowledge Cutoff）。这个截止日期不仅仅是文档中的一个脚注。它是模型认知的真实情况与实际现实之间日益扩大的鸿沟，而且你每在生产环境中多运行一天旧模型，这种差距就会累积。团队庆祝上线，随后眼睁睁看着用户信任在接下来的六个月里悄然瓦解——世界在前进，而模型却停滞不前。

大多数工程师发现实时网络接地局限性的方式如出一辙：花一个下午接入搜索 API，推上生产，然后接下来三周都在解释为什么延迟高达六秒、近期事件的回答出错，以及用户偶尔被引导到假冒电话号码。

根本假设——搜索增强型 LLM 不过是"带新鲜数据的普通 RAG"——是大多数痛苦的来源。实时网络接地与静态检索几乎没有共同之处，除了"检索"这个词。它是一个披着 NLP 外衣的分布式系统问题。

你的 RAG 系统在上线时运行良好。三个月后，它在三分之一的用户查询中自信地给出了错误答案——而你的追踪日志显示一切正常。检索器在抓取文档，模型在生成回复，整个流水线看起来健康运转。问题是不可见的：向量存储中的每个向量依然有相似度分数，但其中一半已经指向了不再存在的事实。

这就是语料库衰减。它不会抛出异常，不会触发告警，而是在后台悄无声息地积累。等你通过用户投诉或质量下滑察觉到时，你的向量存储已经变成了一个负担。

RAG 系统中存在一种常见的失败模式，数月内都不会被察觉：你的检索器（retriever）返回了错误的文档，但你的生成器（generator）足够擅长即兴发挥，以至于端到端的质量分数依然保持绿色。你不断调整提示词（prompt）。你升级模型。但都无济于事。这个 Bug 存在于上游三层，而你的指标对其视而不见。

这就是检索器评估反模式（retriever eval antipattern）——将整个 RAG 流水线作为一个整体进行评估，这让生成器吸收并隐藏了检索失败。其结果是，你无法区分是“生成器失败”还是“检索器失败”，从而使得系统性的改进几乎变得不可能。

向量搜索正在吞噬世界。基于嵌入（Embedding）的检索现在为各大电商平台的商品搜索提供动力，驱动着 RAG 系统的检索层，并处于大多数 AI 驱动的搜索重写（search rewrites）的核心。但有一类用户，这些系统一直在默默且持续地令其失望：即“浏览型用户”（browsing user）。这并不是因为嵌入模型不好，而是因为它们被设计用来解决一个完全不同的问题。

语义搜索背后的基本假设是：用户带着一个与其需求相近的查询（query）而来。只要在嵌入空间中优化与该查询的邻近度（proximity），你就赢了。但很大一部分真实用户带来的更像是“好奇心”而非具体的查询——对于他们来说，向量空间中的最近邻（nearest neighbors）恰恰是错误的答案。

大多数构建多租户 RAG 系统的团队在身份验证（authentication）上做得很好，但在授权（authorization）上却做得不对。他们验证用户确实是其所声称的身份，然后从共享向量索引中检索文档，并在将结果发送给 LLM 之前对其进行过滤。这种过滤——即检索后过滤——只是“安全防御的假象”（security theater）。当你从列表中移除未授权文档时，它们已经处于模型的上下文窗口中了。

真正的问题比放错位置的过滤器更深。大多数 RAG 系统将文档授权视为摄取时（ingest-time）的关注点（“该用户可以上传此文档吗？”），但完全未能在查询时（query-time）强制执行（“该用户可以查看与此查询匹配的文档吗？”）。这两个检查点之间的差距就是静默数据泄露发生的地方——也是大多数生产事故的根源。

你的语义搜索很可能正在悄然恶化，而你的监控面板对此毫无显示。

没有错误日志，没有 p99 毛刺，没有健康检查失败。查询依然返回结果，余弦相似度评分依然看起来正常。但相关性正在一点一点地悄然下滑——每一个被遗漏的新词，都在拉大用户语言与嵌入模型训练语言之间的距离。

这就是嵌入漂移问题。它之所以难以察觉，正是因为它不产生任何可见的失败信号——只有检索质量的缓慢侵蚀。用户会说产品"越来越没用了"，然后悄悄离开。

Most RAG 的实现都以同样的方式失败：向量搜索检索到了看起来合理但并非用户真正需要的内容，LLM 用自信的辞令对其进行包装，最终用户得到一个大体正确但细节错误的答案。令人沮丧的是，这种失败模式是隐形的 —— 余弦相似度分数看起来很正常，检索到的片段也提到了正确的主题，但答案仍然是错的，因为问题需要跨关系进行推理，而不仅仅是语义上的接近。

向量嵌入 (Vector embeddings) 擅长一件事：找到听起来 像 你查询内容的文本。这是一种强大的能力，涵盖了极广的生产用例。但当问题取决于实体之间如何 连接（而非它们的描述有多匹配）时，这种方式就会出现可预见的失效。对于这类查询，知识图谱 —— 一种你可以通过 Cypher 或 SPARQL 遍历的属性图 —— 不仅仅是一种优化。它是一种从根本上不同的检索方式，解决的是另一类问题。

大多数团队在保护 RAG 应用时，把精力放错了地方。他们验证用户输入、清洗查询语句、实施访问频率限制、添加输出过滤器。这些措施固然必要——但没有一项能阻止 RAG 系统中最关键的那类攻击。

大多数团队在调优 RAG 系统时关注两个杠杆：分块策略和嵌入模型选择。当检索质量下降时，他们重新分块；当召回率数据不好看时，他们升级嵌入模型。这两步都合理——但它们在优化流水线的中间环节，却让最高杠杆点一直没有触及。

用户的查询几乎从来不是向量检索的理想形式。它简短、口语化、模糊，或者假设了索引中并不存在的上下文。无论你的嵌入有多好，如果你用一个表述糟糕的查询来搜索，检索结果就会很差。解决方法不在下游——而是在查询命中向量索引之前对其进行变换。

向生产环境中的 RAG 系统提一个你的语料库无法回答的问题，看看会发生什么。它很少会说“我没有那方面的信息”。相反，它会检索出五个排名最高的片段——由于没有更好的匹配项，这五个片段其实是五个最不糟糕的无关内容——然后将它们交给模型，并配上类似“请使用以下上下文回答用户的问题”的提示词。模型在被训练为要乐于助人的同时，手中握着与主题有几分相似的文本，于是产生了一个自信的回答。这个答案的错误在架构上是不可见的：检索成功了，生成也成功了，每个片段都在检索到的文档中有据可查，但用户却被误导了。

这就是检索空洞问题。它不是任何单一层级的 bug。它是一个流水线的涌现行为，该流水线将 “top-k” 视为一种契约，却从不询问 top-k 的质量如何。ICLR 2025 上发表的一项关于“充分上下文”（sufficient context）的研究量化了这一影响：当 Gemma 获得充分的上下文时，其在事实性问答上的幻觉率约为 10%。当它收到的上下文不足时——即检索到的文档实际上并不包含答案——该比率会飙升至 66%。向描述不足的查询中添加检索到的文档会让模型错得更自信，而不是更少。

大多数关于 RAG 安全的讨论都集中在生成层 —— 越狱、系统提示词泄露、输出过滤。从业者花费数周时间在模型端调整护栏，却忽视了为其提供数据的摄入管道。一个令人不安的现实是：你的管道摄入的每一份文档都是一个潜在的指令面。一个 PDF 文件就能覆盖你的系统提示词、窃取用户数据，或在你的日志基础设施没有发现任何异常的情况下操纵决策。

这并非理论推测。在过去的两年里，Microsoft 365 Copilot、Slack AI 和商业 HR 筛选工具都曾通过这种向量被攻击。同样的攻击模式也出现在 arXiv 上的 18 篇学术论文中，研究人员通过嵌入隐藏提示词，使 AI 同行评审系统做出有利于他们的偏向性评价。