AI Day 21
AI Day 21: 生产级RAG(3)：评估体系与持续迭代 — 用数据驱动RAG优化
RAG评估与持续迭代是让RAG系统从"能用"走向"好用"的工程闭环——通过系统化的指标度量(Faithfulness/Relevancy/Precision/Recall)、自动化评估流水线(LLM-as-Judge)、幻觉检测与治疗，以及数据驱动的诊断-优化循环，使RAG系统在生产环境中持续演进。没有评估体系的RAG，就像没有回测的量化策略——你以为它在赚钱，其实可能一直在亏。
2026-04-22
RAGRAGASFaithfulnessHallucinationLLM-as-JudgeTruLensDeepEvalArizeGoldenNLIGroundingRAGContinuous
日期：2026-04-22
阶段：第二阶段 — 工程实践 (Day 16-30)
标签：RAG Evaluation RAGAS Faithfulness Hallucination Detection LLM-as-Judge TruLens DeepEval Arize Phoenix Golden QA NLI Grounding Score RAG Maturity Model Continuous Iteration
学习路径树
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│ ├── Day 1: Transformer架构与LLM基础 ✅
│ ├── Day 2: 模型量化与本地部署 ✅
│ ├── Day 3: 训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│ ├── Day 4: Prompt Engineering与上下文学习(ICL)原理 ✅
│ ├── Day 5: RAG架构：检索增强生成全链路 ✅
│ ├── Day 6: 向量数据库与Embedding模型 ✅
│ ├── Day 7: Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│ ├── Day 8: 推理优化：vLLM / TensorRT-LLM / SGLang ✅
│ ├── Day 9: 长上下文技术：RoPE扩展 / Ring Attention ✅
│ ├── Day 10: 多模态模型：Vision-Language架构 ✅
│ ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking ✅
│ ├── Day 12: Agent框架：ReAct / Tool Use / Planning ✅
│ ├── Day 13: MCP协议与Tool生态 ✅
│ ├── Day 14: 模型评估：Benchmark / Arena / 安全评估 ✅
│ └── Day 15: 阶段复习与架构总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30)
│ ├── Day 16: LLM应用架构设计 — API Gateway/路由/缓存 ✅
│ ├── Day 17: LLM安全与Guardrails — 生产环境防护体系 ✅
│ ├── Day 18: LLM可观测性 — 日志/Tracing/指标/告警 ✅
│ ├── Day 19: 生产级RAG(1) — 文档解析与Chunking工程 ✅
│ ├── Day 20: 生产级RAG(2) — Retrieval优化与Reranking ✅
│ ├── Day 21: 生产级RAG(3) — 评估框架与持续迭代 ← 你在这里
│ ├── Day 22-25: Agent系统工程化（状态管理/错误恢复/成本控制）
│ └── Day 26-30: 多模型编排/部署策略/端到端项目
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│ ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│ └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念
一句话定义
RAG评估与持续迭代是让RAG系统从"能用"走向"好用"的工程闭环——通过系统化的指标度量(Faithfulness/Relevancy/Precision/Recall)、自动化评估流水线(LLM-as-Judge)、幻觉检测与治疗，以及数据驱动的诊断-优化循环，使RAG系统在生产环境中持续演进。没有评估体系的RAG，就像没有回测的量化策略——你以为它在赚钱，其实可能一直在亏。
金融类比
RAG评估体系 = 信贷模型回溯测试(Backtesting) —— 不是上线就完了，要持续监控并迭代
信贷模型管理: RAG系统管理:
├── 模型开发 ├── RAG开发
│ ├── 训练集/验证集/测试集划分 │ ├── 评估数据集(Golden QA)构建
│ ├── KS值/AUC/Gini系数评估 │ ├── RAGAS四维指标评估
│ ├── 模型上线前的审批(Model Validation) │ ├── 上线前的评估Gate(质量阈值)
│ └── 上线部署 │ └── 上线部署
│ │
├── 模型监控 ├── RAG监控
│ ├── PSI(群体稳定性指标)监控 │ ├── 回答质量分数趋势监控
│ ├── Vintage Analysis(逾期率追踪) │ ├── 幻觉率趋势追踪
│ ├── 特征漂移(Feature Drift)检测 │ ├── 知识漂移(文档更新导致答案过时)检测
│ └── 模型效能衰退预警 │ └── RAG效能衰退预警
│ │
├── 模型迭代 ├── RAG迭代
│ ├── 冠军-挑战者(Champion-Challenger) │ ├── A/B测试(新Prompt/新Retrieval策略)
│ ├── 定期重新训练 │ ├── 定期重新索引/参数调优
│ ├── 回溯测试(Backtesting) │ ├── 回归测试(评估集版本化)
│ └── 模型退役与替换 │ └── 组件替换(换Embedding/换Reranker)
│ │
└── 核心原则: └── 核心原则:
没有回测的模型不能上线 没有评估的RAG不能上线
模型上线≠万事大吉，持续监控才是常态 RAG上线≠万事大吉，持续迭代才是常态
监管要求至少年度回溯 最佳实践至少月度评估
→ 巴塞尔协议的Model Risk Management → RAG的Evaluation-Driven Development
Day 19-20-21 三天RAG深潜总结
Day 19: 数据层 — 文档解析与Chunking
→ 解决"原始数据如何变成高质量的知识片段"
→ 解析质量决定RAG的理论上限
Day 20: 检索层 — Retrieval优化与Reranking
→ 解决"如何从海量Chunk中精准找到用户需要的"
→ Hybrid Search + Reranking逼近理论上限
Day 21: 评估层 — 评估体系与持续迭代 ← 今天
→ 解决"如何知道RAG好不好、坏在哪、怎么改"
→ 没有评估，前两天的优化都是盲人摸象
→ 评估驱动的迭代循环 = RAG的长期生命力
知识点1: RAG评估框架 — RAGAS四维指标
为什么要单独的RAG评估框架
传统NLP评估(BLEU/ROUGE)的局限:
├── 只比较字面相似度，不理解语义
├── 无法检测"说得流畅但内容错误"的幻觉
├── 无法区分"检索没找到"还是"生成没用好"
└── 不适用于开放式生成任务
RAG特有的评估挑战:
├── 双模块问题: 检索器(Retriever)和生成器(Generator)哪个出了问题？
├── 忠实性问题: 回答是否忠于检索到的上下文？(还是LLM自己编的)
├── 相关性问题: 检索到的内容和问题相关吗？回答和问题相关吗？
└── 完整性问题: 回答是否覆盖了所有必要信息？
→ 需要一套专门为RAG设计的评估框架
→ RAGAS (Retrieval Augmented Generation Assessment) 是2024-2026最主流的开源方案
RAGAS四维评估体系
┌──────────────────┐
│ 用户Query │
└────────┬─────────┘
│
┌────────▼─────────┐
│ 检索器Retriever │
└────────┬─────────┘
│
┌────────▼─────────┐
│ 检索到的Context │◄─── Context Precision: 检索结果中有用的比例
│ (多个Chunk) │◄─── Context Recall: 是否检索到了所有必要信息
└────────┬─────────┘
│
┌────────▼─────────┐
│ 生成器Generator │
└────────┬─────────┘
│
┌────────▼─────────┐
│ 最终Answer │◄─── Faithfulness: 回答是否忠于Context
│ │◄─── Answer Relevancy: 回答是否回答了Query
└──────────────────┘
指标1: Faithfulness (忠实度)
定义: 回答中的每个声明(claim)是否都能从检索到的Context中找到支撑？
计算方式:
Faithfulness = (Context支持的Claim数) / (回答中的总Claim数)
Step 1: 从Answer中提取所有事实声明(claims)
Answer: "招商银行2025年净利润为1200亿元，同比增长5.3%，不良贷款率为0.95%。"
Claims:
c1: 招商银行2025年净利润为1200亿元
c2: 同比增长5.3%
c3: 不良贷款率为0.95%
Step 2: 逐个验证每个claim是否被Context支持
Context: "招商银行2025年年报显示，全年实现净利润1198.5亿元，
同比增长5.3%。资产质量持续改善，不良贷款率为0.95%..."
c1: 1200亿 vs 1198.5亿 → 不精确，但近似 → 部分支持(严格模式:不支持)
c2: 5.3% → Context明确包含 → 支持
c3: 0.95% → Context明确包含 → 支持
Step 3: 计算
Faithfulness = 2/3 = 0.67 (严格模式)
= 3/3 = 1.0 (宽松模式，允许四舍五入)
优化方向:
├── 低Faithfulness → LLM在"编造"信息
├── 检查Prompt是否明确要求"仅基于提供的信息回答"
├── 检查是否需要更多Context(信息不够LLM只能猜)
├── 考虑Post-processing: 回答生成后做NLI校验
└── 金融场景: 数字精度要求极高，"约1200亿"vs"1198.5亿"可能不可接受
指标2: Answer Relevancy (答案相关性)
定义: 回答是否直接回答了用户的问题？(不跑题、不答非所问)
计算方式(RAGAS实现):
1. 用LLM从Answer反向生成N个可能的问题
2. 计算这N个生成问题与原始Query的语义相似度
3. Answer Relevancy = mean(cosine_similarity(generated_questions, original_query))
直觉:
如果Answer确实回答了Query，那么从Answer反推出来的问题应该和原始Query很像
如果Answer跑题了，反推出来的问题自然和原始Query不同
示例:
Query: "Aave V3的借贷利率是如何计算的？"
Good Answer: "Aave V3使用分段利率模型，利用率<最优利率时..."
→ 反向生成: "Aave V3的利率机制是什么？" → 与原Query高度相似 → 高分
Bad Answer: "Aave是一个去中心化借贷协议，成立于2017年..."
→ 反向生成: "Aave是什么？" → 与原Query不太相似 → 低分
优化方向:
├── 低Relevancy → 回答在跑题
├── 检查Prompt是否要求"直接回答问题"
├── 检查检索到的Context是否相关(如果Context都不相关，答案必然跑题)
├── 考虑增加System Prompt约束: "如果信息不足以回答，请说明"
└── 金融场景: 用户问利率，你回答历史沿革 → 虽然相关但不是用户要的
指标3: Context Precision (上下文精度)
定义: 检索到的Context中，排名靠前的Chunk是否比排名靠后的更相关？
→ 衡量检索结果的排序质量
计算方式:
Context Precision@K = (1/K) * Σ(Precision@k * rel(k))
其中rel(k) = 1如果第k个Chunk是相关的，0如果不相关
直觉: 类似搜索引擎的NDCG——不仅要找到相关结果，还要把最相关的排在最前面
示例(检索返回5个Chunk):
Chunk 1: [相关] "Aave V3利率模型采用分段函数..." ✓
Chunk 2: [不相关] "Compound的治理代币COMP..." ✗
Chunk 3: [相关] "最优利率(Optimal Rate)定义为..." ✓
Chunk 4: [不相关] "DeFi协议的TVL统计方法..." ✗
Chunk 5: [相关] "Aave V3利率参数表..." ✓
Precision@1 = 1/1 = 1.0 (第1个相关)
Precision@2 = 1/2 = 0.5 (前2个中1个相关)
Precision@3 = 2/3 = 0.67 (前3个中2个相关)
Context Precision = (1.0*1 + 0.5*0 + 0.67*1 + 0*0 + 0.6*1) / 3 = 0.76
优化方向:
├── 低Precision → 检索噪声大，混入了不相关的Chunk
├── 改进Embedding模型(更好地表示Query和Chunk的语义)
├── 引入Reranker(Day 20学的Cross-Encoder)
├── 优化Chunking(Day 19学的——Chunk质量差自然检索差)
├── 调整Metadata过滤(缩小搜索范围)
└── 金融场景: 搜"利率风险"不应返回"信用风险"的Chunk
指标4: Context Recall (上下文召回率)
定义: 回答所需的所有信息，是否都被检索到了？
→ 衡量检索的完整性
计算方式(RAGAS):
1. 需要一个Ground Truth (参考答案)
2. 从Ground Truth中提取所有关键信息点(claims)
3. 检查每个claim是否能在检索到的Context中找到支持
4. Context Recall = (被Context支持的claim数) / (Ground Truth中的总claim数)
示例:
Query: "Aave V3有哪些主要新功能？"
Ground Truth: "V3新增了跨链桥接(Portal)、高效模式(E-Mode)、
隔离模式(Isolation Mode)、供应/借款上限(Supply/Borrow Caps)。"
Ground Truth Claims:
c1: 跨链桥接Portal
c2: 高效模式E-Mode
c3: 隔离模式Isolation Mode
c4: Supply/Borrow Caps
检索到的Context只提到了Portal和E-Mode:
c1: 被Context支持 ✓
c2: 被Context支持 ✓
c3: 未被Context支持 ✗
c4: 未被Context支持 ✗
Context Recall = 2/4 = 0.50 → 只找到了一半信息
优化方向:
├── 低Recall → 遗漏了关键信息
├── 增大Top-K(检索更多Chunk)
├── 使用Query Expansion/HyDE(Day 20)生成多个检索Query
├── 改进Chunking(信息不应被切碎到无法检索)
├── 构建Multi-hop检索(一个Chunk引用另一个)
└── 金融场景: 问"全面风险管理"，只返回市场风险、漏掉信用风险和操作风险 → 不可接受
四维指标诊断矩阵
┌───────────────────┬──────────────────┬──────────────────────────────────┐
│ 症状 │ 诊断 │ 处方 │
├───────────────────┼──────────────────┼──────────────────────────────────┤
│ 高Faithful, │ 检索和生成都好 │ 继续保持，关注边缘案例 │
│ 高Relevancy, │ → 系统健康 │ │
│ 高Precision, │ │ │
│ 高Recall │ │ │
├───────────────────┼──────────────────┼──────────────────────────────────┤
│ 低Faithful, │ 生成器在编造 │ 加强Prompt约束 / 降低temperature │
│ 高Relevancy │ → 幻觉问题 │ / 增加Grounding检查 │
├───────────────────┼──────────────────┼──────────────────────────────────┤
│ 高Faithful, │ 回答忠实但跑题 │ 改进Prompt引导 / 加Response格式 │
│ 低Relevancy │ → Prompt问题 │ 约束 │
├───────────────────┼──────────────────┼──────────────────────────────────┤
│ 低Precision, │ 检索噪声大 │ 优化Embedding / 加Reranker / │
│ 高Recall │ → 检索质量问题 │ 缩小搜索范围 │
├───────────────────┼──────────────────┼──────────────────────────────────┤
│ 高Precision, │ 检索遗漏信息 │ 增大Top-K / Query Expansion / │
│ 低Recall │ → 检索覆盖不足 │ 改进Chunking │
├───────────────────┼──────────────────┼──────────────────────────────────┤
│ 低Faithful, │ 检索差+生成差 │ 全链路检查 / 可能是数据质量问题 │
│ 低Relevancy, │ → 系统性问题 │ (回到Day 19) │
│ 低Precision, │ │ │
│ 低Recall │ │ │
└───────────────────┴──────────────────┴──────────────────────────────────┘
知识点2: 评估数据集构建
Golden QA对——评估的基石
什么是Golden QA对:
一组经过人工验证的 (Query, Ground Truth Answer, Source Context) 三元组
→ 就像信贷模型的"标注好的历史贷款数据"——你知道哪些该批、哪些该拒
为什么必须有Golden Set:
├── 自动评估需要Ground Truth来计算Recall
├── 回归测试: 每次改动后跑一遍Golden Set，确保没有退化
├── 基线对比: 不同RAG策略在同一Golden Set上的效果对比
└── 上线Gate: Golden Set通过率达标才能上线
Golden QA对的结构:
{
"id": "finance-001",
"question": "招商银行2025年的不良贷款率是多少？",
"ground_truth": "招商银行2025年不良贷款率为0.95%，较上年末下降0.03个百分点。",
"source_chunks": ["annual_report_2025_p42.chunk_7", "annual_report_2025_p43.chunk_1"],
"category": "financial_metric",
"difficulty": "easy",
"requires_reasoning": false,
"created_by": "human",
"version": "v2.1"
}
构建方法: 人工标注 vs 合成数据
方法1: 纯人工标注
流程: 领域专家阅读文档 → 自己写问题+答案 → 交叉验证
优点: 质量最高、最贴近真实场景
缺点: 成本高(金融专家时薪不便宜)、速度慢、难以大规模
适用: 核心场景(高风险金融问答)、Golden Set的种子集
方法2: LLM合成 + 人工审核
流程:
Step 1: 给LLM一段文档，让它生成QA对
Prompt: "基于以下金融年报内容，生成5个专业的问答对。
问题应覆盖: 关键指标、趋势分析、风险因素。
答案必须完全基于提供的文本，不可编造。"
Step 2: 人工审核合成的QA对
→ 删除低质量的(太简单/答案不准/问题不现实)
→ 修正有偏差的(答案不够精确)
→ 补充遗漏的类型(边缘案例)
Step 3: 标注难度和类别
优点: 速度快(10x)、成本低、覆盖面广
缺点: 需要人工审核(否则质量不可控)、LLM可能生成"看起来对但实际有细微错误"的QA对
适用: 大规模评估集构建、初始阶段快速建立基线
方法3: 生产日志挖掘
流程:
Step 1: 收集生产环境中的真实用户Query
Step 2: 人工回答这些Query(或找到标准答案)
Step 3: 标注为评估集
优点: 最贴近真实使用场景、发现你没想到的问题类型
缺点: 需要先有线上流量、隐私合规考虑
适用: 系统上线后的持续完善
推荐策略(分阶段):
Phase 1 (上线前): 人工50 + LLM合成200 = 250条Golden QA
Phase 2 (上线后): + 生产日志挖掘100条/月
Phase 3 (成熟期): 维护500-1000条覆盖所有核心场景的Golden Set
边缘案例收集
为什么边缘案例重要:
RAG在"正常"问题上通常表现尚可
但在边缘案例上往往暴露严重缺陷
→ 就像信贷模型在正常经济周期表现好，但在极端市场中崩溃
金融RAG常见边缘案例:
1. 数字精度:
Q: "工商银行2025Q3净利润同比增速?"
→ 必须精确到小数点后一位，不能"约5%"
2. 时间敏感:
Q: "当前LPR是多少?"
→ 文档库中可能有多个时期的LPR数据，必须返回最新的
3. 否定/对比:
Q: "为什么招行的零售转型比工行更成功?"
→ 需要同时检索两家银行的信息并做对比
4. 多跳推理:
Q: "如果美联储加息50bps，对招行净息差的影响是多少?"
→ 需要: 美联储利率→中国利率联动→招行资产负债结构→净息差计算
5. 不存在的信息:
Q: "招行2026年的分红计划是什么?"
→ 如果文档库没有2026年信息，应明确说"无法回答"而非编造
6. 歧义消解:
Q: "招行利率是多少?"
→ 什么利率? 存款/贷款/LPR? 哪个期限? → 应要求澄清
7. 跨语言:
Q: "What is CMB's NPL ratio?"
→ 文档是中文，需要理解CMB=招商银行、NPL=不良贷款
边缘案例收集方法:
├── 红队测试(Red Teaming): 专人尝试"破坏"系统
├── 生产日志分析: 找低分回答对应的Query
├── 领域专家贡献: 金融分析师提供"会问到但很难答"的问题
└── 系统性枚举: 按上述7类每类准备5-10个案例
评估集版本管理
为什么需要版本管理:
├── 文档库更新后，某些Ground Truth可能过时
├── 新增了文档类型，需要新增对应的评估QA
├── 发现了新的边缘案例，需要追加
├── 评估标准可能调整(更严格/更宽松)
└── 不同版本RAG系统需要在同一评估集上对比
版本管理实践:
eval_datasets/
├── v1.0/ # 初始版本
│ ├── golden_qa.jsonl # 250条QA对
│ ├── metadata.json # 版本说明、创建日期、覆盖范围
│ └── changelog.md # 变更记录
├── v1.1/ # 新增边缘案例
│ ├── golden_qa.jsonl # 300条(+50边缘案例)
│ ├── metadata.json
│ └── changelog.md
├── v2.0/ # 文档库重大更新后
│ ├── golden_qa.jsonl # 350条(更新过时答案+新增)
│ ├── metadata.json
│ └── changelog.md
└── latest -> v2.0/ # 软链接到最新版本
关键原则:
├── 旧版本永不删除(历史对比需要)
├── 每个版本记录变更原因
├── 自动化: CI/CD中每次RAG变更自动跑latest版评估集
└── 金融类比: 就像信贷模型的Validation Dataset也需要定期更新样本
知识点3: 自动化评估Pipeline
LLM-as-Judge — 用AI评估AI
核心思想:
用一个强大的LLM(如GPT-4o/Claude)来判断RAG系统的回答质量
→ 类似"用资深审计师来审核初级分析师的报告"
为什么可行:
├── LLM在评估任务上与人类判断的相关性已达0.8+(2025-2026研究)
├── 成本远低于人工评估(1000条评估~$5 vs 人工$500+)
├── 速度快(分钟级 vs 人工天级)
├── 可重复(同一Prompt每次评估标准一致)
└── 可扩展(从100条到10000条无边际成本增加)
但要注意的偏差:
├── Position Bias: 倾向于给排在前面的选项更高分
├── Verbosity Bias: 倾向于给更长的回答更高分(长≠好)
├── Self-Enhancement Bias: GPT-4可能给GPT-4生成的内容更高分
├── 格式偏好: 带列表/标题的回答可能被偏好
└── 数字盲区: LLM对数字精度的判断可能不如人类
评估Prompt设计
一个好的Judge Prompt应该包含:
1. 角色定义:
"你是一位资深金融分析师，负责评估AI助手的回答质量。"
2. 评估维度说明:
"请从以下维度打分(1-5分):
- 准确性: 回答中的事实和数字是否正确
- 完整性: 是否覆盖了问题的所有方面
- 相关性: 回答是否直接针对问题
- 忠实性: 回答是否忠于提供的参考文档"
3. 评分标准(Rubric):
"评分标准:
5分: 完全正确、全面、可直接使用
4分: 基本正确，有小的遗漏或不精确
3分: 部分正确，有明显遗漏或错误
2分: 大部分不正确或严重跑题
1分: 完全错误或无法使用"
4. 输出格式:
"请按以下JSON格式输出:
{
'accuracy_score': int,
'completeness_score': int,
'relevancy_score': int,
'faithfulness_score': int,
'overall_score': float,
'reasoning': string,
'issues_found': [string]
}"
5. Few-shot示例(关键！):
提供2-3个评分示例，明确什么样的回答给什么分
→ 大幅减少评分不一致
金融领域特殊考量:
├── 数字精度Rubric: "数字错误任何一个直接扣2分"(零容忍)
├── 合规措辞: "是否包含必要的风险提示/免责声明"
├── 时效性: "是否使用了最新数据而非过时数据"
└── 来源归属: "是否标注了数据来源"
多Judge投票
问题: 单个LLM Judge可能有偏差，怎么办？
方案: Multi-Judge Voting (多评委投票制)
实现方式:
Judge 1: GPT-4o → Score: 4.2
Judge 2: Claude → Score: 3.8
Judge 3: GPT-4o(不同Prompt) → Score: 4.0
最终分数 = median(4.2, 3.8, 4.0) = 4.0
或: 最终分数 = mean(4.2, 3.8, 4.0) = 4.0
升级版: Debate Protocol
Step 1: Judge A评分并给出理由
Step 2: Judge B看到Judge A的理由后独立评分
Step 3: 如果分歧>1分，进入"辩论"
Step 4: 两个Judge看到对方理由后重新评分
Step 5: 取最终平均
实际工程建议:
├── 生产评估用3个Judge投票(成本可控)
├── 高争议样本(分歧>1.5分)标记为需要人工仲裁
├── 定期校准: 用人工评分结果校准LLM Judge的Prompt
└── 成本控制: 日常监控用单Judge，月度评估用多Judge
评估工具对比 (2025-2026)
┌──────────────┬─────────────────┬──────────────────┬──────────────────┬──────────────────┐
│ 工具 │ RAGAS │ TruLens │ DeepEval │ Arize Phoenix │
├──────────────┼─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 定位 │ RAG评估框架 │ LLM应用评估+追踪 │ 单元测试风格评估 │ 可观测性+评估 │
│ 开源 │ ✅ MIT │ ✅ MIT │ ✅ Apache │ ✅ Elastic │
│ RAGAS指标 │ ✅ 原生支持 │ ✅ 集成 │ ✅ 集成 │ ✅ 集成 │
│ LLM-as-Judge │ ✅ │ ✅ (多种Feedback) │ ✅ │ ✅ │
│ CI/CD集成 │ 需自己写 │ 需自己写 │ ✅ pytest风格 │ 需自己写 │
│ UI Dashboard │ ❌ │ ✅ 内置 │ ❌ │ ✅ 内置 │
│ Tracing │ ❌ │ ✅ 深度追踪 │ ❌ │ ✅ OpenTelemetry │
│ 生产监控 │ ❌ 偏离线评估 │ ✅ 实时反馈 │ ❌ 偏离线测试 │ ✅ 实时监控 │
│ 学习曲线 │ 低(API简单) │ 中 │ 低(pytest风格) │ 中 │
│ 适用阶段 │ 开发/评估 │ 开发→生产全链路 │ CI/CD自动测试 │ 生产监控+调试 │
├──────────────┼─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 推荐场景 │ 快速评估RAG │ 需要追踪+反馈闭环 │ 工程团队CI/CD │ 已上线系统监控 │
│ │ 质量的首选 │ 的生产系统 │ 驱动的质量保障 │ + 问题诊断 │
└──────────────┴─────────────────┴──────────────────┴──────────────────┴──────────────────┘
推荐组合(生产级RAG):
开发阶段: RAGAS (快速评估) + DeepEval (CI/CD集成)
生产阶段: TruLens (反馈追踪) + Arize Phoenix (可观测性)
金融RAG额外考量:
├── 审计需求: 所有评估结果需要可追溯、可解释(TruLens/Phoenix有优势)
├── 合规要求: 评估数据不能发送给外部LLM(需要本地LLM-as-Judge或自托管)
├── 数字精度: 可能需要自定义评估函数(标准RAGAS对数字不够敏感)
└── 版本对比: 需要支持不同RAG版本在同一评估集上的横向对比
知识点4: 幻觉检测与治疗
幻觉类型学
RAG幻觉 ≠ LLM幻觉 —— RAG有自己特有的幻觉模式
类型1: 事实性幻觉 (Factual Hallucination)
定义: 生成了与现实世界不符的"事实"
来源: LLM的参数知识与检索到的Context冲突时，LLM"坚持自己的错误记忆"
示例:
Context: "招商银行2025年净利润1198.5亿元"
Answer: "招商银行2025年净利润1250亿元" ← LLM用了自己的(错误的)参数知识
金融影响: 数字错误可能导致投资决策失误 → 高风险
类型2: 忠实性幻觉 (Faithfulness Hallucination)
定义: 回答超出了检索到的Context的范围
来源: LLM"自由发挥"了Context中没有的信息
示例:
Context: "该基金2025年收益率为12.3%"
Answer: "该基金2025年收益率为12.3%，在同类基金中排名前10%"
← "排名前10%"不在Context中，是LLM编的
金融影响: 添加了未经验证的比较/判断 → 中-高风险
类型3: 推理性幻觉 (Reasoning Hallucination)
定义: 基于正确的事实做出了错误的推理
来源: LLM的推理能力不足，尤其在金融计算和因果推断方面
示例:
Context: "CPI同比上涨3.2%，央行维持利率不变"
Answer: "由于CPI上涨3.2%，央行将在下次会议上加息"
← Context说"维持不变"，LLM自行推断"将加息"
金融影响: 错误的因果推断导致错误预期 → 高风险
三种幻觉的诊断与频率:
┌─────────────┬────────────┬─────────────┬──────────────┐
│ 幻觉类型 │ 频率(估计) │ 检测难度 │ 金融风险等级 │
├─────────────┼────────────┼─────────────┼──────────────┤
│ 事实性幻觉 │ 5-15% │ 中(可自动) │ ★★★★★ │
│ 忠实性幻觉 │ 10-25% │ 中(NLI可检) │ ★★★★ │
│ 推理性幻觉 │ 5-10% │ 高(需领域知识) │ ★★★★★ │
└─────────────┴────────────┴─────────────┴──────────────┘
幻觉检测方法
方法1: NLI (Natural Language Inference) 检测
原理: 将Answer的每个claim与Context做蕴含/矛盾/中立判断
工具: deberta-v3-large-nli / bart-large-mnli / 专用NLI模型
流程:
Input: (Context, Claim)
Output: entailment(蕴含,0.92) / contradiction(矛盾,0.05) / neutral(中立,0.03)
如果 entailment > 0.8 → Claim被支持 ✓
如果 contradiction > 0.5 → Claim与Context矛盾 → 幻觉! ✗
如果 neutral > 0.5 → Claim在Context中无依据 → 可能幻觉 ⚠️
优点: 快速(模型推理<100ms)、成本低(本地模型)、无需LLM
缺点: 对复杂推理判断能力有限、对数字精度不敏感
适用: 大规模实时检测、第一道过滤
方法2: SelfCheckGPT
原理: 让LLM对同一问题生成多次回答，如果每次都一样→可信，如果每次不同→可能幻觉
流程:
Step 1: 生成主回答A
Step 2: 对同一问题再生成N次(N=3-5)，得到A1, A2, ...An
Step 3: 检查A中的每个claim是否在A1...An中也出现
Step 4: 一致性高 → 可信; 不一致 → 幻觉风险高
优点: 不需要外部知识/Ground Truth
缺点: 成本高(N+1次生成)、LLM一致地犯同一个错误时失效
适用: 无法获取Ground Truth时的fallback方案
方法3: Grounding Score (接地分)
原理: 逐句检查回答是否能在Context中找到"锚点"
实现(LLM-as-Judge):
Prompt:
"对于回答中的每一句话，判断它是否完全基于以下参考文本:
参考文本: {context}
回答: {answer}
请对每句话标注:
[GROUNDED] — 完全基于参考文本
[PARTIALLY_GROUNDED] — 部分基于，部分推断
[NOT_GROUNDED] — 无法在参考文本中找到依据
[CONTRADICTS] — 与参考文本矛盾"
Grounding Score = GROUNDED句数 / 总句数
优点: 细粒度(句级别)、可解释性强
缺点: 需要LLM调用、成本较高
适用: 高价值场景的详细诊断
实际部署建议:
Layer 1 (实时): NLI模型做快速过滤 → <100ms
Layer 2 (异步): Grounding Score做详细标注 → 分钟级
Layer 3 (离线): SelfCheck + 人工审核 → 天级
→ 类比信贷风控的"实时规则→模型评分→人工审批"三层架构
幻觉治疗方案
治疗1: Prompt约束 (最简单、立即见效)
System Prompt增强:
"你是一个严格基于文档回答的助手。
规则:
1. 只使用提供的文档中的信息来回答
2. 如果文档中没有相关信息，明确说"根据提供的资料，无法回答此问题"
3. 每个数字必须与文档原文一致，不可四舍五入或估算
4. 不可添加文档中未提及的比较、评价或预测
5. 如有不确定，用"根据文档记载..."开头，而非断言语气"
效果: 幻觉率降低30-50%(低投入高回报)
局限: 强模型(GPT-4/Claude)效果好，弱模型可能忽略指令
治疗2: Retrieval增强 (从源头减少幻觉动机)
原理: 如果检索到的Context足够完整和相关，LLM就没有"编造"的动机
措施:
├── 提高Context Recall(检索更多相关Chunk)
├── 使用RAG Fusion(多Query检索，汇总结果)
├── 引用标注: 要求LLM标注每个claim的来源Chunk
│ → "[来源: 2025年报P42] 净利润为1198.5亿元"
│ → 逼迫LLM"回去查原文"，减少凭空编造
└── 提供"无信息"的处理路径
→ 如果Context不足，生成"我没有足够信息"而非编造
治疗3: 后处理过滤 (最后一道防线)
流程:
RAG Answer → NLI检查 → Grounding Score → 决策
if grounding_score >= 0.9:
return answer # 直接返回
elif grounding_score >= 0.7:
return answer + "⚠️ 部分内容基于推断，请核实原文" # 警告标注
elif grounding_score >= 0.5:
return "该回答可能包含不准确信息，建议查阅原始文档: [链接]" # 降级
else:
return "抱歉，我无法基于现有资料给出可靠回答" # 拒绝回答
金融场景的严格模式:
任何数字类claim的grounding_score < 0.95 → 标记为需要人工复核
涉及监管/合规的回答 → 必须100% grounded → 否则拒绝回答
治疗效果对比:
┌──────────────────┬──────────────┬───────────┬──────────────┐
│ 治疗方案 │ 幻觉降低幅度 │ 实施成本 │ 对延迟影响 │
├──────────────────┼──────────────┼───────────┼──────────────┤
│ Prompt约束 │ 30-50% │ ★☆☆☆☆ │ 无 │
│ Retrieval增强 │ 20-40% │ ★★★☆☆ │ +100-500ms │
│ 引用标注 │ 25-45% │ ★★☆☆☆ │ +10-20% token│
│ 后处理NLI过滤 │ 40-60% │ ★★★☆☆ │ +50-200ms │
│ 全套组合 │ 70-85% │ ★★★★☆ │ +300-800ms │
└──────────────────┴──────────────┴───────────┴──────────────┘
→ 实际项目: 先做Prompt约束(0成本)，再加引用标注，最后加后处理过滤
→ 金融场景: 建议上全套，幻觉的代价远高于额外延迟
知识点5: RAG迭代优化循环
评估驱动的迭代闭环
核心理念: 不要"拍脑袋"优化，要"看数据"优化
迭代循环:
┌─────────────────────────────────────────────────────────┐
│ │
│ ①评估 → ②诊断瓶颈 → ③针对性优化 → ④再评估 → ⑤确认改善 │
│ ↑ │ │
│ └──────────────────────────────────────────────┘ │
│ (持续循环) │
└─────────────────────────────────────────────────────────┘
Step 1: 评估 (Measure)
→ 跑Golden QA Set，获取RAGAS四维分数
→ 当前基线: Faithfulness=0.72, Relevancy=0.68, Precision=0.65, Recall=0.58
Step 2: 诊断瓶颈 (Diagnose)
→ Recall最低(0.58) → 主要瓶颈在检索覆盖不足
→ 同时Faithfulness不高(0.72) → 生成器也有幻觉问题
Step 3: 针对性优化 (Optimize)
→ 瓶颈是Recall → 实施Query Expansion + 增大Top-K(5→10)
→ 同时加Prompt约束减少幻觉
Step 4: 再评估 (Re-measure)
→ Faithfulness=0.85(+0.13), Relevancy=0.71(+0.03),
Precision=0.60(-0.05), Recall=0.73(+0.15)
→ Recall大幅提升，但Precision略降(Top-K增大引入了噪声)
Step 5: 确认改善，进入下一轮 (Iterate)
→ 新瓶颈: Precision下降 → 加Reranker
→ 循环继续...
常见瓶颈诊断与解决方案
瓶颈1: 检索不准 (低Context Precision)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
症状:
├── 返回了很多不相关的Chunk
├── 用户问A话题，返回B话题的内容
├── 同一文档的不同版本混在一起
诊断方法:
├── 随机抽样20个Query，人工检查Top-5 Chunk的相关性
├── 计算Context Precision@5
├── 检查是否有明显的"类型错误"(如问存款返回贷款)
解决方案(按优先级):
1. 加Reranker: Cross-Encoder重排Top-20→Top-5 [效果最大，+10-20% Precision]
2. 优化Embedding: 换更好的Embedding模型(如BGE-M3→Cohere) [+5-15%]
3. Hybrid Search: 向量检索+BM25关键词检索 [+5-10%]
4. Metadata过滤: 加时间/类别/来源等预过滤 [效果视场景]
5. 优化Chunking: Chunk边界不对导致语义碎片化 [根本性改善]
瓶颈2: 上下文不足 (低Context Recall)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
症状:
├── 回答只覆盖了问题的一部分
├── 需要综合多个Chunk的信息但只找到了一个
├── "已知文档里有答案但系统说找不到"
诊断方法:
├── 检查Ground Truth的关键信息点是否出现在Top-K Chunk中
├── 手动执行Query，看遗漏的信息在第几个Chunk
├── 检查是否是Chunking问题(信息被切断在两个Chunk中)
解决方案:
1. 增大Top-K: 5→10→15(简单有效，但增加Token成本) [+10-20% Recall]
2. Query Expansion: 一个用户Query扩展为3-5个变体 [+10-15%]
原Query: "银行资本充足率"
扩展: "核心一级资本充足率" + "资本充足率监管要求" + "CAR ratio"
3. HyDE: 先让LLM生成假设性答案，用假答案做检索 [+5-15%]
4. Parent-Child检索: 检索到Child后自动拉取Parent Chunk [+5-10%]
5. Multi-hop: 第一轮检索→提取线索→第二轮检索 [处理复杂问题]
瓶颈3: 生成偏离 (低Faithfulness / 低Answer Relevancy)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
症状:
├── 回答编造了Context中没有的信息
├── 回答答非所问(虽然检索到了正确的Context)
├── 回答过于泛泛，没有利用检索到的具体信息
诊断方法:
├── 逐条检查低分回答的Grounding Score
├── 检查Prompt模板是否有引导幻觉的倾向
├── 检查Context长度是否超出了LLM的有效注意力范围
解决方案:
1. Prompt工程:
├── 明确"仅基于以下文档回答"
├── 要求引用来源: "在回答中标注[来源X]"
├── 添加"如果信息不足请说明"的指令
└── 降低temperature(0.7→0.1)减少随机性
2. Context压缩:
├── 用LLM/专用模型压缩Context，只保留最相关的部分
├── 避免Context过长导致LLM"迷路"(Lost in the Middle问题)
└── 将最相关的Chunk放在Context的开头和结尾
3. 后处理验证:
├── NLI检测每个claim
├── Grounding Score < 阈值 → 标记或拒绝
└── 自动添加不确定性标注
瓶颈4: 延迟过高 (用户体验差)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
症状:
├── 端到端响应时间>5秒(用户不耐烦)
├── Reranker成为瓶颈(Cross-Encoder慢)
├── Context过长导致LLM生成慢
诊断方法:
├── 逐阶段计时: Embedding(xms) + ANN(xms) + Rerank(xms) + LLM(xms)
├── 找到耗时最长的阶段
├── 检查是否有不必要的重复计算
解决方案:
1. 并行化: Embedding计算和BM25检索并行执行 [-30-50% 检索延迟]
2. 缓存: 高频Query缓存整个RAG结果 [-90% for cache hits]
3. Streaming: LLM输出流式返回，用户看到"打字效果" [感知延迟降低]
4. 轻量Reranker: 用ColBERTv2替代Cross-Encoder [-50% rerank延迟]
5. Context裁剪: 压缩Context到必要最小长度 [-20-40% LLM延迟]
6. 模型选择: 非关键Query用小模型(GPT-4o-mini) [-60% LLM延迟]
延迟预算分配(目标<3秒):
┌────────────────┬──────────────┬─────────────┐
│ 阶段 │ 预算 │ 优化手段 │
├────────────────┼──────────────┼─────────────┤
│ Query处理 │ <100ms │ 预计算/缓存 │
│ Embedding │ <200ms │ 本地模型/GPU │
│ ANN搜索 │ <50ms │ HNSW/IVF │
│ Reranking │ <300ms │ ColBERT/剪枝 │
│ LLM生成 │ <2000ms │ Streaming │
│ 后处理 │ <200ms │ 异步/可选 │
├────────────────┼──────────────┼─────────────┤
│ 总计 │ <3000ms │ │
└────────────────┴──────────────┴─────────────┘
迭代优化的优先级框架
不是所有优化都值得做——用"影响×难度"矩阵决定优先级
┌──────────────────────────────────────────────────────────┐
│ 影响大 │
│ │ │
│ 难度低 │ ★★★ 优先做 ★★ 值得做 │
│ │ · Prompt约束 · Reranker引入 │
│ │ · temperature调低 · Query Expansion │
│ │ · 增大Top-K · Hybrid Search │
│ │ │
│ │───────────────────────────────────────────── │
│ │ │
│ 难度高 │ ★★ 看ROI再决定 ★ 最后考虑 │
│ │ · 换Embedding模型 · 自训练Reranker │
│ │ · 重做Chunking策略 · 知识图谱增强 │
│ │ · 后处理过滤Pipeline · Fine-tune LLM │
│ │ │
│ 影响小 │
└──────────────────────────────────────────────────────────┘
迭代节奏建议:
├── 每日: 检查线上幻觉率和低分Query
├── 每周: 分析Top-10低分案例，确定优化方向
├── 每月: 跑完整Golden Set评估，对比历史趋势
├── 每季: 重新审视评估数据集是否需要更新
└── 金融场景: 在监管审查前做全面评估(类似信贷模型年度回溯)
知识点6: RAG系统成熟度模型
四级成熟度
L1: 基础级 (Basic RAG)
━━━━━━━━━━━━━━━━━━━━━━
特征:
├── 简单的Naive RAG架构(Embed→Search→Generate)
├── 固定大小Chunking
├── 单一Embedding模型
├── 无评估体系(靠"感觉"判断好不好)
├── 无监控(出了问题才知道)
└── 手动更新文档
典型表现:
├── RAGAS综合分数: 0.4-0.6
├── 幻觉率: 20-40%
├── 用户满意度: "能用但不好用"
└── 适用: PoC/Demo/内部工具
升级到L2需要:
├── ✅ 建立Golden QA评估集(≥100条)
├── ✅ 接入RAGAS自动评估
├── ✅ 引入Reranker
├── ✅ 优化Chunking策略(至少Recursive)
└── ✅ 基础幻觉检测
L2: 优化级 (Optimized RAG)
━━━━━━━━━━━━━━━━━━━━━━━━
特征:
├── Advanced RAG架构(Hybrid Search + Reranker + Query Expansion)
├── 语义或结构化Chunking
├── RAGAS四维评估定期运行
├── 基础幻觉检测(NLI)
├── 文档更新自动化
└── 基础监控(成功率/延迟/成本)
典型表现:
├── RAGAS综合分数: 0.65-0.80
├── 幻觉率: 10-20%
├── 用户满意度: "大部分时候好用"
└── 适用: 面向内部用户的生产系统
升级到L3需要:
├── ✅ 多Judge自动评估Pipeline
├── ✅ 幻觉检测+治疗全套
├── ✅ 评估驱动的迭代循环(≥月度)
├── ✅ A/B测试基础设施
├── ✅ 用户反馈收集与闭环
└── ✅ 评估集版本管理(≥300条)
L3: 自适应级 (Adaptive RAG)
━━━━━━━━━━━━━━━━━━━━━━━━━━
特征:
├── Query分类→不同检索策略(简单Query直接搜索, 复杂Query多跳)
├── 动态Top-K(根据Query类型调整检索数量)
├── 自动检测文档过时并触发重新索引
├── 实时幻觉检测+自动降级
├── A/B测试常态化
├── 用户反馈自动标注+评估集自动扩充
└── 完整的可观测性(Tracing/指标/告警)
典型表现:
├── RAGAS综合分数: 0.80-0.90
├── 幻觉率: 5-10%
├── 用户满意度: "很好用，偶尔出问题"
└── 适用: 面向外部用户/客户的核心产品
升级到L4需要:
├── ✅ RAG组件的自动调参(Auto-tuning)
├── ✅ 知识图谱增强(结构化知识补充向量检索)
├── ✅ 多模态RAG(文本+表格+图表)
├── ✅ 自我修复(检测到幻觉自动重试)
└── ✅ 持续学习(从用户反馈中自动提升)
L4: 自主学习级 (Self-Improving RAG)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
特征:
├── 自动从用户反馈中学习(哪些回答好/不好)
├── 自动优化检索策略(Embedding权重/Reranker阈值)
├── 自动扩充知识库(发现缺失知识→自动抓取/请求补充)
├── 自动管理评估集(从生产数据中自动挖掘新的评估Case)
├── 多Agent协作(一个Agent检索，一个Agent验证，一个Agent生成)
├── 预测性维护(预测文档何时过时)
└── 完整的MLOps/RAGOps流水线
典型表现:
├── RAGAS综合分数: 0.90+
├── 幻觉率: <5%
├── 用户满意度: "比人工客服还好用"
└── 适用: 核心业务决策支持/面向客户的金融产品
注意: 2026年大多数团队在L2-L3之间，L4还处于前沿探索阶段
成熟度自评检查表
你的RAG系统在哪一级？逐项检查:
□ 有≥100条Golden QA评估集 → L1→L2的门槛
□ 定期(至少月度)运行自动评估 → L2的标志
□ 能区分检索问题和生成问题 → L2的标志
□ 有幻觉检测机制 → L2→L3的门槛
□ 评估驱动的迭代循环已建立 → L3的标志
□ 用户反馈与评估系统打通 → L3的标志
□ 系统能根据Query类型自适应调整策略 → L3的标志
□ 有A/B测试基础设施 → L3→L4的门槛
□ 从用户反馈中自动学习优化 → L4的标志
□ 完整的RAGOps流水线(CI/CD/监控/回滚) → L4的标志
大多数团队的现实:
├── 创业公司: L1(快速上线) → 3-6个月到L2
├── 中型公司: L2(有一定评估) → 6-12个月到L3
├── 大型金融机构: L2(合规要求) → 12-18个月到L3
└── 顶尖AI公司: L3→L4探索中
从L1到L3的实操路线图
Month 1: L1→L2 (建立评估基线)
Week 1: 构建Golden QA Set
├── 用LLM合成150条 + 人工审核
├── 涵盖: 简单查找、对比分析、数字提取、多跳推理
└── 建立评估集版本管理
Week 2: 接入RAGAS评估
├── 跑第一次基线评估
├── 记录四维分数
└── 识别最大瓶颈
Week 3: 优化检索
├── 引入Reranker(Cross-Encoder)
├── 切换到Recursive Chunking
└── 再评估，对比改善
Week 4: 基础幻觉检测
├── 接入NLI模型
├── 优化Prompt约束
└── 建立低分Query的人工审核流程
Month 2-3: L2→L3 (建立迭代闭环)
├── 搭建自动化评估Pipeline(CI/CD集成)
├── 收集用户反馈并闭环到评估集
├── 建立A/B测试能力
├── 实现Query分类+自适应检索策略
├── 完善幻觉检测+自动降级
└── 建立完整的可观测性(Day 18)
Month 4-6: L3稳定运营
├── 月度评估+迭代常态化
├── 评估集持续扩充(500+条)
├── 探索L4方向(自动学习/多Agent)
└── 建立RAGOps最佳实践文档
今日思考
思考1: RAG评估的"古德哈特定律"
"当一个指标成为目标时，它就不再是一个好的指标。"
风险:
├── 团队为了提高Faithfulness分数，让LLM只做"摘抄"而非"理解后回答"
│ → 分数高了，但用户体验差了(用户要的是理解后的总结)
├── 为了提高Answer Relevancy，让LLM过度"重复问题"
│ → "你问的是净利润，净利润是..."
├── 为了提高Context Recall，Top-K设为50
│ → Recall高了，但Token成本爆炸、延迟不可接受
金融类比:
银行的KPI如果只看不良率，就会出现"不做贷款"的策略——不良率=0但没有收入
→ 必须综合看: 不良率 + 贷款规模 + 收入 + 客户满意度
应对:
├── 综合看四维指标 + 用户满意度 + 延迟 + 成本
├── 设定最低门槛而非最大化单一指标
│ → Faithfulness≥0.8 AND Relevancy≥0.7 AND Latency<3s AND Cost<$0.05/query
├── 最终评判标准是"用户任务完成率"(Task Completion Rate)
└── 定期人工抽检，防止"指标好但体验差"的情况
思考2: 金融RAG的特殊评估需求
金融领域对RAG的要求远高于通用场景:
1. 数字零容忍:
通用场景: "大约1200亿" → 可接受
金融场景: "1198.5亿" → 唯一正确答案
→ 需要自定义数字精度评估指标
2. 合规追溯:
通用场景: 回答正确即可
金融场景: 回答正确 + 可追溯到原始文档 + 有审计日志
→ 每个claim必须标注来源，评估时也要验证来源正确性
3. 时效性:
通用场景: 知识截止日期模糊也行
金融场景: "2025Q3数据"和"2025Q4数据"差一个季度可能完全不同
→ 需要时间敏感性评估指标
4. 负面案例处理:
通用场景: 尽量回答，错了也没大事
金融场景: 不确定时必须说"不知道"，错误可能导致投资损失
→ 需要评估"该拒绝时是否拒绝了"(False Positive Rate of Abstention)
5. 公平性:
通用场景: 一般不考虑
金融场景: 不能因为某些客户群体的数据少就给出更差的回答
→ 需要按客户群/产品类型分层评估
→ 标准RAGAS四维指标是起点，金融场景需要扩展为"RAGAS+精度+追溯+时效+拒绝率"
思考3: 评估体系本身的ROI
现实问题: 老板问"为什么要花2周时间搭评估体系，而不是直接优化RAG？"
回答框架(用金融语言):
"不搭评估体系就优化RAG，等于不做回测就上线交易策略。"
没有评估体系的代价:
├── 每次优化不知道是否真的变好了(可能A指标好了B指标差了)
├── 无法量化优化效果(向管理层汇报只能说"感觉好了")
├── 上线后出问题没有预警(客户投诉才知道)
├── 团队各自凭感觉调参，无法对齐标准
└── 积累的"技术债"越来越大
搭评估体系的回报:
├── 每次优化有数据支撑(Faithfulness从0.72→0.85)
├── 回归测试防止退化(改了A不会坏B)
├── 上线Gate有明确标准(综合分≥0.8才能上线)
├── 团队对齐同一套指标
└── 长期看，优化速度反而更快(不走弯路)
ROI估算:
投入: 2人×2周 = 20人天
回报: 每月减少1次线上事故(估值10人天修复+声誉损失)
+ 每次优化迭代缩短3天(不再"盲人摸象")
+ 上线信心提升(管理层可量化的质量报告)
→ ROI > 5x (保守估计)
关键: 评估体系不是一次性投入，而是持续产生复利的基础设施
→ 就像银行的风控体系——前期投入大，但没有它你不敢做业务
面试表达
面试题: 如何评估RAG系统的质量？
结构化回答 (2-3分钟):
"RAG评估我会从四个维度来看，对应检索和生成两个环节:
检索端两个指标:
Context Precision — 检索结果中排名靠前的是否真的相关，衡量排序质量
Context Recall — 回答需要的信息是否都被检索到了，衡量覆盖完整性
生成端两个指标:
Faithfulness — 回答是否忠于检索到的上下文，有没有编造
Answer Relevancy — 回答是否直接针对用户问题，有没有跑题
这四个指标组合起来可以精准定位问题在哪里。比如Recall低但Faithfulness高，
说明检索遗漏了信息但生成器没有乱编；反过来如果Recall高但Faithfulness低，
就是检索到了正确信息但生成器没有好好用。
工程实践上，我会:
1. 构建Golden QA评估集(人工标注+LLM合成，至少200-300条)
2. 搭建自动化评估Pipeline(用RAGAS/DeepEval，集成到CI/CD)
3. 建立迭代闭环(评估→诊断瓶颈→优化→再评估)
4. 生产环境加幻觉检测(NLI模型做实时过滤)
如果是金融场景，我还会额外关注数字精度、来源追溯和拒答率——
该说不知道的时候不能编造。"
面试题: 你的RAG系统出现了幻觉问题，如何解决？
结构化回答:
"首先我会分类诊断——幻觉分三种:
事实性幻觉(数字/事实错误)、
忠实性幻觉(添加了Context中没有的信息)、
推理性幻觉(基于正确事实做出错误推理)。
不同类型的治疗方案不同:
对于忠实性幻觉(最常见):
短期: 加强Prompt约束——'仅基于以下文档回答，不可添加任何外部信息'，
降低temperature到0.1，效果立竿见影
中期: 要求LLM引用来源——'每个声明标注[来源X]'，
这会迫使模型回到原文寻找依据
长期: 加后处理NLI过滤——每个claim做蕴含检测，
不被Context支持的claim自动标记或过滤
对于事实性幻觉(金融高危):
增强检索覆盖(让LLM有足够的Context就不会用参数知识编造)
数字类回答做专门的精度验证(正则提取+对比)
对于推理性幻觉:
限制LLM只做信息提取不做推理
如果需要推理，拆分为多步: 先提取事实，再做推理，分别验证
整体效果: 组合使用Prompt约束+引用标注+NLI过滤，
幻觉率通常可以从20%+降到5%以下。"
实操练习建议
1. 用RAGAS评估一个简单RAG:
pip install ragas datasets
→ 用RAGAS自带的示例数据集跑一遍四维评估
→ 理解每个指标的计算过程和输出格式
→ 修改System Prompt观察Faithfulness变化
2. 构建一个Mini Golden QA Set:
→ 准备10页金融文档(年报/研报)
→ 人工写10个QA对 + 用LLM合成20个
→ 对合成的QA做人工审核(标注质量)
→ 保存为标准JSONL格式
3. 实现简单的幻觉检测:
pip install transformers
→ 加载NLI模型(deberta-v3-base-nli)
→ 对10个RAG回答做claim-level的蕴含检测
→ 统计幻觉率
4. 设计一个评估Dashboard:
→ 画出RAG评估Dashboard的原型(纸上/Figma)
→ 包含: 四维分数趋势、低分Query列表、幻觉率、延迟分布
→ 思考: 哪些指标需要实时、哪些可以日级别
资源推荐
| 资源 | 说明 | 链接 |
|---|---|---|
| RAGAS官方文档 | RAG评估框架核心文档 | docs.ragas.io |
| TruLens文档 | LLM应用评估+追踪框架 | trulens.org |
| DeepEval文档 | pytest风格的LLM评估 | docs.confident-ai.com |
| Arize Phoenix | 开源LLM可观测性+评估 | docs.arize.com/phoenix |
| RAGAS论文 | "RAGAS: Automated Evaluation of RAG" (2023) | arxiv.org |
| LLM-as-Judge论文 | "Judging LLM-as-a-Judge" (Zheng et al., 2023) | arxiv.org |
| SelfCheckGPT论文 | 无参考的幻觉检测方法 | arxiv.org |
| Hamel Husain博客 | 实战RAG评估经验分享 | hamel.dev |
| LangSmith Evaluation | LangChain配套评估平台 | docs.smith.langchain.com |
明日预告
Day 22: Agent系统工程化(1) — 状态管理与错误恢复
预习问题:
1. Agent在多步骤执行中，如何保存和恢复中间状态？如果第3步失败了怎么办？
2. Agent调用外部工具(API/数据库)时，如何处理超时、限流、不一致等问题？
3. Agent的成本如何控制？一个复杂Query如果触发了20次LLM调用怎么办？
连接点:
Day 19(解析+Chunking) → Day 20(检索+Reranking) → Day 21(评估+迭代)
→ 三天完成了生产级RAG的完整知识体系
Day 22开始进入Agent系统工程化:
→ Day 12学了Agent架构原理(ReAct/Tool Use)
→ Day 22-25深入工程细节: 状态管理/错误恢复/成本控制/安全
→ 从"知道Agent是什么"到"能在生产环境中可靠运行Agent"
→ 类比: Day 12是"知道自动驾驶原理"，Day 22是"让自动驾驶车在真实道路上安全行驶"