错误检测与验证 - 面试题

#

★★★

1. LLM-as-Judge 作为 Agent 输出校验器时存在哪些偏差、成本与校准问题，如何防止校验器与执行器同源偏好

问题

LLM-as-Judge 作为 Agent 输出的校验器时，存在哪些偏差（bias）、成本与校准问题？如何防止校验器与执行器（生成模型）同源带来的偏好？

考察点

LLM-as-Judge 的偏差类型：位置偏差、长度偏差、自我偏好、谄媚偏差
成本问题：每轮校验的额外调用
校准问题：评判置信度不可靠

答案

LLM-as-Judge 常见偏差包括：①位置偏差——更偏好出现在前面的答案；②长度偏差——答案越长越容易得分；③自我偏好（self-preference）——同源模型对自己生成的文本打分偏高；④谄媚/风格偏差——偏好听起来更自信或更符合人设的答案；⑤格式偏差。成本问题是每次校验都多一次 LLM 调用，叠加在已有成本上，需控制评判频率与模型大小。校准问题是 Judge 的置信度与实际正确率偏差大，不能直接用其分数当概率。防止同源偏好的关键：让执行器与校验器用不同模型/不同 prompt，避免"自己评自己"；采用盲评（隐藏答案来源）、随机化候选顺序、多次评分取平均、明确 rubrics 评分标准来稳定判断。必要时用确定性校验或人工抽检兜底。

解析

LLM-as-Judge 灵活但不可靠，其偏差源于"模型的主观性"。工程上通过"去同源、盲评、rubrics、多次采样"来缓解，并把 Judge 只用于"语义层"判断，规则与工具校验放在前面，既省成本又更可靠。

#

★★★

2. Agent 输出如何用形式化校验（schema/类型/单测）拦截低级错误

问题

Agent 输出如何通过形式化校验（如 JSON Schema、类型检查、单元测试）来拦截低级错误？

考察点

形式化校验的类型：schema、类型、枚举、单测
在管线中的位置：输出即校验
校验失败的处理：重试、告警、约束生成

答案

形式化校验是拦截低级错误最可靠的手段。可以在 Agent 输出处做：①JSON Schema 校验——验证输出结构、必填字段、类型、枚举、值域；②类型校验——参数类型、数值范围、日期格式；③枚举/白名单校验——只允许合法值；④单元测试——对生成代码跑测试，对生成数据跑断言。实现上这些校验是确定性的、可重复的、零 LLM 成本，通常在产出输出后立即执行。失败时可按错误类型处理：结构错误可让模型带 Schema 报错重试，参数错误自动修正，测试失败则触发回修。为减少失败，可结合"约束生成"（如 function calling/structured output）让模型"更容易产生合法输出"。形式化校验的局限是只能拦截"形式/语法"错误，无法保证"语义正确"，因此需与语义审查、事实核对配合。

解析

形式化校验的成本低、可靠、可解释，是"防错"的第一道也是最可靠的门。它把"模型输出"从"可能任意"约束到"合法结构"，是 Agent 工程可靠性的基石，但必须理解它管不了语义。

示例代码

import * as z from "zod";
const ToolCallSchema = z.object({
  tool: z.enum(["search", "summarize", "pay"]),
  params: z.object({
    query: z.string().min(1).max(200),
    amount: z.number().positive().max(100000),
  }),
});
function validate(raw: unknown): ToolCall | Error {
  const r = ToolCallSchema.safeParse(raw);
  if (!r.success) return new Error(`schema violation: ${r.error.message}`);
  return r.data;
}

#

★★★

3. Plan-and-Execute 模式中计划与执行偏差如何实时监控

问题

在 Plan-and-Execute 模式中，计划与执行之间的偏差应如何实时监控和处置？

考察点

Plan-and-Execute 的两阶段结构
偏差的类型：计划外行为、执行结果与预期不符、步骤遗漏
实时监控手段：每一步校验、里程碑比对

答案

