AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


手猫助手Agent技术探索总结
发布日期:2024-06-07 18:35:33 浏览次数: 2126 来源:大淘宝技术



随着LLM的发展,ChatGPT能力不断增强,AI不断有新的概念提出,一种衍生类型的应用AI Agent也借着这股春风开启了一波话题热度,各种初创公司,包括Open AI内部也都在密切关注着AI Agent领域的变化。阿里集团内的AI团队也有很多基于Agent的尝试,Xlangchain和阿里LangEngine有很多Agent的例子,手猫端在过去一年中始关注AI技术动向,不断在手猫端上做面向用户的AI产品尝试,也结合结合Agent技术结合购物组手业务做探索。本文就手猫在探索Agent能力和智能助手业务结合过程、技术侧遇到的问题、想法和实践做简单总结,欢迎大家一起讨论、交流意见。



什么是Agent?

OpenAI应用研究主管Lilian Weng在一篇长文中提出了Agent = LLM(大型语言模型)+记忆+规划技能+工具使用这一概念。AI Agent需要具备感知环境、做出决策并执行适当行动的能力。在这些关键步骤中,最重要的是理解输入给Agent的内容、进行推理、规划、做出准确决策,并将其转化为可执行的原子动作序列,以实现最终目标。

一个精简的Agent决策流程:感知(Perception)→ 规划(Planning)→ 行动(Action)
  • 感知(Perception)是指Agent从环境中收集信息并从中提取相关知识的能力。
  • 规划(Planning)是指Agent为了某一目标而作出的决策过程。
  • 行动(Action)是指基于环境和规划做出的动作。

Agent通过感知从环境中收集信息并提取相关知识。然后通过规划为了达到某个目标做出决策。最后,通过行动基于环境和规划做出具体的动作。Planning是Agent做出行动的核心决策,而行动又为进一步感知提供了观察的前提和基础,形成了一个自主的闭环学习过程。

借用网上的一个案例来解释agent的执行:
    1. 当一个人问Agent是否会下雨时,感知模块将指令转换为LLM可以理解的表示。
    2. 然后,大脑模块开始根据当前天气和互联网上的天气预报进行推理。
    3. 最后,动作模块做出响应,将伞交给人类。
通过重复上述过程,智能体可以不断地获得反馈并与环境进行交互。


在以LLM驱动的Agent系统中,LLM扮演着Agent的大脑角色,并辅以几个关键组件:

  • 规划:LLM能够进行全面的规划,不仅仅是简单的任务拆分。它可以评估不同的路径和策略,制定最佳的行动计划,以实现用户给出的目标。

  • 记忆:可以利用LLM具有的记忆功能,存储和检索过去的信息和经验。这使得它能够在处理用户查询时,利用之前学到的知识和经验,提供更准确和个性化的答案。

  • 工具使用:LLM通过理解工具的描述,来学习使用各种工具和资源,并灵活运用它们来支持任务的完成,在构建Agent的时候可以让Agent感知自己可以使用什么工具。工具的实现可以是利用搜索引擎、数据库、调用API等,获取和整理相关信息,以满足用户的需求。


这里关于Agent不过多介绍,网上关于Agent的文章很多,感兴趣的可以查看这几位大神的文章了解Agent的更多知识:

Agents 能力解密:

https://blog.csdn.net/youyi300200/article/details/132864191

AI Agent到底是什么:

https://zhuanlan.zhihu.com/p/681639504


手猫端智能体业务探索


了解了Agent的概念后,结合手猫在做的智能助手相关探索,PD希望把Agent技术与智能助手业务结合起来做用户侧的创新。PD希望在手猫APP中可以提供一个交互页面,可以使用LLM智能体的自然语言理解能力、思维规划能力、工具使用等能力,直接理解用户输入的需求,然后通过Agent规划能力,决策出实现用户述求的行动路径,并调用智能体对应的工具实现用户需求,最后把结果展示在页面上,解决用户述求。先看做出来的demo版本的视频,再在来介绍整体的思路。

