K7 · 如何评估知识检索与回答质量？ - Retrieval Evaluation

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：04 · AI 如何获取和利用外部知识？ - Knowledge & Retrieval
文档类型：技术原理与工程实践研究
版本：v1.0
更新日期：2026 年 10 月 27 日
核心问题：如何分别评价检索系统、证据组织和模型回答的质量？Precision、Recall、MRR、MAP、nDCG、Faithfulness 与答案正确性如何定义和计算？如何构建具有代表性、可复现的评测集，诊断检索与生成的错误来源，并在权限、版本、延迟、成本等约束下持续验证 AI 知识库、RAG 与 Agent 的实际效果？

专题导读

当 AI 系统能够通过信息检索、向量数据库和 RAG 获取外部知识后，如何判断它是否找到了真正相关的信息、是否获得了足够的证据，以及最终回答是否准确可靠，就成为知识系统工程中不可缺少的质量评估问题。

本篇围绕 Retrieval Evaluation（检索与回答质量评估）展开研究，首先建立从查询理解、候选检索、结果排序、证据组织到答案生成和任务完成的分层评估框架，解释不同环节的质量问题如何影响最终结果。

在技术原理部分，系统研究 Precision、Recall、Hit Rate、MRR、MAP 和 nDCG 等经典信息检索指标的计算方法与适用条件，并进一步分析证据充分性、答案正确性、Faithfulness、完整性、引用准确性和拒答能力等 RAG 评估维度。

在工程实践部分，研究如何构建具有代表性的评测数据集，结合人工标注、自动化评估和 LLM-as-a-Judge 建立可复现的测试流程，并通过企业知识问答案例展示检索错误、证据缺失、模型生成错误和知识版本问题的诊断方法。

最后进一步讨论离线实验、线上评估、质量回归与持续监控，以及如何将这些方法扩展到 Agent 的多步骤知识检索与任务执行过程，建立从知识获取到最终任务结果的完整质量验证体系。

一、研究概述：评价的对象不是一个分数，而是一条证据链

K1—K6 已经分别讨论模型参数知识、Embedding、向量数据库、信息检索、RAG 与知识库工程。它们最终汇聚成一条实际业务链路：用户提出问题，系统确定信息需求，访问被授权的知识源，检索和选择证据，将证据交给模型，模型形成回答，用户依据回答采取行动。任何一个环节都可能失效，而且不同环节的失效会表现为相似的错误答案。

例如，员工询问“2026 年 10 月的差旅住宿上限是多少”。系统可能因为检索未找到新版制度而回答旧标准；可能已经找到新版，却在重排序时将旧版排在前面；可能将新旧两版都交给模型，模型选择了旧版；也可能回答数值正确，却引用了无权访问的内部附件。只统计“回答正确率”，无法识别这些故障，更无法指导修复。

**Retrieval Evaluation（检索评估）**在本知识库中采用较宽的工程定义：不仅评价检索结果与信息需求的匹配程度，还评价证据是否足以支持回答、生成结果是否忠于证据，以及整个知识应用是否符合业务约束。严格的信息检索学术语境中的 retrieval evaluation 主要关注检索质量；生成质量、安全和端到端任务成功率属于相邻的评估层。本篇把它们连接起来，是为了建立完整的 AI 知识系统评估方法，而不是将所有指标混为一谈。

本篇的核心立场是：先明确“什么叫成功”，再构建可追溯的评测样本；分层定位失败，再做端到端验收；所有质量提升都必须在相同数据、权限和成本条件下比较。

二、评估对象与边界：六层质量模型

一个典型知识问答系统可拆为以下评估层次：

用户问题 / 任务目标
        │
        ▼
[1 查询理解]   意图、实体、时间、约束是否识别正确？
        │
        ▼
[2 候选检索]   应该找到的文档/段落是否被召回？
        │
        ▼
[3 排序与选择] 正确证据是否排在可用的前列？
        │
        ▼
[4 证据组织]   内容是否充分、有效、授权、可追溯？
        │
        ▼
[5 答案生成]   回答是否正确、忠实、完整、可核验？
        │
        ▼
[6 任务结果]   用户是否真正完成任务，且满足时延/成本/安全约束？

