企业官网建设流程全解析

1. 为什么 RAG 检索效果必须做量化测评

1.1 从“感觉还行”到“数据说话”的转折点

做 RAG 项目的人大概都经历过这个阶段：知识库搭起来了，向量库也灌进去了，随便问几个问题，模型答得头头是道，于是拍着胸脯跟团队说“效果不错”。结果上线没两天，业务方甩过来一句“它连我们上个月刚发的政策都答错了”，瞬间哑火。

问题出在哪？出在我们把“生成结果看起来通顺”当成了“检索结果确实正确”。这两件事在 RAG 里是解耦的——检索负责从海量切片里捞出相关上下文，生成负责把这些上下文组织成人话。生成端现在的大模型能力普遍够用，真正拖后腿的往往是检索端：该捞的没捞到，不该捞的捞了一堆，或者捞到了但排序靠后，被截断窗口挤掉了。

所以量化测评的核心目的只有一个：把“检索质量”这个模糊概念拆成可计算、可对比、可回归的数字。没有这套数字，你做的任何优化（换 embedding 模型、调 chunk size、加 rerank、改混合检索权重）都是盲调，调完也不知道是真变好了还是碰巧那几个 case 对了。

我自己的习惯是，任何 RAG 项目在进入调优阶段之前，先花半天时间把测评集和指标跑通。这半天省下来的时间，后面能翻好几倍还回来。

1.2 测评到底测的是哪一层

很多人一上来就说“我要测 RAG 效果”，但没分清测的是检索还是生成。这两层的指标、数据集、排查手段完全不同。

检索层关注的是：给定一个 query，系统返回的 top-k 文档里，有多少是真正相关的，相关的那几个排在第几位。这一层是纯信息检索问题，指标沿用 IR 领域几十年的积累，成熟且客观。

生成层关注的是：给定检索回来的上下文，模型输出的答案是否忠实于上下文、是否回答了问题、有没有胡编。这一层更接近 NLP 生成评测，主观性更强，通常需要 LLM-as-judge 或者人工标注。

这篇主要聊检索层的量化测评，因为它是整个 RAG 的地基。地基不稳，上面盖什么都是歪的。生成层我会在最后一节简单带一下衔接方式，但不展开。

1.3 适合谁来照着做

这套流程对以下几类人最有用：一是正在做企业知识库、客服问答、文档助手的工程师，手里有真实语料但不知道怎么证明检索有效；二是做 RAG 教程或课程的人，需要一套可复现的测评脚手架；三是技术负责人，需要一套能写进验收标准的量化口径。

不需要你懂信息检索理论，但需要你会写 Python、能跑通一个向量检索 demo、愿意花时间标注一批测评数据。标注这件事没有捷径，后面会讲怎么把标注成本压到最低。

2. 测评数据集怎么造才靠谱

2.1 测评集的三种来源与取舍

造测评集是整件事里最费人力的一环，但也是最不能省的。常见三种来源：

第一种是真实用户日志。如果系统已经上线，直接从 query log 里采样，再人工标注每个 query 对应的相关文档。这是最贴近真实分布的，但冷启动阶段没有。

第二种是业务专家出题。找熟悉业务的人，针对知识库覆盖的内容，写出“用户可能会问的问题”，再标出标准答案对应的文档片段。质量高，但成本高，且专家的提问方式和真实用户往往有偏差。

第三种是从文档反向生成。拿一段文档切片，让大模型生成它“能回答的问题”，文档本身就是标准答案。这是冷启动最常用的办法，成本低、可批量，但要注意生成的问题往往过于“书面”，和真实口语化 query 有 gap。

我的实操建议是：冷启动用第三种快速造一批，上线后用第一种持续补充。两者混合，既保证覆盖度又保证真实性。

2.2 反向生成测评集的具体做法

反向生成听起来简单，但直接让模型“读这段生成一个问题”会得到大量低质样本。我踩过的坑是：生成的问题太依赖原文措辞，导致检索时只要 embedding 稍微好一点就能命中，测评结果虚高，掩盖了真实问题。

改进做法是分两步。第一步让模型生成问题，第二步让模型对生成的问题做“去措辞化”改写，把它变成用户真正会问的口语版本。

# 伪代码示意，实际用你手头的 LLM SDK prompt_gen = """ 阅读以下文档片段，生成一个它能回答的问题。 要求：问题要具体，包含文档中的关键实体。 文档：{chunk} 问题： """ prompt_rewrite = """ 把下面的问题改写成真实用户会问的口语化版本， 不要出现文档里的原句措辞，可以加入同义替换。 原问题：{question} 口语化问题： """