Plan-and-Execute 先由规划器产出分步计划，再逐步执行。偏差监控的关键是"在执行过程中持续比对执行结果与计划预期"。监控手段包括：①每步执行后把 Observation 与计划中该步的预期目标比对，判断是否达成；②在关键里程碑做计划级的校验（如"是否偏离了最终目标"）；③记录执行轨迹，监控是否有计划外动作、是否执行了错误步骤；④用校验器/规则对中间结果做质量检查。一旦发现偏差，按严重程度处置：小偏差局部修正当前步骤；结构偏差（计划顺序错、目标漂移）触发重规划（re-plan）；无法修复则回退到最近检查点并升级。偏差监控的实时性依赖"执行→校验→决策"的循环要以步为单位高频进行，而非等全部执行完才检查。

解析

Plan-and-Execute 的偏差监控本质是"计划是预期，执行是实际，每一步都比对两者"。把"校验"嵌入执行循环，早发现、早处置，避免偏差累积到末端爆发，这是 Agent 可靠性的关键。

#

★★

4. 工具调用失败（超时/异常/格式错）如何分类并差异化处理

问题

工具调用失败（超时、异常、格式错误等）应如何分类，并对不同类别的失败做差异化处理？

考察点

失败分类：超时、异常、格式错误、业务拒绝、权限
可重试性判断：瞬时 vs 永久
差异化处理：重试、退避、纠正、换工具、升级

答案

工具调用失败应先分类再处理，避免"一刀切"重试。常见类别：①超时（timeout）——瞬时类，可带指数退避重试；②异常（异常崩溃/连接失败）——不一定持久，可重试；③格式错误（参数非法、schema 不符）——确定性错误，重试无用，应纠正参数或让模型重新生成；④业务拒绝（权限不足、业务规则拒绝、401/403）——不可重试，直接升级或换工具；⑤数据问题（返回空/无结果）——可换查询或换工具。落地时给工具返回结构化错误（error.type + error.recoverable + error.message），Agent 据此决策：recoverable 的带退避重试，格式类自动纠正，不可恢复的升级给人类。还要设置总重试上限，避免无限重试。

解析

失败的差异化处理建立在"错误分类"之上。把"是否可重试、重试能否成功"这些信息编码进错误本身，Agent 才能做出正确的重试/纠正/升级决策，而不是盲目重试。

示例代码

def handle_error(err, params):
    if err.type == "TIMEOUT" and params.retries < 3:
        return RETRY, backoff(params.retries)   # 瞬时，退避重试
    if err.type == "BAD_PARAMS":
        return RETRY_WITH_FIX, fix_params(params, err)  # 纠正参数
    if err.type in ("FORBIDDEN", "INVALID_SCHEMA"):
        return ESCALATE, None                    # 确定性，升级
    if err.type == "EMPTY_RESULT":
        return RETRY_WITH_ALT, alt_tool(params)  # 换工具
    return RETRY, 0

#

★★

5. 幻觉在 Agent 长链路中如何被早期信号捕获而非末端爆发

问题

幻觉在 Agent 长链路中应如何被早期信号捕获，而不是在链路末端才爆发问题？

考察点

长链路中幻觉累积放大的风险
早期信号：中间结果置信度、自洽性、证据缺失
逐环节检测 vs 末端汇总

答案

长链路中一个环节的幻觉会被后续步骤放大，等到末端才爆发代价巨大。早期捕获的策略是在每个关键环节生成后立即做轻量检测：①置信度检测——模型对中间输出的置信度低时标记；②自洽性检查——同一信息多次生成是否一致，矛盾即可疑；③证据锚定——中间结论是否引用/可回溯到检索到的证据，无证据支持的声明标记为幻觉；④格式/约束校验——中间输出是否符合计划预期。检测可按环节分级：高风险环节加事实核对，低风险环节做格式校验。一旦早期信号触发，立即在当环节纠正、重试或回退，避免错误进入下游。关键在于"把检测嵌入链路而非只在末端汇总"。

解析

幻觉的早期捕获本质是"把可靠性检查从末端前移到每环节"。通过逐环节的置信度、自洽性、证据锚定检查，把错误隔离在源头，避免累积放大，比末端一次性返工便宜得多。

#

★★

6. Agent 轨迹（trace）回放如何用于版本升级回归评测，不可回放节点（副作用工具、时效数据）如何处理

问题

Agent 轨迹（trace）回放如何用于版本升级的回归评测？对于不可回放节点（副作用工具、时效数据）应如何处理？

考察点