查询理解关注问题改写是否改变原意，例如“今年”是否被解析为正确日期；候选检索关注能否找到必要证据；排序关注有限 Top-K 预算中的证据位置；证据组织关注去重、版本、权限与上下文容量；答案生成关注事实与证据关系；任务结果关注是否真正满足用户需求。生产系统还应对数据采集与索引的新鲜度、完整性做独立质量检查，因为“检索不到”也可能是知识根本没有进入索引。

需要明确三个边界。第一，Embedding 的向量相似度不是最终相关性真值；高余弦相似度只能说明某种表示空间中的接近程度。第二，检索相关不等于证据充分：一段文档可能主题相关，但缺少关键数值、例外条款或生效日期。第三，回答忠于证据不等于符合现实：模型可以准确复述一份过期文件。评价必须同时考虑证据支持、来源有效性和外部事实正确性。

三、先定义任务成功：从业务目标反推指标

评估设计应从实际任务出发，而不是从可用的自动化指标出发。FAQ 查询、政策合规问答、研究报告撰写、法律条款定位和多步 Agent 调研对“成功”的要求不同。

任务类型	关键成功条件	常用主指标	不可忽略的约束
单事实问答	回答正确且有有效依据	答案正确率、证据命中率	版本、引用、拒答
条款定位	找到全部必要条款	Recall@K、证据覆盖率	例外条款、权限
文献研究	证据覆盖不同观点与来源	分级相关性、nDCG、覆盖率	来源质量、重复率
内部知识助手	对授权用户给出有效答案	端到端成功率、越权泄漏率	ACL、删除同步
多跳问题	找到可组合的证据链	证据集合召回、任务成功率	推理链完整性
Agent 自动执行	依据正确证据完成行动	任务成功率、人工接管率	错误动作、成本

在风险较高的场景中，应设置硬性门槛：未经授权的资料不得出现；关键事实无依据时不得伪造引用；缺少必要证据时必须能够拒答或升级人工处理。平均分不能抵消安全违规。

评估对象还要区分三个粒度：文档（document）、段落或 Chunk（passage/chunk）、事实或证据单元（claim/evidence）。同一查询在文档层面召回正确，不意味着被送入模型的 Chunk 包含答案；同一答案可能需要来自多个 Chunk 的组合证据。因此，标注粒度必须与评估问题一致。

四、构建评测集：比选择指标更重要

一个可复现的评测样本至少应包含：query_id、原始问题、任务类型、时间与用户上下文、检索语料快照、授权主体、相关证据标识、相关性等级、必要证据集合、参考答案或事实清单、可接受的拒答条件，以及标注依据。对生成系统还要保存检索结果、实际注入模型的上下文、模型版本、提示模板和最终回答。

问题来源应混合真实用户查询（脱敏并取得合法使用依据）、专家编写的关键业务问题、历史失败案例和针对性压力样本。仅由模型自动生成“看起来像真实问题”的样本，容易产生措辞单一、答案过于直接、与语料过度贴合的偏差。

数据划分应至少区分开发集与锁定测试集。开发集用于选择分块策略、检索器和重排序参数；锁定测试集用于最终验收。若评估包含训练或微调，还需额外隔离训练数据，防止同一问答、相似模板或近重复文档跨集合泄漏。对于不断变化的知识库，还应设置按时间切分的评测集，专门测试新旧版本交替、撤销文档与生效日期。

样本覆盖应显式记录分层：简单/复杂、短/长问题、关键词完全匹配/同义改写、单跳/多跳、常见/长尾、包含表格或扫描件、跨语言、存在歧义、资料冲突、不可回答、无权限访问等。总体平均分要与分层结果同时报告，避免大批简单问题掩盖少数高风险问题。

标注原则：相关性可采用二元（相关/不相关）或多级（例如 0 不相关、1 部分相关、2 高度相关、3 直接且充分）标注。需要标注“足以支持答案”的证据时，不能只看主题是否相近。多跳问题应允许多个最小充分证据集合；不同证据组合可能同样正确。标注者应获得明确规则、来源版本、时间约束和冲突处理方式；双人标注与争议仲裁适用于关键样本。标注一致性（例如 Cohen's κ）可以辅助发现规范模糊，但不能代替事实复核。

4.1 评测样本结构示例

