构建 RAG 系统后，真正难的不是“让它能回答”，而是判断它回答得是否正确、可靠、可解释、可持续迭代。

RAG 评估工具大致可以分成三类：

一、简介

RAG 系统中，数据加载是整个流水线的第一步，也是不可或缺的一步。文档加载器负责将各种格式的非结构化文档（如PDF、Word、Markdown、HTML等）转换为程序可以处理的结构化数据。数据加载的质量会直接影响后续的索引构建、检索效果和最终的生成质量。

文本分块（Text Chunking）是构建 RAG 流程的关键步骤。它的原理是将加载后的长篇文档，切分成更小、更易于处理的单元。这些被切分出的文本块，是后续向量检索和模型处理的基本单位。

什么是RAG

在基础的 RAG 流程中，我们通常先把文档切分成 Chunk，再用 Embedding 建立向量索引，最后根据向量相似度召回 Top-K 文档。这套流程简单、通用，但在生产环境里很容易遇到三个问题：

在 RAG 系统的默认实现中，稠密向量（Dense Vector）检索 是最常用的召回方式。它擅长捕捉语义相近的表达（例如 “汽车” 与 “轿车”），但在面对专有名词、型号编号、人名、代码标识符等需要“精确字面匹配”的场景时，经常会出现漏检或误召回。

在构建向量索引时，文档块（Chunk）通常不会只存"正文 + 向量"，还会附加一批元数据（Metadata），例如文档来源、发布日期、作者、章节、类别、标签等。这些元数据让我们在语义搜索之外还能进行精确过滤，也就是常说的 "先筛选，再向量检索"（Pre-filtering） 或 "先向量检索，再筛选"（Post-filtering）。

在真实的 RAG 场景中，用户的原始 Query 很少是"检索友好"的：