轨迹回放的原理：记录输入输出，重放比对
用真实轨迹做回归测试
不可回放节点的处理：Mock、幂等、跳过、记录后重放

答案

Agent 轨迹回放是把真实执行记录（输入、工具调用、输出、中间状态）保存下来，在版本升级后重放这些轨迹，比对新旧版本行为是否一致，用于回归评测。可回放节点直接重放比对。对不可回放节点要特殊处理：①副作用工具（发邮件、扣款、写库）——用 Mock 或 Dry-run 模式，记录真实行为但执行时隔离，避免重复副作用；②时效数据（当前时间、实时价格、动态库存）——冻结快照或屏蔽，重放时用记录时的固定值，保证可复现；③随机性（采样温度）——固定 seed 或记录输出直接比对。处理原则是"保证可复现性"：把确定性输入固定、把副作用隔离、把时效数据锁定，使轨迹能稳定重放。回归评测关注的是"在新版本下，是否还产生符合预期（或更好）的结果、是否引入回归"。

解析

轨迹回放是 Agent 回归测试的基石。它把"真实执行"变成"可复现代理"，但前提是处理好不可重放性。通过 Mock 副作用、冻结时效数据、固定随机性，才能得到可信的回归结果。

#

★★

7. Agent 生成代码后自动运行测试并据失败信息回修的闭环设计

问题

Agent 生成代码后自动运行测试、并根据失败信息回修的闭环应如何设计？

考察点

闭环结构：生成→测试→分析失败→回修→再测试
失败信息解析（测试输出、断言、堆栈）
回修策略与收敛

答案

闭环设计为"生成代码→运行测试→解析失败→回修→再测试"，直到测试通过或达到上限。关键点：①测试运行要隔离、可复现（沙箱、固定依赖）；②失败信息要结构化——把失败用例、断言差异、堆栈、错误类型传给模型，让它"看到具体失败"而非模糊的"测试未通过"；③回修策略应"最小修改+带回归意识"，避免破坏已通过的用例（可跑全量回归或只跑相关用例）；④收敛控制——设最大回修轮数，测试通过数不再上升时停止并保留历史最好版本；⑤日志与审计——记录每轮修改与测试结果，便于复盘。为提高效率，可优先运行失败相关的用例、并行运行、做增量测试。

解析

这个闭环是"代码生成自我纠正"的落地实现。核心是"把测试失败变成可消费的反馈"，并配合收敛与回退，让回修有方向、可度量、不失控。测试是客观评分器，比模型自评可靠。

示例代码

def code_fix_loop(prompt, tests, max_rounds=5):
    code = llm_generate(prompt)
    best = (code, 0)
    for r in range(max_rounds):
        results = run_tests(code, tests)
        if results.passed == len(tests):
            return code
        if results.passed > best[1]:
            best = (code, results.passed)
        failures = summarize_failures(results)   # 结构化失败信息
        code = llm_fix(code, failures)
    return best[0]  # 返回历史最优

#

★★

8. Agent 输出的结构化校验，JSON Schema 验证、工具参数校验与可重试的错误分类如何设计？

问题

Agent 输出的结构化校验应如何设计？包括 JSON Schema 验证、工具参数校验与可重试的错误分类？

考察点

输出结构校验（JSON Schema）
工具参数校验（类型/值域/必填）
错误分类（可重试 vs 不可重试）

答案

结构化校验应分"结构、参数、可重试性"三层设计。①JSON Schema 验证：校验 Agent 输出的整体结构——必填字段、类型、嵌套、枚举、值域，确保输出"形状合法"；②工具参数校验：把要传给工具的参数做类型/范围/必填/格式校验，防止非法参数进入工具；③错误分类：把校验失败分成可重试与不可重试——可重试（如参数可由模型修正、瞬时错误）带重试策略；不可重试（如 schema 永久不匹配、业务拒绝）直接升级。设计中 Schema 与工具参数 schema 应复用同一份定义，减少两面刀。校验失败时返回结构化错误信息给模型，让它知道"哪里错了、怎么改"，提高重试成功率；同时设置重试上限，防止循环。

解析

结构化校验的设计核心是"校验什么、失败怎么分类、怎么引导重试"。Schema 保证形状、参数校验保证安全、错误分类保证处置正确，三者配合构成 Agent 输出的第一道防线。