{
  "query_id": "travel-2026-017",
  "question": "2026年10月出差住宿标准是多少？",
  "as_of": "2026-10-27",
  "principal": "employee-demo",
  "corpus_snapshot": "kb-snapshot-2026-10-27",
  "task_type": "policy_fact_lookup",
  "relevant_passages": {"policy-v3:p18": 3, "policy-v2:p11": 0},
  "required_evidence_sets": [["policy-v3:p18"]],
  "reference_facts": ["以生效的 v3 制度为准", "具体上限按城市等级查询"],
  "answerability": "requires_city",
  "expected_behavior": "请求用户补充目的地城市等级，不能凭空给出统一金额"
}

以上为虚构教学样本。它强调：有时“正确答案”不是一个数字，而是识别信息不足并追问必要条件。

五、检索指标：Precision、Recall 与 Hit Rate

令某个查询的前 K 个检索结果集合为 $R_K$，相关文档集合为 $G$，则：

$$\mathrm{Precision}@\mathrm{K}=\frac{|R_K\cap G|}{K}$$$$\mathrm{Recall}@\mathrm{K}=\frac{|R_K\cap G|}{|G|}$$$$\mathrm{HitRate}@\mathrm{K}=\mathbb{1}(|R_K\cap G|>0)$$

多查询时，分别计算每个查询的指标，再取宏平均。Precision@K 衡量前 K 个结果的相关比例；Recall@K 衡量全部标注相关内容被覆盖的比例；HitRate@K 衡量是否至少找到一个相关结果。三者回答不同问题。

例如，某问题有 4 个相关段落，系统 Top-5 找到其中 2 个，且另外 3 个无关，则 Precision@5=2/5=0.4，Recall@5=2/4=0.5，HitRate@5=1。对只需一条充分证据的问答，HitRate 可能有用；对必须综合四份证据的研究任务，HitRate=1 并不代表完成检索。

分母陷阱：真实语料中通常无法穷举全部相关文档。若 G 只是有限标注池，则 Recall@K 是“相对于已标注相关集合的召回”，不能直接声称全库真实召回率。常见解决方法包括多系统结果池化、对新增结果补充人工判断、建立可审计的候选集合，并报告判断覆盖率。若某查询无相关文档，Recall 分母为零，应预先规定处理策略；通常将其单列为不可回答/无证据测试，不随意设成 1。

六、排序指标：MRR、AP/MAP 与 nDCG

6.1 MRR：首个正确结果出现得有多早

对查询 $q$，首个相关结果的排名为 $r_q$，则 $R{R}_q=1/r_q$；若检索范围内没有相关结果，则为 0。多查询平均得到：

$$\mathrm{MRR}=\frac{1}{|Q|}\sum _{q\in Q}\frac{1}{r_q}$$

MRR 适合“找到第一个正确答案即可”的任务。若正确结果分别排第 1、2、5 位，对应倒数排名为 1、0.5、0.2。它不评价第二条及之后的相关结果，因此不适合独立衡量多证据覆盖。

6.2 AP 与 MAP：相关结果在整个排序中的分布

对有 $|G_q|>0$ 个相关结果的查询，Average Precision 可写为：

$$AP(q)=\frac{1}{|G_q|}\sum _{k=1}^{N}P@k\cdot rel(k)$$

其中 $rel(k)$ 为第 k 位是否相关。若只评估截断 Top-K，应明确使用 AP@K 的定义和分母约定。MAP 是各查询 AP 的平均值。MAP 对多个相关结果的位置敏感，适合系统性检索；但同样依赖相关性标注的覆盖程度。

6.3 nDCG：不同相关程度如何加权

当标注包含等级 $g_i$ 时，可使用折扣累计增益：

$$DCG@K=\sum _{i=1}^K\frac{2^{g_i}-1}{{\log }_2(i+1)}$$$$nDCG@K=\frac{DCG@K}{IDCG@K}$$

IDCG 是理想排序的 DCG。nDCG 在理想排序有正增益时位于 0 到 1 之间，适合区分“高度相关”和“略微相关”的文档。若所有候选均标为 0，分母为 0，应按既定规则单独处理。

指标选择原则：单答案定位优先关注 HitRate、MRR 和正确证据位置；多证据研究优先关注 Recall、MAP、nDCG 与证据覆盖；上下文预算很紧时，还应关注前几个结果的高等级相关性与冗余率。不要把不同任务的指标机械加权成一个“万能分”。

七、从相关性到证据充分性：RAG 必须增加的评价

RAG 中的检索器即使返回高相关段落，仍可能缺少回答所需的条件。例如问题“哪些员工可以申请例外报销”，返回“报销标准”总则虽相关，但不包含“例外审批流程”。因此，需要在相关性之外评估证据充分性（evidence sufficiency）。

