m205. RAG 生产环境：索引运维与评估体系

RAG 不是”搭好就完了”，它是一个需要持续维护和迭代的系统。本章覆盖索引的生命周期管理，以及如何系统性地衡量 RAG 质量。

2.3.5 索引构建、更新与运维

增量索引

新文档入库不需要重建全部索引，支持：

新增文档独立索引并合并
文档更新时：旧 chunk 删除 + 新 chunk 插入
过期文档的索引清理（定期 TTL 检查）

版本管理：同一文档多版本时，标记版本信息（检索结果注明”此信息来自 v2.0”），并决定是否保留旧版索引（有时旧版本有历史查询价值）。

索引监控指标（运维必须追踪）

指标	含义	异常信号
检索命中率	query 至少命中一个相关 chunk 的比例	下降 → 知识库覆盖出现空白
空结果率	完全没有命中的 query 比例	上升 → 需要补充知识库内容
Chunk 引用频率分布	每个 chunk 被检索引用的次数	零引用 chunk → 可能是冗余或错误入库
Embedding Drift	新旧 chunk 的 Embedding 分布差异	大量更新后需重新评估 Embedding 模型效果

PM 的意义：索引监控数据是产品迭代的基础信号。“哪些问题始终答不好” = 空结果率高的 query 类型 = 知识库扩充的优先级队列。

知识库冷启动策略

如果是全新知识库（无历史 query 数据），优先级：

梳理用户最高频的 20 个问题，确保这些问题的相关文档全部入库
分析现有客服/用户反馈，找到最常见的困惑点
上线后打开空结果日志，按频率补充缺失内容

2.3.6 RAG 评估体系（生产级）

模块一提出了”检索-生成评估解耦”的原则（c09 §9.6）。本节给出具体的评估框架。评估体系的设计与 c14 Goodhart 陷阱的防御逻辑相通——指标必须真正反映业务目标。

RAGAS 框架（当前最主流的 RAG 评估框架）

RAGAS 定义了四个核心指标：

指标	测量什么	直觉解释
Faithfulness（忠实度）	生成的回答是否完全基于检索到的内容（防幻觉）	回答中每个声明是否都能在检索结果中找到支持
Answer Relevancy（回答相关性）	回答是否真正回答了用户的问题	从回答反向生成问题，看与原始问题的相似度
Context Precision（上下文精度）	检索到的内容中，相关内容是否排在前面	相关 chunk 在 Top-K 中的排名
Context Recall（上下文召回率）	回答所需的所有信息是否都被检索到	标准答案中的每个要点是否至少有一个检索结果覆盖

评估的工程实践

① 构建黄金评估集（最高优先级投资）

从真实用户 query 中采样 200–500 条，人工标注标准答案。这是 RAG 评估的基础设施投资——没有评估集，一切优化都是盲调。

② 自动化评估管线

用 LLM-as-Judge（详见 c14 §14.2 LLM-as-Judge 偏见）自动化 RAGAS 评估，集成到 CI/CD 中。每次修改以下内容后自动跑评估：

Chunking 策略调整
Embedding 模型切换
Reranker 升级
检索参数（Top-K、相似度阈值）修改

③ 分层诊断逻辑

检索指标差（低 Recall / Precision）
    → 先优化检索：[Embedding](/kb/基础知识库/embedding/)模型、chunking 策略、混合检索、Reranker

检索指标好，但生成指标差（低 Faithfulness）→ [幻觉](/kb/基础知识库/幻觉/)风险高
    → 优化 Prompt 或切换生成模型

检索指标好，生成指标好，但业务指标差
    → 问题出在评估指标定义上，重新审视"什么是好回答"（见 [c14 Goodhart 定律](/kb/基础知识库/c14-模型评估体系与-goodhart-陷阱/)）

评估工具生态

工具	核心能力	适用场景
RAGAS（库）	自动化四核心指标计算	任何 RAG 系统
LangWatch	RAG 评估 + tracing + 质量监控	RAG 重度用户
Arize Phoenix	开源 LLM observability、Embedding 可视化	自建、开源偏好
LangSmith	LLM 调用 tracing、prompt 调试	LangChain 生态内

PM 的操作建议：每次产品迭代（调整知识库内容、修改 Prompt、升级模型）前后都跑一次评估。把评估分数的变化作为迭代效果的核心衡量依据，而非主观感受。

相关概念卡：RAG、Embedding、幻觉与校准上一章：m204 Chunking 与范式演进下一章：m206 Agent 记忆与技术进展

m205 - RAG 生产环境：索引运维与评估体系