每个 chunk 生成 1 到 2 个问题就够了，太多会导致测评集冗余。生成完之后一定要人工过一遍，把明显不合理、答案不在 chunk 里的删掉。这一步别偷懒，测评集里混进脏数据，后面所有指标都是错的。

2.3 标注相关性的粒度问题

标注时最容易纠结的是：一个 query 到底对应几个相关文档？是只标“最相关的那一个”，还是把所有沾边的都标上？

这取决于你的检索目标。如果业务场景是“精确问答”，比如查某个具体条款，那通常只有一个或少数几个 chunk 是真正相关的，标注时用二值（相关/不相关）即可。如果场景是“主题探索”，比如“帮我找找关于 XX 的资料”，那相关文档可能有一大片，这时候更适合用分级标注（高度相关/部分相关/不相关）。

我一般推荐新手从二值标注起步，简单、争议小、指标好算。等团队对相关性判断标准有共识了，再考虑升级到分级。

标注时还有个细节：要记录每个 query 的“难度标签”。比如“简单”（关键词直接匹配）、“中等”（需要同义理解）、“困难”（需要多跳推理）。这样后面分析指标时，能看出系统到底是在哪类问题上掉链子，而不是只看一个平均数。

2.4 测评集规模与划分

规模上没有绝对标准，但有几个经验值。做快速迭代时，50 到 100 个 query 就能看出趋势；做正式验收时，建议 200 个以上，且覆盖不同难度和不同业务子领域。

划分上，我习惯留出三份：开发集用来日常调参，验证集用来选方案，测试集只在最终验收时用一次。很多人把所有数据都拿来调参，结果指标很好看，上线就崩，就是因为过拟合了测评集。测试集的存在就是为了给你一个诚实的数字。

3. 检索效果的核心指标与实现

3.1 Hit Rate 与 Recall：最直观的两个数

Hit Rate@k的定义是：在 top-k 检索结果中，只要包含至少一个相关文档，就算命中。它衡量的是“系统有没有捞到”，是最宽松也最直观的指标。

Recall@k则更严格：top-k 中命中的相关文档数，除以测评集中该 query 的全部相关文档数。当每个 query 只有一个相关文档时，Recall@k 和 Hit Rate@k 数值相同；当有多个相关文档时，Recall 会低于 Hit Rate。

实现上，先要把检索结果和标注结果对齐。假设标注数据是{query_id: [relevant_doc_ids]}，检索结果是{query_id: [retrieved_doc_ids]}：

def hit_rate_at_k(retrieved, relevant, k): hits = 0 for qid, docs in retrieved.items(): top_k = docs[:k] if any(d in relevant[qid] for d in top_k): hits += 1 return hits / len(retrieved) def recall_at_k(retrieved, relevant, k): total_recall = 0 for qid, docs in retrieved.items(): top_k = set(docs[:k]) rel = set(relevant[qid]) if not rel: continue total_recall += len(top_k & rel) / len(rel) return total_recall / len(retrieved)

这两个指标的好处是解释成本极低，跟业务方沟通时一句“100 个问题里 87 个能捞到正确答案”就说明白了。缺点是它们不关心排序，只要相关文档在 top-k 里就行，哪怕排在第 10 位。

3.2 MRR：关心“第一个正确答案排多前”

MRR（Mean Reciprocal Rank）解决的就是排序问题。对每个 query，找到第一个相关文档的位置 rank，取倒数 1/rank，再对所有 query 求平均。

如果第一个相关文档排第 1，贡献 1 分；排第 2，贡献 0.5 分；排第 5，贡献 0.2 分。这个指标对“把最相关的排到最前面”特别敏感，适合问答类场景。

def mrr(retrieved, relevant): total = 0 for qid, docs in retrieved.items(): rel = set(relevant[qid]) for rank, doc in enumerate(docs, start=1): if doc in rel: total += 1 / rank break return total / len(retrieved)

MRR 的一个坑是：它只看第一个相关文档，后面的相关文档完全不计。所以如果业务需要返回多个答案，MRR 会低估系统能力，这时候要配合 MAP 或 NDCG 一起看。

3.3 MAP 与 NDCG：更全面的排序质量

MAP（Mean Average Precision）综合考虑了所有相关文档的位置。对每个 query，计算每个相关文档位置上的 precision，再求平均，最后对所有 query 求平均。它比 MRR 更全面，但计算也稍复杂。

NDCG（Normalized Discounted Cumulative Gain）则支持分级相关性，是信息检索里最“正统”的指标。它引入了一个折损因子：排得越靠后，即使相关，贡献也越小。公式里通常用 log 折损。

