面试题库

30 天从前端工程师到 Agent 工程师

D21 评估与可观测：golden set、LLM-as-judge、tracing、失败率/成本面板；Pi vs LangGraph 总结；W3 复盘

• 用大模型给大模型的输出打分（LLM-as-judge），有哪些不可靠的地方？怎么办？What makes LLM-as-judge unreliable, and what do you do about it?

  国内高频海外高频深入#evaluation#llm-as-judge#reliability

  分析过程 · 先想清楚再作答

  1. 这题筛的是「你是真用过，还是听说过」。用过的人能报出具体的失效形态和量级，没用过的人只会说「可能不准」。
  2. 第一种，**同源偏差**：judge 和被评估的 Agent 用同一个模型时，它偏向认可自己的输出——同一个模型对「什么算好答案」的偏好是一致的，让它复核自己刚写的东西，它当然觉得没问题。实测数量级：同一批被改坏的产出，同源 judge 给 14/15，换个模型只给 12/15，被多放过去的正是最该抓的边缘产出。这个坑不止在 judge，**凡是「模型评模型」的位置都有**，Critic 节点是同一个问题。
  3. 第二种，**长度偏好**：judge 倾向给篇幅大的答案更高分。实测：一条 33 字的正确回复灌上 141 字无关客套话，凭印象打分的提示词就从 2 分涨到 4 分，内容一个字没变。
  4. 第三种，**评分提示词漂移**：judge 的评分随提示词微调整体移动。同一份产出，两套评分提示词一套给 2 分一套给 5 分。所以有条硬纪律——**分数只在同一套 judge 提示词内部可比**，跨版本比较是没有意义的。
  5. 解药要一一对应，别笼统说「多测几次」：固定 judge 提示词并版本化（每条评分记录带上 rubric 版本与 judge 模型，那是它的坐标；面板发现混了两套口径应当直接拒绝聚合，而不是算出一个没含义的平均分）；默认用不同的模型当 judge，而且这该是默认值不是可选项；留一小批人工标注做校准集，每次改评分提示词拿它对一遍，**比的是结论（过或不过）而不是分数差**——差 1 分无所谓，结论翻了就是事故。
  6. 还有一条更根本的：**把评分标准从主观印象换成可核对的清单**，它同时解掉长度偏好——照清单逐条数，灌水加不了分。实测那条灌水回复在清单口径下前后都是 5 分，纹丝不动。
  7. 可以预期的追问：judge 便宜还是人工便宜？答：judge 的成本和被评估的系统本身一个量级，所以「跑一次全量评估多少钱」是你决定每次提交都跑还是每天跑一次的依据；而人工的成本不在钱在延迟——它给不了你改一次提示词就想看一次结果的反馈速度，所以人工只该用在校准集上。

  How to reason about it · think before answering

  1. This screens for whether you have actually used it. People who have can name specific failure shapes with magnitudes; people who have not just say it might be inaccurate.
  2. First, self-preference: when the judge and the evaluated agent share a model, it favours its own output — the same model has a consistent notion of what a good answer looks like, so asking it to review what it just wrote gets an approving verdict. Measured: on the same batch of deliberately degraded outputs, a same-model judge gave 14/15 while a different model gave 12/15, and the extra passes were exactly the borderline cases worth catching. This is not confined to judges — every model-grading-model position has it, and a Critic node is the same problem.
  3. Second, length bias: judges reward longer answers. Measured: padding a correct 33-character reply with 141 characters of irrelevant pleasantries moved an impression-based rubric from 2 to 4 without changing a word of substance.
  4. Third, rubric drift: scores shift wholesale when the judge prompt is tweaked. The same output scored 2 under one rubric and 5 under another. Hence the hard rule: scores are comparable only within one judge prompt, and cross-version comparison is meaningless.
  5. Match each remedy to its failure rather than saying run it a few more times. Freeze and version the judge prompt — every score record carries its rubric version and judge model, which are its coordinates, and a dashboard that finds two rubrics mixed should refuse to aggregate rather than emit a meaningless average. Default to a different model as judge, as a default and not an option. Keep a small human-labelled calibration set and re-run it whenever the rubric changes, comparing verdicts (pass or fail) rather than score deltas — one point of drift is fine, a flipped verdict is an incident.
  6. And one deeper fix: replace impressionistic criteria with a checkable list, which also dissolves length bias — counting items off a list gives padding nothing to earn. Measured, that padded reply scored 5 both before and after under the checklist rubric.
  7. Expect: is a judge cheaper than humans? The judge's cost is the same order as the system being evaluated, so what a full evaluation run costs decides whether you run it per commit or nightly. Human cost is not money but latency — it cannot give you feedback at the speed of one prompt edit, which is why humans belong on the calibration set only.

  答题要点

  • 同源偏差：judge 与被评估 Agent 同模型会虚高（实测 14/15 vs 异源 12/15），且凡「模型评模型」的位置都有，Critic 同理
  • 长度偏好：灌水 141 字能让印象分从 2 涨到 4，内容一字未变
  • 评分提示词漂移：同一产出两套 rubric 一个 2 分一个 5 分，所以分数只在同一套提示词内部可比
  • 解药一一对应：rubric 版本化并随记录存坐标、面板发现混口径直接拒绝聚合、默认换模型当 judge
  • 留人工标注校准集，比结论（过/不过）而不是比分数差——差 1 分无所谓，结论翻了是事故
  • 更根本的是把主观印象换成可核对的清单，同时解掉长度偏好（清单口径下灌水前后都是 5 分）

  Key points

  • Self-preference: a same-model judge inflates scores (14/15 vs 12/15 cross-model), and it applies to every model-grading-model spot including Critic
  • Length bias: 141 characters of padding moved an impression score from 2 to 4 with no substantive change
  • Rubric drift: the same output scored 2 and 5 under two rubrics, so scores compare only within one judge prompt
  • Remedies map one-to-one: version the rubric and store it alongside each record, refuse to aggregate mixed rubrics, default to a different judge model
  • Keep a human-labelled calibration set and compare verdicts, not score deltas — a point of drift is fine, a flipped verdict is an incident
  • The deeper fix is a checkable list instead of impressions, which also removes length bias (the padded reply scored 5 both ways)
