RAG应用为何失败？分块、检索与评估闭环开发指南

当RAG应用给出错误答案时，大多数人第一反应是换模型。但真正的根源往往藏在模型看到问题之前——文档解析错误、分块切断语义、检索漏掉关键段落，或者用户看到了不该看的文本。

解决思路是一个闭环：先写好黄金问题集，逐阶段改动，分别评估检索和生成，每次发布都用分数把关。

模型还没上场，RAG为什么就已经失败了？

Barnett等人在研究、教育和生物医学领域的三个RAG案例中列出了七个失败点：内容缺失、相关文档排名不够高、相关文档未进入上下文、模型未能提取答案、输出格式错误、具体程度不当以及答案不完整。其中三个失败点发生在模型看到任何token之前。

上下文本身也有代价。"Lost in the Middle"研究发现，当相关段落位于输入的开头或结尾时准确率最高，位于中间时明显下降，即使是对长上下文优化的模型也一样。研究者还发现，用50篇检索文档替换20篇，效果提升非常有限——堆更多内容并不能替代更好的检索。

VentureBeat在2026年10月发布的一项读者调查中，130家组织里有64%表示至少有一次自信但错误的AI回答可以追溯到自有数据中缺失或不一致的业务上下文。样本量小且自我选择偏差明显，但方向与上述失败点一致。

七步RAG流水线

以下代码为示意性示例，默认值和库版本会变化，请根据你自己的文档适配并测试。

第一步：先写黄金问题集

黄金集是一份标注好的问题列表，配对应回答这些问题所需的文档。Qdrant的评估指南描述了三种构建方式：人工标注、从日志中提取真实用户查询、以及从采样文档中用LLM生成问题。指南同时警告合成问题往往比真实问题更简单，会虚高评分，几百对问答就能揭示大的指标差异。

从50到100个真实问题开始，加入用户实际会问的偏门问题，以及必须返回空结果的案例（比如无法回答的问题、或提问用户无权阅读的文档）。这个文件要和代码一起做版本管理，并记录构建时所对应的语料快照，因为语料一变，旧标签就过时了。

第二步：解析和清洗文档

大多数检索问题从这里开始。Amazon Bedrock Knowledge Bases的默认解析器只能从文件中读取文本，AWS建议当文档包含图表、表格或图像时使用高级解析器。Unstructured等开源工具可以把文档拆分为标题、叙述文本、列表项和表格等元素，让你保留结构而不是把所有内容压成一个字符串。

删除重复的页眉页脚等模板内容，每个文档只保留一个当前版本，并存储文档ID、所有者、日期和访问权限。近重复文档也要处理，Qdrant将其列为评估标签可能看起来不完整的原因之一。

第三步：带元数据的分块

只有当文档超过嵌入模型的输入限制时才需要分块，但当一个长页面用单个向量表示效果很差时，分块也有帮助。Microsoft的指南建议从512个token、25%重叠开始，Pinecone建议先用固定大小分块，测量不够之后再迭代。

各工具的默认值差异很大，单位也不统一：LangChain源码中基础文本分割器默认4000字符、200重叠；LlamaIndex的常量文件用1024个token、20重叠；Amazon Bedrock默认约300个token；OpenAI的自动向量存储策略用800个token、400重叠。把这些都当作测试的起点，而不是答案。

以下分割器优先按标题切割，确保一个块不会跨越两个主题，然后让每个块都保留其标题。要正确比较分块大小，Pinecone的建议是分别索引每个候选大小，运行真实查询并比较结果。

第四步：嵌入和索引

不同模型的嵌入不可比较，所以要在每个块旁边存储模型名称和维度。以下示例使用Postgres加pgvector扩展，默认执行精确最近邻搜索，召回率完美。HNSW等近似索引用一些召回率换速度，只在查询量需要时创建，并测量相对精确搜索损失了多少召回率。

