50 篇博文 含有标签「retrieval」

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

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

大多数团队发现自己需要 GraphRAG 时往往已经晚了六个月——在他们已经向用户解释了为什么 AI 搞错了关系、为什么它混淆了两个具有相似嵌入（embeddings）的实体，或者为什么它言之凿凿地引用了一份与实际答案相矛盾的文档之后。Vector RAG 在其擅长的领域确实表现出色。问题在于，团队把它当成了全能选手，并在底层架构已经达到数学上限时，仍不断堆砌检索补丁。

截至 2025 年，只有不到 15% 的企业在生产环境中部署了基于图的检索。这并不是因为技术不成熟。而是因为纯向量 RAG 的失败信号非常微妙：系统在运行，LLM 在响应，只有经过仔细检查才会发现，检索到的上下文虽然看似合理，但却是错误的。

你的 RAG 系统评估看起来还不错。NDCG 尚可接受，演示也能运行。但有一类故障是单一指标评估无法捕捉的：那些你的检索器从未接近过的查询——持续如此，因为你的整个嵌入空间从一开始就没有能力处理它们。

这就是检索单一化。一个嵌入模型、一种相似度度量、一条检索路径——因此也是一套系统性盲点，这些盲点看起来像模型错误、幻觉或用户困惑，直到你真正检查检索层才会发现真相。

解决方法不是更大的模型或更多数据，而是理解不同的查询结构需要不同的检索机制，并构建一个能够停止将一切都路由到同一漏斗中的系统。

大多数团队在起步时都会选择向量数据库 (Vector Store)，因为它们上手简单，但随后会发现即使无论如何调整分块大小 (Chunk size) 或嵌入模型 (Embedding model)，某些类型的查询也完全无法生效。这并非调优问题 —— 而是架构上的不匹配。向量相似度与图遍历是两种根本不同的检索机制，随着查询复杂度的增加，这种差异会变得愈发关键。

这不是一篇推荐“两者兼顾”的文章。在实际应用中需要进行真正的权衡，选择失误会耗费数月的工程时间。以下是这种选择在实践中的真实面貌。

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

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

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

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

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

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

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

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

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

这就是知识污染问题：模型的参数记忆——训练期间编码进权重的知识——压制了检索到的上下文。这种失败悄无声息、表现自信，也是生产环境 RAG 系统中最常见的故障模式之一。

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

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

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

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

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

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

大多数构建语义搜索的团队都从 RAG 概念验证出发：对文档分块、生成嵌入向量、存储到向量库、用余弦相似度查询。在演示中效果不错。然后他们把它发布给用户，结果有一半的查询以与检索质量毫无关系的方式失败了。

原因在于 RAG 和面向用户的语义搜索解决的是不同的问题。RAG 在问"给定一个问题，检索上下文供 LLM 回答"。语义搜索在问"给定用户的查询，呈现真正符合其需求的结果"。第二个问题有一层 RAG 基准系统性忽视的复杂性——而这种复杂性几乎完全存在于检索开始之前。