一种可操作的标注方法是：为每个问题列出回答所需的原子事实与最小充分证据集合。对系统实际送入模型的上下文 $C$，检查是否存在一个完整证据集合 $S_j\subseteq C$。若存在，记 Sufficiency=1；否则为 0。对于多条件问题，还可计算已覆盖必要事实的比例，但要注意不同事实的重要性并不相同。

**证据精度（context precision）**可以衡量注入上下文中真正有帮助的内容比例；**证据召回（context recall）**可以衡量参考答案所需事实是否被上下文覆盖。这些名称在不同评测框架中可能采用不同的实现与判定方法，报告时必须给出操作性定义，不能只写指标名。

还应检测：重复 Chunk 是否占用预算、文档标题和表格表头是否丢失、引用是否定位到原始来源、证据是否已过期、用户是否有权访问、是否存在来源冲突。证据选择是一项独立工程环节，不应完全归因于检索器。

八、回答质量：Correctness、Faithfulness、Completeness 与 Citation

答案正确性（Answer Correctness）：回答是否符合任务事实、参考答案或权威来源。它关注“对不对”。对于开放性任务，可把回答拆成可核验的事实断言，逐条判断，而不是简单字符串匹配。

证据忠实度（Faithfulness / Groundedness）：回答中的事实性断言是否得到提供给模型的证据支持。它关注“是不是根据这些材料说的”。即使答案碰巧正确，如果引用材料没有支持该结论，仍不应视为良好的证据化回答。

完整性（Completeness）：是否覆盖任务所需的关键事实、限定条件和例外情况。回答可能每句话都正确，但漏掉重要条件。

引用准确性（Citation Accuracy）：引用是否指向真实存在、用户有权访问、版本正确且实际支持对应断言的资料。引用格式存在不代表引用正确；应检查“断言 → 引用 → 原文片段”的映射。

拒答与不确定性（Abstention / Calibration）：证据不足时是否明确说明缺口，必要时提出澄清问题；证据充分时是否避免过度拒答。对不可回答样本，应同时衡量正确拒答率与误拒答率。若系统输出置信度，还需验证校准程度，不能把模型自报“90%确信”直接当成真实概率。

举例：模型说“差旅住宿上限为 800 元，见制度 v2”。若当前有效制度为 v3，且 v2 已撤销，则答案可能同时存在时效性错误和引用有效性错误；若 v3 恰好也写 800 元，但模型引用 v2，事实数值可能正确，引用依然不合格。评价时应保留多维标签，而不是用单一“对/错”遮蔽原因。

九、自动化评估与 LLM-as-a-Judge：便利性和局限

自动化评估可以使用三类方法。第一类是确定性检查，如 JSON 结构、引用 ID 存在性、文档版本、权限策略、数值字段和精确字符串匹配；结果可复现，但语义覆盖有限。第二类是基于模型或语义的评估，如句子相似度、自然语言推断或模型判断；可处理表达变化，但存在误判。第三类是人工专家评估，适合复杂推理、隐含条件、行业知识和高风险场景，但成本较高。

LLM-as-a-Judge 可按明确评分规则审查回答正确性、证据支持和完整性，但其输出仍是一个模型判断，不是客观真值。常见偏差包括：偏好冗长答案、受措辞和顺序影响、对同类模型输出产生偏好、无法识别细小数值错误、对隐含知识做无证据补全。必须为评审模型提供独立证据、固定评分标准、保存版本与提示，并通过人工标注集测量评审器与专家的一致性及错误类型。

建议采用分层评审：先用确定性规则筛掉无效引用、越权结果和结构错误；再用自动化语义评估覆盖大规模回归；最后对争议、高风险、低置信度或抽样结果进行人工复核。不要让被评估的系统自行选择证据并完全自行裁判正确性。

十、故障归因：把错误定位到具体组件

端到端失败后，应依次检查：

1. 知识是否存在：目标事实是否进入当前有效语料？解析是否正确？是否有索引延迟或删除残留？
2. 检索是否召回：在相同权限、过滤条件下，目标证据是否出现在候选 Top-N？
3. 重排序是否保留：目标证据是否被 reranker 降权或截断？
4. 上下文是否包含：正确 Chunk 是否实际传入模型？是否因 Token 预算被裁掉？
5. 模型是否正确使用：模型是否忽略限定条件、混淆来源、引入无依据断言？
6. 最终输出是否合规：引用、格式、权限、拒答和业务动作是否符合约束？