1536维对应OpenAI text-embedding-3-small的默认输出长度，请改成你自己模型的维度。pgvector的README列出了HNSW默认参数：m为16，ef_construction为64，hnsw.ef_search为40，值越高召回率越好但速度越慢。

第五步：混合检索、过滤与重排序

关键词搜索更擅长产品编码、专业术语、日期和人名，而向量搜索能找到概念相似但没有共同词汇的内容。Microsoft的混合搜索文档描述了并行运行两者，然后用倒数排名融合（RRF）合并排名列表，对每个结果求1/(rank + k)之和，k取原论文中使用的60。

有两个细节很重要。第一，pgvector在索引扫描之后应用过滤，所以带过滤的近似查询可能返回少于限制的行数；0.8.0版本增加了迭代索引扫描，在需要时扫描更多索引，同时在过滤列上加索引也有帮助。第二，取前20个左右的候选项，用交叉编码器或托管的重新排序模型重排，然后把最好的3到8个发给模型。Pinecone称这种两阶段模式是改善RAG流水线检索质量最简单的方法之一。

倒数排名融合（RRF, Reciprocal Rank Fusion） 是一种无需调参即可合并多路检索结果的方法。在混合检索中，向量搜索和关键词搜索各自返回一份按相关性排序的文档列表，但两者的分数尺度完全不同，无法直接比较或相加。RRF的解法是抛弃原始分数，只看排名：对每一篇文档，在每一路结果中计算 1 / (k + rank)，然后求和得到融合分数，其中 rank 是该文档在这一路中的位置（从1开始），k 是一个平滑常数，原论文取 60。这样，同时出现在两路结果靠前位置的文档会得分最高，而只在某一路排名很高的文档也能获得一定权重。RRF 的优势在于对分数分布不敏感、无需归一化，因此在生产系统中被广泛用作默认融合策略。

第六步：带引用和约束的生成

只给模型允许的段落，每段标注来源，并告诉它找不到答案时该怎么做。拒绝路径是产品的一部分，因为黄金集里应该包含语料无法回答的问题。

系统提示的最后一句很重要，因为OWASP将间接提示注入（外部来源内容改变模型行为）列为风险，并指出RAG并不能完全缓解它。

间接提示注入（Indirect Prompt Injection） 是指攻击者把恶意指令藏在模型会读取的外部内容中——在RAG场景里，就是藏在被检索到的文档、网页或数据库字段里。与用户直接输入恶意提示不同，间接注入不需要攻击者接触对话界面，只要其内容被检索进上下文即可生效。常见的攻击目标包括让模型忽略原有系统提示、泄露系统提示词或其他用户的敏感数据、调用本不该调用的工具，或在回答中插入钓鱼链接。OWASP 将其列为 LLM01，并明确指出RAG无法完全缓解这一风险，因为检索本身就意味着模型会处理不可信来源的文本。可行的缓解措施包括：隔离外部内容与系统指令、对模型输出做格式校验、对高风险操作强制人工审批、以及限制模型可调用的工具权限。

第七步：评估与监控

分别评估检索和生成，因为错误答案可能来自任何一端。检索方面，recall@k是已知相关文档出现在前k个结果中的比例，MRR（平均倒数排名）对第一个相关结果排名的倒数取平均。Qdrant推荐RAG流水线使用recall@k，因为完全漏掉相关段落比排名靠后伤害更大。

阈值的具体数字是占位符。用基线运行设定你自己的阈值，然后随时间逐步提高。答案质量方面，RAGAS库定义了Faithfulness（回答中由检索上下文支持的声称占比）、Context Precision（检索器把相关块排在无关块前面的能力）、Context Recall（检索上下文覆盖参考答案的程度，这个始终需要参考答案）以及Response Relevancy（原名answer relevancy，不检查事实准确性）。在每次CI变更时运行检索检查，并随时间把生产问题采样进黄金集。