结合下图的工程侧实现方案,串联整个链路大致做了以下几件事情:

  1. 搭建端到LLM直接信息传输链路,完成工程侧业务管理能力建设。

  2. 搭建用户会话管理、多场景识别、链路分发机制。

  3. 完成Agent模版到工具协议串联,把工具抽象化、按照协议“喂”给tpp Agent模版工程,完成Agent的使用工具的动态构建和在线灵活管理。

  4. 完成Agent工具抽象模版化建设以及工具描述的步步调优,提升Agent整体链路规划准确性。

  5. 完成工具&LLM输出到端展示的视图层转换,页面流式协议引入,提升端上输出稳定性。


  端展示方案


Agent方案中,LLM有理解工具描述、区分工具使用场景的能力,可以按照工具的约定,将指定的参数结构化的输入到接口内部,总结下来我们LLM能力解决了人类非结构化语言到工具结构化输入的问题。但是现在手猫APP端页面的展示,都需要转化为非常复杂的结构化数据结构才行,经过测试LLM输出复杂结构化展示数据的稳定性非常的差,面对复杂的页面展示逻辑,至少现在无法达到面向C端用户放开的标准。因为业务产品是无法容忍对线上用户透出内容的不确定性,所以解决LLM非结构化输出到端上结构化数据转化问题,才能解决APP展示端的问题,也是大模型项目能够面向C端用户顺利上线的前题。


为了解决LLM输出非结构化数据到端上展示的问题,我们根据工具实现功能的特性和页面交互特征不同,把工具分类抽象和分别建模(具体可见4-工具类型与定义),根据工具类型与端上约定特定协议,同时把工具的返回做区分,工具返回定义了Object(给LLM消费的内容)和 ViewDTO(app端消费数据结构)两个数据结构,在Agent侧做数据解析,把Object内容输入给LLM做下次ReAct推演,同时把ViewDTO输出到端上展示。在定义工具的展示协议,也抽象化定义了工具异常、模型中断、用户选择等交互模式,实现整体的用户交互方案,详见下图。


工程侧会在视图层,做页面工具数据的解析和转化,具体逻辑大致如下图所示:


首先会在视图层会根据agent执行输出内容,判断整体Agent思维和执行流程是否使用工具,

  1. 如果没有使用工具,会直接返回大模型的输出结果返回到C端做文案展示。

  2. 如果流程使用工具,会解析整个思维链中最后一个工具的返回结果,判断是否有给端上的展示数据结构viewDTO,

  3. 如果有返回viewDTO,使用viewDTO内容展示。

    1. 如果工具没有返回viewDTO,直接使用模型返回文案。


经过上述的逻辑解析,可以覆盖每一个既定场景的端上交互,然后再根据用户下一步的输入或者选择,继续新的一轮交互。


Agent抽象&管理

业务PD做AI技术结合业务场景的尝试时,需要经常做技术可行性尝试,例如需要测试Agent智能体的推理过程是否合理,是否能按照自己的思维路径落地,推理一致性问题等。在基建没有完成之前,资源有限的情况下,如果通过写脚本支持业务反复验证测试、参数调整等,技术成本比较高。体会到AI项目与传统项目落地的差异后,意识到后续不同场景的迭代都会经历这样的过程,提供给产技一个类似大学“实验室”的地方,让他们做自己各种各样的验证,是AI项目落地过程中必不可少的一环,于是就有了搭建Agent实验室的想法,提供给产技做业务探索和提效工具,提高业务迭代效率。


  Agent101实验室


基于自己对AI技术的理解,做数据建模、类型抽象,搭建了自己的AI运维实验室,并不断地完善和补充功能,让AI“实验室”应用到产技日常开发和业务迭代中去,AI实验室设计思路如下图。

搭建Agent实验室,是为了提供给产技快速构建Agent,验证业务想法的测试场地,提供可以组合现有的已有工具,搭属于自己的私有Agent模版的平台,让业务技术快速试错。