import math def dcg(gains): return sum(g / math.log2(i + 2) for i, g in enumerate(gains)) def ndcg_at_k(retrieved, relevance_grades, k): # relevance_grades: {qid: {doc_id: grade}} total = 0 for qid, docs in retrieved.items(): grades = relevance_grades[qid] gains = [grades.get(d, 0) for d in docs[:k]] ideal = sorted(grades.values(), reverse=True)[:k] idcg = dcg(ideal) if idcg == 0: continue total += dcg(gains) / idcg return total / len(retrieved)

NDCG 的优点是能反映“相关程度”的差异，比如高度相关给 2 分、部分相关给 1 分。缺点是解释起来不如 Hit Rate 直观，业务方可能听不懂。我的做法是内部调优看 NDCG，对外汇报用 Hit Rate 和 MRR。

3.4 指标选择速查表

实际项目里，我一般同时看 Hit Rate@5、MRR 和 NDCG@10 三个数。Hit Rate 看底线，MRR 看头部质量，NDCG 看整体排序。三个数一起涨，才说明优化是真有效。

4. 完整测评流程的落地实操

4.1 环境与依赖准备

测评脚本本身不复杂，依赖也就几个：向量检索库（FAISS、Milvus、Qdrant 都行）、embedding 模型、pandas 做数据处理。我习惯用 FAISS 做本地快速验证，因为它零依赖、启动快，适合测评阶段反复跑。

pip install faiss-cpu pandas numpy # embedding 用你项目里实际用的那个，保持一致

关键原则：测评用的检索链路必须和线上完全一致。包括 embedding 模型、chunk 策略、相似度度量、top-k 参数。我见过有人测评时用 A 模型，线上用 B 模型，测出来的数完全没有参考价值。

4.2 数据准备与索引构建

先把知识库文档按线上同样的 chunk 策略切好，每个 chunk 分配一个唯一 ID。这个 ID 是后面所有对齐工作的基础，一定要稳定、可追溯。

import faiss import numpy as np # chunks: List[str]，每个元素是一个切片 # ids: List[str]，与 chunks 一一对应的唯一 ID embeddings = embed_model.encode(chunks, normalize_embeddings=True) embeddings = np.array(embeddings).astype('float32') index = faiss.IndexFlatIP(embeddings.shape[1]) # 内积，配合归一化即余弦 index.add(embeddings)

这里有个细节：如果线上用的是带 rerank 的两阶段检索，测评时也要把 rerank 加上，否则测的是第一阶段的效果，和线上不一致。rerank 对 MRR 和 NDCG 的影响通常很大，不能忽略。

4.3 批量检索与结果收集

测评的核心循环就是：对每个 query，检索 top-k，记录返回的 doc ID 列表。

def batch_retrieve(queries, index, ids, k=10): results = {} q_embs = embed_model.encode(queries, normalize_embeddings=True) q_embs = np.array(q_embs).astype('float32') scores, indices = index.search(q_embs, k) for i, qid in enumerate(queries): results[qid] = [ids[idx] for idx in indices[i]] return results

跑的时候注意两点：一是 k 要设得比最终展示的 top-k 大一些，比如线上展示 5 条，测评时检索 10 条，这样能看出“如果放宽到 10 条能不能捞到”，帮助判断是检索能力问题还是排序问题。二是要保存原始分数，后面排查 bad case 时分数分布很有用。

4.4 指标计算与结果汇总

把前面写的指标函数串起来，输出一张汇总表：

def evaluate(retrieved, relevant, k_list=[1, 3, 5, 10]): report = {} for k in k_list: report[f'hit_rate@{k}'] = hit_rate_at_k(retrieved, relevant, k) report[f'recall@{k}'] = recall_at_k(retrieved, relevant, k) report['mrr'] = mrr(retrieved, relevant) return report

跑完得到类似这样的结果：

从这张表能读出很多信息。hit_rate@1 只有 0.62，说明头部排序还有优化空间；hit_rate@10 到 0.93，说明大部分答案其实在库里，只是没排上来，这时候加 rerank 往往立竿见影。如果 hit_rate@10 也很低，那就是召回本身有问题，得回头查 chunk 策略或 embedding 模型。

4.5 分难度、分领域的切片分析

只看总体指标容易掩盖问题。我习惯按难度标签和业务子领域再切一刀：

def evaluate_by_group(retrieved, relevant, groups): # groups: {qid: 'easy'/'medium'/'hard'} from collections import defaultdict buckets = defaultdict(lambda: {'retrieved': {}, 'relevant': {}}) for qid in retrieved: g = groups[qid] buckets[g]['retrieved'][qid] = retrieved[qid] buckets[g]['relevant'][qid] = relevant[qid] return {g: evaluate(v['retrieved'], v['relevant']) for g, v in buckets.items()}