RAGAS 是一套面向RAG流水线的开源评估框架，它把“答案好不好”拆解为若干可独立测量的指标，从而避免只凭人工感觉打分。其中 Faithfulness（忠实度）衡量回答中的每一条声称是否都能在检索上下文中找到支撑，能有效捕捉模型“编造”的行为；Context Precision（上下文精确率）评估检索器是否把真正相关的块排在无关块前面；Context Recall（上下文召回率）衡量检索到的上下文覆盖参考标准答案的程度，因此必须提供参考答案才能计算；Response Relevancy（回答相关性）则判断回答是否切题，但它不检查事实准确性——一个切题但完全错误的回答也可能得高分。这些指标组合使用，才能定位问题出在检索端还是生成端。

权限与安全

权限属于检索层，不属于提示词。Microsoft的Azure AI Search指南将文档级授权描述为对每个查询应用安全过滤器，Supabase推荐使用Postgres行级安全而非where子句过滤，因为策略始终会被应用，但要注意测量延迟成本。第五步中的模式用允许组数组完成了同样的事。道理很简单：如果一段文本从未离开数据库、从未被无权打开源文档的用户触达，模型就不可能重复它。

OWASP LLM应用十大风险（2025）中有四项直接映射到RAG应用：

• LLM01 提示注入：检索到的文本是不可信输入。隔离外部内容，验证输出格式，高风险操作要求人工审批。
• LLM02 敏感信息泄露：按最小权限原则限制对敏感数据的访问。
• LLM08 向量与嵌入弱点：OWASP建议细粒度访问控制和权限感知的向量与嵌入存储，警告多租户环境中上下文可能跨用户泄漏，并指出嵌入有时可以被逆向还原出源信息。
• LLM10 无界消费：限流和设配额，防止公开端点被用来推高成本。

最后，为变化做规划。MongoDB和Voyage AI的文档建议在迁移到后继模型时重新生成整个语料的嵌入，即使维度相同也一样，因为不同模型的向量不可比较。此外还要确保删除操作传播到索引，而不只是新增。

行级安全（Row-Level Security, RLS） 是Postgres等数据库提供的一种访问控制机制，允许在表级别定义策略，使不同用户或角色只能看到符合其权限的行。相比在应用层用 WHERE 子句过滤，RLS 的优势在于策略由数据库强制执行，即使应用层漏写了过滤条件，数据库也不会返回越权数据，从根本上杜绝“忘了加条件”这类错误。在RAG架构中，把文档权限建模为RLS策略，意味着检索查询天然只返回当前用户有权访问的文档，模型也就无法获得不该看到的文本。需要注意的是，RLS会在查询执行时增加额外开销，尤其在配合向量索引做近似最近邻搜索时，过滤条件和索引扫描的交互可能影响召回率和延迟，因此上线前应实测查询性能和召回损失。

毁掉RAG质量的常见错误

• 没有测试集：没有它，每次调整都是猜测。Barnett等人发现验证只能在运行期间进行，所以要持续添加真实问题。
• 照搬默认分块设置：上面的默认值在大小和单位上都不同。针对你的问题测试两到三种大小。
• 压平表格和扫描件：如果解析器丢掉了表格，任何检索器都找不到它。
• 在生成后过滤：对答案做权限检查已经太晚了。在候选项进入提示词之前过滤。
• 混用嵌入模型：查询和文档向量必须来自同一模型。在每个块旁存储模型名称。
• 往提示词里塞内容：更多块可能掩埋相关的那一个，Lost in the Middle的结果已经证明了这一点。重排后少发几个。
• 让索引变陈旧：定期同步，传播删除操作，追踪每个文档最旧索引版本的年龄。
• 把RAG当注入防御：它不是。对模型能调用的每个工具保持最小权限。

RAG开发服务商：5个值得关注的团队

如果你更愿意把流水线交给专业团队，以下公司在其服务列表中包含RAG开发或AI数据工程。数据来自各公司自己的网站，属于自我报告，签约前请直接确认。