#

★★

9. LLM 输出的幻觉检测，事实性核对（引用检索）、自洽性检查与置信度阈值如何组合？

问题

LLM 输出的幻觉检测应如何组合事实性核对（引用检索）、自洽性检查与置信度阈值来提升检测效果？

考察点

事实性核对：把声明与检索到的证据比对
自洽性检查：同一信息多次生成是否矛盾
置信度阈值：低置信标记

答案

幻觉检测是"多信号融合"，单一信号不可靠。组合策略：①事实性核对（grounding check）——把输出中的关键声明抽取出来，与检索到的证据（文档、数据库）比对，判断是否有来源支持，无证据支持的声明标记为幻觉；②自洽性检查——对同一问题多次生成（或对同一声明多次重述），比较是否一致，出现矛盾或自我推翻即可疑；③置信度阈值——模型对输出的置信度或概率低于阈值时标记为低置信，需复核。三者互补：事实性核对最可靠但依赖检索质量，自洽性检查无需外部证据但只能抓"自相矛盾"，置信度阈值找出"模型自己也没把握"的。工程上可分层：先低成本置信度/自洽性粗筛，对可疑声明再做事实性核对，形成"粗筛+精核"的漏斗，兼顾召回与成本。

解析

幻觉检测的核心是"证据、一致性、置信度"三个信号互补。单一信号（尤其置信度）不可靠，组合成"粗筛→精核"漏斗能在成本可控下提高检出率，降低漏放与误报。

#

★★

10. 输出检测的分层，语法（可解析）、语义（字段含义）与事实（证据支持）三层校验应如何组织，每层的失败处理有何不同

问题

输出检测的分层——语法（可解析）、语义（字段含义）、事实（证据支持）三层校验应如何组织？每层的失败处理有何不同？

考察点

三层校验的定义：语法/语义/事实
各层的可靠性与成本差异
分层顺序与逐层通过原则

答案

三层校验按"从确定到不确定"组织：①语法层——校验输出能否解析、结构是否合法（JSON 可解析、格式正确、字段存在），用确定性解析器，成本低、可靠；②语义层——校验字段含义是否正确（值是否合理、是否符合业务逻辑、类型对不对），用规则+模型，判断"内容对不对"；③事实层——校验输出是否被证据支持（引用检索、grounding check），用检索+比对，防幻觉。失败处理不同：语法层失败→让模型重新生成合法结构（结构错误，重试修复）；语义层失败→结合规则修正或模型修正，可能需业务上下文；事实层失败→标记/降级/拒绝，因为缺证据的声明不可信，应标注或要求补充引用。原则是"逐层通过"：语法不过不进入语义、语义不过不进入事实，避免在不可靠的层浪费时间。

解析

分层检测把"可信度"作为排序依据——语法最可靠、事实最不可靠。逐层通过可尽早拦截、控制成本，且各层失败处置不同（语法修、语义纠、事实拒），是 Agent 输出质量把关的完整框架。

#

★★

11. 事实性验证的工程实现，基于检索的证据核对（grounding check）、矛盾检测与不确定声明标记？

问题

事实性验证的工程实现是什么？包括基于检索的证据核对（grounding check）、矛盾检测与不确定声明的标记？

考察点

证据核对（grounding check）的实现
矛盾检测（输出与证据/上下文矛盾）
不确定声明的标记与降级

答案

事实性验证的工程实现核心是"把输出声明与证据对齐"。①证据核对（grounding check）：从输出中抽取可验证的声明（用 NER/LLM 抽取），对每个声明做检索找到支撑证据，再判断声明是否被证据支持（支持/部分支持/不支持/无证据），用相似度或 LLM 判定；②矛盾检测：比对声明与上下文/证据，识别"直接矛盾"（自相矛盾或与证据冲突），矛盾声明高风险；③不确定声明标记：对置信度低、证据不足或含糊的声明打上"不确定性"标签，提示用户或降级其可信度。实现上是"抽取→检索→比对→标记"的管线，可缓存检索结果降成本，用分层（先粗筛再精核）控制开销。结果用于输出标注引用、拦截高风险声明、或触发降级（如加"此声明未经证实"提示）。

解析

