2. 五个深题
深题 01
你的 agent 上线后用户反馈“偶尔胡说、偶尔工具调用错”。你如何定位并证明改动有效?
考察点:考 observability 和 eval 闭环。
7+ 分回答骨架:先看 trace,把失败分成 retrieval miss、wrong context、tool args error、policy miss、model hallucination、latency/cost。把代表性 trace 转成 eval case,保留输入、期望路径、允许工具、禁止行为和 rubric。修复后跑离线回归,通过后 canary,线上继续采样新坏 case。
继续追问会衍生:衍生知识点:trace-to-eval、failure taxonomy、regression gate、canary。
知识展开
| 概念 | 是什么 | 工程落点 | 面试表达 / 常见坑 |
| trace-to-eval | trace-to-eval 是把线上失败 trace 抽象成可重复运行的测试样本。 | 保留输入、上下文、工具结果、期望路径、禁止动作、rubric 和版本信息。 | 面试表达:坏 case 不只是修一次,要进入回归集防止再犯。 |
| failure taxonomy | 失败分类把“回答不好”拆成可定位类别。 | 常见类包括 retrieval miss、wrong context、tool arg error、policy miss、hallucination、timeout、cost blowup。 | 常见坑是直接调 prompt,没有先判断坏在哪一层。 |
| regression gate | 回归门禁要求新版本不能破坏旧的关键 case 和安全红线。 | CI 或发布前跑 golden set、bad-case set、safety set、latency/cost thresholds。 | 强回答要说安全红线 case 失败应阻断发布。 |
深题 02
LLM-as-judge 可以用吗?如何避免不可靠?
考察点:考评价方法边界。
7+ 分回答骨架:可以用于可观察标准,如是否引用支持、是否包含必要字段、是否违反安全规则。必须有明确 rubric、少量人工标注校准、judge prompt/version 固定、抽样复核。不能用模糊的“好不好”替代业务状态和工具结果断言。
继续追问会衍生:衍生知识点:rubric、calibration、inter-rater agreement、observable criterion。
知识展开
| 概念 | 是什么 | 工程落点 | 面试表达 / 常见坑 |
| rubric | rubric 是 judge 或人工评分的明确标准,避免“看起来不错”这种主观评价。 | 把答案拆成可观察项,如是否引用、是否包含审批、是否拒绝越权。 | 面试里要说 LLM judge 只能评可观察标准。 |
| calibration | calibration 是用人工标注样本校准自动评测,确认 judge 的偏差和稳定性。 | 抽样对比人工和 judge 分数,调整 rubric,跟踪一致率。 | 常见坑是直接相信 LLM judge 的分数。 |
| observable criterion | 可观察标准是能从输入、输出、trace 或状态中客观判断的条件。 | 例如“是否调用 refund tool 前查订单”,而不是“回答是否聪明”。 | 强回答要把主观质量转成可执行检查项。 |
深题 03
如何为 RAG agent 设计分层 eval?
考察点:考系统拆解。
7+ 分回答骨架:检索层测 Recall@k、MRR、nDCG、context precision;生成层测 faithfulness、answer correctness、citation accuracy、no-answer;agent 层测 query rewrite、分步检索、工具选择、成本和延迟。不要只测最终答案。
继续追问会衍生:衍生知识点:retrieval eval、generation eval、citation eval、agentic RAG eval。
知识展开
| 概念 | 是什么 | 工程落点 | 面试表达 / 常见坑 |
| retrieval eval | retrieval eval 判断正确证据是否被召回和排序靠前。 | 用 Recall@k、MRR、nDCG、filter correctness 测检索阶段。 | 面试中要先测 evidence 是否到场,再测生成。 |
| generation eval | generation eval 判断有证据时答案是否正确、完整、忠实。 | 测 answer correctness、faithfulness、citation accuracy、no-answer accuracy。 | 常见坑是把 RAG 评测简化成最终答案打分。 |
| agentic RAG eval | agentic RAG eval 还要评 query rewrite、多步检索、工具选择和 step budget。 | trace 中检查每次检索目标、来源选择、停止条件和成本。 | 强回答要说明 agentic RAG 比普通 RAG 多了路径评估。 |
深题 04
线上成本升高,你如何用 observability 找原因?
考察点:考指标归因。
7+ 分回答骨架:按 tenant、feature、model、prompt version、tool、retrieval、rerank、retry、cache miss、agent steps 拆成本和延迟 waterfall。看是否 prompt 变长、loop 增多、cache 失效、工具超时重试、rerank 批量扩大或模型路由变化。
继续追问会衍生:衍生知识点:cost attribution、latency waterfall、cache miss、step count。
知识展开
| 概念 | 是什么 | 工程落点 | 面试表达 / 常见坑 |
| cost attribution | 成本归因把费用拆到 tenant、feature、model、tool、retry、cache miss 和 agent steps。 | 埋点记录 token、模型价格、工具耗时、重试次数、缓存命中率。 | 面试表达:成本升高不能只说换便宜模型,要先知道钱花在哪。 |
| latency waterfall | 延迟瀑布把一次请求拆成 retrieval、rerank、tool、model、network、queue、agent loop。 | trace 每个 span 记录 start/end、status、timeout 和 payload size。 | 常见坑是只看总 P95,不知道是哪一段变慢。 |
| step count | step count 是 agent 决策和行动次数,直接影响延迟、成本和风险。 | 监控 per-run step_count、tool_call_count、loop_count 和 stop_reason。 | 强回答要把 step count 作为 agent 质量和成本指标。 |
深题 05
如何把 eval 接入发布流程?
考察点:考工程落地。
7+ 分回答骨架:定义 golden set、risk-specific safety set、线上坏 case regression set。CI 中跑快速关键集,发布前跑完整集;门禁包含质量不下降、红线安全 case 0 失败、成本/延迟不超过阈值。通过后 shadow/canary,失败可 rollback。
继续追问会衍生:衍生知识点:golden set、CI gate、safety regression、shadow mode。
知识展开
| 概念 | 是什么 | 工程落点 | 面试表达 / 常见坑 |
| golden set | golden set 是稳定、代表核心能力和边界场景的评测集合。 | 由高频真实请求、业务关键路径、线上坏 case、安全红线组成。 | 面试里要说明 golden set 会演进,但不能随意改到只让新版本通过。 |
| CI gate | CI gate 是把 eval 接进工程发布流程,自动阻断明显退化。 | 快速集进 PR,完整集进 release,红线 case 失败直接 fail。 | 常见坑是 eval 只在 notebook 里跑,无法约束上线。 |
| shadow mode | shadow mode 让新系统在真实流量旁路运行但不影响用户。 | 记录新旧输出、工具计划、成本延迟和安全拦截差异。 | 强回答要把 shadow mode 放在 offline eval 和 canary 之间。 |