_{🧠 记忆锚点：把模型、索引和检索参数打成可追踪策略包；离线、影子、金丝雀逐级放量，按检索、生成、业务和成本分层归因。}

💡 答案要点

背景（面试高频）：

简历写了 RAG 项目，面试官必问："上线之后，检索策略怎么灰度？效果怎么评测？翻车怎么回滚？成本怎么算？" Demo 能跑通 vs 生产能跑稳，中间差的就是检索治理（RetrievalOps）。

Demo 级 vs 生产级的差距：

Demo：top_k 写在代码里 → 想改要改代码、发版、重启、祈祷
生产：检索策略热配置 → 改参数不重启，秒级生效

RetrievalOps 四大核心能力（面试必答）：

能力	说明	关键点
策略热加载	top_k、embedding 模型、混合检索权重等配置中心化	改配置不重启，秒级生效
灰度发布	Shadow 影子模式 → Canary 金丝雀 → 全量	小流量验证再放量
质量门禁	上线前跑评测集，指标不达标不允许发布	Recall/NDCG/Faithfulness 门槛
一键回滚	配置版本化管理，异常秒级回滚	配置库版本 + 缓存清理

Shadow vs Canary 灰度（高频追问）：

模式	原理	用途
Shadow（影子）	新策略同时在线上跑，结果只记录不返回用户	离线评测新策略效果，零风险
Canary（金丝雀）	小比例流量（如5%）真实走新策略	真实用户验证，异常可控
全量	验证通过后全量切换	保留回滚能力

效果评测指标（为什么只看 Recall@K 不够）：

• 检索层：Recall@K、NDCG、MRR（召回+排序质量）
• 生成层：Faithfulness、Answer Relevance（RAGAS）
• 业务层：用户满意度、点赞/投诉率、人工接管率
• 成本层：请求级 Token 消耗归因，按查询类型/用户维度统计

成本归因（面试加分）：

请求级成本 = Embedding费用 + 检索费用 + 生成Token费用
按 查询类型 / 模块 / 用户维度 归因
→ 发现某类查询成本异常高，针对性优化（如加缓存、降K值）

面试话术：

"我的 RAG 项目在生产环境做了检索治理：策略配置中心化热加载，top_k 和混合检索权重改配置不重启；上线走 Shadow→Canary→全量三步灰度，Shadow 模式新策略影子运行只记录不生效，Canary 放 5% 真实流量验证，通过后全量；质量门禁用评测集卡 Recall 和 Faithfulness，不达标不让发布；配置版本化管理支持一键回滚。成本按请求级归因，发现异常查询类型单独优化。"

📚 参考：Langfuse（灰度发布与效果评测）

---

版本: v3.128 | 更新: 2026-07-02 | 补充 Go Worker Pool / LLMOps / Prompt 管理