2 第一次上线时，最值得优先补齐的 3~5 个能力是什么
1️⃣ 考察意图
面试官想看你是否具备“从 demo 到生产”的工程化思维，而非只会搭个 RAG 原型。这道题表面问优先级排序，实则考察你对生产系统稳定性、可观测性和安全性的理解。刁钻点在于：候选人常只提“检索准确率”或“模型效果”，忽略数据质量、降级策略和日志监控这些“非功能性”但决定系统生死的能力。答好了能展示你经历过线上事故、懂得用最小成本规避最大风险，体现一线大厂要求的“工程落地硬实力”。
2️⃣ 标准答
从生产经验出发，第一次上线时最值得优先补齐的 5 个能力，按优先级排序如下：
- 数据质量监控（优先级最高）
- 为什么：RAG 的根基是索引数据。如果文档更新延迟、格式异常（如 PDF 乱码、HTML 标签残留），检索结果会直接崩坏。
- 怎么做：上线前必须实现自动化检查脚本，检测文档更新时间戳、文本长度、特殊字符比例。例如，用
langchain的DocumentLoader后接一个validate_document函数，检查 token 数是否在 50-2000 之间、是否包含<script>标签。 - 实际坑：某次线上，爬虫抓取到空文档，导致索引为空，所有 query 返回“无结果”。解法：在索引 pipeline 中加入“空文档检测 + 告警”，并设置兜底索引（如通用 FAQ 库）。
- 检索质量评估（离线+在线）
- 为什么：没有指标，你无法判断模型升级或数据变更是否有效。
- 怎么做：离线用 RAGAS 框架计算
context_relevancy和faithfulness，在线用 A/B 测试对比Recall@k（k=5）和用户点击率。例如，用ragas的evaluate()函数，输入 query、retrieved chunks、generated answer，自动打分。 - 工程取舍：离线评估成本低但滞后，在线评估实时但需埋点。建议先跑离线，上线后逐步加在线。
- 错误处理与降级策略
- 为什么：LLM 超时、检索为空、API 限流是常态，没有降级系统会直接 500。
- 怎么做：设计三级降级：① 检索为空时，返回“抱歉，未找到相关信息，请换个问法”；② LLM 超时（如 5 秒无响应），返回检索到的 top-3 chunks 原文；③ 整条链路故障，返回静态 FAQ 页面。
- 实际坑：某次 LLM 服务宕机，系统直接报错，用户流失 20%。解法：引入
fallback_chain，用langchain的RunnableBranch判断异常后切到规则引擎。 - 日志与可观测性
- 为什么：线上问题排查全靠日志。没有 trace，你连是检索慢还是生成慢都分不清。
- 怎么做：接入 ELK（Elasticsearch + Logstash + Kibana）或 OpenTelemetry，记录每个 query 的：① 检索耗时（ms）、② 检索结果数、③ LLM 生成耗时、④ 最终答案。设置告警：检索耗时 > 500ms 或生成耗时 > 3s 时触发。
- 工程取舍：全量日志会爆存储，建议采样率 10% 或只记录异常 query。
- 安全与合规（底线能力）
- 为什么：RAG 系统容易泄露隐私或生成有害内容，一次事故就可能导致产品下架。
- 怎么做：① 输入侧：用
presidio或spaCy做 PII 检测（如身份证号、手机号），匹配后替换为[REDACTED]；② 输出侧：用NeMo Guardrails或自定义敏感词过滤（如政治、暴力词汇）；③ 防止 prompt 注入：对用户输入做正则匹配，拦截类似 “忽略之前指令” 的模式。 - 实际坑：某次用户输入包含 SQL 注入尝试，被 LLM 误执行。解法：在输入层加
re.sub(r'ignore.*instructions', '', query)和sqlparse检测。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从数据质量、评估、降级、可观测性和安全五个层面回答。第一，数据质量监控是根基，必须检测文档更新和格式异常；第二，用 RAGAS 做离线评估，确保检索和生成质量；第三，设计三级降级策略，防止 LLM 超时或检索为空导致系统崩溃；第四，接入 ELK 日志，记录每个 query 的耗时和结果；第五，用 PII 检测和敏感词过滤守住安全底线。总结一句：先保稳定和可排查，再谈效果优化。”
4️⃣ 高频追问 & 应对
追问 1：如果资源有限（比如只有 1 个工程师），你砍掉哪个能力？
砍掉“检索质量评估”的在线部分，保留离线 RAGAS 评估。因为离线评估只需跑脚本，不依赖用户流量，成本最低。但数据质量监控和降级策略不能砍——前者防止数据污染，后者防止系统崩溃。安全合规也不能砍，这是法律风险。日志可观测性可以简化：先只记录异常 query 和错误堆栈，不存全量日志。
追问 2：你提到的降级策略，怎么保证降级后的答案不误导用户？
降级答案必须明确标注“非 AI 生成”。例如，检索为空时返回“抱歉，未找到相关信息”，而不是编造答案。LLM 超时时返回 chunks 原文，并加前缀“以下为相关文档片段，请自行判断”。关键原则：降级宁可说“不知道”，也不胡说。同时，降级答案要记录到日志，便于后续分析为什么触发降级。
追问 3：安全方面，你怎么处理多语言 PII 检测？
多语言 PII 检测是个坑。
presidio默认只支持英文，中文身份证号、手机号需要自定义正则。例如，中文手机号用r'1[3-9]\d{9}'，身份证号用r'\d{17}[\dXx]'。更稳妥的方案是：先用langdetect检测语言，再加载对应语言的 PII 模型。如果资源不足，至少对中文输入做通用正则匹配，并加上[REDACTED]替换。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提“提高检索准确率”或“优化 embedding 模型” → ✅ 生产上线优先考虑的是稳定性和可排查性，效果优化是上线后迭代的事。先保证不崩、能查问题，再谈 Recall@k 提升 5%。
- ❌ 说“用 LLM 做所有降级” → ✅ LLM 降级成本高且不可控，应该用规则引擎（如 if-else 或静态 FAQ）做兜底，只在核心链路用 LLM。
- ❌ 忽略安全，认为“RAG 系统不涉及用户数据” → ✅ 即使索引是公开文档，用户 query 可能包含敏感信息（如“我的身份证号是...”），必须做输入侧 PII 过滤。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“上线后遇到的数据质量事故”切入，比如“某次文档更新延迟导致检索结果过时，我加了时间戳监控和告警”，展示实战经验。
- 如果你只做过传统 NLP：用“搜索系统的降级策略”类比，比如“传统搜索中，索引为空时返回空结果页，RAG 类似，但需要更精细的 LLM 超时处理”，体现迁移能力。
- 如果你是校招无项目：聚焦“RAGAS 评估框架的论文复现”，比如“我复现了 RAGAS 论文中的 context_relevancy 指标，并写了一个 demo 脚本，能自动评估 100 条 query 的检索质量”，展示学习能力。
- RAGAS: Automated Evaluation of Retrieval Augmented Generation（论文）
- LangChain 官方文档：Error Handling & Fallbacks
- NeMo Guardrails: A Framework for Controlling LLM Behavior（论文）
- Presidio: Data Protection and De-identification SDK（GitHub 项目）
- OpenTelemetry: Distributed Tracing for LLM Applications（官方指南）