• 系统设计：一个多 Agent 客服平台已经上线，团队每周改几次提示词，但没人说得清质量是变好还是变差，成本也只有一个月底的总数。请为它设计一套评估与可观测体系。System design: a multi-agent support platform is live, the team edits prompts several times a week, nobody can say whether quality is improving, and cost is only known as a month-end total. Design its evaluation and observability system.

  国内高频海外高频深入#system-design#evaluation#observability#cost

  分析过程 · 先想清楚再作答

  1. 先别画架构图。这道题的陷阱是它听起来像「搭一套监控」，于是很多人上来就报 Prometheus 加 Grafana——那答的是基础设施，不是这道题。花三到五分钟问清四件事：一是**改提示词的频率和发布方式**（每周几次、有没有灰度、能不能回滚）；二是**现在出问题是怎么发现的**（用户投诉？还是有人偶然看到？）；三是**有没有历史数据**（线上对话存了多久、能不能回放）；四是**谁来看这套东西**（工程师排障，还是老板看成本）。这四个答案会实质改变设计，问它们本身就是分数。
  2. 然后给主干，一句话定形状：**一份数据、两种读法。** 埋点只做一套（span），横着读是一次请求的调用树（排障用），竖着堆是面板（趋势和成本用）。**这条是地基**——两套数据来源迟早对不上，然后没有人相信任何一个。很多候选人在这里就分叉成「监控系统」和「评估系统」两套，那是后面所有麻烦的源头。
  3. 接着按三层展开。**第一层，离线回归**：建一个小而稳的 golden set（15 到 50 条），三层覆盖——每条路由都有人走、每种失败模式各一条（置信度不足落兜底、工具预算耗尽降级、下游挂掉）、以及历史上真出过事故的那几条。每条写清期望路由和必备信息清单。维护规矩是**只增不改**：改一条期望，历史分数全部作废。用 LLM-as-judge 对照清单打分，**judge 换一个模型、rubric 版本化并随每条记录存下来**。这一层挂在 CI 上，每次改提示词跑一遍，产出一个能和上次比的数字。
  4. **第二层，在线观测**：每次请求落一棵 span 树，必须记路由理由（模型做的决策，当时不记就永远丢了）、每个节点的 token 与耗时、以及降级和兜底事件。面板回答四个问题：错了多少、慢在哪、花了多少、**钱花在哪个角色身上**。最后一个是多 Agent 特有的，也最有用。
  5. **第三层，在线采样评估**：离线的 15 条覆盖不了真实流量分布，所以按比例采样线上请求（比如 1%）跑同一套 judge，得到一条真实质量曲线。**这一层是前两层的桥**：离线告诉你有没有改坏已知的东西，在线告诉你真实用户遇到了什么。
  6. 成本这块要给数字感，这是区分层级的地方。**多 Agent 一次用户请求可能产生 5 到 10 次模型调用**，所以「每次调用多少钱」比真实单价小一个数量级，**必须按请求算钱**。给个算式：日活一万、人均三次会话、每次 5 次调用就是 15 万次调用；按输入 2000 输出 500 token、$0.15/$0.60 每百万算，一天约 90 美元。这个数立刻推出两件事：按节点分摊能定位省钱的地方，以及**评估本身的成本要单独记**——judge 调用和被评估系统一个量级，它决定你每次提交都跑还是每天跑一次。
  7. 最后收在「怎么让它真的被用起来」，这是很多人漏的一层：把评估结果接进发布流程（通过率跌破阈值就挡住发布）、把 rubric 和 golden set 放进代码仓库走 code review、以及**给每个机制配一句失效模式**——judge 会偏向同源模型、golden set 会被针对性优化（有人为了让它绿而调提示词，那一刻它就失去了意义）、采样会漏掉长尾。说不出失效模式的方案，面试官会认为你只是读过。
  8. 可以预期的追问，按频率排：judge 用什么模型（比被评估的强一档，且必须异源）；golden set 从哪来（先从线上捞一批人工标注，再逐次把事故补进去）；这套东西自己出问题怎么办（面板发现 rubric 混版直接拒绝聚合，而不是给一个没含义的平均分）；多久能上线（第二层一周、第一层两周、第三层一个月，因为它依赖前两层）。

  How to reason about it · think before answering

  1. Do not draw an architecture diagram yet. The trap is that this sounds like build monitoring, so many candidates open with Prometheus and Grafana — that answers infrastructure, not this question. Spend three to five minutes on four things: how often prompts change and how they ship (weekly cadence, canary, rollback); how problems surface today (user complaints, or someone happening to notice); what history exists (how long conversations are retained, whether they can be replayed); and who consumes this (engineers debugging, or an executive watching spend). All four materially change the design, so asking them scores.
  2. Then the trunk, in one sentence: one dataset, two readings. Instrument once, as spans; read across for a single request's call tree (debugging) and stack them for a dashboard (trends and cost). This is the foundation — two data sources will eventually disagree and then nobody trusts either. Many candidates fork here into a monitoring system and an evaluation system, which is the source of every later problem.
  3. Then three layers. Layer one, offline regression: a small stable golden set (15 to 50), covering three things — every route exercised, one item per failure mode (low-confidence fallback, tool budget exhaustion, downstream outage), and the cases behind real past incidents. Each item declares its expected route and a checklist of required facts. The maintenance rule is add, never edit: changing an expectation voids all historical scores. Score with an LLM-as-judge using a different model, and version the rubric, storing that version on every record. This layer runs in CI on every prompt change and emits a number comparable to last time.
  4. Layer two, online observability: every request writes a span tree recording the routing rationale (a model decision, lost forever if not captured), per-node tokens and latency, and degradation and fallback events. The dashboard answers four questions: how much is wrong, where it is slow, what it cost, and which role spent it — that last one is multi-agent specific and the most actionable.
  5. Layer three, online sampled evaluation: fifteen offline cases cannot cover the real traffic distribution, so sample a fraction of live requests (say 1%) through the same judge to get a true quality curve. This layer bridges the other two: offline tells you whether you broke something known, online tells you what real users encountered.
  6. Bring numbers on cost, which is what separates levels. A multi-agent request can produce five to ten model calls, so per-call price is an order of magnitude below the real unit cost and you must price per request. Give the arithmetic: 10k DAU at three sessions each and five calls per session is 150k calls a day; at 2000 input and 500 output tokens, $0.15 and $0.60 per million, that is roughly $90 a day. That number implies two things: per-node attribution shows where to optimise, and evaluation's own cost must be tracked separately, since judge calls are the same order as the system itself and decide whether you evaluate per commit or nightly.
  7. Close on adoption, which many candidates omit: wire evaluation into the release process (block a deploy when pass rate drops below threshold), keep the rubric and golden set in the repository under code review, and pair every mechanism with a failure mode — judges favour same-family models, golden sets get gamed (someone tunes prompts to make it green, and at that moment it is worthless), sampling misses the long tail. A proposal with no stated failure modes reads as book knowledge.
  8. Expect, by frequency: which model judges (one tier above the system under test, and necessarily a different family); where the golden set comes from (start with human-labelled production samples, then append every incident); what happens when this system itself misbehaves (the dashboard refuses to aggregate mixed rubric versions rather than emitting a meaningless average); and how long to build (layer two in a week, layer one in two, layer three in a month since it depends on both).

  答题要点

  • 先用三到五分钟问清四件事：改提示词的频率与发布方式、现在问题怎么被发现、有无历史数据可回放、这套东西给谁看
  • 主干是「一份数据、两种读法」：埋点只做一套 span，横着读是调用树、竖着堆是面板；两套数据源迟早对不上
  • 第一层离线回归：小而稳的 golden set，三层覆盖（每条路由、每种失败模式、历史事故），只增不改，挂 CI
  • 第二层在线观测：span 树记路由理由、每节点 token 与耗时、降级兜底事件；面板回答错了多少/慢在哪/花了多少/钱花在哪个角色
  • 第三层在线采样评估：按比例采样线上请求跑同一套 judge，补上离线覆盖不到的真实分布
  • 成本必须按请求算而非按调用：一次请求 5 到 10 次调用，给出日活一万约 90 美元一天的算式；评估自身成本单独记
  • 收在落地：通过率跌破阈值挡发布、rubric 与 golden set 进仓库走 review
  • 每个机制配失效模式：judge 偏向同源、golden set 会被针对性优化、采样漏长尾——说不出失效模式等于只是读过

  Key points

  • Spend three to five minutes clarifying four things: prompt change cadence and release process, how problems surface today, what replayable history exists, and who the audience is
  • The trunk is one dataset, two readings: instrument once as spans, read across for a call tree and stack for a dashboard; two sources will disagree
  • Layer one, offline regression: a small stable golden set covering every route, every failure mode and past incidents, add-never-edit, wired into CI
  • Layer two, online observability: span trees recording routing rationale, per-node tokens and latency, degradation events; the dashboard answers wrong/slow/cost/which-role
  • Layer three, sampled online evaluation through the same judge, covering the real distribution the offline set cannot
  • Price per request, not per call: five to ten calls per request, with arithmetic showing ~$90/day at 10k DAU; track evaluation's own cost separately
  • Close on adoption: block releases when pass rate drops, keep rubric and golden set in the repo under review
  • Pair every mechanism with a failure mode: judge self-preference, golden set gaming, sampling missing the tail — omitting these reads as book knowledge

