171 篇博文 含有标签「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 同行评审系统做出有利于他们的偏向性评价。

你的 RAG 系统正在向你撒谎。当用户询问当前价格、有效安全策略或上季度发布的功能时，检索管道返回的是索引中语义最相似的文档——而不是最新鲜的文档。一份 18 个月前的定价页面和今天早上的更新，对余弦相似度来说看起来毫无差异。标准 RAG 架构中没有任何组件能判断所检索的文档是否仍然正确。

这就是过时检索，它的失败方式与幻觉截然不同。模型没有凭空捏造任何内容，它准确地概括了真实存在过的内容。标准评估指标——忠实度、有根据性、上下文精确度——全部通过。系统对一个几个月前就已失效的事实表现出充分的自信。

在大多数 RAG 架构中都存在这样一种信念：如果检索返回了正确的区块（chunks），LLM 就会生成正确的答案。团队在嵌入模型选择、混合检索策略和重排序流水线方面投入了巨资。然而，在部署到生产环境三个月后，回答质量悄然下降——这不是因为模型变了，也不是因为查询模式发生了剧变，而是因为底层的语料库腐烂了。

企业级 RAG 的实施失败率约为 40%，而从业者最容易低估的失败模式既不是幻觉，也不是检索召回率低，而是文档质量。一项分析发现，通过引入文档质量评分，一个实施方案在不改变嵌入模型或检索算法的情况下，将搜索准确率从 62% 提高到了 89%。语料库是唯一的变量。语料库一直都是变量。

生产环境中的 LLM 给出了一个错误的答案。一张支持工单到来。你翻查日志，只看到提示词、补全内容和延迟指标——却没有任何信息说明检索系统到底拉取了哪些文档、哪些块进入了上下文窗口，或者模型在综合答案时最依赖的是哪段内容。你只能像做考古一样：重新对一个已经更新过的语料库跑一次查询，祈祷结果还和之前一样，同时不知道问题究竟出在检索、分块、文档本身还是模型推理上。

这就是数据溯源的缺口，而大多数 AI 团队直到掉进去才意识到它的存在。

你的 AI 系统正在自信地回答关于一个已经不存在的世界的问题。不是因为模型坏了，不是因为检索失败了，而是因为每个生产环境的 AI 应用内部都有三个独立的时钟在以不同的速率运转——而没有人把它们同步起来。

这就是三时钟问题：墙上时钟（wall clock）、模型时钟（model clock）和数据时钟（data clock）各自运行在自己的时间线上。当它们发生偏移时，你得到的系统在技术上正常运行，但在实质内容上以错误日志永远无法捕捉的方式出错。