这套“漏斗式归因”可对应明确的修复动作：缺数据先修采集，召回不足先修索引或查询，排序失败先修 reranker，证据不足先修分块与上下文构建，生成不忠实再调整提示、模型或验证策略。避免所有失败都归因于“模型不够聪明”。

10.1 反事实诊断：Oracle 实验

为了隔离组件，可以开展受控的 Oracle 实验：给生成器人工确认的正确证据，测量其在“理想检索”条件下的表现；或者保留真实检索结果，只替换重排序策略。若正确证据下模型仍回答错误，生成环节有独立问题；若正确证据下回答明显改善，则优先优化上游。Oracle 只是诊断上限，不代表真实系统可以自动获得完美证据。

十一、离线实验：基线、对照组与显著性

评估一次优化时，应保持查询集、语料快照、权限上下文和参考标注不变。常见对照组包括：BM25、Dense Retrieval、BM25+Dense 融合、融合后重排序；也可以比较不同 Chunk 大小、Embedding 模型、Top-K、上下文裁剪策略。一次实验尽量只改变一个主要因素，否则难以归因。

对于每个配置，保存查询级结果，而不只是全局均值。对同一批查询使用配对比较，并报告绝对差值、相对变化、分层结果及不确定性。样本量允许时，可通过按查询重采样的 bootstrap 估计置信区间；若进行大量参数尝试，应保留独立测试集，避免测试集被反复调参污染。

一个示意性实验表如下（数字为教学假设）：

方案	Recall@5	nDCG@5	证据充分率	P95 检索延迟	每千次查询成本
BM25	0.68	0.61	0.55	45 ms	低
Dense	0.72	0.65	0.60	70 ms	中
Hybrid + Rerank	0.82	0.76	0.71	165 ms	较高

不能据此得出“Hybrid + Rerank 永远最好”。如果业务 P95 预算为 100 ms，第三种方案可能不合格；如果关键问题要求证据覆盖率至少 0.8，三个方案都未达到目标。质量评估必须结合服务等级目标和风险阈值。

十二、在线评估：用户行为与真实任务成功率

离线评估适合可复现对照，但不等于真实用户满意度。上线后应记录经过隐私和权限处理的查询类型、检索候选、证据版本、模型输出、错误类别、用户反馈、响应时延、成本和人工接管结果。用户点击、复制或继续追问可以作为行为信号，却不能直接当作事实正确性的证明。

线上 A/B 测试应按稳定随机单位分流，保证权限与知识快照条件可比，并预先定义主指标与护栏指标。对于高风险知识服务，不宜仅凭点击率提升放行；应监控越权泄漏、错误引用、过期知识、错误拒答、P95/P99 延迟与预算超限。必要时采用灰度发布、影子流量、人工审批和可回滚策略。

长期运行还需要漂移监控：新文档格式可能降低解析质量，Embedding 模型升级可能改变向量空间，用户查询分布可能转向新领域，业务制度可能发生版本变化。评测集应包含稳定核心集、近期真实样本和新发现的失败回归集，既能横向比较，又能反映当前业务。

十三、权限、时效性与安全：必须独立评估的硬约束

在企业知识库中，检索结果“相关”但“未授权”不是部分成功，而是安全失败。应设计跨租户、跨部门、撤销权限、共享链接、缓存复用和日志暴露等负向测试，验证权限过滤在检索、重排序、缓存、引用解析和最终输出的每一环都有效。模拟攻击样本只能验证指定路径，不等于系统已通过安全审计。

知识时效性测试应覆盖：新版本发布但索引未更新、旧版本被撤销、未来生效文件、同名不同日期文档、删除后的残留 Chunk、引用指向历史快照等。对时间敏感问题，应评价系统是否使用查询要求的 as-of 时间，而非机械选择最新文件。

还应纳入提示注入与恶意内容测试。外部文档可能包含“忽略之前指令”等文本；它们属于待分析数据，不能自动提升为系统指令。评估应检查模型是否错误执行文档中的指令、是否泄漏隐藏上下文、是否调用未经授权的工具。此类安全测试与传统 Recall/nDCG 是不同维度，不应混成一个质量分。

十四、工程实现：最小可复现离线评测器

