2.4 KiB
面试追问 Q&A
为什么不用普通 Chatbot？
这个项目的重点不是生成一段诊断文本，而是把诊断拆成可审计链路：Planner 拆解问题，Executor 调工具拿证据，Gatekeeper 用代码核验证据引用，Verifier 判断可推导性，Composer 生成最终表达。每次运行都能通过同一个 sessionId 回放。
为什么 RAG 要做成显式工具？
lookup_knowledge 保持显式工具调用，才能在 tool_invocation 里看到 Agent 查了什么、命中了什么、相关性等级是什么，以及最终答案是否真的使用了这些证据。隐式 Advisor 更方便，但不利于审计 Agent 决策。
怎么防止 Executor 幻觉？
Executor 不直接负责最终用户答案，而是输出 executor_evidence_v2 的微观事实和证据引用。Gatekeeper 会校验 source_invocation_id、raw_path、evidence_excerpt 是否真实存在；Verifier 再判断 claim 是否能由已验真的证据推出；Composer 只表达 Verifier 允许输出的内容。
LOW_CONFID 是失败吗？
不是。LOW_CONFID 表示当前证据不足以支撑强结论，但系统仍然可以安全表达已确认事实和缺失信息。面试时可以把它作为“没有证据就不强答”的质量门禁，而不是模型能力失败。
Prompt 改了怎么审计？
Chat verifier evaluation 里会记录 prompt_audit.version，并列出 planner、executor、verifier、composer 的 Prompt 版本和资源路径。它不保存完整 Prompt 文本，只保留用于回放和回归解释的紧凑元数据。
Gatekeeper 改了怎么审计？
Gatekeeper 结果里记录 gatekeeper_result.rule_set_version 和已启用规则元数据摘要。规则执行仍是确定性 Java 代码，版本和规则元数据用于解释“这次引用验真用的是哪套规则”。
为什么现在不拆 SubAgent？
当前 MVP 的主要风险不是 Agent 数量不够，而是证据、验证和回归是否稳定。文档里的演进路线把 SubAgent 放在 P2：等故障类型、工具权限和评测集足够明确后再拆，避免只是移动复杂度。
为什么 baseline 比 live demo 更重要？
live demo 证明链路在当前环境能跑通，但 LLM 和外部依赖会波动。mvp/eval 的固定 fixture baseline 是确定性回归来源，用来判断 Prompt、工具、Gatekeeper、Verifier 或 Composer 的改动有没有让系统退化。