D24 RAG 进阶：hybrid search、rerank、引用、recall 评估

• 怎么评估一个 RAG 系统的检索效果？评估集应该怎么构造？How do you evaluate retrieval quality in a RAG system, and how should the evaluation set be built?

  国内高频海外高频深入#rag#evaluation#recall

  分析过程 · 先想清楚再作答

  1. 这题是国内面试的极高频题，也是最容易暴露「只搭过没调过」的一题。判据很简单：你的回答里有没有出现**具体的指标名和标注粒度**，没有就是没做过。
  2. 先把评估对象分清楚——这是最容易混的一步：**检索评估问「找得到找不到」，生成评估问「答得对不对」**。两套评估集要分开维护。混成一套的后果是分数掉了你分不清是检索漏了还是模型答砸了，而这两件事的修法完全不同。
  3. 评估集的形状：20 条左右的 query，每条**人工标注 1 到 3 个必须召回的 chunkId**。注意标注粒度是**块**不是文档——检索的单位就是块，标到文档级会让指标虚高。query 要覆盖真实分布，尤其要包含那些你知道会翻车的类型（编号、同义改写、跨文档）。
  4. 三个指标各回答一个问题：recall@5 是「进上下文的那几条覆盖了多少」，也就是你真正关心的数；recall@20 是天花板，它上不去说明问题在召回侧、重排再强也没用；MRR 对排序质量敏感，recall 打平时用它分高下。
  5. 生产视角：评估集一旦定下来就要冻结，换了样本分数就没有可比性——这和产线质检必须用固定的标准样品是同一个道理。同时线上要有对照指标（引用为空率、幻觉引用率、转人工率），因为离线过了不等于线上没事。
  6. 可预期的追问：标注成本这么高，20 条够吗？答：20 条不够做统计显著性，但足够做**回归**——它的作用是「改了检索之后别悄悄变差」。要做 A/B 定论再上规模，而且优先扩充失败案例，不是随机加样本。

  How to reason about it · think before answering

  1. This is a very common question in the Chinese market and the fastest way to expose someone who has assembled RAG but never tuned it. The test: does your answer contain concrete metric names and an annotation granularity?
  2. First separate what is being evaluated — the step people most often conflate. Retrieval evaluation asks 'was it found'; generation evaluation asks 'was the answer right'. Keep two separate sets. Merge them and, when the score drops, you cannot tell whether retrieval missed or the model fumbled — and those have completely different fixes.
  3. Shape of the set: about 20 queries, each annotated with 1-3 chunk ids that must be retrieved. Annotate at chunk level, not document level — chunks are the retrieval unit, and document-level labels inflate the numbers. Cover the real query mix, especially the types you know break: codes, paraphrase, cross-document.
  4. Three metrics, three questions. recall@5 is what actually reaches the model, so it is the number you care about. recall@20 is the ceiling — if it does not move, the problem is on the recall side and no reranker will save you. MRR is sensitive to ordering and breaks ties when recall is equal.
  5. Production view: freeze the set once agreed, because changing samples destroys comparability — the same reason a factory keeps fixed reference samples. Pair it with online counterparts (empty-citation rate, hallucinated-citation rate, escalation rate), since passing offline does not mean passing in production.
  6. Expected follow-up: is 20 enough given the labelling cost? Not for statistical significance, but enough for regression — its job is to stop retrieval silently getting worse. Scale up before you settle an A/B, and grow it from failure cases rather than random additions.

  答题要点

  • 检索评估和生成评估是两套：前者问「找得到找不到」，后者问「答得对不对」，分开维护。
  • 评估集是 20 条左右的 query，每条人工标 1 到 3 个必须召回的 chunkId——标到块级，不是文档级。
  • recall@5 是真正关心的数（模型只看得到这几条），recall@20 是天花板，MRR 衡量排序质量。
  • 评估集一旦定下来就冻结，否则分数没有可比性；线上再配引用为空率、幻觉引用率做对照。
  • 20 条不够做显著性但够做回归；扩充时优先补失败案例，不是随机加样本。

  Key points

  • Retrieval and generation evaluation are two separate sets: 'was it found' versus 'was the answer right'.
  • Around 20 queries, each labelled with 1-3 chunk ids that must be retrieved — chunk level, not document level.
  • recall@5 is what the model actually sees, recall@20 is the ceiling, MRR measures ordering quality.
  • Freeze the set once agreed or scores stop being comparable; pair it with online empty-citation and hallucinated-citation rates.
  • Twenty cases is a regression guard, not a significance test; grow it from failure cases, not random samples.

5 天提示词工程零基础

D5 跨模型迁移：Claude / GPT / 国产模型的差异、system prompt 组织；进入 Claude 课与 Codex 课

• 迁移之后怎么验证效果没有退步？如果通过率降了，你的排查顺序是什么？After migrating a prompt, how do you verify nothing regressed, and if the pass rate drops, what is your debugging order?

  国内高频海外高频深入#model-migration#evaluation

  分析过程 · 先想清楚再作答

  1. 这题是 D4 与 D5 的合题，考的是「验证有没有流程」。答「多跑几条看看」是最低分；面试官要听的是基线、同一批用例、逐字段对号。
  2. 拆法：验证的前提是基线——迁移前在源模型上跑过同一份测试集并记录通过率与失败用例；没有基线就没有「退步」可言。迁移后用完全相同的用例在目标模型上跑，两列并排。
  3. 排查顺序：先看失败用例是正常还是边界——边界优先怀疑提示词；再把失败字段对四处断裂对号，改厂商适配块，通用块不动；再跑一遍；仍失败的用例看是否与源模型的失败重合——重合的是提示词自身的已知回退，与迁移无关，按 D4 的变更记录处理。
  4. 结论：达到与源模型相同的通过率、且通用规则块一个字没改，迁移才算完成；改了通用块就等于改了提示词版本，要重新在源模型上跑。
  5. 追问：真模型有随机性，一次运行的通过率能信吗？每条跑三次取多数或温度设 0；另一个追问是要不要在两家上长期并跑，答案是至少保留一段时间的双跑对比，因为模型版本更新会让通过率漂移，测试集是唯一能及时发现漂移的工具。

  How to reason about it · think before answering

  1. A combined D4/D5 question testing whether verification is a process. 'Run a few and see' is the floor; the interviewer wants baseline, identical cases, field-level triage.
  2. Verification needs a baseline: the same test set run on the source model beforehand with pass rate and failing cases recorded. Then run the identical cases on the target and put the columns side by side.
  3. Debugging order: normal versus edge failures first — edge failures point at the prompt; map failing fields to the four breakages and fix the vendor block, leaving the common block untouched; rerun; remaining failures that overlap the source model's are the prompt's own known regressions, unrelated to migration, handled through the D4 changelog.
  4. Conclusion: migration is done when the target matches the source pass rate with zero edits to the common block; editing the common block is a new prompt version and must be re-run on the source too.
  5. Follow-ups: single-run noise — run each case three times and take the majority, or use temperature zero. And keep dual-running for a while, because vendor model updates drift pass rates and the test set is the only thing that catches drift early.

  答题要点

  • 验证前提是基线：迁移前在源模型跑过同一份测试集
  • 同一批用例在目标模型上跑，两列并排看通过率与失败用例
  • 排查顺序：正常还是边界 → 失败字段对四处断裂 → 改厂商块不动通用块 → 重跑 → 与源模型重合的失败是已知回退
  • 通用块改了就是新版本，要回源模型重跑；随机性用多次取多数或温度 0 压住

  Key points

  • Verification requires a baseline: the same test set run on the source model before migrating
  • Run identical cases on the target and compare pass rates and failing cases side by side
  • Triage: normal versus edge, map failing fields to the four breakages, fix the vendor block only, rerun, and treat failures shared with the source as known regressions
  • Any edit to the common block is a new version that must be re-run on the source; tame randomness with majority-of-three or temperature zero