Agent实验平台提供能力如下:

  • 提供Agent抽象、管理和测试,每个人都能基于现在的工具快速搭建自己的智能体,做业务场景验证和工具串联验证。类似于你提供一个注入"tool"工具,构建"Agent" Spring bean的方式,可以在页面做Agent调用和能力验证。

Agent管理页面


  • 提供工具定义抽象,工具描述管理、工具类型抽象,让工具管理可视化,实现工具的可视化配置,根据工具功能抽象通用工具、中断器、选择器等工具类型。详见下图。

图-工具管理页面


  • 提供工具接口数据mock等能力,通过Agent测试链路中mock工具返回,实现在没有工具功能实现的前提下,能验证LLM智能ReAct流程对工具的理解和判断,评测Agent是否能达到业务预期,降低业务试错成本。

图-工具数据mock&Agent测试页面

工具类型和定义

  工具分类


Agent可以通过学习调用外部API来获取模型权重中所缺少的额外信息,这些信息包括当前信息、代码执行能力和访问专有信息源等。这对于预训练后难以修改的模型权重来说是非常重要的。


掌握使用工具是人类最独特和重要的特质之一。我们通过创造、修改和利用外部工具来突破我们身体和认知的限制。同样地,我们也可以为语言模型(LLM)提供外部工具来显著提升其能力,LLM可以利用搜索引擎、数据库、API等工具,获取和整理相关信息,以满足用户的需求。


在工具的使用过程中,有必要对工具的类型进行归类使用,确认工具边界后,开发者在定义和使用工具过程中,能更好的根据业务提供更好工具。目前FC部门内部工具的分类,是根据不同工作的作用来划分。目前平台支撑的工具类型有以下分类。

  工具类型定义


工具的类型是以工具的使用特性为标准抽象的,一类工具的定义,会与底层Agent模版工程做协议,Agent模版工程会区分不同的类型,做不同的动作。例如通用工具,Agent会使用通用工具模版,按照工具提供的描述拼接给LLM,LLM规划使用工具时候,Agent模版工程会按照通用工具的协议,执行配置接口/方法的调用,按照返回协议,解析工具返回,给到Agent做Observations:


中断的定义:

中断是指Agent在做规划和调用工具时候的一种行为。Agent执行用户指令的时候,遇到不能继续执行的情况,可以先中止流程的继续执行,需要外部输入或者反馈后,继续后续推理流程的动作。

例如用户需要执行一个订单退款操作,但是在订单查询的时候,查到了多个订单,这个时候需要先中断退款的操作,反馈给用户,让用户选择其中的一个订单继续执行。


  • 通用类型


是否中断

执行Agent执行到通用类型工具的时候,不会中断推理-执行的流程。

通用型工具定义LLM判断需要调用工执行,系统需要执行一段工程化指令来获取答案,并且不会中断ReAct流程的时候,可以使用通用型工具。通用型工具目前支持外调服务(tpp/hsf)来获取答案,也支持调用本地方法来获取结果。

使用场景:业务场景中,需要借助外部工具查询信息、执行操作、逻辑处理等,都可以抽象成通用工具给LLM使用。例如外调订单接口,查询用户的历史订单;外调商家接口,查询商家信息等等。

支持类型:

    • HSF :工程以hsf方式,提供外调服务执行查询、写、等业务定制操作。

    • TPP :工程TPP形式,提供外调服务执行查询、写、等业务定制操作。

    • LOCAL:工程本地方法、JAR包形式,提供定制业务操作。

    • 其他:待扩展类型


  • 中断类型


执行这个类型的工具,会中断ReAct推理过程,等待外部反应或者用户输入,才能继续推理流程。


选择器


是否中断:

执行:Agent执行到选择器类型工具的时候,会中断推理-执行的流程。

选择器定义:工具实现一个集合的输入,让用户做一次选择。