grounding check 是把"生成"与"检索"闭环起来的关键。它的难点不在"比对"而在"声明抽取与证据匹配的质量"，以及成本控制。标记、降级、引用是它的工程出口。

#

★★

12. 错误检测的效果度量，检出率、误报率与漏放率的定义与权衡，如何用带标注的 bad case 集评估校验器本身？

问题

错误检测的效果如何度量？检出率、误报率与漏放率如何定义与权衡？如何用带标注的 bad case 集评估校验器本身？

考察点

检出率（召回）、误报率、漏放率定义
三者的权衡（查得严 vs 查错多）
用带标注 bad case 集评估校验器

答案

错误检测的度量借鉴分类指标：检出率（召回率）＝检测出的错误数/实际错误数，衡量"漏不该漏的"；误报率＝被误判为错误但实际正确的比例，衡量"查错太多"；漏放率＝1-检出率，错误未被发现的比率。三者存在权衡：阈值/检测越严，检出率提高但误报率上升，反之亦然。评估校验器本身，需要构建带标注的 bad case 集（golden set）：一组样本，标注每个是否为错误、属于哪类错误，然后运行校验器，统计检出率、误报率、漏放率、以及 F1/精确率。通过在不同阈值下画 ROC/PR 曲线，选择满足业务要求的操作点（如对高风险场景要求高检出率，可接受一定误报）。关键是要基于真实分布的样本集，避免"只测错误样本"导致误报率失真。

解析

校验器本身也是需要评估的"模型"。用带标注样本集量化检出率、误报率、漏放率，才能科学设定阈值与决策，且要依据业务风险权衡——高风险场景偏高检出、低风险场景偏少误报。

#

★★

13. 校验器与业务规则引擎的协作，哪些错误应交给确定性规则（金额、日期、枚举），哪些交给模型校验，规则与模型的边界如何划分？

问题

校验器与业务规则引擎如何协作？哪些错误应交给确定性规则（金额、日期、枚举），哪些交给模型校验？规则与模型的边界如何划分？

考察点

确定性规则适合的校验类型
模型校验适合的类型
边界划分原则（确定性 vs 语义）

答案

边界划分的核心原则是"能确定判断的交给规则，不能确定判断的交给模型"。确定性规则适合：金额范围/非负、日期格式与有效性、枚举白名单、必填字段、数值计算一致性、正则格式——这些可精确判定、可靠且零成本。模型校验适合：语义理解、逻辑一致性、事实性判断、风格与合规措辞、复杂业务意图——无法用规则表达或需要上下文推理。协作模式是"规则先行、模型兜底"：先用确定性规则做快速、可靠的低级拦截，通过后再对规则覆盖不到的语义层用模型校验。这样既保证可靠性和低延迟，又弥补模型的不确定性。同时要避免"把所有规则都交给模型"（不可靠、成本高）或"把所有语义都写成规则"（难维护、不全面）。

解析

规则与模型的分工本质是"确定性 vs 概率性"的边界。规则可靠但僵硬，模型灵活但不可靠。把能确定的交给规则、把模糊的交给模型，并让规则先行短路，是成本、可靠性与能力的最佳平衡。

#

★★

14. 多模型交叉验证的工程代价，用强模型复核弱模型输出（或反之）的成本与收益，什么场景下值得引入第二模型？

问题

多模型交叉验证的工程代价是什么？用强模型复核弱模型输出（或反之）的成本与收益如何，什么场景下值得引入第二模型？

考察点

交叉验证的成本（第二模型调用、延迟）
收益（纠正错误、减少单模型偏差）
强校验弱 vs 弱校验强的场景

答案

多模型交叉验证的代价是额外的推理成本与延迟（第二模型调用），以及系统复杂度。收益是纠正单模型错误、引入独立视角减少同源偏差。方向选择：强模型复核弱模型——能提升弱模型输出质量，但成本高，适合"弱模型执行、强模型把关"且输出价值高的场景；弱模型复核强模型——成本低，但只能抓到明显错误，适合"强模型执行、弱模型做粗筛/格式检查"。值得引入第二模型的标准：①任务价值高（金融、医疗、关键决策），错误代价大；②单模型偏差/幻觉风险高，需要独立验证；③输出需要高可信度；④成本可接受（能容忍额外延迟与费用）。反之，低价值、高实时、成本敏感的场景不值得引入。