经常出现的情况是：简单问题 hit_rate@1 有 0.9，困难问题只有 0.3。这时候优化方向就很明确了——针对困难问题，是不是需要 query 改写、多路召回、或者引入知识图谱辅助。没有这层切片，你只会看到一个平庸的平均数，不知道该往哪使劲。

5. 踩坑总结与常见问题排查

5.1 测评集本身的坑

坑一：测评集和知识库不同步。知识库更新了，测评集里的标准答案还是旧的，导致明明检索对了却被判错。解决办法是给测评集加版本号，知识库大更新时同步 review 测评集。

坑二：query 分布偏差。反向生成的问题太书面，真实用户 query 太口语，两者检索表现差异巨大。我实测过，同一套系统，书面 query 的 hit_rate@5 比口语 query 高 15 个百分点。所以测评集里一定要混入真实口语 query。

坑三：相关文档标注过松。标注时觉得“这个 chunk 好像也沾点边”就标成相关，导致指标虚高。判断标准应该是：这个 chunk 单独拿出来，能不能回答这个 query。不能，就不算相关。

5.2 指标计算的坑

坑四：k 值不一致。检索时取 top-10，算 hit_rate@5 时却用了全部 10 条，结果偏高。所有指标计算必须严格截断到对应的 k。

坑五：多相关文档时 Recall 分母算错。有些 query 有 3 个相关文档，但检索只返回了 1 个，Recall 应该是 1/3 而不是 1。分母是标注的相关文档总数，不是检索返回数。

坑六：空相关集的处理。如果某个 query 标注时发现知识库里根本没有相关文档，这个 query 应该从测评集中剔除，而不是算作未命中。否则会拉低所有指标，误导判断。

5.3 检索链路的坑

坑七：embedding 归一化不一致。建索引时归一化了，查询时忘了归一化，余弦相似度直接算错。用内积索引时，两边必须都归一化。

坑八：chunk 边界切断答案。一个完整答案被切成两半，分别落在两个 chunk 里，检索时只捞到一半，生成时答不全。这种情况指标上表现为“相关文档明明在库里但没捞到”，排查时要看 chunk 策略是不是切得太碎。

坑九：rerank 模型和 embedding 模型不匹配。有些 rerank 模型对输入长度有限制，超长 chunk 会被截断，导致排序失真。上线前一定要用测评集验证 rerank 的实际增益，别默认它一定有用。

5.4 常见问题速查表

5.5 几个实测有效的优化方向

第一，混合检索。纯向量检索对关键词精确匹配不敏感，加一路 BM25 做融合，对包含专有名词、编号、代码的 query 提升明显。我实测在技术文档场景，混合检索比纯向量 hit_rate@5 高 8 到 12 个百分点。

第二，query 改写。用户 query 往往很短、有指代、有口语省略。用 LLM 做一次 query 扩展或改写，再拿去检索，对困难问题提升显著。代价是多一次 LLM 调用，延迟增加，要权衡。

第三，chunk 重叠。相邻 chunk 之间留 10% 到 20% 的重叠，能缓解边界切断问题。重叠太多会导致检索结果冗余，太少又起不到作用，一般 15% 左右比较稳。

第四，rerank 精排。第一阶段召回 top-50，rerank 后取 top-5，是性价比很高的方案。rerank 模型选型上，cross-encoder 类效果通常好于 bi-encoder，但延迟更高，看业务能接受多少。

6. 从检索测评到生成测评的衔接

检索测评跑通之后，生成层的测评可以顺势接上。核心思路是：把检索返回的上下文和标准答案一起喂给评判模型，让它判断生成答案是否忠实、是否完整。

这里不展开细节，只提一个衔接要点：检索指标和生成指标要能对上号。如果检索 hit_rate@5 是 0.87，但生成准确率只有 0.6，那说明有 27% 的情况是“捞到了但没答对”，问题出在生成端，可能是上下文太长被截断、prompt 没写好、或者模型能力不够。反过来，如果检索 hit_rate@5 只有 0.5，生成准确率却有 0.6，那要怀疑生成端是不是在“自由发挥”，答案可能根本没依据上下文。

我自己的习惯是每次优化完检索，先看检索指标涨没涨，再看生成指标跟没跟上。两个数一起看，才能定位问题到底在哪一层。这套流程跑顺之后，RAG 调优就从“玄学”变成了“工程”，每一步改动都有数据支撑，心里踏实得多。