使用场景:在业务实现的过程中,往往会遇见需要用户再次决策的场景,例如让用户选择目标商品集合的一个继续操作,这个时候就需要使用选择器。

支持类型:

    • 订单选择器:如果LLM判断使用一个工具只需要一个订单,而上一个工具查询出多个订单的时候,可以使用订单选择器,让用户确认一个订单,继续继续使用工具做后续流程。

    • 商品选择器:如果LLM判断使用一个工具只需要一个商品,而上一个工具查询出多个商品的时候,可以使用商品选择器,让用户确认一个商品,继续继续使用工具做后续流程。

使用选择器的时候,需要注意前台做样式的适配和定制,目前支持的订单选择器和商品选择器,需要APP端适配展示卡片。


中断器


是否中断:

执行:Agent执行到中断器类型工具的时候,会中断推理-执行的流程。

中断定义:工具实现一个自定义输出,输出可以是一个页面地址或者一个协议地址,让用户做反馈。

使用场景:在业务实现的过程中,会遇见需要用户补充信息的场景,例如盯降级的场景,如果用户没有给出需要盯降价的商品,【盯降价】的工具就无法继续执行,这个时候可以使用中断器,中断流程后,返回盯降价的商品选择页面让用户补充信息,用户盯价商品后,LLM使用【盯降价】工具创建盯价任务。

支持类型:

    • 业务中断器:使用中断器,中断流程,返回页面动作,让用户反馈信息。

使用中断器时候,需要注意中断以后跟端上协议,中断器要配合APP端上动作,才能起到让用户补充信息的作用。


  工具异常定义


正常一个工程接口的返回示例如下:

{"code":200,"success":true,"pageDTO":null,"message":null,"class":"com.alibaba.test.api.response.Result","object":[{"itemId":665788007683,}],"viewDTO":{"sceneName":"showOrder",}}

Agent模版工程解析工具异常路径如下:

  1. 会优先取object字段,如果object字段不为空,直接输出给LLM,做下次ReAct。

  2. 如果object为空,会取message字段输出给LLM做下次ReAct,不会再判断message是否为空。

  3. 目前tools返回异常不会中断ReAct流程,无论是系统异常还是业务异常。


  • 举例1:


如果系统发生异常,直接使用以下方式返回tools结果

return Result.buildFail(-1, "系统异常");
{"code":-1,"success":false,"message":"系统异常","class":"com.alibaba.test.api.response.Result","object":null}


这个时候因为object里没有值,给到LLM的就是:“系统异常”

  • 举例2:


如果业务查询异常,返回了空list,使用以下方式返回tools结果

List<Obejct> list = null;return Result.buildSuccess(list);
{"code":200,"success":true,"class":"com.alibaba.test.api.response.Result","object":[]}


这个时候因为object里有值,给到LLM的就是:"[]"

  • 举例3:


如果业务正常

{"code":200,"success":true,"pageDTO":null,"message":null,"class":"com.alibaba.test.api.response.Result","object":[{"itemId":665788007683,}],"viewDTO":{"sceneName":"showOrder",}}


这个时候因为object里有值,给到LLM的就是:"[{"itemId":665788007683} ]",viewDTO不会给到LLM消费,只是页面展示用。

  • 异常页面展示输出


如果异常想提示给用户,需要把异常按照特定格式设置到ViewDTO中,这样页面才能按照协议展示。最简单的在胶囊展示提示如下,"sceneName":"showError" 这个写死:

{"code":-1,"success":false,"pageDTO":null,"message":"没有权限","class":"com.alibaba.test.api.response.Result","object":null,"viewDTO":{"sceneName":"showError","showTips":"抱歉,你暂时没有权限",}}


Tools工具定义粒度


  粒度的概念


工具定义粒度就是工具实现功能范围的大小,工具实现的功能越多,工具的粒度越大;工具实现的工具越小,工具的粒度越小。例如要实现一个订单退款场景,如果工具定义的粒度大,可以一个工具就实现订单查询+订单退款操作;如果工具定义的粒度小,可以分订单查询工具,订单退款工具。


  工具粒度大小的优劣