Dev Technosys

成立于2010年，团队250+人，总部在印度斋浦尔，持有ISO 27001:2022和ISO 9001:2015认证，CMMI Level 3评估。其五阶段RAG和数据工程流程为：数据发现、流水线设计、构建与集成、评估与加固、上线与运营。核心服务包括定制RAG解决方案、RAG流水线开发、向量数据库集成（Pinecone、Weaviate、pgvector、Milvus）、AI知识库开发、LLM数据工程，以及与SharePoint、Confluence、Salesforce、Zendesk和内部API的RAG集成。

其流程与本指南中的闭环顺序一致——先做数据发现和流水线设计，再接入模型，上线前有评估加固阶段，之后持续运营。对于希望由一家供应商负责流水线、索引和测试的团队，这种连续性就是实际优势。

Excellent Webworld

总部标注为迪拜，自称成立于2011年，首页称有300+工程师，RAG页面称350+。其RAG页面描述了针对散文的语义分块、针对表格和代码的结构感知分块、带重排序的混合搜索、查询改写和HyDE，以及先检查权限再检索而非事后过滤。页面称其针对真实查询集测试检索精确率、召回率和有据性，但未点名评估工具。其页面提到的合规框架如SOC 2 Type II和ISO/IEC 27001是"工作所支持的"，并非公司持有这些证书。适合海湾地区和全球买家。

SCAND

自称自2000年运营，在纽约和华沙设有办公室，250+全职工程师。其RAG页面描述了智能分块、混合搜索、交叉编码器重排序和HyDE，支持Pinecone、Weaviate、pgvector、Qdrant、Milvus和Elasticsearch，提供云端或本地部署。描述了基于角色的访问、审计日志和数据隔离，并点名LangSmith和Langfuse作为监控工具，但未声明评估指标。自称ISO 9001认证（质量而非安全标准），将GDPR、HIPAA和SOC 2仅列为架构可对齐的框架。适合想要本地部署方案的买家。

Uvik Software

成立于2015年，列出塔林（标注为HQ）和伊普斯威奇（标注为商业HQ）两个地址，50+资深工程师。有独立的RAG页面和AI数据工程页面。RAG页面描述了混合BM25和向量搜索加交叉编码器重排序、查询时权限执行，以及每次变更都评估context recall、context precision、faithfulness、answer correctness和citation accuracy的评估框架。安全表述为"对齐"ISO/IEC 27001和SOC 2，正式证明可按需提供。适合想要评估优先的小型资深团队的英国和欧盟买家。

Kanerika

自称始于2015年，在美国、印度和新加坡设有六个办公室，未公布人数。其RAG页面描述了分块、混合搜索和重排序，在用户看到之前用真实问题测试集对每个版本打分，上线后监控漂移。描述了检索层的基于角色的访问、每次检索的日志记录，以及摄入前的PII脱敏，支持云端或本地部署。页脚有CMMI Level 3标志，列出与Microsoft、Snowflake等的合作伙伴关系，但未声明ISO 27001或SOC 2。适合在Microsoft Fabric、Azure或Snowflake上想要在受治理数据栈内做RAG的团队。

常见问题

RAG是什么？ 检索增强生成在模型回答时从你自己的文档中提供相关段落，让回答有据可依并能引用来源。

RAG开发费用多少？ 取决于来源的数量和质量、权限模型、评估深度和托管方式。Dev Technosys表示其项目从1万美元起。其他公司大多未公布价格。

该用什么分块大小？ 没有通用答案。Microsoft建议的起点是512个token加25%重叠，但各库默认值差异很大，所以构建两到三个变体，在黄金集上比较recall@k。

RAG比把所有文档放进提示词更好吗？ 默认不一定。检索适合大型、频繁变化或权限不同的语料，而小型稳定的文档集可能适合长上下文。用同一套问题集测试两者，并记住长输入有它自己的准确率问题。