下面的 Python 示例仅依赖标准库，计算二元相关性下的 Precision@K、Recall@K、HitRate@K、MRR@K、AP@K，以及分级相关性的 nDCG@K。示例不调用 LLM、Embedding API 或真实数据库，适合检查指标定义和建立小规模评测基线。

from math import log2


def evaluate(ranked_ids, relevant_ids, grades, k=5):
    if k <= 0:
        raise ValueError("k must be positive")
    ranked = list(ranked_ids[:k])
    if len(ranked) != len(set(ranked)):
        raise ValueError("duplicate result IDs are not allowed")
    gold = set(relevant_ids)
    if not gold:
        raise ValueError("queries without relevant items need a separate policy")

    hits = [int(doc in gold) for doc in ranked]
    hit_count = sum(hits)
    precision = hit_count / k
    recall = hit_count / len(gold)
    hit_rate = float(hit_count > 0)
    first_rank = next((i for i, h in enumerate(hits, 1) if h), None)
    rr = 1 / first_rank if first_rank else 0.0

    running = 0
    ap_numerator = 0.0
    for i, hit in enumerate(hits, 1):
        if hit:
            running += 1
            ap_numerator += running / i
    ap_at_k = ap_numerator / len(gold)

    def dcg(values):
        return sum((2 ** grade - 1) / log2(i + 1)
                   for i, grade in enumerate(values, 1))

    actual_grades = [grades.get(doc, 0) for doc in ranked]
    ideal_grades = sorted(grades.values(), reverse=True)[:k]
    ideal = dcg(ideal_grades)
    ndcg = dcg(actual_grades) / ideal if ideal else 0.0
    return {
        "precision_at_k": precision,
        "recall_at_k": recall,
        "hit_rate_at_k": hit_rate,
        "rr_at_k": rr,
        "ap_at_k": ap_at_k,
        "ndcg_at_k": ndcg,
    }


if __name__ == "__main__":
    result = evaluate(
        ranked_ids=["d3", "d1", "d4", "d2", "d5"],
        relevant_ids={"d1", "d2", "d6"},
        grades={"d1": 3, "d2": 2, "d6": 1},
        k=5,
    )
    assert result["precision_at_k"] == 2 / 5
    assert result["recall_at_k"] == 2 / 3
    assert result["hit_rate_at_k"] == 1.0
    assert result["rr_at_k"] == 1 / 2
    assert abs(result["ap_at_k"] - ((1 / 2) + (2 / 4)) / 3) < 1e-12
    assert 0 <= result["ndcg_at_k"] <= 1
    print(result)

此处 AP@K 采用“在前 K 名累积精度贡献，分母为全部已标注相关文档数”的约定。部分工具库使用其他截断分母约定，跨工具比较前必须统一定义。Precision@K 以固定 K 为分母；当实际返回少于 K 条时，这是一种对未返回位置按不相关处理的选择，报告中需说明。nDCG 的理想排序基于 grades 字典包含的所有已标注文档；若存在未标注结果，应先处理不完整标注，而非直接将未知一律当作不相关。

14.1 工程化评测数据流

固定知识快照 + 固定用户权限 + 固定问题集
                  │
                  ▼
           执行多种检索配置
                  │
                  ▼
      保存 Top-N ID / 排名 / 分数 / 延迟
                  │
                  ▼
       与人工标注的证据集合匹配
                  │
                  ▼
          计算检索与排序指标
                  │
                  ▼
       将真实上下文传入固定生成器
                  │
                  ▼
     校验断言、引用、正确性与忠实度
                  │
                  ▼
         按问题类型分析失败原因
                  │
                  ▼
           生成可追溯实验报告

工程实现中建议将每次实验标记为不可变的 run_id，记录代码提交、索引版本、Embedding 版本、reranker 版本、模型参数、随机种子、数据快照与评测器版本。对于无法完全确定性的模型输出，应重复运行或至少报告采样设置与波动范围。

十五、完整案例：企业制度知识问答如何验收

假设一个组织建立了差旅制度知识库，文档包含多个年度版本、地区差异和审批例外。希望上线一个可以回答“出差住宿报销标准”的助手。此案例为虚构设计，不包含真实企业数据。

阶段一：定义问题与风险。 把问题分成标准查询、例外审批、跨地区、历史时点、信息不足、无权限访问六类。确定必须给出有效制度版本和引用；目的地未知时应澄清；查询未授权资料时不得泄漏。

