 玄同 765 AI Engineer | ▍深耕领域 AI Agent 架构设计 Agent Harness 工程 Context Engineering 多智能体协同 & RAG |
| 「 让 AI 交互更智能，让技术落地更高效 」 ｜ 欢迎技术探讨 / 项目合作，关注解锁大模型与智能交互的无限可能！ | |
【RAG 架构与评测实战 #05】Agent 评测体系（下）：证据感知的澄清判分与防假通过契约
📚 《企业级 RAG 架构与全链路评测实战》五篇连载导航
- #01 确定性切分与防注入预览：确定性文档切分、受控 LLM 摘要增强与防注入预览输出
- #02 双路混合召回与三态降级：双路混合召回：自适应 RRF 平滑常量、文档级聚合与三态降级
- #03 数据视图安全投影与重排门禁：数据表与 SQL 检索：防泄密结构提取、双表征索引与重排五重门禁
- #04 三轴评测归因与三态门禁：Agent 评测体系（上）：三轴结果模型、基建故障归因与三态门禁
- #05 证据感知澄清判分与防假通过：Agent 评测体系（下）：证据感知的澄清判分与防假通过契约
在上一篇（#04）中，我们通过“正交三轴结果模型 + 基建故障精准归因 + 三态运行结论门禁”解决了环境抖动对评测准确率的污染；而在先前的《Agent Harness 架构手册》中，我们也曾探讨过 实时动态流与阶段性结论合成引擎 与 零信任权限审计与 AST 行级安全注入。作为本系列的收官之作，今天我们将深潜到评测体系最核心的“裁判大脑（LLM-as-a-Judge）”——如何公正评判 Agent 的“反问澄清（Clarification）”动作，并彻底堵死 Judge 解析中的“假通过（False Positive）”与“故障嫁祸”漏洞。
在真实的企业级数据分析与知识问答评测中，我们曾遇到过四个极具迷惑性的判分冤案与工程 Bug：
- Agent 调用终止型澄清工具（
return_direct=True），被评测采集器当成“空回答”全部判 0 分：为了防止模型在缺乏口径或参数歧义时瞎猜幻觉，架构师专门给 Agent 配了终止型反问澄清工具（调用后立即挂起等待用户选择，不再触发后续 LLM 流式输出message_delta）。然而评测采集脚本只从message_delta拼接文本，导致所有发起安全澄清的 Case 都被采集成空字符串""，在 100 道测试题里制造了 20 多起冤假错案！ - 用“参考答案（Gold Answer）”倒推强迫 Agent 盲猜，或者对“查出 0 行后顺带询问下一步”一刀切判错：有的题目在当前测试工作区里根本没有录入对应的指标定义，Agent 检查完知识库与数据表后诚实披露“当前环境缺少该指标定义，请选择替代口径”，结果裁判模型看到测试集里有参考答案，就无脑判 Agent 错！反过来，有时 Agent 已经查明并报告了“按当前条件查询结果为 0 行”，只是礼貌性地在追问字段里附带了一句“是否需要扩大时间范围？”，也被简单粗暴地当成“未回答问题”判了 0 分。
- Python 隐式布尔转换
bool(parsed.get("is_correct"))酿成惊天“假通过”漏洞：当裁判模型偶发抽风，把 JSON 里的布尔值输出成字符串"false"（即{"is_correct": "false", "score": 0.0}）时，Python 的bool("false")返回的竟然是True！结果明明答错的题目被静默判成了通过（Pass）！ - Judge JSON 解析失败时合成
is_correct=False的假判分，把“裁判坏了”伪装成“Agent 答错了”：当裁判模型自身输出截断或违反 JSON 契约时，很多代码在except分支里直接返回{"is_correct": False}，导致裁判模型的稳定性问题全部算在了被测 Agent 的错误率头上。
本文将手把手带你实现一套生产级 证据感知双模 LLM 裁判与强契约解析引擎：一次性打通终止工具采集、证据感知澄清 Rubric、非对称澄清期望门禁以及零隐式转换的 Judge 契约校验闭环。
文章目录
一、为什么“反问澄清”是检验企业级 Agent 的试金石？（原理拆解篇）
1.1 诚实的专业顾问 vs 不懂装懂的算命先生
在严肃的企业级 RAG 与数据分析场景中，一个优秀的 Agent 绝不应该是“有问必答的算命先生”，而应该是**“证据驱动的专业顾问”**：
- 当用户问题存在真实的参数歧义（如只说了“看下上月退货率”，但库里有“按发货口径”和“按签收口径”两套表），或者当前环境确实缺失权威口径映射时，拒绝盲猜、披露已检查范围并向用户发起结构化追问（
followup_inquiry）是唯一正确的行为。 - 反之，如果用户问题已经写得清清楚楚（如“查询 2026 年第 3 季度华东区净销售额”），Agent 却因为懒惰不去检索就直接反问“请问您要查哪个季度？”，或者查出 0 行记录后隐瞒不说、直接反问“要不要换个条件？”，这就是典型的逃避作答（Evasive Clarification），必须严厉判错！
下面这张决策树展示了 证据感知的双模评测判分引擎 是如何精准区分“高质量安全澄清”与“劣质逃避反问”的：
1.2 六种典型交互场景下的证据感知判分准则对比表
为了让 LLM Judge 彻底摆脱主观臆断，我们将澄清判分规则固化为以下六条可核对的工程契约：
| 场景编号 | Agent 的实际交互表现（verified_context + inquiry_prompt） | 传统二元评测结果 | 本文证据感知 Rubric 判定结果与核心依据 |
|---|---|---|---|
| 场景 01 | 调用终止追问工具，无 message_delta 流式文本输出 | 误判 0 分（采集成空串） | 进入澄清专判通道（从 tool_result 提取追问结构体） |
| 场景 02 | 披露已检索全部可用表，但某细分指标口径缺失，列出 2 个候选字段请用户确认 | 误判 0 分（未命中参考数值） | 判对（True）：参考答案不代表当前环境真有该证据，严禁逼模型盲猜 |
| 场景 03 | 成功执行 SQL 查出 0 行，先明确告知“当前条件下无记录”，再问“是否放宽日期” | 误判 0 分（因触发了追问工具） | 判对（True）：当前问题已明确给出空结果结论，询问可选下一步完全合理 |
| 场景 04 | 查询返回 0 行，Agent 隐瞒 0 行事实不说，直接反问“要不要换个区域查？” | 判 0 分 | 判错（False）：未先报告已确定的空结果，借追问回避当前结论 |
| 场景 05 | 用户已明确写出“2026年第2季度”，Agent 却未做任何检索直接反问“请问查哪个季度？” | 判 0 分 | 判错（False）：信息已完整仍以前置追问阻塞回答 |
| 场景 06 | 题目声明 mandatory_inquiry=True（必考歧义识别），但 Agent 未追问直接猜了一个数 | 若碰巧猜中数值则误判通过 | 前置门禁直接拦截判错（False）：缺失必要前提却跳过澄清强行作答 |
二、基础篇：终止型澄清工具事件采集与非对称期望门禁
2.1 为什么 mandatory_inquiry（澄清期望声明）的设计是“非对称”的？
在测试集（如 CSV 或 TOML）中，我们可以为每道题配置一个可选的 mandatory_inquiry 字段（True / False / None）：
- 当
mandatory_inquiry=True时（硬性前置门禁）：说明这道题故意埋设了缺失口径或歧义陷阱，Agent 必须调用澄清工具；如果 Agent 没有追问而是直接给出了答案，无需调用 LLM Judge，直接在确定性前置门禁enforce_inquiry_direction_gate中判错！ - 当
mandatory_inquiry=False时（非对称柔性穿透）：说明这道题不需要前置澄清就能回答。但如果 Agent 的interaction_mode是followup_inquiry，我们绝不能仅凭模式标签就直接判错！ 因为正如前面“场景 03”所述，Agent 完全可能已经在追问工具的verified_context（摘要）里完整回答了当前问题，只是顺带在inquiry_prompt里礼貌询问是否执行下一步排查。因此，mandatory_inquiry=False时必须继续放行给澄清 Judge 做内容级裁决！ - 严格布尔配置解析（
parse_mandatory_inquiry_flag）：如果在测试集 CSV 里手误把布尔值写成了"maybe"或"unsure"，绝不能用bool("maybe")静默当成True，必须立即抛出ValueError暴露配置错误！
2.2 完整实现代码：终止工具载荷提取与非对称澄清期望门禁
下面这段代码完整实现了从事件流提取终止型追问工具输出的 decode_inquiry_tool_payload、严格布尔解析器 parse_mandatory_inquiry_flag 以及非对称门禁 enforce_inquiry_direction_gate：
from __future__ import annotations
import json
from typing import Any
_INQUIRY_TOOL_NAMES = frozenset({"request_user_clarification", "propose_followup_options"})
_TRUTHY_LITERALS = frozenset({"1", "true", "yes", "y", "on", "是"})
_FALSY_LITERALS = frozenset({"0", "false", "no", "n", "off", "否"})
def is_terminating_inquiry_tool(tool_Identifier: Any) -> bool:
"""判断工具名称是否属于 return_direct=True 的终止型澄清追问工具。"""
return str(tool_Identifier or "").strip() in _INQUIRY_TOOL_NAMES
def decode_inquiry_tool_payload(raw_tool_output: Any) -> dict[str, Any]:
"""解析终止型澄清工具的 tool_result 载荷；兼容 JSON 对象与参数报错纯文本。"""
text_val = str(raw_tool_output or "").strip()
if not text_val:
return {"verified_context": "", "inquiry_prompt": "", "option_items": []}
try:
parsed_obj = json.loads(text_val)
except json.JSONDecodeError:
return {"verified_context": "", "inquiry_prompt": text_val, "option_items": []}
if not isinstance(parsed_obj, dict):
return {"verified_context": "", "inquiry_prompt": text_val, "option_items": []}
raw_opts = parsed_obj.get("option_items")
clean_opts = [str(item) for item in raw_opts] if isinstance(raw_opts, list) else []
return {
"verified_context": str(parsed_obj.get("verified_context") or ""),
"inquiry_prompt": str(parsed_obj.get("inquiry_prompt") or ""),
"option_items": clean_opts,
}
def parse_mandatory_inquiry_flag(raw_flag: Any) -> bool | None:
"""严格解析测试集中的澄清期望声明；拒绝把拼写错误的非标字符串静默转为 True。"""
if raw_flag is None:
return None
if isinstance(raw_flag, bool):
return raw_flag
normalized = str(raw_flag).strip().lower()
if not normalized:
return None
if normalized in _TRUTHY_LITERALS:
return True
if normalized in _FALSY_LITERALS:
return False
raise ValueError(f"Invalid mandatory_inquiry flag in testset: {raw_flag!r}")
def enforce_inquiry_direction_gate(
*,
interaction_mode: str,
mandatory_inquiry: Any,
) -> dict[str, Any] | None:
"""执行非对称澄清期望门禁：mandatory_inquiry=True 时强校验追问，False 时穿透交由 Judge 细判。"""
expected_flag = parse_mandatory_inquiry_flag(mandatory_inquiry)
if expected_flag is None:
return None
if expected_flag is True and interaction_mode != "followup_inquiry":
return {
"is_correct": False,
"numeric_score": 0.0,
"verdict_reason": "测试题存在必要的口径或证据映射缺口，要求必须先澄清再作答，但 Agent 直接给出了结论。",
"eval_channel": "direction_gate",
}
return None
def render_inquiry_direction_hint(mandatory_inquiry: Any) -> str:
"""将测试题的澄清方向声明转化为注入 Judge Prompt 的明确指引。"""
expected_flag = parse_mandatory_inquiry_flag(mandatory_inquiry)
if expected_flag is True:
return "【本题期望声明】本题必须先发起澄清。请重点核查追问是否具体、必要且指向真实歧义或证据缺口。"
if expected_flag is False:
return (
"【本题期望声明】本题无需前置澄清即可作答。若 Agent 未回答当前问题而反问已知信息，应判错；"
"但若 verified_context 已明确交代当前结论（含报告确定的 0 行空结果），inquiry_prompt 仅询问"
"是否扩大范围等可选下一步，绝不可仅因触发了追问工具就判错。"
)
return "【本题期望声明】未预设固定交互方向，请完全依据问题本身与 Agent 披露的证据核查情况公正裁决。"
三、进阶篇：根治 bool("false") == True 假通过与自相矛盾分数的强契约解析器
3.1 为什么解析 LLM Judge 的 JSON 输出必须用“零宽容契约”？
在编写 LLM Judge 解析器时，有两个极易踩中的致命陷阱：
- 陷阱一：
bool(parsed.get("is_correct"))把字符串"false"变成True：
在 Python 中，任何非空字符串的布尔值都是True（即bool("false") is True）！如果裁判模型返回了{"is_correct": "false", "numeric_score": 0.0}，使用bool()转换会直接把答错的题判为满分通过！因此，必须使用isinstance(raw_correct, bool)做严格类型断言，一旦发现不是原生 JSON 布尔类型，立即抛出自定义的ScorerProtocolViolation触发重试！ - 陷阱二：
is_correct与numeric_score自相矛盾，或把解析失败当成 Agent 答错：
有时裁判模型返回{"is_correct": true, "numeric_score": 0.0}；如果下游报告看is_correct而排行榜算numeric_score均值，两边数据就会打架。此外，当ScorerProtocolViolation重试 3 次仍失败时，必须标记scorer_down=True（由上篇的三轴模型归因为scorer_outage从分母剔除），绝不能合成一个没有标记的is_correct=False冤枉被测 Agent！
3.2 完整实现代码：防假通过强契约解析与弹性重试执行器
下面这段代码完整实现了 ScorerProtocolViolation、decode_scorer_json、validate_and_align_verdict 与 invoke_resilient_scorer：
from __future__ import annotations
import json
import time
from typing import Any
class ScorerProtocolViolation(RuntimeError):
"""裁判模型输出违反 JSON 契约（非 JSON 对象、缺失核心字段或 is_correct 非原生布尔值）。"""
def decode_scorer_json(raw_text: str) -> dict[str, Any]:
"""从裁判模型响应中提取 JSON 对象，不合法时立即抛出 ScorerProtocolViolation。"""
cleaned = raw_text.strip()
fence = "`" * 3
if cleaned.startswith(fence):
cleaned = cleaned.strip("`").strip()
if cleaned.lower().startswith("json"):
cleaned = cleaned[4:].strip()
try:
parsed = json.loads(cleaned)
except json.JSONDecodeError as exc:
left, right = cleaned.find("{"), cleaned.rfind("}")
if left >= 0 and right > left:
try:
parsed = json.loads(cleaned[left : right + 1])
except json.JSONDecodeError:
raise ScorerProtocolViolation(f"Scorer returned invalid JSON: {raw_text[:160]}") from exc
else:
raise ScorerProtocolViolation(f"Scorer returned non-JSON text: {raw_text[:160]}") from exc
if not isinstance(parsed, dict):
raise ScorerProtocolViolation("Scorer top-level JSON value must be an object")
return parsed
def validate_and_align_verdict(parsed_obj: dict[str, Any]) -> dict[str, Any]:
"""强校验 is_correct 必须为原生布尔值（杜绝 bool('false')==True），并对齐分数自洽性。"""
if "is_correct" not in parsed_obj:
raise ScorerProtocolViolation("Scorer JSON missing required field 'is_correct'")
raw_correct = parsed_obj["is_correct"]
if not isinstance(raw_correct, bool):
raise ScorerProtocolViolation(
f"Field 'is_correct' must be a strict JSON boolean, got {type(raw_correct).__name__}: {raw_correct!r}"
)
raw_score = parsed_obj.get("numeric_score")
if raw_score is None:
aligned_score = 1.0 if raw_correct else 0.0
else:
if isinstance(raw_score, bool):
raise ScorerProtocolViolation("Field 'numeric_score' must be a number, not boolean")
try:
aligned_score = float(raw_score)
except (TypeError, ValueError) as exc:
raise ScorerProtocolViolation(f"Invalid numeric_score: {raw_score!r}") from exc
if raw_correct and aligned_score <= 0.0:
aligned_score = 1.0
elif not raw_correct and aligned_score >= 1.0:
aligned_score = 0.0
return {
"is_correct": raw_correct,
"numeric_score": max(0.0, min(1.0, aligned_score)),
"verdict_reason": str(parsed_obj.get("verdict_reason") or "").strip(),
"omitted_facts": [str(x) for x in (parsed_obj.get("omitted_facts") or [])],
"hallucinated_facts": [str(x) for x in (parsed_obj.get("hallucinated_facts") or [])],
}
def invoke_resilient_scorer(
*,
llm_call_fn: Any,
judge_prompt: str,
eval_channel: str,
max_attempts: int = 3,
) -> dict[str, Any]:
"""调用裁判模型并校验契约；重试耗尽后显式标记 scorer_down=True，绝不伪造 Agent 答错。"""
last_err_msg = ""
is_protocol_err = False
for attempt_idx in range(max(1, max_attempts)):
try:
raw_reply = llm_call_fn(judge_prompt)
verdict = validate_and_align_verdict(decode_scorer_json(raw_reply))
return {**verdict, "eval_channel": eval_channel, "scorer_down": False}
except ScorerProtocolViolation as exc:
is_protocol_err = True
last_err_msg = str(exc)
except Exception as exc:
is_protocol_err = False
last_err_msg = f"{type(exc).__name__}: {exc}"
if attempt_idx < max_attempts - 1:
time.sleep(min(1.5 * (attempt_idx + 1), 5.0))
failure_tag = "协议违约" if is_protocol_err else "服务调用异常"
return {
"is_correct": False,
"numeric_score": 0.0,
"verdict_reason": f"裁判器{failure_tag}（已重试 {max_attempts} 次）：{last_err_msg}",
"omitted_facts": [],
"hallucinated_facts": [],
"eval_channel": eval_channel,
"scorer_down": True,
"protocol_violation": is_protocol_err,
}
四、高阶实战：双模证据感知判分引擎（Answer Judge & Clarification Judge）
4.1 完整实现代码：组装直接作答与证据感知澄清双模判分器
现在我们将前面的非对称期望门禁、证据感知澄清 Rubric 与弹性强契约执行器组装成完整的双模评测入口 evaluate_turn_with_rubric：
from __future__ import annotations
from typing import Any
_DIRECT_REPLY_RUBRIC = """
【直接作答判分准则】
1. 仅核对业务事实与核心结论是否准确，不要求行文措辞与参考答案逐字一致。
2. 关键指标数值、正负号、业务线名称、时间周期及归属实体必须与参考答案严格对齐。
3. 若关键数值缺失、算错或张冠李戴，is_correct 必须为 false。
""".strip()
_FOLLOWUP_INQUIRY_RUBRIC = """
【证据感知澄清追问判分准则】
1. 真实歧义或证据缺口下的安全澄清（判 true）：
- 用户问题本身存在时间、口径、粒度或实体歧义，且追问正是指向该歧义；
- 或 Agent 在 verified_context 中明确说明已核查可用知识与数据视图，但精确指标定义、字段映射缺失或冲突，
直接作答只能靠拆词盲猜，因此列出安全候选路径请用户确认 -> is_correct = true。
- 注意：参考答案仅代表出题人意图，不证明当前运行环境一定存有支撑证据，严禁逼迫 Agent 盲猜！
2. 已报告确定空结果后的礼貌追问（判 true）：
- 若 Agent 已通过有效查询确认当前条件下返回 0 行记录，且在 verified_context 中清楚报告了「无符合记录」的结论，
仅在 inquiry_prompt 中询问是否放宽时间或筛选条件 -> 当前问题已回答，is_correct = true。
3. 阻塞式逃避反问（判 false）：
- 用户提问已明确给出完整时间与实体参数，Agent 未先回答却重复追问已知信息 -> is_correct = false；
- 查询返回 0 行但 Agent 隐瞒不报，直接反问用户要不要换条件借此逃避结论 -> is_correct = false。
""".strip()
_STRICT_JSON_SCHEMA_NOTE = """
请仅输出合法 JSON 对象（严禁使用 Markdown 代码块，is_correct 必须为原生布尔值 true 或 false）：
{"is_correct": true, "numeric_score": 1.0, "verdict_reason": "简短原因", "omitted_facts": [], "hallucinated_facts": []}
""".strip()
def evaluate_turn_with_rubric(
*,
llm_call_fn: Any,
user_query: str,
gold_answer: str,
gold_facts: list[str] | None,
interaction_mode: str,
actual_reply_text: str,
mandatory_inquiry: Any = None,
) -> dict[str, Any]:
"""根据交互模式自动路由至直接作答或证据感知澄清判分通道。"""
gate_rejection = enforce_inquiry_direction_gate(
interaction_mode=interaction_mode,
mandatory_inquiry=mandatory_inquiry,
)
if gate_rejection is not None:
return {**gate_rejection, "scorer_down": False}
facts_block = "\n".join(f"- {item}" for item in (gold_facts or [])) or "(none)"
if interaction_mode == "followup_inquiry":
direction_hint = render_inquiry_direction_hint(mandatory_inquiry)
full_prompt = "\n\n".join(
[
"你是企业级 AI Agent 严格评测裁判。",
_FOLLOWUP_INQUIRY_RUBRIC,
direction_hint,
f"用户原始问题:\n{user_query}",
f"Agent 的澄清追问输出:\n{actual_reply_text or '(empty)'}",
f"参考业务语义（不代表当前环境必有支撑证据）:\n{gold_answer or '(none)'}",
f"参考核对要点:\n{facts_block}",
_STRICT_JSON_SCHEMA_NOTE,
]
)
return invoke_resilient_scorer(
llm_call_fn=llm_call_fn,
judge_prompt=full_prompt,
eval_channel="followup_inquiry",
)
full_prompt = "\n\n".join(
[
"你是企业级 AI Agent 严格评测裁判。",
_DIRECT_REPLY_RUBRIC,
f"用户原始问题:\n{user_query}",
f"参考标准答案:\n{gold_answer or '(none)'}",
f"参考核对要点:\n{facts_block}",
f"Agent 实际回答:\n{actual_reply_text or '(empty)'}",
_STRICT_JSON_SCHEMA_NOTE,
]
)
return invoke_resilient_scorer(
llm_call_fn=llm_call_fn,
judge_prompt=full_prompt,
eval_channel="direct_reply",
)
五、实战避坑指南：LLM-as-a-Judge 判分与澄清评测高频问题速查表
在维护自动化评测平台与排查离奇判分案例时，可随时查阅下表：
| 序号 | 遇到的报错或异常现象 | 背后的真正原因 | 一句话解决办法 |
|---|---|---|---|
| 01 | 裁判模型明明在 verdict_reason 里写“回答完全错误”，但该题最终状态却显示为 pass_ok | 裁判模型返回了字符串 "false"，解析代码写了 bool(parsed.get("is_correct")) 变成了 True | 在 validate_and_align_verdict 中强制断言 isinstance(raw_correct, bool)，非布尔类型一律抛协议违约异常 |
| 02 | 离线评测与线上实时评测对同一道题的判分标准不一致，一边判过一边判挂 | 离线评测脚本与线上评测服务各自维护了一套复制粘贴的 Judge Prompt，迭代中发生漂移 | 将直接作答与澄清判分 Rubric 统一收口到单一模块 evaluate_turn_with_rubric，两端共享同一套解析与重试逻辑 |
| 03 | 测试集 CSV 里的 mandatory_inquiry 列有人填了 "todo"，结果那道题被强制要求必须追问 | 用 bool(str_val) 解析配置列，任何非空字符串都被当成了 True | 使用 parse_mandatory_inquiry_flag 严格匹配真假值白名单集合，遇到未知词立即抛 ValueError |
| 04 | 裁判模型网关偶发限流返回 429，导致当天评测报告里多出十几个“Agent 答错”的回归案例 | Judge 调用异常被捕获后直接返回了 is_correct=False 且未标记 scorer_down=True | 在重试耗尽后返回 scorer_down=True，由外层三轴状态机定性为 exempt_err（scorer_outage）并从分母剔除 |
结语：五篇连载全景回顾
到这里，我们这套 《企业级 RAG 架构与全链路评测实战》 五篇连载就圆满收官了！让我们最后串联回顾这五座环环相扣的工程基石：
- #01 确定性切分与防注入预览：用程序锁定 Markdown 标题树与空行字符偏移量，让 LLM 仅在受控契约内补充摘要，配合双代际（Epoch Tag）零停机发布与单行防伪造预览卡片，打牢知识入库与读取地基。
- #02 自适应双层 RRF 与三态降级：用候选窗口自适应平滑常量
effective_k根治末位弱命中反超主路状元的倒挂怪象，结合文档级聚合、引号锚点提权与三态可用性契约，实现高韧性混合召回。 - #03 数据视图安全投影与重排五重门禁：用
sqlglotAST 提取公开结构事实并自动掩码描述中的私有底表名，将 Schema 清单与用法画像卡拆分为双表征独立向量，并在重排输出端实施五重边界校验。 - #04 三轴评测归因与三态运行门禁：将交互模式、故障责任方与评分状态正交解耦，精确划定连接超时与查询超时的归因边界，并用样本覆盖率三态门禁杜绝幸存者偏差。
- #05 证据感知澄清判分与防假通过契约：从工具事件流拯救终止型澄清输出，用证据感知 Rubric 公正裁决安全反问与空结果礼貌追问，并用零隐式转换契约彻底消灭
bool("false")假通过漏洞。
希望这套凝结了真实生产踩坑与架构演进的五篇实战手册，能成为你构建高可靠 AI Agent 与 RAG 系统时的得力案头参考！欢迎在评论区交流你在 RAG 检索与 Agent 评测中遇到的疑难杂症，我们下个系列再见！
2085
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
