问题界定：指标繁荣与落地失效的割裂

当nDCG@10、Recall@5等检索指标持续优化，业务团队却频繁收到「答非所问」的投诉。这种现象往往源于评测集与真实场景的断层： - 静态评测泄漏：评测问题与文档片段存在显式关键词重叠（如「DeepSeek-V4的KV cache配置」直接匹配文档标题） - 过拟合题型：评测集过度集中于简单事实型问答，缺乏多跳推理、否定句式等真实场景 - 分数误导：cosine相似度0.85的文档可能完全不解决用户意图（例：询问「Ollama端口冲突」却返回泛泛的安装指南）

决策依据：从指标到用户体验的映射

分层归因检查清单

1. 检索阶段：
2. 用explain search命令检查向量库（如Milvus）的原始匹配片段
3. 验证是否启用HyDE（假设性文档嵌入）缓解零样本问题
4. 检查分块策略：过度细碎的切片会导致上下文碎片化（建议结合语义与结构分块）
5. 生成阶段：
6. 隔离测试：直接喂入人工筛选的TOP3文档，观察DeepSeek-V4输出质量
7. 检查Prompt中是否包含「严格基于上下文回答」的护栏语句
8. 验证temperature参数（过高会导致虚构内容）
9. 上下文管理：
10. 监控实际生效的token窗口（常见坑：重排后超过模型max_length被静默截断）
11. 检查会话历史是否污染当前问题（尤其多轮对话场景）

评测集构建的反模式

• 仅从文档自动生成QA对（导致问题与片段存在机械重复）
• 未包含「负样本」（应有人工标注的「不应召回但被误召」案例）
• 忽略时间衰减（如技术文档更新后旧答案失效但仍在评测集）
• 单一来源采样（应混合用户日志、人工构造、对抗性测试）

落地步骤：构建抗过拟合的验证体系

动态评测集方案

1. 问题采集：
2. 从真实工单日志抽取高频但当前RAG失败的案例（如客服对话中的模糊提问）
3. 人工构造对抗性问题（例：「请对比DeepSeek-V3与V4的推理延迟」需合并多篇文档）
4. 引入「陷阱问题」：测试模型对超出知识范围的响应（如「2027年未发布的功能」）
5. 混合评估层：
6. 定量层：保持传统nDCG等指标
7. 定性层：每周人工抽检20%预测结果，标注「实际可用性」
8. 时效层：对动态知识（如API变更）设置验证时效标签
9. 压力测试：
10. 故意注入噪声文档（如相似但过时的API说明）
11. 测试重排模型（如bge-reranker）的抗干扰能力
12. 模拟长尾查询分布（避免头部query过度优化）

DeepSeek-V4的护栏集成

# 在生成阶段插入确定性验证
response = deepseek.generate(
    prompt=f"""{context_str}\n\n请严格基于上述内容回答：{query}\n\n必须满足：\n1. 若信息不足明确说明\n2. 禁止扩展非上下文内容\n3. 关键数字需标注来源段落""",
    temperature=0.3,  # 降低随机性
    max_tokens=500    # 防止过度展开
)

工程实施关键点

• 索引更新策略：当文档变更时，需同步更新评测集中的相关案例（建议建立文档-问题映射表）
• 灰度发布验证：新模型上线前，用A/B测试对比新旧版在bad case上的改善
• 错误归因看板：可视化各环节错误占比（检索错误/生成幻觉/上下文丢失）

反例边界：何时问题不在RAG本身

• 领域知识完全缺失（如询问未训练的专业术语）
• 需要实时API调用的场景（如「当前服务器负载」需Agent介入）
• 问题本身模糊度过高（应先澄清需求再检索）
• 多模态需求（纯文本RAG无法处理图像/表格查询）

成本监控与优化

• 重排延迟增长与召回率提升的ROI（例：rerank使P99增加120ms但准确率仅升2%时需权衡）
• 人工复核的边际成本（建议控制在总请求量的5%以内，可通过主动学习优化）
• token消耗分析：监控截断率与有效利用率（避免长文档被截断关键信息）

延伸思考：评测驱动的迭代闭环

建立「问题发现-归因-修复-验证」的持续迭代机制，将bad case分类沉淀为： 1. 检索优化类（调整分块/检索算法） 2. 生成约束类（改进prompt/模型参数） 3. 知识缺失类（触发人工知识库补充）