Codex 与 OpenAI Agents SDK 高效使用

D5 Claude 与 Codex 选型与协作：同一任务双工具实测对比、一个写一个审的混用工作流

• 怎么评价一个 coding agent 这次任务的输出质量，而不只是看它跑没跑通？How do you judge the quality of a coding agent's output on a task, beyond whether it ran?

  国内高频海外高频深入#coding-agent#evaluation#quality

  分析过程 · 先想清楚再作答

  1. 这题考的是你有没有把「测试绿了」当终点。答「看测试」是及格线，区分度在测试之外。
  2. 拆成四层：正确性（测试是否覆盖了需求里的边界，比如 title 超长、done 传字符串）、契约（错误响应形状是否与需求一字不差，还是它自作主张改了）、范围（有没有改不该改的文件、有没有偷偷加依赖或改默认值）、可维护性（校验规则是否抽成常量、测试是否隔离、命名是否与仓库一致）。
  3. 再说怎么量：正确性看它写的测试之外你再补的反例能不能过；契约与范围看 diff 与需求逐条对照；可维护性交给第二家模型或人做结构化审查。
  4. 补一条随机性：单次结果不能下结论，同一需求跑三次看方差，方差大本身就是一个质量信号。
  5. 可预期的追问：它自己说「已完成并通过测试」能信吗？只信你能复现的部分——在你的机器上重跑测试、看 diff，agent 的汇报是线索不是证据。

  How to reason about it · think before answering

  1. This tests whether you treat green tests as the finish line; 'check the tests' is the pass mark, differentiation lies beyond it.
  2. Four layers: correctness (do the tests cover the requirement's edges such as overly long titles or a string for done), contract (does the error shape match the spec exactly or did it improvise), scope (did it touch forbidden files, add dependencies or change defaults silently), maintainability (constants extracted, tests isolated, naming consistent with the repo).
  3. How to measure: correctness by adding your own counterexamples beyond its tests; contract and scope by diffing against the requirement line by line; maintainability via a structured review by a second model or a person.
  4. Add variance: one run proves nothing; run the same requirement three times and treat high variance as a quality signal in itself.
  5. Expect the follow-up: can you trust its 'done, tests pass'? Only what you can reproduce; rerun tests and read the diff yourself, the agent's report is a lead, not evidence.

  答题要点

  • 四层：正确性、契约、范围、可维护性，测试绿只是正确性的一部分
  • 正确性用自己补的反例验证，契约与范围对照需求逐条看 diff，可维护性做结构化审查
  • 同一需求跑多次看方差，方差大本身是质量信号
  • agent 的汇报是线索不是证据，只信自己能复现的部分

  Key points

  • Four layers: correctness, contract, scope, maintainability; green tests cover only part of correctness
  • Verify correctness with your own counterexamples, contract and scope by diffing against the spec, maintainability via structured review
  • Run the same requirement several times; high variance is itself a quality signal
  • The agent's report is a lead, not evidence; trust only what you reproduce

7 天 Agent Skills：把经验做成可复用能力

D3 设计方法：从重复任务提炼、检查清单式与参考手册式、四种反模式与触发测试

• 优化 description 的时候怎么避免过拟合到你自己写的那几条测试查询？When optimizing a description, how do you avoid overfitting to the very queries you wrote?

  国内高频海外高频深入#agent-skills#evaluation

  分析过程 · 先想清楚再作答

  1. 这题是机器学习的老概念换了个场景，考的是你能不能把它迁移过来。能说出「验证集」三个字只是起点，真正的区分度在你怎么描述那个具体的错误动作。
  2. 先点明过拟合在这里长什么样：一条查询没触发，你把它的原话抄进描述，于是这一条过了，换一句同义的又不过。**抄原话就是过拟合的动作本身。**
  3. 正确做法是归纳：找出这条失败查询代表的**那一类说法**，然后把这一类补进去。比如「这几个文件我要提交了」失败了，该补的不是这句话，是「不含专业词的口语提交请求」这一类。
  4. 结构上靠拆分兜底：查询集按六比四拆成训练与验证，只用训练集的失败项指导改写，验证集全程不参与优化过程，两份都要保持正负比例接近，拆完固定不再洗牌。
  5. 还有两条实操经验。**挑版本按验证集通过率挑，不是按迭代顺序挑**——后面几轮往往在往训练集上过拟合，最好的可能是第三版而不是第五版。改五轮左右还不动就该停，问题多半在查询集本身而不在描述。
  6. 可预期的追问是「怎么知道是查询集的问题」。答案是看那些在两种配置下都失败或都成功的条目：都成功说明这条太容易、没有信息量，都失败说明要么标注错了要么要求超出模型能力，两类都该换掉。

  How to reason about it · think before answering

  1. This is a familiar machine learning idea in a new setting. Saying validation set is only the start; the discriminator is describing the exact wrong move.
  2. Name what overfitting looks like here: a query fails, you paste its wording into the description, that query passes, and a synonymous one fails. Pasting the wording is the overfitting act itself.
  3. The right move is to generalize: identify the category the failing query represents and cover that. If a casual phrasing failed, cover casual phrasings, not that sentence.
  4. Structurally, rely on the split: roughly sixty-forty, revise only from train-set failures, keep the validation set out of the loop, preserve label balance in both, and freeze the split across iterations.
  5. Two practical rules: pick the version by validation pass rate rather than by recency, since later rounds tend to overfit, and stop after about five iterations if nothing moves, because the problem is then in the queries.
  6. Expected follow-up: how do you know the queries are the problem? Look at items that pass or fail in every configuration. Always-pass items carry no information; always-fail items are mislabeled or beyond the model.

  答题要点

  • 过拟合的具体动作是把失败查询的原话抄进描述，要改成补它代表的那一类说法。
  • 查询集六四拆分，只用训练集指导改写，验证集全程不看。
  • 两个集合都要保持正负比例接近，拆完固定，不要每轮重洗。
  • 按验证集通过率挑版本，最好的那版不一定是最后一版。
  • 五轮不动就停，去查查询集本身是不是太容易、太难或标注错了。

  Key points

  • The overfitting move is pasting a failing query verbatim; generalize to its category instead.
  • Split roughly sixty-forty and revise only from train-set failures.
  • Keep label balance in both splits and freeze the split across iterations.
  • Select the version by validation pass rate; the best is not always the last.
  • If five rounds change nothing, inspect the query set for triviality, impossibility or mislabeling.

D7 综合与复盘：把一套团队规范做成 skill 包并驱动子代理完成一次真实任务

• 你怎么证明一个 skill 真的有用，而不是感觉上更好？How do you prove a skill actually helps rather than just feeling better?

  国内高频海外高频深入#agent-skills#evaluation#methodology

  分析过程 · 先想清楚再作答

  1. 这题在考评估能力，也在考诚实。答「我试了几次感觉好多了」直接出局，面试官要的是一个可复现的对照。
  2. 先给整体结构：同一批用例、两组只差一个变量、逐条判定、比通过率。**结论只有一个数：通过率差值。**
  3. 然后讲对照怎么做干净，这是本题最容易被忽略的一半。**绝对不要在你调试了两小时的那个会话里试**——那个上下文里散落着你手打的规范片段和你纠正过的措辞，模型产出得好是因为你自己把答案说了一遍。要用一个上下文干净的子代理，两份定义只差「预加载哪几个 skill」这一行，模型、工具集、提示词全部一致。
  4. 再讲用例集怎么配：正例、边界例、负例大约五比三比二。负例不能省，它测的是触发面有没有过宽，而**过宽是 skill 最常见的坏法**——少了负例，一个什么都抢的 skill 也能拿满分。
  5. 断言是全部重点。可判定的意思是不看好坏、只看事实成不成立：「类型字段取自那六个值之一」「范围等于仓库里真实存在的目录名」「首行不超过 50 个字符」是可判定的；「写得清楚」不是。一条断言只查一件事，失败时才知道是哪一条挂了。
  6. 最后补诚实这一层：有些判断写不出可靠断言，比如「这条评审意见有没有抓住真问题」。硬凑只会得到假绿，老实标成人工判定、抽查几条、并在结论里注明有几条是人工判的。**一份诚实的部分自动化评估远好过一份全绿的假评估。**
  7. 可预期的追问是「样本量这么小，结论站得住吗」。答话要坦率：小样本只能支撑「在这一批任务上」的结论，所以每个数字都要带测量条件，不要外推成通用效率提升。

  How to reason about it · think before answering

  1. This tests evaluation skill and honesty. Saying it felt better ends the answer; the interviewer wants a reproducible comparison.
  2. Give the structure first: one set of cases, two arms differing in exactly one variable, per-assertion judging, and a pass-rate comparison. The conclusion is a single number, the delta.
  3. Then explain how to keep the comparison clean, the half most people skip. Never test in the session you spent two hours debugging: that context is littered with convention snippets you typed and corrections you made, so good output reflects you, not the skill. Use a fresh subagent, with the two definitions differing only in which skills are preloaded.
  4. Describe the case mix: positive, boundary and negative roughly five to three to two. Negatives are non-negotiable because they measure whether the trigger surface is too wide, which is the most common way a skill goes wrong. Without them, a skill that grabs everything scores perfectly.
  5. Assertions are the core. Decidable means checking facts, not quality: the type field is one of six values, the scope equals a real directory in the repository, the first line is under fifty characters. Written clearly is not decidable. One assertion checks one thing so failures point somewhere.
  6. Close on honesty: some judgments resist reliable assertions, such as whether a review comment found the real problem. Forcing an assertion yields false green. Mark those as human-judged, sample a few, and say so in the conclusion.
  7. Expected follow-up: does a small sample support the claim? Be candid. A small sample supports a claim about that batch of tasks only, so every number carries its measurement conditions and is never extrapolated into a general efficiency gain.

  答题要点

  • 同一批用例、两组只差一个变量、逐条判定、比通过率差值。
  • 对照必须用上下文干净的子代理，不能在调试过的会话里试。
  • 两份子代理定义只差预加载 skill 那一行，模型、工具、提示词全部一致。
  • 用例要含负例，它测触发面有没有过宽，过宽是最常见的坏法。
  • 断言要可判定、一条只查一件事；判不了的老实标人工判定并在结论里注明。

  Key points

  • Same cases, two arms differing in one variable, judged per assertion, compared by pass rate.
  • The comparison needs a context-clean subagent, never the session you debugged in.
  • The two subagent definitions differ only in preloaded skills; model, tools and prompt are identical.
  • Include negative cases: they measure an over-wide trigger surface, the most common failure.
  • Assertions must be decidable and single-purpose; mark human-judged cases honestly in the conclusion.
• 让子代理带着 skill 去执行任务，和在主会话里执行有什么区别？What is the difference between running a task in a subagent with skills and running it in the main session?

  国内高频海外高频深入#agent-skills#subagent#evaluation

  分析过程 · 先想清楚再作答

  1. 这题考的是上下文隔离的价值，答得浅会变成「子代理就是开个新会话」。要说清它带来的三件事，以及每一件对应什么问题。
  2. 第一件是**上下文干净**。子代理不继承主会话的对话历史，你说过什么、纠正过什么它一概不知道。这一条在做评估时是决定性的：在调试了两小时的会话里试 skill，模型产出得好往往是因为你自己在会话里把答案说了一遍，这是评估 skill 时最常见的自欺。
  3. 第二件是**能力可以精确限定**。子代理定义里能声明可用工具、模型，也能直接声明预加载哪几个 skill。做对照时两份定义只差这一行，其它完全一致——任何第二个差异都会让结论说不清是谁的功劳。
  4. 第三件是**噪音不进主会话**。翻文件、试错、跑脚本这些过程留在子代理自己的上下文里，只把结论交回来。主会话的窗口因此能留给真正要连贯推进的那条线。
  5. 还要说清代价，只说好处会显得没做过。子代理拿不到主会话的上下文，意味着**交接摘要要写清楚**，任务描述含糊时它比主会话更容易跑偏；而且它多跑一遍系统提示与技能目录，不是免费的。
  6. 补一个实现细节能显出实感：skill 进子代理有两条路，一是在定义里预加载、启动时就注入完整正文，二是让它在执行中自己发现并激活。做对照实验用预加载，因为它把变量固定住了；做真实任务用自动发现，更接近日常。
  7. 可预期的追问是「什么时候不该用子代理」。答案是任务需要跟用户来回确认、或强依赖前面几十轮的上下文时——隔离带来的干净，这时候正好是缺陷。

  How to reason about it · think before answering

  1. This tests the value of context isolation. A shallow answer reduces it to opening a new session. Name three effects and the problem each solves.
  2. First, a clean context. A subagent does not inherit the main conversation, so it knows nothing you said or corrected. This is decisive for evaluation: testing a skill in a session you debugged for two hours usually measures your own hints, the most common self-deception here.
  3. Second, precisely bounded capability. A subagent definition can declare its tools, its model, and which skills to preload. For a controlled comparison the two definitions differ only in that line, because any second difference makes the result unattributable.
  4. Third, noise stays out. File reading, trial and error and script runs live in the subagent's own context, and only the conclusion comes back, leaving the main window for the thread that must stay coherent.
  5. Name the costs too. Without the main context, the handoff prompt must be explicit, and a vague task description sends a subagent off course faster than the main session. It also pays for its own system prompt and skill catalog.
  6. An implementation detail shows real experience: skills reach a subagent either by preloading in the definition, which injects the full body at startup, or by letting it discover and activate them during execution. Use preloading for controlled comparisons and discovery for real work.
  7. Expected follow-up: when should you not use one? When the task needs back-and-forth with the user or depends heavily on dozens of earlier turns. There, isolation is the defect rather than the feature.

  答题要点

  • 子代理有独立上下文窗口，不继承主会话历史，这是做干净对照的前提。
  • 定义里能限定工具、模型与预加载的 skill，对照时两份定义只差那一行。
  • 过程噪音留在子代理里，只把结论交回主会话。
  • 代价是交接摘要必须写清楚，任务含糊时更容易跑偏，且多付一次系统提示的开销。
  • 预加载适合做对照实验，自动发现更接近真实使用；需要与用户反复确认的任务不适合隔离。

  Key points

  • A subagent has its own context window and no inherited history, which is what makes a clean comparison possible.
  • Its definition bounds tools, model and preloaded skills, so a controlled pair differs in one line.
  • Process noise stays inside the subagent; only the conclusion returns.
  • The costs are an explicit handoff prompt, more drift on vague tasks, and paying for another system prompt.
  • Preload for controlled experiments, discovery for real work, and skip isolation when the task needs user back-and-forth.

14 天 RAG：从检索到可信回答

D4 切块策略：固定、递归、按结构、父子与语义五种切法，以及用评估而不是直觉来选

• 语义切分比递归切分贵不少，你怎么向团队证明这笔钱值得花？Semantic chunking costs considerably more than recursive splitting. How would you prove to your team that the money is well spent?

  国内高频海外高频深入#chunking#evaluation#cost

  分析过程 · 先想清楚再作答

  1. 这题表面问技术，实际考的是你会不会做一次带对照组的技术论证。上来就讲语义切分原理的人，答的是另一道题。
  2. 第一步是先承认它可能不值。语义切分的收益来自「文档没有可用的结构」；如果知识库是结构良好的文档，作者的标题层级已经免费替你做完了语义切分，这时候花的钱大概率打水漂。**先说清适用前提，再谈证明，这一步就把大多数候选人区分开了。**
  3. 第二步是把「值不值」翻译成可测的三笔账：指标涨了多少（同一批标准问题、同一个 token 预算下的命中率）、延迟涨了多少（切块是离线的，但更新链路的端到端时间会变）、钱涨了多少（首次全量 embedding 的费用，加上按更新频率折算的重算费用）。只报第一笔的论证不成立。
  4. 第三步是设计对照。递归切分是基线，语义切分是实验组，两组必须用同一份语料、同一批问题、同一个上下文预算、同一个检索器，只改切法这一个变量。改两个变量的实验，结论一文不值。
  5. 第四步是给决策一个门槛，而不是给一个感想。比如：命中率相对基线提升低于三个百分点就不上；提升超过五个百分点且重算成本在月度预算内就上；中间地带先在一类文档上灰度。**门槛要在跑数字之前定好**，否则你会不自觉地去迁就已经跑出来的结果。
  6. 可预期的追问是「有没有更便宜的办法拿到同样的收益」。答有：先试按结构切，它零成本且效果常常接近；结构确实不可用时，再考虑只对高价值的那一部分文档做语义切分，而不是全量上。

  How to reason about it · think before answering

  1. This looks like a technical question but it tests whether you can run a controlled technical argument. Launching into how semantic chunking works answers a different question.
  2. Step one is to concede that it may well not be worth it. The gain comes from documents that have no usable structure; if your knowledge base is well-formed documents, the authors' heading hierarchy already did the semantic split for free and the money is likely wasted.
  3. Step two is translating 'worth it' into three measurable numbers: how much the metric moved (hit rate on the same golden set under the same token budget), how much latency moved (chunking is offline, but the end-to-end update path changes), and how much it costs (the initial full embedding pass plus recomputation amortised over update frequency).
  4. Step three is the control. Recursive splitting is the baseline, semantic chunking the treatment, and they must share the corpus, the questions, the context budget and the retriever. Change one variable only; a two-variable experiment proves nothing.
  5. Step four is a decision threshold rather than an impression. For example: below three points of hit-rate gain, no; above five points with recomputation inside the monthly budget, yes; in between, roll it out on one document class first. Fix the threshold before you run the numbers, or you will quietly bend it to fit them.
  6. Expect the follow-up: is there a cheaper way to the same gain. Yes — try structural splitting first, since it is free and often nearly as good, and if the structure really is unusable, apply semantic chunking only to the high-value subset rather than the whole corpus.

  答题要点

  • 先讲适用前提：语义切分的收益来自文档没有可用结构，结构良好的文档上它大概率不值。
  • 把「值不值」翻译成三笔账：命中率涨多少、延迟涨多少、钱涨多少，只报第一笔不算论证。
  • 做对照实验：同语料、同问题集、同上下文预算、同检索器，只改切法一个变量。
  • 决策门槛必须在跑数字之前定好，避免事后迁就结果。
  • 先试零成本的按结构切；确需语义切分时也优先只覆盖高价值文档，而不是全量上。

  Key points

  • Start with the precondition: the gain comes from documents without usable structure, so on well-formed documents it usually is not worth it.
  • Translate 'worth it' into three numbers — hit rate, latency, and cost. Reporting only the first is not an argument.
  • Run a controlled comparison: same corpus, same golden set, same context budget, same retriever, with the splitting strategy as the only variable.
  • Fix the decision threshold before running the numbers so you cannot bend it to fit the result afterwards.
  • Try free structural splitting first, and if semantic chunking is genuinely needed, apply it to the high-value subset rather than the entire corpus.

D6 生成这一侧：上下文怎么排、引用怎么标、什么时候必须拒答，以及流式回答

• 知识库问答的拒答阈值怎么定？定高了和定低了各自的代价是什么？How do you set the refusal threshold for a knowledge-base assistant, and what does it cost you when the threshold is too high or too low?

  国内高频海外高频深入#refusal#thresholds#evaluation

  分析过程 · 先想清楚再作答

  1. 这题真正在考的是：你有没有意识到拒答不是一个阈值，而是好几条判据；以及你定阈值靠不靠数据。只谈一个分数阈值的回答，说明只做过最浅的一层。
  2. 先把拒答拆成三条线，它们的触发时机完全不同。检索分数太低：生成之前就能判，省一次模型调用。材料互相矛盾：也在生成之前判，代码在块之间找同一件事的不同数字，检出后要么并列两种说法与各自的更新日期，要么在有权威信号（比如一份点破了这条不一致的会议纪要）时按更新日期择一——选哪条是产品决策，但无论如何不能让模型自己悄悄挑一个。问题超出材料覆盖范围：只能在生成之后判，判据是跑完引用校验一条有效引用都没有。
  3. 强调三种话术必须不同。第一种要说「库里没有相关材料，换个说法或确认资料是否入库」，第三种要说「找到了相关文档但里面没有能直接回答的内容」——用户的下一步动作完全不同，混成一句「抱歉我不知道」等于把信息扔了。
  4. 再答代价这一半。定高了：能答的问题被挡在门外，用户看到查不到而材料其实在库里，这是最伤信任的一种错，而且它在日志里几乎不可见。定低了：低分噪声材料进上下文，模型拿着不相关的东西硬答，错误反而更隐蔽，因为回答看起来还带着引用。
  5. 怎么定：拿一批已知有答案和已知没答案的问题跑一遍，看两组的分数分布在哪里分开，按你更怕哪种错来取点。分数是没有绝对量纲的，换语料、换检索方式都要重定，所以真正要交付的是这套定阈值的流程，不是那个数字。
  6. 可预期的追问：单一分数阈值不够怎么办？答案是加判据而不是调数字——最高分与次高分的差、命中块数、以及生成后的引用校验结果，都是比原始分数更稳的信号。

  How to reason about it · think before answering

  1. What is really being tested: do you know that refusal is several rules rather than one threshold, and do you set thresholds from data. An answer that mentions only a score cutoff shows you have only touched the surface.
  2. Break refusal into three rules with different timing. Score too low: decidable before generation, saving a model call. Sources conflict: also decidable before generation, by finding differing numbers about the same thing across blocks. You then either present both with their update dates, or pick the newer one when an authoritative signal backs it, such as meeting notes that flagged the discrepancy. Which of the two is a product decision, but silently letting the model pick is never an option. Question outside coverage: only decidable after generation, when citation verification leaves you with zero verified citations.
  3. Stress that the three responses must read differently. 'Nothing relevant in the knowledge base, try rephrasing or check whether the document was ingested' is a different instruction to the user than 'we found related documents but none of them answers this'. Collapsing both into 'sorry, I don't know' throws away information.
  4. Then the cost half. Too high: answerable questions get blocked, the user is told nothing was found while the material is in fact indexed. That is the most trust-damaging failure and it is nearly invisible in logs. Too low: weak passages enter the context and the model answers from irrelevant material, which is worse because the answer still looks cited.
  5. How to set it: run a set of questions with known answers and known non-answers, look at where the two score distributions separate, and pick a point according to which error you fear more. Scores have no absolute scale, so the deliverable is the procedure, not the number.
  6. Expected follow-up: what if one score threshold is not enough? Add signals rather than tuning the number: the gap between top and second score, the number of hits above threshold, and the post-generation verification result are all steadier than the raw score.

  答题要点

  • 拒答不是一条线而是三条：分数过低、材料冲突（都在生成前判）、超出材料覆盖范围（只能生成后按引用校验结果判）。
  • 冲突检出后并列两说还是按更新日期择一，是产品决策；只有在有权威信号背书时择一才站得住，否则老实并列。
  • 三种情况的话术必须不同，因为它们给用户的下一步动作不同。
  • 定高了会把能答的问题挡住，用户看到查不到而材料其实在库里，最伤信任且日志里看不见。
  • 定低了会让噪声材料进上下文，错误更隐蔽，因为回答看起来仍然带着引用。
  • 定法是拿已知有答案与已知没答案的两组问题跑分数分布，按更怕哪种错取点；换语料或换检索方式都要重定。

  Key points

  • Refusal is three rules, not one: low score and source conflict decided before generation, out-of-coverage decided after generation from the verification result.
  • On conflict, presenting both versions versus picking the newer one is a product decision; picking only holds up when an authoritative signal backs it.
  • The three responses must be worded differently because each implies a different next action for the user.
  • Too high blocks answerable questions; the user is told nothing exists while it does, which is the most damaging and least visible failure.
  • Too low lets weak passages in, producing errors that are harder to spot because the answer still carries citations.
  • Set it by comparing score distributions over answerable and unanswerable question sets, then choose based on which error is worse; re-tune whenever the corpus or retriever changes.

D7 第一周综合：把六天的零件装成一个可一键启动的检索问答服务并复盘

• 你刚拼出来的这个检索问答系统，现在最大的风险在哪里？你打算怎么证明这个判断？What is the biggest risk in the RAG service you just assembled, and how would you prove that judgment?

  国内高频海外高频深入#evaluation#risk-assessment#retrospective

  分析过程 · 先想清楚再作答

  1. 这题有两半，后半句才是题眼。说出一个风险不难，难的是给出一个能证伪你自己判断的方法——答不出后半句，前半句就只是意见。
  2. 先排除两个常见的错误答案：说「幻觉」太笼统，没有指向任何可动的地方；说「延迟」则是把看得见的问题当成最大风险。
  3. 真正的最大风险是**没有评估**：切块大小、取几条、门槛定多少、两路怎么加权，全是拍出来的。它最重要的地方在于它让所有其他风险都无法验收——你连「改了之后变好还是变坏」都说不出口。
  4. 怎么证明：先从语料反向出一份带标准答案文档的问题集，刻意掺进无答案问题和需要跨文档的多跳问题；再实现召回率与排序指标，给当前配置跑出一个基线；然后把一个参数来回改两次，看指标动不动。如果指标对参数完全不敏感，说明是评估集有问题，不是系统没问题。
  5. 补一句成本口径：每一项优化都要同时报三笔账——指标涨了多少、延迟涨了多少、钱涨了多少。只报第一笔的结论不能用。
  6. 可预期的追问：评估集多大才够？先做二十题能覆盖主要问题类型的小集，用它挡住明显的退步；等真实用户问题攒起来，再按真实分布扩到几百题。一上来就追求规模，只会得到一堆自己出的、跟真实用法无关的题。

  How to reason about it · think before answering

  1. There are two halves here and the second is the real question. Naming a risk is easy; giving a method that could falsify your own claim is what separates answers from opinions.
  2. Rule out two common wrong answers: 'hallucination' is too vague to act on, and 'latency' mistakes a visible problem for the biggest one.
  3. The biggest risk is the absence of evaluation. Chunk size, top-k, thresholds and route weights were all guessed, and that makes every other risk unverifiable: you cannot even say whether a change helped.
  4. How to prove it: build a question set from the corpus with known answer documents, deliberately including unanswerable and multi-hop questions; implement recall and ranking metrics; produce a baseline for the current configuration; then move one parameter back and forth and watch whether the metrics move. If they do not move at all, the evaluation set is wrong, not the system.
  5. Add the accounting rule: every optimisation reports three numbers, metric gain, latency added and cost added. A claim with only the first is not usable.
  6. Expected follow-up: how large must the set be? Start with roughly twenty questions covering the main question types to catch obvious regressions, then grow toward the real distribution once you have actual user questions. Chasing size first only yields questions you invented yourself.

  答题要点

  • 最大的风险是没有评估：所有参数都是拍的，导致任何改动的好坏都无法判断。
  • 证明方式是先建标准答案集，刻意包含无答案问题与多跳问题，再跑出当前配置的基线。
  • 用参数扰动反过来验证评估集本身：指标对参数完全不敏感，说明题出得有问题。
  • 每项优化同时报三笔账：指标、延迟、成本；只报指标的结论不能用。
  • 评估集先小而全，覆盖问题类型即可，等真实问题攒起来再按真实分布扩大。

  Key points

  • The biggest risk is having no evaluation: every parameter was guessed, so no change can be judged.
  • Prove it by building a golden set with known answer documents, including unanswerable and multi-hop questions, then baseline the current configuration.
  • Validate the set itself by perturbing parameters: metrics that never move mean the questions are wrong.
  • Report three numbers per optimisation: metric gain, added latency, added cost.
  • Start small but well covered, then grow toward the real question distribution.

D8 评估先行：搭 golden set、算召回与排序指标、用模型当裁判判忠实度

• 用模型当裁判来评 RAG 的忠实度，有哪些系统性偏差？你怎么发现它们、又怎么证明你的裁判可信？What systematic biases does an LLM judge have when scoring RAG faithfulness, and how do you detect them and prove your judge is trustworthy?

  国内高频海外高频深入#llm-as-judge#evaluation#faithfulness

  分析过程 · 先想清楚再作答

  1. 这题的题眼在后半句。能背出「位置偏好、长度偏好、自我偏好」三个名词的人很多，能说出「怎么证明可信」的很少——面试官要的是后者。
  2. 先把三个偏差和各自的缓解手段一一对应：位置偏好用逐条独立打分代替两两比较，非要比较就交换顺序跑两遍、结论不一致判平局；长度偏好用逐句判定加比例计分，写得越长分母越大，长度红利自动消失；自我偏好用跨供应商或跨档位的模型评判，生成和评判不同源。
  3. 再补两条提示词层面的：给死评分锚点，1.0 / 0.6 / 0.3 各自是什么必须写明，否则同一份输入不同天给的分都不一样；强制结构化输出并要求把没支撑的句子原样列出，这是人工复核的抓手。
  4. 证明可信只有一条路：人工抽检算一致率。分层抽十到三十条——各类型都要有、命中和没命中都要有、裁判给高分和低分都要有，只判一个二元问题（有没有材料外的内容），跟裁判的结论比对。低于 0.8 就不能拿它的分数做拦合并这类决策。
  5. 一个能加分的细节：一致率很高不一定是好消息。如果抽的十条都是「答案原样抄自材料」的简单题，判对是理所当然的，这时候 100% 说明的是抽检没难度，不是裁判可靠。
  6. 可预期的追问是「裁判本身会不会坏」。答案是给裁判写探针：喂几组已知正确答案的输入（照抄材料的、明显编造的），每次跑评估都验一遍——评估系统坏掉的方式最阴险，分数照常输出，只是不再有意义。

  How to reason about it · think before answering

  1. The second half of the question is the discriminator. Plenty of people can name position, length, and self-preference bias; few can say how they prove the judge is trustworthy.
  2. Pair each bias with its mitigation: position bias - score pointwise instead of pairwise, and if you must compare, swap the order and call disagreement a tie; length bias - decompose into claims and score a ratio, so a longer answer grows its own denominator; self-preference - judge with a different vendor or tier than the generator.
  3. Add two prompt-level requirements: fixed rubric anchors (spell out what 1.0, 0.6 and 0.3 mean, or the same input scores differently on different days) and forced structured output that quotes the unsupported sentences verbatim, which is what makes human review possible.
  4. Proving trust has exactly one route: human spot-checks and an agreement rate. Stratify ten to thirty items across types, hits and misses, high and low judge scores; answer one binary question only - is anything here not in the material - and compare. Below 0.8 the judge's scores cannot gate a merge.
  5. A detail that scores points: a very high agreement rate may mean your spot-check was too easy. If all ten sampled answers copy the material verbatim, agreeing is trivial and 100% says nothing about the judge.
  6. Expected follow-up: can the judge itself break? Add probes - fixed inputs with known verdicts, one faithful and one obviously fabricated, checked on every run. An evaluation system fails silently: the numbers keep coming, they just stop meaning anything.

  答题要点

  • 三个偏差：位置偏好、偏爱长答案、自己评自己，各自有对应的缓解手段。
  • 逐条独立打分代替两两比较；逐句判定按比例计分抵消长度红利；生成与评判不同源。
  • 提示词要给死评分锚点，并强制结构化输出、列出没支撑的句子。
  • 可信度靠人工分层抽检算一致率，低于 0.8 不能用它做拦合并的决策。
  • 给裁判本身写探针，每次跑评估都验一遍它有没有坏。

  Key points

  • Three biases: position, verbosity, and self-preference, each with a matching mitigation.
  • Score pointwise rather than pairwise; decompose into claims and score a ratio to kill the length premium; never let the generator judge itself.
  • Pin rubric anchors in the prompt and force structured output that quotes unsupported sentences.
  • Establish trust through stratified human spot-checks and an agreement rate; below 0.8 the judge cannot gate merges.
  • Add probes with known verdicts so a broken judge is caught on every run.

D9 混合检索与重排：两路召回、倒数排名融合，再用交叉编码器把前几名重新排一遍

• 你把纯向量检索换成了混合检索加重排，上线之后评估指标反而掉了。你会怎么排查？You replaced pure vector retrieval with hybrid search plus reranking, and after shipping it your eval metrics went down. How do you investigate?

  国内高频海外高频深入#hybrid-search#evaluation

  分析过程 · 先想清楚再作答

  1. 这题考的是你有没有真的做过分阶段归因。答「调一下权重再看看」就输了——那是在猜，不是在查。
  2. 第一步是拆档跑，不是改代码：纯关键词、纯向量、混合、混合加重排四档在**同一份评估集、同一个上下文预算**下各跑一遍。指标掉在哪一档就在哪一档找原因，这一步能立刻区分「融合坏了」和「重排坏了」。
  3. 第二步问一个具体问题：掉的是召回率还是排序指标？召回率掉说明答案根本没进上下文，是候选池或者预算的问题；排序指标掉而召回率没动，说明答案还在、只是被挤到了后面，那是融合权重或重排模型的问题。这两类故障的解法完全不同。
  4. 第三个常见根因是召回深度。每路取多少条这个旋钮方向反直觉：取深了不是更保险，是把噪声也一起投了票。我在一份 134 块的语料上实测过，每路从取 50 收到取 5，混合那一档的召回率从 87.5% 回到 93.8%、多跳档从 50% 回到 75%，而 nDCG 反而掉了近 0.1——两个指标会打架，先想清楚业务要哪个。
  5. 第四个根因是评估口径被悄悄改了。上下文预算、命中判定、候选池深度只要动过一个，新旧数字就不可比，这时候「掉了」可能根本不是真的掉了。
  6. 可预期的追问：怎么防止下次再踩？答把四档对照做成一条命令、把上一版报告存成基线、指标退步就以非 0 退出码拦住合并——这就是评估要先于优化的原因。

  How to reason about it · think before answering

  1. This question tests whether you have actually done stage-by-stage attribution. Answering `I would tune the weights and see` loses — that is guessing, not investigating.
  2. Step one is to run the stages apart, not to change code: pure keyword, pure vector, hybrid, and hybrid plus rerank, all on the **same eval set with the same context budget**. Whichever stage the drop appears in is where you look, and this alone separates `fusion is broken` from `reranking is broken`.
  3. Step two asks a specific question: did recall drop, or did the ranking metrics drop? A recall drop means the answer never entered the context at all — a candidate-pool or budget problem. Ranking metrics dropping while recall holds means the answer is still there but pushed down — a fusion-weight or rerank-model problem. The two failures have completely different fixes.
  4. A third common root cause is recall depth. This knob runs against intuition: going deeper is not safer, it lets noise vote too. On a 134-chunk corpus I measured that narrowing each route from 50 to 5 took hybrid recall from 87.5% back to 93.8% and multi-hop from 50% to 75%, while nDCG fell by almost 0.1. The metrics fight each other, so decide which one the product needs first.
  5. A fourth root cause is that the eval protocol quietly changed. Touch the context budget, the hit rule, or the candidate depth, and the old and new numbers stop being comparable — in which case the `drop` may not be a drop at all.
  6. Expected follow-up: how do you avoid this next time? Make the four-way comparison a single command, store the previous report as a baseline, and fail the build with a non-zero exit code on regression. That is precisely why evaluation comes before optimization.

  答题要点

  • 先拆档跑四种配置，在同一份评估集和同一个上下文预算下归因，不要一上来就调参。
  • 区分召回率掉与排序指标掉：前者是候选池或预算问题，后者是融合或重排问题。
  • 查召回深度：每路取太深会把噪声也投进融合，收窄反而可能救回召回率。
  • 确认评估口径没被改：预算、命中判定、候选池深度动过一个，新旧数字就不可比。
  • 把四档对照固化成一条命令加一份基线报告，指标退步直接拦住合并。

  Key points

  • Run all four configurations separately for attribution, on one eval set with one context budget, before touching any parameter.
  • Separate a recall drop from a ranking drop: the first is a candidate-pool or budget issue, the second is a fusion or rerank issue.
  • Check recall depth: taking too many per route lets noise vote, and narrowing it can bring recall back.
  • Confirm the eval protocol did not change; touching budget, hit rule, or candidate depth makes old and new numbers incomparable.
  • Freeze the four-way comparison into one command plus a baseline report, and block merges on regression.