阶段二：建立金标准。 每条问题保存查询时点、授权角色、正确制度版本、必要条款、关键条件、预期回答行为。对“不同城市不同标准”的问题，金标准不是某个固定金额，而是要求先获取城市等级。

阶段三：建立检索基线。 分别运行 BM25、Dense 和 Hybrid；先测 Recall@10，再测 nDCG@5 与必要证据充分率。如果新版条款没有被召回，检查索引和过滤；如果召回但排序靠后，检查重排序；如果引用只定位到整份 PDF，改进段落级溯源。

阶段四：测生成质量。 固定检索上下文，评估答案是否引用正确版本、是否漏掉审批条件、是否混合旧版与新版、是否在缺少城市时错误给出金额。再用 Oracle 证据测生成器上限，以区分检索问题与生成问题。

阶段五：设置上线门槛。 例如：关键条款的证据充分率达到预定阈值；越权访问负向测试必须全部通过；错误版本引用必须为零；P95 延迟不超过业务预算。具体阈值由业务风险、数据规模与用户体验决定，不能照搬通用数字。

阶段六：持续回归。 新制度发布、权限变更、解析器升级、Embedding 更换和提示修改，都触发相关评测子集。发生错误时，将其转化为有证据标注的新回归样本，并记录修复原因。

这一案例说明：评估不仅是一份上线前的分数报告，更是知识库从建设、发布到维护的工程反馈机制。

十六、Agent 与 Agent System 中的评估扩展

Agent 可能主动决定何时检索、检索几次、是否换用网页搜索、是否核验冲突来源，以及何时停止。因此，单轮 RAG 指标不能完整描述 Agent 的知识利用能力。还应评价：检索触发决策（该查时是否查、不该查时是否浪费调用）、多步证据链（是否找到完成任务所需的全部证据）、来源选择（是否选择权威且授权的来源）、行动结果（是否基于证据正确调用工具）以及成本效率（每个成功任务消耗的 Token、检索请求、时间和费用）。

可以将一次 Agent 运行记录为轨迹：任务输入 → 检索决策 → 查询 → 检索结果 → 证据选择 → 中间结论 → 工具调用 → 最终产出。评估时分别检查每一步是否必要、是否有依据以及是否导致错误。轨迹中的“推理文本”不应被直接视为模型真实内部推理过程的可靠证明；可审计的是可观测操作、输入输出和证据关联。

在 Agent System 中，多个 Agent 可能共享知识服务。需要进一步检查租户隔离、跨 Agent 缓存、统一引用标识、版本一致性、资源配额和失败恢复。检索组件指标可作为基础服务 SLI，但最终仍应以任务级成功率和治理约束验收。这些更大范围的系统测试将在 Agent System 的 H3 Evaluation、H9 Data Governance 与 H10 Testing & Validation 中展开。

十七、常见误区与反例

误区一：Recall@K 越高，最终回答一定越好。 召回提高可能同时带来更多噪声，挤占上下文并增加模型混淆；必须联合评估排序、证据充分性和答案质量。

误区二：相似度高就说明证据可信。 相似度无法证明来源有效、版本正确或事实真实。

误区三：有引用就代表没有幻觉。 引用可能不存在、指向错误版本，或者根本不支持断言。

误区四：模型评分可以完全代替人工评审。 自动评审需要校准、抽样复核和错误审计，尤其是高风险问题。

误区五：一个总体平均分足够判断上线。 长尾问题、越权访问、过期文档和不可回答样本可能被平均值掩盖。

误区六：测试集越大就一定越好。 大量重复、泄漏或低质量标注样本可能增加虚假的确定性；代表性与标注质量同样关键。

误区七：离线指标提升就可以直接全量发布。 线上延迟、成本、真实用户查询分布和安全边界可能改变结论。

误区八：评估只在系统建成后进行。 数据解析、索引、权限、版本、检索和生成都需要各自的测试与回归机制。

十八、实施路线：从最小基线到持续质量治理

第一阶段：定义任务与金标准。 选取真实高频问题与关键风险问题，固定语料快照，明确相关性等级、必要证据、正确回答和拒答条件。先做小而可信的人工标注集。

第二阶段：建立可复现检索评估。 从 BM25 或现有检索器开始，保存 Top-K 结果，计算 Recall、MRR、nDCG 与证据充分性。建立错误归因标签。

第三阶段：引入生成评估。 对相同检索上下文测试答案正确性、忠实度、完整性、引用有效性和拒答行为；设置人工抽检。