解析

多模型交叉验证本质是"用成本换独立性"。是否引入第二模型，取决于"错误代价 vs 验证成本"的权衡。独立模型能降低同源偏差，但只有当错误代价足够大时才划算。

#

★★

15. 流式输出的实时校验，如何在 token 流中尽早检测格式错误与敏感内容，边生成边校验与生成后校验的取舍？

问题

流式输出的实时校验应如何实现？如何在 token 流中尽早检测格式错误与敏感内容？边生成边校验与生成后校验如何取舍？

考察点

流式校验的可行性（部分 token 校验）
早期检测格式错误与敏感内容
边生成边校验 vs 生成后校验

答案

流式校验在 token 逐个/批产出时尽早检测问题，而非等全部生成完。可检测的：①格式错误——如 JSON 流式解析，在括号未闭合、字段类型错误处立即发现；②敏感内容——用规则/轻量分类器对已生成的片段做敏感词、PII、违规内容检测，发现即中断或改写。边生成边校验的优势是"早发现、早止损"，避免浪费 token 和暴露违规内容；代价是校验粒度不完整（部分 token 无法判断完整语义），且每批校验有额外开销，可能降低吞吐。生成后校验的优势是"能看全貌、语义判断准确"，但发现太晚。取舍原则：能实时确定的（格式、敏感词、硬规则）用流式校验；需要完整语义的（逻辑、事实、风格）用生成后校验。混合策略是"流式做粗校验 + 生成后做精校验"。

解析

流式校验的核心是"针对可实时判定的信号"。格式与敏感内容这类可局部判断的，适合及早拦截；语义类需全貌。分段取舍，才能兼顾实时性与准确性。

#

★

16. 校验结果的一致性基线（多次校验一致率）如何建立，防止校验抖动造成误报

问题

校验结果的一致性基线（多次校验的一致率）如何建立？如何防止校验抖动造成误报？

考察点

校验抖动（同一输出多次校验结果不同）的成因
一致性基线：多次校验一致率
降低抖动：多次采样取平均、投票、固定 seed

答案

校验抖动源于模型校验的非确定性（温度采样、模型随机性），同一输出多次校验可能给出不同结果，造成误报或漏报。预防措施：①建立一致性基线——对同一输出做多次校验，统计一致率，若多次结果一致则可信，不一致则进一步处理；②多数投票——多次校验取多数结果决定，减少单次偶然；③固定参数——用较低温度/固定 seed 降低随机性；④缓存与比对——对重复输出复用校验结果，避免重复抖动。对于"校验抖动"造成的误报，可设置"连续多次失败才判定失败"或"多数一致才判定"，并记录每次校验的置信度。基线本身可通过对校验器在标注集上多次运行来标定一致性水平，作为报警阈值。

解析

校验器若本身不稳定，就会制造误报。一致性基线是"校验器的校验"——通过多次一致率、多数投票固定参数，把"随机抖动"的影响降到最低，让校验结果可信。

#

★

17. 错误检测的闭环，失败样本如何回流到评测集与 Prompt 优化，形成持续改进？

问题

错误检测的闭环应如何设计？失败样本如何回流到评测集与 Prompt 优化，从而形成持续改进？

考察点

失败样本的收集与沉淀
回流到评测集（回归测试）
回流到 Prompt 优化（few-shot、错误示例）

答案

错误检测的闭环是"检测→收集失败→回流→改进→再检测"。设计：①失败收集——检测到错误的样本（含输入、输出、失败原因）入库，标注类别；②回流评测集——把失败样本加入回归评测集，保证后续版本不重犯，形成回归护栏；③回流 Prompt——遴选代表性失败样本作为 few-shot 反例、错误示例或约束写入 Prompt，或用于调优检测规则/阈值；④持续改进——定期用累积的失败样本评估系统（正确率、误报率），发现模式后针对性优化（加规则、调阈值、改 Prompt、换模型）。通过"用户反馈+检测失败"双通道不断补充 bad case，形成数据飞轮。关键是失败样本要结构化、可检索、去重，且回流要可验证（确实提升了效果）。

解析

错误检测的闭环本质是"把失败变成资产"。失败样本回流入评测与 Prompt，既防回归又驱动改进，形成持续学习的数据飞轮，是 Agent 质量提升的核心机制。

