121 篇博文 含有标签「rag」

当工程师评估向量数据库时，他们通常会加载 ANN 基准测试，并选择在 recall-at-10 排行榜上名列前茅的产品。三个月后，他们就开始提交迁移工单了。这些基准测试是在单一客户端、静态且索引完美的索引数据集上测量查询吞吐量的。但生产环境完全不是这样。

本指南涵盖了预测向量数据库在实际工作负载下能否撑住的五个维度，以及一个将这些维度与你的技术栈进行匹配的决策框架。

一个合规承包商构建了一个 RAG 系统，旨在回答有关 400 页政策文档的问题。系统通过了内部 QA，针对单主题查询的检索表现正确。然而系统上线后，在处理涉及例外条款的任何问题时，它开始返回语气自信、结构严谨但错误百出的答案。

调试过程似曾相识：更换嵌入模型、调整相似度阈值、试验分块大小、添加重排序器。几周过去了，改进微乎其微。真正的症结在于，一个关键的例外条款在段落边界处被分割到了两个分块（chunks）中 —— 这并非由于分块策略，而是因为 PDF 提取器在误读排版时，悄无声息地将该段落一分为二。孤立来看，这两个分块都无法检索或解析。系统无法通过幻觉得到正确答案，因为正确的信息从未完整地进入索引。

这就是“提取天花板”：即当下游优化再多也无法弥补受损或缺失的输入数据时，系统所面临的瓶颈。

40% 到 60% 的企业 RAG 部署无法进入生产环境。罪魁祸首几乎从来不是检索算法——HNSW 索引运行正常，嵌入质量也不错，向量相似度搜索已是成熟技术。问题发生在上下游：没有文档所有权、查询时未执行访问控制、PII 裸露在向量索引中，以及检索语料库在上线数周内就与现实脱节。这些都是治理失败，而大多数工程团队将其视为别人的问题，直到合规团队、安全审计，或某个收到了其他租户数据的用户把这变成自己的问题为止。

本文是受控 RAG 知识库的组织与技术解剖——写给拥有管道的工程师，而不是批准预算的高管。

大多数团队在构建 RAG 流水线时都会选择向量嵌入（vector embeddings）。这是一个显而易见的默认选择：嵌入文档、嵌入查询、寻找最近邻，然后将结果输入给 LLM。在演示（demo）中它的表现还不错。但当部署到合规团队或科学文献语料库时，准确率就会断崖式下跌。不是逐渐下降，而是突然暴跌。在涉及五个或更多实体的查询中，向量 RAG 在企业分析基准测试中的准确率降至零。不是 50%，也不是 20%，而是零。

这不仅是一个配置问题，而是架构上的不匹配。向量检索将文档视为语义空间中的点。知识图谱（knowledge graphs）则将它们视为关系结构中的节点。当你的查询需要遍历关系——而不仅仅是寻找相似内容时，检索架构的拓扑结构（topology）决定了你是否能得到正确答案。

大多数 RAG 实现都以同样的方式开始：启动一个向量数据库，使用一个不错的模型嵌入文档，在查询时运行余弦相似度，然后发布。演示效果看起来很棒。相关性感觉出奇地好。然后你将其部署到生产环境，发现“Error 221”检索到了关于“Error 222”的文档，搜索特定的产品 SKU 会出现语义相似但错误的条目，而添加日期过滤器会导致检索质量大幅下降。

向量搜索是一个真正强大的工具。但在大多数生产环境的检索工作负载中，仅靠它是不够的。在 2025 年，通过 RAG 获胜的团队并不会在稠密嵌入（dense embeddings）和关键词搜索之间做选择——他们会刻意同时使用两者。

这是一个决策框架，用于判断混合检索何时值得增加复杂性，以及如何在不破坏延迟预算的情况下构建每一层。

一个团队为内部文档构建了 RAG 流水线。检索效果看起来不错——相关段落都被召回了。但在生产环境中，用户持续收到过时的答案。深入查看日志后他们发现，模型返回的是训练数据中的事实，而非它被给予的文档内容。检索成功了，但模型就是没用上它。

这就是知识污染问题：模型的参数记忆——训练期间编码进权重的知识——压制了检索到的上下文。这种失败悄无声息、表现自信，也是生产环境 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）强制执行（“该用户可以查看与此查询匹配的文档吗？”）。这两个检查点之间的差距就是静默数据泄露发生的地方——也是大多数生产事故的根源。