AI 工程(AI Engineering) — 本课题摘录
读了哪一章: 第 6 章(检索增强与智能体)。 全书九章,其余本轮没读。
这一份的角度和前面六十几份都不同:它不问"循环该怎么写",它问"这个循环坏了的时候,你怎么知道、怎么数"。本课题第四圈("怎么知道它好不好")到这里才第一次有了系统材料。
它对本课题回答了什么
故障分三类,而且每一类都给了可数的指标
| 类别 | 是什么 |
|---|---|
| 规划故障 | 计划 本身就不对 |
| 工具故障 | 用对了工具,但工具输出错了 |
| 效率故障 | 计划有效、任务也完成了,但走得太绕、太贵、太慢 |
(依据:书 · AI工程(AI Engineering) §第6章 —— 智能体特有的故障模式由规划、工具执行、效率三方面引起;评估一个智能体的做法是识别其故障模式并统计每种发生的频率)
它的方法论一句话:评估一个智能体,就是识别它的故障模式,然后统计每种发生的频率。
这句话对本课题的原型阶段直接可用: "评估"不是给它打一个分,是给每一种坏法各记一个数。
而且这跟 shen-ru 那本的"做消融实验,逐项关掉看哪个影响最大"是配套的: 一个告诉你怎么定位原因,一个告诉你怎么给症状分类。
"工具使用失败"被拆成三档 —— 这一条最实用
| 档 | 例子 |
|---|---|
| 调了不存在的工具 | 计划里要调某个搜索工具,而工具库里根本没有它 |
| 工具对,但参数个数不对 | 一个只要一个参数的换算工具被传了两个 |
| 参数个数对,但数值错 | 该传 120 却传了 100 |
(依据:书 · AI工程(AI Engineering) §第6章 —— 最常见的规划故障是「工具使用失败」,细分为无效工具(调了工具库里没有的)、工具有效但参数无效(参数个数不对)、工具有效但参数值错误(个数对但数值错)三档)
这三档的排查手段完全不同,这才是它的价值:
- 第一档:程序能自动检出(名字不在表里)——这正是 dong-shou-zuo-ai-agent 那条"无效工具当成一次观察回填"处理的情况;
- 第二档:程序也能自动检出(参数校验)——厂商的结构化输出能挡掉大部分;
- 第三档:程序检不出来。 参数合法、类型正确、就是数错了。
只有第三档需要外部裁判(db-gpt 的"真执行对答案")或人来看。 本课题的原型应该把前两档做成自动统计,第三档留给人。
它还给了六个可以直接算的指标: 生成的计划里有多少是有效的、平均要生成几个计划才得到一个有效的、所有工具调用里有多少有效、无效工具被调的频率、有效工具被传错参数个数的频率、有效工具被传错参数值的频率。
一种独立的故障:它以为自己做完了
"反思错误":智能体确信自己已经完成了任务,但实际上并没有。
它的例子:把 50 个人分配到 30 间房, 智能体只分配了 40 个,却坚称任务已完成。 (依据:书 · AI工程(AI Engineering) §第6章 —— 「反思错误」是一种规划故障——智能体确信自己完成了任务但实际未完成,例子是把 50 个人分配到 30 个酒店房间却只分了 40 人还坚称已完成)
这一条直接打在本课题第四个决定的要害上: 前面绝大多数实现的停止条件是"模型不再要工具了"——而这条故障说的正是"模型不再要工具了,但活没干完"。
kun 用五道纠正来兜它,db-gpt 用"真执行对答案"来兜它, 这本书给了它一个名字和一个可数的定义。有名字才好统计。
一个经常被忽略的约束:时间
在某些场景下,智能体的价值会随时间推移而降低。
它的例子:你要求智能体准备一份资助申请,但它在截止日期之后才完成——那便没什么实际价值了。
本课题读到现在,"什么时候停"讨论的都是"跑太久要停"(省钱、防死循环)。 这一条给了另一个理由:跑太久,做对了也没用。
两者的区别在于谁来定那个上限:前者由预算定,后者由外部的截止时间定。
决定四:规划与执行解耦,以及验证计划的几种办法
它给的动机很具体:如果模型生成了一个一千步的计划,最终却无法实现目标怎么办?在缺乏监督的情况下,智能体可能会花上数小时执行,浪费大量时间和调用成本,最后你才发现它毫无进展。
所以:先生成计划,验证通过才执行。 (依据:书 · AI工程(AI Engineering) §第6章 —— 规划最好与执行解耦——先生成计划、验证通过才执行;验证可用启发式规则(计划里含无效动作就排除、步数超过 X 就排除)或用另一个模型评估计划是否合理;若评估为不佳就让规划器重新生成)
验证的两条启发式规则很实在:
- 计划里有智能体没有权限的动作 → 这个计划无效;
- 步数超过某个阈值 → 排除。
也可以让另一个模型来评。
注意这条跟本课题选的路线是相对的:我们的最小循环是"每一步只决定下一步"(增量规划),没有一个可以先验证的完整计划。
但那两条启发式规则可以下放到单步:
- "这一步要调的工具存在吗" → 就是上面第一档故障的自动检查;
- "已经走了多少步" → 就是轮数上限。
换句话说:先验证再执行这件事,在增量模式下等价于"每一步都过一遍闸"。
它还点出了规划粒度的权衡:细粒度计划难生成、易执行;粗粒度计划易生成、难执行。分层规划是一种解法。
一条对"模型到底会不会规划"的诚实交代
它列了反方的论点(有研究者认为自回归模型根本不具备规划能力),也列了正方的反驳(沿一条路走一段后判断不可行就换一条,效果上等价于回溯)。
它自己的判断:目前还不清楚这究竟是因为我们尚未掌握正确使用的方法,还是模型从根本上就无法规划。
它给了一个更有用的角度:模型缺的往往不是"有哪些动作可选",而是"执行这个动作之后会变成什么状态"的预测能力。 (依据:书 · AI工程(AI Engineering) §第6章 —— 规划的核心是一个搜索问题——在通往目标的多条路径间搜索、预测每条的结果、选最有希望的;书指出仅提示模型生成一串动作不够,还需要知道每个动作会把状态带到哪里才能判断该不该执行)
这条对本课题有一个具体推论:工具的返回值应该让模型看清"现在变成什么样了",而不只是"这一步成功了"。 browseros 的"动作结果自动附带变化差异"正是这条的实现——它把"执行后的状态"塞进了工具结果里。
效率的三个可测量
平均多少步完成一个任务、平均成本多少、每个动作耗时多久(有没有特别慢或特别贵的动作)。
它提醒了一句:与人对比时要注意——对人低效的操作对 AI 可能轻而易举(比如访问一百个网页)。
它没回答什么
- 循环本身——怎么认出模型要调工具、结果怎么回填、什么时候停,这一章都没讲。它站在评估那一侧。
- 上下文压缩的机制——提到记忆系统补充上下文,但机制留给了后一章。
- 其余八章——本轮没读。
坑与代价
- 它谈的规划大多是"先出完整计划"那一路,跟我们选的增量路线不完全对得上。要自己做一次转译(上面第三条判断)。
- 它给的指标要能算出来,前提是每一次工具调用及其输出都被记下来。 书里明说:务必打印出每次工具调用及其输出。
判断(无锚): 这条印证了前面那句"最小原型从第一天就该有事件流"。没有记录就没有指标,没有指标"评估"就只剩感觉。 如果错,会错在: 如果原型只跑几轮、终端里全看得见,直接翻屏幕就够,专门的记录是多余的。
- "反思错误"这类故障没有自动检测办法。 它能被命名、被统计,但要人先判断"到底做完了没有"。