#

★

18. 验证工具的组合，检索核对、执行测试与人工抽检在验证链路上如何分工，各自的覆盖率与成本如何

问题

验证工具的组合——检索核对、执行测试与人工抽检在验证链路上如何分工？各自的覆盖率与成本如何？

考察点

三种验证方式的能力与成本
分工与链路组织
覆盖率与成本差异

答案

三种验证方式的成本与覆盖不同：①检索核对（grounding check）——覆盖"有证据可查"的事实性声明，成本中等（需检索+比对），覆盖率高但不覆盖无证据/内部逻辑；②执行测试——覆盖"可执行"的输出（代码、函数、数据断言），成本取决于测试规模，覆盖"可客观验证"的部分，最可靠；③人工抽检——覆盖"高价值/高风险/语义复杂"的输出，成本最高但覆盖语义与判断，无法全量。分工上按"能自动就自动、能抽样就抽样"：优先用自动的检索核对与执行测试做全量/低成本覆盖，再对剩余高风险或自动无法判定的部分做人工抽检。覆盖率与成本成反比：自动验证覆盖广、成本低但只覆盖可验证类型；人工抽检覆盖有限但可处理复杂语义。组合策略是"自动全量 + 人工抽样聚焦高风险"。

解析

验证链路的分工本质是"用自动化覆盖可验证的、用人工覆盖高价值的"。检索核对与执行测试自动、可扩展，人工抽检贵但能处理语义，按"自动优先、人工聚焦"组合，在覆盖度与成本间取得平衡。

#

★

19. 校验的延迟与成本预算，全量校验 vs 抽样校验在链路中的工程取舍？

问题

校验的延迟与成本预算应如何设置？全量校验与抽样校验在链路中如何取舍？

考察点

全量校验的保障与成本
抽样校验的省与风险
分层/混合校验策略

答案

全量校验保障每份输出都经过检验，但延迟与成本高（尤其模型校验按数量线性增长）；抽样校验只查部分，成本低但可能漏掉高风险样本。取舍原则看风险与成本：高风险场景（金融、医疗、关键交易）必须全量校验，不能抽；低风险、海量、实时场景可用抽样校验或只做低成本确定性校验。工程上常用混合/分层：①确定性规则校验全量（成本低、可靠）；②模型级校验对高风险子集或抽样做；③对抽检样本统计错误率，若错误率超阈值则升级为全量。这样在"预算固定"下，用抽样估计质量、按风险动态调整校验强度，兼顾覆盖与成本。

解析

全量 vs 抽样的取舍是"质量保障 vs 成本预算"的权衡。用"确定性全量 + 模型抽样 + 错误率动态升级"的混合策略，能在预算内最大化保障，比一刀切更优。

#

★

20. 校验器的自我校准，LLM-as-Judge 的置信度校准与一致性提升（投票、多次采样），校准后的阈值如何设定？

问题

校验器（LLM-as-Judge）如何自我校准？其置信度校准与一致性提升（投票、多次采样）如何实现？校准后的阈值如何设定？

考察点

置信度校准的意义
一致性提升：多次采样、投票
校准方法：对比已知答案、标定分数区间

答案

LLM-as-Judge 的置信度往往未校准（分数高不代表对），需要校准。校准方法：①用带标注的样本集，比对 Judge 的分数与真实正确率，建立"分数→实际正确率"的映射（如分数 0.8 实际只有 0.6 对），据此修正；②一致性提升——对同一输出多次采样评判，取平均或多数投票，减少单次随机性，提高稳定性；③校准策略——让 Judge 输出分数+理由，结合抽样一致性估计其置信度。校准后阈值设定：在标定曲线上选择满足业务要求的操作点——如要求"判定为正确时至少 90% 对"，就在映射表上找到对应分数阈值；高风险的"通过"阈值设高、"拒绝"阈值设低，中间留灰区转人工。阈值需随模型/数据变化定期重校准。

解析

Judge 的置信度校准是"让分数可信"的关键。通过标注集标定分数与实际正确率的关系，并结合多次采样投票提升一致性，再按业务风险设定阈值（通过/拒绝/灰区），让校验器的决策可解释、可调优。