切换深色模式
可靠 Agent：把回答拆成可检查的计算
对应 CS224V · 2026-09-23 · Introduction。日期为校方课表日期，可能调整。核对官方课表。
资料状态
核对日期：2026-09-19。对应课程尚未开课；本文是基于公开课纲与文中原始资料的原创预习技术解读，不是课堂实录、讲义翻译或官方作业答案。本文于 2026-09-20 深度修订。示例为原创教学设计；离线实验与真实模型实验的边界分别说明，不以推演冒充模型实测。
用户想选一门秋季课程：时间不冲突，先修要求满足，总学分不超过上限，还希望项目实践充分。模型可以马上推荐几门知名课，但名字熟悉、介绍好听，都不是这些条件已经满足的证据。
本系列用一个虚构的课程资料助手贯穿知识系统设计。所有课程 C1、C2 等都是教学记录，不对应 Stanford 的真实课程信息。主线是把自然语言请求转成可检查的表示，再让计算与证据共同约束回答。
先把问题拆成不同种类的判断
“秋季开课”是枚举条件；“时间不冲突”是区间计算；“满足先修”是逻辑条件；“实践充分”需要理解评价文本。它们不能都交给同一种相似度判断。
我们固定用户已有 4 学分，上限 10 学分，周三 14–16 点已有课程，完成先修 A，先修 B 是否完成未知。候选数据如下：
| 课程 | 学期/学分 | 时间 | 先修 | 评价证据 |
|---|---|---|---|---|
| C1 | 秋/3 | 周一 9–11 | A | 明确描述多次项目实践 |
| C2 | 秋/4 | 周三 15–17 | A | 实践充分 |
| C3 | 秋/3 | 周二 9–11 | B | 未说明实践 |
| C4 | 春/3 | 周四 9–11 | A | 实践充分 |
| C5 | 秋/4 | 周四 9–11 | A | 以考试为主、几乎无项目 |
| C6 | 秋/3 | 周五 9–11 | A | 只说老师讲得清楚 |
给定这些事实，C1 是明确候选；C2 冲突；C4 学期不符；C3 的先修未知；C5 的文本条件不满足；C6 的文本条件未知。这张表将成为后续章节的共同起点。
中间表示让理解错误暴露出来
先生成任务表示：硬约束是学期、时间、先修和学分；文本要求是实践充分；证据不足的候选是否展示，需要单独约定。若用户说“尽量实践多”，文本要求应是软偏好，而不是排除条件。
text
硬约束：秋季 ∧ 无时间冲突 ∧ 先修满足 ∧ 学分不超限
文本条件：存在足够证据支持“项目实践充分”
输出策略：明确推荐与待核实候选分开中间表示可以交给规则检查，也可以在高歧义情况下给用户确认。它的价值不是多一段 JSON，而是把“至少”“或者”“尽量”等会改变决策的语义显式化。
让每层负责它能验证的事
数据库负责结构化过滤，时间函数负责冲突检测，模型处理文本条件，最后的解释器依据这些结果生成说明。Stanford OVAL将语言能力与数据库、软件系统结合，是本系列的研究背景。
这样的架构并未消灭模型错误，而是把错误分成可定位的层次：语义解析可能把或写成且，查询可能连错表，文本判断可能把没有提及当成否定，生成可能夸大结果。
如果全部压在一段提示里，最终推荐 C2 时只能说“模型错了”；分层后，可以检查时间约束是否被解析、时间函数是否运行、最终回答是否忽略了冲突标记。
可检查依据与漂亮解释不同
系统若实际按评分排序，却声称“最符合你的时间”，解释并不忠实。每条推荐理由应绑定执行结果：C1 学期匹配、时间不冲突、先修 A 已完成，评价 E1 支持实践要求。
C6 不能写成“实践不足”，因为资料只是不涉及实践。这里必须引入未知状态。把未知强行压成真假，后续查询会得到确定但不正确的结果。
用条件变化检查系统是否理解了任务
把用户上限从 10 改为 6，C1 的 3 学分会使总数达到 7，因此原推荐失效。把“秋季”改为“任意学期”，C4 才进入候选。把“必须实践充分”改为“优先实践充分”，C5、C6 的排序与展示策略应改变，但证据标签不应被改写。
这些是一次只改一个条件的反事实测试。它们能区分真正执行约束的系统与只记住“C1 是正确答案”的系统。
单门推荐正确，组合推荐为什么仍会错
假设用户进一步说“给我选两门，实践只是偏好”。C1 和 C5 各自通过单门学分检查，但一起加入后是 4 + 3 + 4 = 11，超过上限 10。逐行检查的通过结果不能直接合并成一个可行课表。
问题的计算单位已经改变：之前判断 eligible(course)，现在判断 feasible(set_of_courses)。后者需要对集合求学分和，检查新选课程之间是否冲突，并处理先修是否允许同期修读。这些条件不能靠提高单门推荐分数解决。
可以先生成单门候选，再搜索满足集合约束的组合；也可以直接交给约束求解器。无论选择哪种实现，中间结果都应同时保存候选级依据和组合级依据。否则最后一句“这两门都适合你”会跨过一个没有执行过的证明步骤。
这解释了系统拆分的真正原则：按判断所需的信息范围拆分，而不是简单地把任务切成若干自然语言小步骤。局部判断只对自己的作用域负责；最终交付者仍需验证组合后的整体。我们将在 SMT 一讲再次用这个区别检查决策。
本讲留下的架构问题
结构化判断能检查逻辑，文本评价仍然需要事实核验；多份资料还可能互相冲突。下一讲先解决最基础的一步：一句带引用的回答，究竟哪些事实得到了支持？继续阅读WikiChat 与核验。