第四阶段：进行受控优化。 对比 Dense、Hybrid、reranker、分块和上下文策略。记录质量、延迟、成本与风险的 Pareto 取舍。

第五阶段：建立上线与回归机制。 将核心评测集纳入 CI 或发布流程，监控知识版本、权限与时效性，建立错误样本回流和灰度回滚机制。

该路线适合从小型知识助手逐步扩展到多知识源、多租户的 Agent System；复杂度随风险和规模增加，而不是从一开始就引入所有评估框架。

十九、研究总结与后续关系

K7 完成了 Knowledge & Retrieval 章节的闭环：K1 解释模型内部知识，K2 解释向量表示，K3 解释向量索引与数据库，K4 解释信息检索，K5 解释检索增强生成，K6 解释知识库建设，而 K7 负责判断整个系统是否真正找到、正确使用并可靠管理了知识。

本篇最重要的结论是：检索质量、证据充分性、答案质量和任务成功率必须分层评估，并在同一知识快照、权限上下文和实验条件下进行可复现比较。 任何单一指标都无法替代完整的证据链质量管理。下一阶段进入 Agent 技术研究时，这些方法将成为评估 Agent Knowledge、Memory、Tools 与多步任务执行的重要基础。

二十、参考文献与延伸阅读

以下资料作为方法与理论研究入口；经典论文与教材可用于定义基础指标，框架实现细节仍应以部署时的实际版本为准。

1. Manning, C. D., Raghavan, P., & Schütze, H. (2008). Introduction to Information Retrieval. Cambridge University Press. https://nlp.stanford.edu/IR-book/ —— Precision、Recall、MAP、nDCG、相关性判断与信息检索实验设计。
2. Järvelin, K., & Kekäläinen, J. (2002). Cumulated Gain-Based Evaluation of IR Techniques. ACM Transactions on Information Systems. https://doi.org/10.1145/582415.582418 —— 分级相关性与 DCG/nDCG 的经典研究。
3. Voorhees, E. M., & Harman, D. K. (eds.). (2005). TREC: Experiment and Evaluation in Information Retrieval. MIT Press. —— 测试集合、相关性判断和共享检索评测传统。
4. Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS. https://arxiv.org/abs/2005.11401 —— RAG 的检索与生成联合建模。
5. Karpukhin, V., et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP. https://arxiv.org/abs/2004.04906 —— Dense Retriever 的评估与开放域问答。
6. Es, S., et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. arXiv:2309.15217. https://arxiv.org/abs/2309.15217 —— RAG 检索与生成自动化评估的研究方向；具体指标定义应以对应版本为准。
7. Saad-Falcon, J., et al. (2023). ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems. arXiv:2311.09476. https://arxiv.org/abs/2311.09476 —— 结合自动化判断与标注校准的 RAG 评估框架。
8. Liu, N. F., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics. https://arxiv.org/abs/2307.03172 —— 长上下文证据位置与利用效果。
9. Gao, Y., et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997. https://arxiv.org/abs/2312.10997 —— RAG 架构、技术分类与评估问题综述。
10. NIST (2023). AI Risk Management Framework 1.0. https://www.nist.gov/itl/ai-risk-management-framework —— 风险治理、测试与持续监控的一般性框架。

二十一、研究声明

研究与验证说明： 本文基于信息检索经典教材、公开研究论文以及 K1—K6 已建立的知识检索工程脉络组织。所有企业差旅制度、评测 JSON、指标表格和业务阈值讨论均为教学假设，不代表真实组织政策或任何产品的实测表现。正文公式采用明确的操作性定义；不同评估库可能对 AP@K、空相关集合、未标注结果及上下文指标使用不同约定，使用时必须统一。

最新性状态： 研究更新日期为 2026 年 10 月 27 日。文献为可追溯的公开研究入口；本次未逐项在线核验所有论文页面、评估框架最新版本、接口变化或最新基准成绩，因此不将框架功能与性能表述为已完成实时核验。实际实施前应复核官方文档、许可条款和评估器版本。

实验与测试边界： Python 代码为不依赖网络的离线指标演示，验证情况以本次实际本地执行结果为准；未进行真实向量数据库部署、RAG 模型调用、专家标注一致性实验、线上 A/B 测试或生产负载测试。文中的延迟、召回率和成本对比仅用于解释评估方法，不是可迁移的行业基准。