工具定义粒度的大小,会影响到很多因素。Agent是ReAct(Thought-Action-Observation)的模式,工具使用的多,就意味着多轮的ReAct,会让执行链路变得更长,消耗更多的RT.

工具粒度

优势

劣势

   大

1、减少执行轮次,整体RT会变短。
2、更多的是逻辑代码执行,LLM执行的准确度会变高。
3、工具粒度越大,整体的工具量会变少,减少LLM消费的Token数,单次执行时间会变小。
1、业务灵活度变差,多种场景的情况下,工具复用性比较差。
2、单个工具执行RT会变长。
3、单工具业务复杂度变高。

   小

1、业务领活度更高,LLM可以根据工具的组合,实现更多的功能。
2、单个工具执行RT变小。
3、单工具业务复杂度变小,原子性更强。
1、Agent执行轮次变多,整体复杂度变高,业务执行链路变长,RT变长。
2、整体复杂度变高,LLM执行准确度下降
3、整体工具变多,LLM消费Token数变多,单次执行RT变长。

  工具实现安全的思考


开发者在实现LLM调用的工具时候,一定要注意接口的安全策略,应用工具的调用者是LLM,使用过程会比一般的程序开发者更加“开放”,无法预知LLM使用工具的前置条件,所以在工具实现的时候,要更加谨慎和保守,前置校验也需要更规范。建议如下:

  • 参数透传:安全级别比较高的参数,一定要使用系统层透传,不要让LLM设定传入参数,防止LLM“臆造”、“篡改”,例如用户id,设备id等参数,影响代码稳定性和数据安全。

  • 代码防腐层:建议设计代码防腐层,用来隔离LLM传入参数和下游调用参数。

  • 参数合法性校验:对于比较关键的参数,一定要校验合法性,例如订单号一定是数字,位数在10位以上等,防止LLM“臆造”的参数对下游系统造成影响。

  • 数据状态校验:对应执行类工具(存在写操作的实现),执行前一定要对数据状态进行校验,防止非法操作存在。

  • 接口幂等:LLM在ReAct流程中可能会重复执行接口,对于幂等要求比较高的操作,设计时候要考虑接口幂等性。

  • 多阶段事务:对于业务比较复杂的场景,尽量保证事务操作在一个工具内实现,防止跨工具事务的工具实现。


问题&总结

项目上线和迭代的过程中,遇见的问题也特别多,大致总结如下:

  • 面向C端的AI创新,对于结果的正确率要求很高,经过对底层模型针对场景的语料的需求和评测,正确率提示至80+%,但是对于面向C端全面开发还有很长的路要走。

  • 大模型解决了用户输入的自然语言到底层工具结构化输入的转化,但是大模型直接输出到端上的结构化展示错误率比较高,直接透出给用户风险比较大,目前只能依赖工具的结构化输出做页面展示,缺点是失去输出内容展示的灵活性。

  • 随着智能体中工具的数量增加,智能体对工具的理解和组合会变得不稳定,影响特定场景的正确率,固定Agent和多Agent方案应该是未来的方向,但是要解决Agent智能体分发的问题。

  • LLM对工具的返回复杂度有要求,不能返回太复杂的对象,入参也不能过于复杂,否则成功率会降低。


感谢项目组的人员一起学习排解难题、落地思路,虽然在项目的过程中遇见很多问题,但是探索的过程中积累了很多项目经验,毕竟“书上得来终觉浅”,要知Agent要躬行。另外也要感谢阿里巴巴集团提供的大量学习平台,让我们在学习和接触AI新技术的过程更加方便快捷,集团内技术平台和框架的推出,给业务创新屏蔽了底层技术细节,为上层业务快速落地打下基础。也希望随着AI技术的越来越成熟,未来阿里巴巴能有更好结合C端的场景落地服务于用户。




53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询