
论文标题:《Language Agents: From Next-Token Prediction to Digital Automation》
本文关键词:Reasoning | CoT的组块化设计 | 评估驱动设计 | Next token prediction | 模型泛化能力
一、基于泛化能力的AI能力演进
开始我们有了语言模型,它可以做文本生成任务
随后有了大语言模型,它基于文本的先验泛化能力,可以做翻译、QA、总结任务。
在大语言模型基础上,构建reasoning空间,定义环境,再加上工具、记忆、判断规则,构建更稳定的Agent体系。
二、用自组织的系统代替规则
通过将“策略组合”-->动作执行的条件,使模型具有更强的泛化性。
在具有reasoning能力的模型中强调“边界”,比强调“步骤”更重要。
三、系统中的环境
环境有内部的(intrinsic)也有外部的(extranel)。
内部的环境空间:通用知识、记忆、上下文、内在推理空间。
外部的环境空间:模型动作作用的空间,例如一个网页、一堆数据。
Defined by the environment——环境定义了动作空间和状态空间,限制模型的动作。
外部的动作空间:Agent可执行的操作,如点击、悬停
外部的状态空间:例如页面的HTML结构、当前URL等
内部的动作空间:写入、读取、更新记忆或知识
内部的状态空间:知识库、文件、函数工具箱
Fixed by the environment——内部环境空间和外部环境空间都需要给予反馈,这种反馈要是明确的。
不同的人有不同的flavor(风格),我从很早就有一个偏好:我想定义一个基于结果的reward(奖励),而不是基于过程的;而且这个reward应该是基于规则、可计算的,而不是来自人的偏好、模型的偏好,或者一些黑盒指标。
我们做WebShop的时候,最困难的一点是,怎么定义reward。我觉得做任何RL(强化学习)任务最难的不是建环境,而是怎么设计reward。你当然可以把Amazon或Facebook模拟出来,工程上确实很难,但总是可以做。但最难的,是怎么设计一个既有难度,又有实际价值,同时又有一个好的reward的任务。
Reasoning能力
1. Reasoning是什么:是通过自然语言在内部环境里进行推理的过程。潜空间指的是推理的内容和结果在没有实际行动时,不会影响真实世界。另外,推理的边界是无穷的。
2. 为什么需要Reasoning:
总之是,就像射箭一样,没有精确瞄准就射出的箭是没法回头的。
目前用LLM做工具调用时也会出现相似问题:
LBM团队《ToolRM: Outcome Reward Models forTool-Calling Large Language Models》的文章提到:
现有的许多模型在预训练和微调时在做“下一个 token 的似然最大化”。
而调用的时候,JSON、AST参数表是一种全局一致性对象,而LLM的 softmax 是局部贪心(或采样),不保证整体是可执行的函数调用(类型、必填项、单位范围、调用顺序都不在 token 级目标里)。只要偏了一两个 token,工具调用就失效。
函数选择是“类别判别”任务而非生成任务:从N个工具里选1个,本质近似多分类;但 LM 是通过生成函数名字符串完成的,同义相近的名字很容易混淆(get_weather vs weather_lookup)。
槽位填充需要强类型语义:例如 date: ISO8601、currency: USD、count: int>=1,LLM的隐式表示不天然对类型和范围敏感,最容易错在数值、时间、单位转换、ID 引用。
多步推理时,Reasoning-Action的工作方法,使得信息可以在推理和实际行动的结果中不断流动,模型通过行动获取更多信息,获得更好的输出。解决线性的Next Token Prediction机制下存在“说出第一个字就无法更改,只能顺着往下说”情况,因为这种情况可能导致一些探索性的任务失效。
3. PM需要关注的Reasoing设计——根据业务逻辑对思维空间做模块化设计。
Yao在评估思维链颗粒度时,基于思维树做过三个颗粒度的探索尝试和实验,发现以Token思考错误率太高,完整进行思维思考又消耗太高
- Token as Thought:以Token作为一次思考
- Equation as Thought:以方程作为一次思考
- Reasoning as Thought:以单次推理作为一次思考
以coding场景为例,由粗到细可以被分为整个代码内容、单个函数、单个循环逻辑、单行代码、单个Token。
Yao 设计中隐含的训练框架包括:
组合性 :利用思想(例如方程)的模块化特性,从更简单的单元组成复杂的推理,增强法学硕士处理多步骤问题的能力。
评估驱动设计(Evaluation-Driven Design):使用可扩展的评估(详见下一部分)来评估思维树,其中每个节点(思想)都通过基于执行的指标(例如,方程正确性)进行验证。这与 InterCode 等基准测试一致,其中状态变化和输出指导训练。
权衡优化(Tradeoff Optimization):根据任务复杂性调整思想的粒度——生成时粒度细,评估时更粗略——以平衡计算成本和准确性
可拓展性评估指的是一种自动化的、基于执行的评估方法,允许对庞大的任务分布中的Agent表现进行系统、低干预的基准测试。这种可拓展性评估无需人工手工判定和介入,只需要在 Docker 容器上运行就能得到Agent运行任务的结果(往往用成功率、错误率等指标表现)。
为达到这一目标,需要清晰、准确的最终状态判定条件。这要求从业者从终局出发,用规则化、白盒化机制给模型做reward。算数、代码、购买特定商品等任务均有明确的判定条件,是低垂的果实,各家厂商都在跟进,设计了SWE-Bench、GSM-8K等评测集。
目前对 “生成类任务”(无明确标准答案 /ground truth)的评估仍会回到 “无法实现 Automatic reward” 的老问题,这也是后续 agent 评估需要突破的方向。
目前的解决方案:
对常见的主观任务,如情感陪伴、疗愈、职业规划等,用提示词固化主观打分标准,使用模型做Auto Eval,这一能力在各大云平台上均有提供(eg百度云千帆的Auto Prompt和火山引擎的AutoPilot功能)
定义客观指标,比如在生成英文文本时使用不同难度级别单词的比例、生成人物时候
追踪归因到结果上
举一个最近看到的韩瞳老师书中的描述的易拉罐问题作为例子:
我有一个叫“罗比”的机器人,它的世界(用计算机模拟,但是很脏乱)是二维的,到处是丢弃的易拉罐。我将用遗传算法为罗比进化出一个“脑”(即控制策略)。
罗比的工作是清理它的世界中的空易拉罐。罗比的世界由10 × 10的100个格子组成(图9.2)。罗比在位置(0,0)。我们可以假设周围围绕着一堵墙。许多格子中散落着易拉罐(不过每个格子中的易拉罐不会多于一个)。
罗比不是很聪明,看得也不远,他只能看到东南西北相邻的4个格子以及本身所在格子中的情况。格子可以是空的(没有罐子),或者有一个罐子,或者是墙。例如,在图9.2中,罗比位于格子(0,0),看到当前格子是空的,北面和西面是墙,南面的格子是空的,东面的格子中有一个罐子每次清扫工作罗比可以执行200个动作。动作可以是以下7种:往北移动、往南移动、往东移动、往西移动、随机移动、不动、收集罐子。每个动作都会受到奖赏或惩罚。如果罗比所在的格子中有罐子并且收集起来了,就会得到10分的奖赏。如果进行收集罐子的动作而格子中又没有罐子,就会被罚1分。如果撞到了墙,会被罚5分,并弹回原来的格子。
显然,罗比尽可能地多收集罐子,别撞墙,没罐子的时候别去捡,得到的分数就最高。
在随机探索的过程中,罗比可能重复撞墙,PM要做的事情是,制定一些人工规则:如果撞到了右边的墙,下一个动作不应该继续向右。但真实世界中的“墙”很难定义,需要PM的判断,例如商业化场景下的adload上限、统计口径的获取、数据披露的规则、平台内容的导向。