技术

LLM工作流编排 Python虚拟机 LLM工作流编排 Python实践 下一个平台Agent 激发LLM涌现——提示工程 LLM微调理论及实践 大佬沉思 LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 LLM部分技术源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办? 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 容器日志采集 Kubernetes 控制器模型 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

大模型推理服务框架 模型服务化(未完成) 大模型RHLF 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 LLM工具栈 ddd从理念到代码 如何应用LLM 小鼠如何驾驭大象(LLM)? 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 helm tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 机器学习中的python调用c 机器学习训练框架概述 embedding的原理及实践 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 tensorflow学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 helm 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? Kubernetes events学习及应用 CRI 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时,我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

下一个平台Agent

2023年10月30日

简介

2023.3.13:当前的agent把nlp的门槛降低了,很多普通程序猿借助llm 也可以做一些之前只能由nlp 算法可以做的事儿。 大多本质上还是个路由器,以及固定了分析流程,区别是以前很多流程固定在代码里,现在是很多分析、逻辑固定在prompt里。虽然llm 是通用的,这些流程仍然是case by case的,比如基于100个api 组合起来 可以干200个活儿,现在的agent 还是做不到根据问题自动分析、拆解。

比尔·盖茨:AI Agent将彻底改变人类生活方式尽管软件在过去几十年里取得了显著的进步,但是,从很多方面来看,它依然有些 “笨拙”。在计算机上完成任务时,你需要告诉设备使用哪个应用程序。例如,你可以用微软 Word 和谷歌文档撰写商业提案,但它们无法帮你发送邮件、分享自拍、分析数据、策划派对或购买电影票。即便是最优秀的网站,也只能片面地了解你的工作、个人生活、兴趣及人际关系,在利用这些信息来为你服务方面能力有限。但在未来五年内,这一切将彻底改变。你不再需要针对不同的任务使用不同的应用。你只需用日常语言告诉你的设备你想要做什么,软件将能够根据你愿意分享的信息量做出个性化的回应,因为它将深入理解你的生活。在不远的将来,任何联网的人都将能夠拥有一个由 AI 驱动的个人助理,其能力将远超现今的技术水平。这种能够理解自然语言并根据对用户的了解来完成多种任务的软件,被称为 “Agent”。PS:各个app 不再直面用户,而是通过接入Agent,由Agent来完成和用户之间的交互,Agent 将成为下一个平台。具象化一下,就是钢铁侠中的Javis。

简单使用LLM 是不够的

目前的大模型一般都存在知识过时、逻辑计算能力低等问题,通过Agent访问工具,可以去解决这些问题。Agent是指能够感知环境、做出决策和采取行动的实体。本质上还是prompt工程,通过Prompt去驱动模型进行 计划和工具调用。PS:你知道一个工具的存在,约等于你会调用这个工具;你会调用这个工具,约等于你会学习使用这个工具;会学习这个工具,约等于你已经会用这个工具;所以,你知道工具的存在,约等于你能把这件事做出来。搜索高于学习, 学习高于熟练

ChatGPT、DALL-E 3 或 Midjourney 等工具使用基于提示的界面进行人机交互。这意味着您需要用自然语言编写一组指令(通常随后进行大量的重复提示尝试)才能获得有意义的响应。考虑到人工智能模型的能力,它的速度很慢,而且违反直觉。我们需要更好、更有效的方式来与人工智能交互。人工智能体(AI Agent),扮演着AI监工的角色。它们以自我导向的循环方式工作,为人工智能设置任务、确定优先级和重新确定任务的优先级,直到完成总体目标。PS:仅靠LLM 还是不够

Agent在LangChain框架中负责决策制定以及工具组的串联,可以根据用户的输入决定调用哪个工具。通过精心制定的提示,我们能够赋予代理特定的身份、专业知识、行为方式和目标。提示策略为 Agent 提供了预设模板,结合关键的指示、情境和参数来得到 Agent 所需的响应。具体的说,Agent就是将大模型进行封装来简化用户使用,根据用户的输入,理解用户的相应意图,通过action字段选用对应的Tool,并将action_input作为Tool的入参,来处理用户的请求。当我们不清楚用户意图的时候,由Agent来决定使用哪些工具实现用户的需求。

吴恩达:目前,我们使用大语言模型的主要方式是一种non-agentic工作流程,即您输入一个提示,模型就生成一个回答。这有点像让一个人坐下来一次性从头到尾编写一篇文章,而不允许使用退格键,尽管这样做很难,但大语言模型的表现出奇地出色。相比之下,代理工作流程看起来是这样的:首先,让人工智能大语言模型写一个文章大纲,如果需要进行网络研究就先做研究,然后写出第一稿,然后阅读并思考需要修订的部分,再修改这一稿,如此循环往复、迭代多次。很多人没有意识到,这种做法可以带来显著的改进效果。我自己在使用这些代理工作流程时也感到非常惊讶,它们工作得如此之好。研究发现,GPT-3.5使用零样本提示时只有48%的正确率,GPT-4提高到了67%。但如果在GPT-3.5上使用一个代理工作流程,它的表现实际上比GPT-4还要好。如果在GPT-4上使用代理工作流程,它的表现也非常出色。这意味着采用代理工作流程对于构建应用程序至关重要。不过我们需要改变一种习惯,那就是习惯了在提示语言模型后立即获得响应。在代理工作流程中,我们需要学会能够耐心等待几分钟甚至几个小时,才能得到响应,就像我们交代任务给人时需要适当地等待一段时间再进行检查一样。

Agent不只是一个工具

万字长文:第一性原理看大模型Agent 未读完

  1. 一开始大家玩 Prompt 工程(把大模型当做工具来调用,工具模式),接着是Prompt Chain或Flow,再到Agent,多Agent,很清晰的一个脉络架构
  2. 我们回到 Agent 这个概念上,实际上,人类是这个星球上最强大的 Agent。Agent是一个能感知并自主地采取行动的实体,这里的自主性极其关键,Agent要能够实现设定的目标,其中包括具备学习和获取知识的能力以提高自身性能。Agent 的复杂程度各不相同,一个简单的恒温器可以是一个 Agent,一个大型的国家或者一个生物群体也可能是个 Agent。感知环境、自主决策、具备行动能力,设定明确的目标和任务,适应环境及学习能力,都是 Agent 的关键特点
  3. 我们认为Agent技术是未来实现社会全面自动化的关键技术。在大模型出现之前,自动化更多的是一些偏结构化固定模式环境中通过实现固定算法流程来完成自动化任务,而大模型智能体的通用性带来了灵活性,使其可能应对人类在脑力劳动中面临的各种复杂长尾任务,进一步实现体力和脑力任务的全面自动化。PS:LLM本质是文字接龙,看你让大模型接什么,如果使用大模型接出来的东西。有点一生二、二生三、三生万物的意思,就好像无论汽油机、还是电动机,基本的动力输出形式是转圈圈,但是经过一些机械传导,可以转为各种机械运动形式:水平、垂直(打夯机)、椭圆运动等等,简单机械运动组合起来可以进行复杂机械运动比如纺织机,进而推动了大部分手工劳动的自动化。
  4. 在通用人工智能(AGI)的漫长旅途中,大模型虽显强大,仍存在着显著的技术天花板。许多人开始探索如何挖掘大模型在大任务执行能力上的可能性,其中一个基本策略就是能够分解和组合。例如,经典的 MapReduce 模式可以将一个大型文本进行摘要,因为它的上下文有限,一种解决办法是扩大 context 的范围。另一个解决方案是,在有限的 context 中,我们先将文本拆分成小片段,对每个片段进行摘要,然后再将其组合,从而得出结果。大家也发现大模型直接给出答案似乎并不靠谱,那么是否可以让它像人类一样,一步一步思考呢?毕竟,人类在解决问题时,也是逐渐构建解决方案,而并非立即给出答案。因此,开始出现了一系列的尝试解法,比如思维链、多思维链、思维树和思维图等。上述的讨论主要是任务分解和组合,他们尽管强大,却不能与外界进行互动,这就不得不讲到反馈机制了。反馈是整个控制论的基石,也是动物体从诞生之初就具备的基本能力。最经典的方法实际就是 ReACT,ReACT让大模型先进行思考,思考完再进行行动,然后根据行动的结果再进行观察,再进行思考,这样一步一步循环下去。这种行为模式基本上就是人类这样的智能体主要模式。
  5. 众人熟知的认知飞轮,感知、认知、决策、行动,今天的人工智能代理更像是基于这个认知飞轮构建的。但是从本质上,人类智能远比这复杂。
  6. 智能究竟是什么?人类对世界进行建模,把世界以实体、关系、属性描绘出来。然而,这也是我们认知的极限,我们只能理解一个对象化的世界,非对象化的世界我们无法理解。比如,当我们探索量子的时候,我们还常常用对事物进行对象化的方式去理解,但是发现我们的理解力有时候是有限的,因为量子世界的真相超出了人类认知能力的范围,我们智能使用低维空间的投影去推断它,就像我们无法在三维世界去想象十一维世界的样子。
  7. 其实在大模型Agent技术出现之前,人们就已经意识到,试图集成各种深度学习模型以实现人工普遍智能(AGI)并不够,还需要更高层次的认知模型。Agent都必须对世界有准确的理解才能做出正确的决策。当模型不能正确运行时,决策就会出错;只有当世界模型构建的正确,才能选择正确的模型,进而做出正确的决策。
  8. 今天计算机领域的工程实践中,人们更多采用的是面向过程架构,无论是接口、函数、UI界面,还是组件,又或者是一个应用程序,都是以接口的形式存在的。而这个接口实质上是一种被调用的子流程,借此过程的完成,我们希望执行结果符合我们的预期,但程序并不为结果负责。它解决的是过程和流程问题,系统内没有目标的概念。当然,也存在一些以目标导向为核心理念的的软件工程,例如声明式编程,它只需要你描述你想要什么,而无需关心执行的过程,像HTML和SQL便是其经典例子。在这样的架构下,程序能够自行寻找达成目标的方法。然而问题在于,这种面向目标的架构只能应用于垂直领域,而无法普遍应用到所有领域,只有在特定的领域内才能发挥作用,这就限制了它的应用范围。总的来说,尽管面向目标架构在计算机领域有一席之地,但由于其只能在特定领域发挥作用,而无法解决所有领域的问题,因此它的应用还是有所限制,更多出现在特定的DSL(领域特定语言)中,这种架构的确也发挥了巨大的作用。在软件工程的范式迁移中,我们发现面向过程架构与面向目标架构之间的重要区别点:随着人类的生产方式的变化,软件工程可能正逐步演化为智能体工程(Agent Engineering);以前我们主导的生产方式是人类处于中心位,AI做辅助。而未来可能会变成以 AI 为中心,人类变为辅助。由此,整个产品形态和平台的构成可能会发生这样的转变。

AgentLM:能打的 Agent 模型来了!开源模型并非没有完成智能体任务的能力,可能只是在智能体任务上缺乏对齐。对于 Agent 能力提升的策略,现有许多工作多使用 Prompt / 微调方法优化模型,在单项智能体任务上取得了卓越的表现,但智能体任务之间的促进及泛化效果有待进一步探索。智谱AI&清华KEG提出了一种对齐 Agent 能力的微调方法 AgentTuning,该方法使用少量数据微调已有模型,显著激发了模型的 Agent能力,同时可以保持模型原有的通用能力。AgentTuning 主要包括 2 个阶段。首先,我们收集并过滤得到一个多任务指令微调数据集 AgentInstrcut;然后,我们将 AgentInstruct 数据集与通用数据对模型进行混合微调。评估结果表明,AgentTuning 能让 LLM 的 Agent 能力在未见过的 Agent 任务中展现出强大的泛化,同时保持良好的通用语言能力。AgentInstruct 是一个经过筛选的智能体任务数据集。其包含 6 项智能体任务,从 Shell 交互到数据库操作,平均回合数从 5 到 35 不等,每条轨迹都有 ReAct 形式的 CoT 标注,帮助模型深入理解决策过程。PS: 大家发现Agent/react 有用,就微调LLM强化这方面的能力。

企业AI智能体、数字化与行业分工现代企业是由人和机器组成的。

  1. 人:负责完成复杂的、具有不确定性的任务。人是一种高度智能化的智能体。
  2. 机器(蓝色方形节点):负责完成简单的、确定性的任务。包括软件、设备等,属于工具。 于是,在这两类节点之间,就产生了三种关系:
  3. 人与人之间:沟通关系。为了完成企业的目标,企业内部的人和人之间需要通过沟通的方式来协作。可能是小团队内紧密的team work,也可能是跨团队之间的沟通,或者是上下级之间的沟通。
  4. 人与机器之间:人机交互。人和机器之间需要通过产品界面来交互。
  5. 机器与机器之间:API。机器与机器之间通过API调用来协作,它们之间沟通所使用的,属于机器语言。 人是智能体,机器是工具。AI智能体加入进来以后,它兼具智能体和工具两种属性:
  6. 半智能体:可以提供知识,且是海量的知识。
  7. 半工具:可以自动化调用真正的工具。甚至,现在以大模型为基础的AI智能体,还能将一定程度的规划工作也自动化掉。 AI智能体可能扮演三种角色:
  8. AI-0:直接参与业务流程自动化。作为自动化流程中的一个节点,完成以前只能由人完成的工作。需要与企业数据对接。场景举例:从文档中批量抽取信息;文档批量翻译;批量的数据挖掘、预测等。
  9. AI-1:作为提供知识的Copilot。不直接面向企业的业绩目标,作为人的辅助。需要与人频繁交互,通常以Chat的形式。不需要与企业数据对接。场景:知识问答、总结、文段翻译、数据可视化分析、公开文献阅读、写报告、画图表、写代码,以及其它的各种创作性任务,等等。ChatGPT承担的主要就是这种角色。
  10. AI-2:作为新型的人机交互接口。提供更自然的交互界面,主要也是Chat的形式。需要与企业数据对接。这一角色承担的任务可大可小。可以是简单的企业私有文档问答,用于替代传统的文档检索;也可以具备非常复杂的逻辑,成为企业大脑,驱动人机协作更有效率。场景:企业私域问答;用自然语言执行命令,查询企业内部数据,驱动自动化流程编排,等等。 理想的AI智能体产品形态,应该是AI-1和AI-2相结合的。用户既能从AI智能体获取企业外部的海量知识和专业数据,又能通过它与背后的企业内部数据或软件工具交互,让更多的工作由AI来完成。

下一代智能体发展的三大关键领域:规划、用户体验和记忆。

  1. 规划是指 AI 智能体能够预先考虑多个步骤,并确定最佳行动方案的能力。目前,语言模型的规划能力还比较有限,主要依靠以下两种方法来加强:
    1. 外部提示策略:开发者通过设计特定的提示,引导语言模型进行规划。例如,可以要求模型在执行每个步骤之前,先列出所有可能的步骤并进行评估。
    2. 流程工程:通过设计预定义的流程图或状态机,将任务分解成多个步骤,并明确每个步骤的执行条件和顺序。这可以帮助语言模型更好地理解任务,并做出更合理的规划。 未来,随着语言模型能力的提升,它们或许能够自主进行更有效的规划,而不再需要外部提示或流程工程的辅助。
  2. 目前,AI 智能体的用户体验仍有许多需要改进的地方,例如:
    1. 可靠性不足:由于语言模型的局限性,AI 智能体有时会犯错或无法理解用户的指令。这可能会导致用户感到沮丧和困惑。
    2. 可控性不足:用户往往无法完全控制 AI 智能体的行为,这可能会导致一些意外的后果。
    3. 缺乏个性化:现有的 AI 智能体大多缺乏个性化,无法根据用户的特定需求和偏好进行调整。
  3. 记忆是指 AI 智能体存储和使用信息的能力。记忆对于 AI 智能体完成各种任务都至关重要,例如:
    1. 程序记忆:记忆如何正确地执行任务,例如如何预订机票或如何撰写电子邮件。
    2. 个性化记忆:记忆与特定用户相关的信息,例如用户的姓名、喜好、经历等。 目前,AI 智能体的记忆功能还比较简单,主要依靠以下两种方式实现:存储在数据库中:将信息存储在外部数据库中,并在需要时进行检索。嵌入语言模型中:将信息嵌入语言模型的参数中,使模型能够在生成文本时使用这些信息。

规划与COT

从 CoT 到 Agent,最全综述来了

  1. 什么是“语言智能”?语言智能可以被理解为“使用基于自然语言的概念对经验事物进行‘理解’以及在概念之间进行‘推理’的能力”,随着参数量的飞升,以 Transformer 为基础架构的大规模语言模型以 “Chat” 的方式逐渐向人们展现出了它的概念理解与概念推理的能力。直观上,作为“语言模型”的大模型具备概念理解能力并不难理解,但是仅仅像 Word2vec 一样只能得到“国王”与“男人”的“距离”更近的结论对于语言智能而言必然远远不够。真正引发人们对大模型逼近“语言智能”无限遐想的,在于大模型展现出的概念推理能力。推理,一般指根据几个已知的前提推导得出新的结论的过程,区别于理解,推理一般是一个“多步骤”的过程,推理的过程可以形成非常必要的“中间概念”,这些中间概念将辅助复杂问题的求解。
  2. 2022 年,在 Google 发布的论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中首次提出,通过让大模型逐步参与将一个复杂问题分解为一步一步的子问题并依次进行求解的过程可以显著提升大模型的性能。而这一系列推理的中间步骤就被称为思维链(Chain of Thought)。区别于传统的 Prompt 从输入直接到输出的映射 <input——>output> 的方式,CoT 完成了从输入到思维链再到输出的映射,即 <input——>reasoning chain——>output>。如果将使用 CoT 的 Prompt 进行分解,可以更加详细的观察到 CoT 的工作流程。
  3. 在许多 Agent 需要处理的任务中,Agent 的“先天知识”并不包含解决任务的直接答案,因此 Agent 需要在一系列与外部环境的交互循环中,制定计划,做出决策,执行行动,收到反馈……在一整个计划、决策与控制的循环中,大模型需要具备“感知”,“记忆”与“推理”的能力。无论是环境的反馈,还是人类的指令,Agent 都需要完成一个对接收到的信息进行“理解”,并依据得到的理解进行意图识别,转化为下一步任务的过程。而使用 CoT 可以大大帮助模型对现有输入进行“感知”,譬如,通过使用“Answer: Let’s think step by step. I see $$, I need to …”的 Prompt,可以让模型逐步关注接收到的信息,对信息进行更好的理解。

一篇大模型Agent工具使用全面研究综述任务规划的方法:

  1. 无需调整的方法(Tuning-free Methods):利用LLMs的内在能力,通过少量示例或零示例提示来实现任务规划。例如,使用CoT(Chain of Thought)或ReACT等框架来引导LLMs逐步思考和规划。
  2. 基于调整的方法(Tuning-based Methods):通过在特定任务上微调LLMs来提高任务规划能力。例如,Toolformer等方法通过微调来增强LLMs对工具使用的意识和能力。

工具选择的分类:

  1. 基于检索器的工具选择(Retriever-based Tool Selection):当工具库庞大时,使用检索器(如TF-IDF、BM25等)来从大量工具中检索出与子问题最相关的前K个工具。这种方法侧重于通过关键词匹配和语义相似性来快速缩小工具选择范围。
  2. 基于LLM的工具选择(LLM-based Tool Selection):当工具数量有限或者在检索阶段已经缩小了工具范围时,可以直接将工具描述和参数列表与用户查询一起提供给LLM。

工具选择的方法:

  1. 无需调整的方法(Tuning-free Methods):利用LLMs的上下文学习能力,通过策略性提示来增强工具选择能力。例如,通过链式思维(Chain of Thought)或ReACT框架来引导LLMs进行推理和行动。
  2. 基于调整的方法(Tuning-based Methods):通过在工具学习数据集上微调LLMs的参数来提高工具选择的能力。

工具学习范式:

  1. 一步任务解决,这种范式涉及到在收到用户问题后,LLMs立即分析用户请求,理解用户意图,并规划出所有需要的子任务来解决问题。在这个过程中,LLMs会直接生成一个基于选定工具返回结果的响应,而不会考虑过程中可能出现的错误或根据工具的反馈调整计划。
  2. 这种范式允许LLMs与工具进行迭代交互,不预先承诺一个完整的任务计划。相反,它允许基于工具的反馈逐步调整子任务,使LLMs能够一步步地解决问题,并根据工具返回的结果不断完善计划。这种方法增强了LLMs的问题解决能力,因为它允许模型在响应工具反馈时进行适应和学习。

工具调用的步骤:

  1. 参数提取:LLMs必须能够从用户查询中提取出符合工具描述中指定格式的参数。
  2. 调用工具:使用提取的参数向工具服务器发送请求,并接收响应。

现有方案如CoT和基于分解的提示,都有擅长的任务类型,适合作为独立的原子模块,不具有普适性;大模型自动推理?谷歌等发布SELF-DISCOVER!

使用

自定义tool 实现

from langchain.tools import BaseTool

# 天气查询工具 ,无论查询什么都返回Sunny
class WeatherTool(BaseTool):
    name = "Weather"
    description = "useful for When you want to know about the weather"
    def _run(self, query: str) -> str:
        return "Sunny^_^"
    async def _arun(self, query: str) -> str:
        """Use the tool asynchronously."""
        raise NotImplementedError("BingSearchRun does not support async")

# 计算工具,暂且写死返回3
class CustomCalculatorTool(BaseTool):
    name = "Calculator"
    description = "useful for when you need to answer questions about math."
    def _run(self, query: str) -> str:
        return "3"
    async def _arun(self, query: str) -> str:
        raise NotImplementedError("BingSearchRun does not support async")

# 这里使用OpenAI temperature=0,temperature越大表示灵活度越高,输出的格式可能越不满足我们规定的输出格式,因此此处设置为0
llm = OpenAI(temperature=0)
tools = [WeatherTool(), CalculatorTool()]
agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True)
agent.run("Query the weather of this week,And How old will I be in ten years? This year I am 28")
# 执行结果
I need to use two different tools to answer this question
Action: Weather
Action Input: This week
Observation: Sunny^_^
Thought: I need to use a calculator to answer the second part of the question
Action: Calculator
Action Input: 28 + 10
Observation: 3
Thought: I now know the final answer
Final Answer: This week will be sunny and in ten years I will be 38.

LangChain Agent中,内部是一套问题模板(langchain-ai/langchain/libs/langchain/langchain/agents/chat/prompt.py):

PREFIX = """Answer the following questions as best you can. You have access to the following tools:"""
FORMAT_INSTRUCTIONS = """Use the following format:

Question: the input question you must answer
Thought: you should always think about what to do
Action: the action to take, should be one of [{tool_names}]
Action Input: the input to the action
Observation: the result of the action
... (this Thought/Action/Action Input/Observation can repeat N times)
Thought: I now know the final answer
Final Answer: the final answer to the original input question"""
SUFFIX = """Begin!

Question: {input}
Thought:{agent_scratchpad}"""

这个提示词就是 Agent 之所以能够趋动大模型,进行思考 - 行动 - 观察行动结果 - 再思考 - 再行动 - 再观察这个循环的核心秘密。有了这样的提示词,模型就会不停地思考、行动,直到模型判断出问题已经解决,给出最终答案,跳出循环。

通过这个模板,加上我们的问题以及自定义的工具,会变成下面这个样子(# 后面是增加的注释)

Answer the following questions as best you can.  You have access to the following tools: #  尽可能的去回答以下问题,你可以使用以下的工具:

Calculator: Useful for when you need to answer questions about math.
 # 计算器:当你需要回答数学计算的时候可以用到
Weather: useful for When you want to know about the weather #  天气:当你想知道天气相关的问题时可以用到
Use the following format: # 请使用以下格式(回答)

Question: the input question you must answer #  你必须回答输入的问题
Thought: you should always think about what to do
 # 你应该一直保持思考,思考要怎么解决问题
Action: the action to take, should be one of [Calculator, Weather] #  你应该采取[计算器,天气]之一
Action Input: the input to the action #  动作的输入
Observation: the result of the action # 动作的结果
...  (this Thought/Action/Action Input/Observation can repeat N times) # 思考-行动-输入-输出 的循环可以重复N次
Thought: I now know the final answer # 最后,你应该知道最终结果了
Final Answer: the final answer to the original input question # 针对于原始问题,输出最终结果


Begin! # 开始
Question: Query the weather of this week,And How old will I be in ten years?  This year I am 28 #  问输入的问题
Thought:

我们首先告诉 LLM 它可以使用的工具,在此之后,定义了一个示例格式,它遵循 Question(来自用户)、Thought(思考)、Action(动作)、Action Input(动作输入)、Observation(观察结果)的流程 - 并重复这个流程直到达到 Final Answer(最终答案)。如果仅仅是这样,openai会完全补完你的回答,中间无法插入任何内容。因此LangChain使用OpenAI的stop参数,截断了AI当前对话。"stop": ["\nObservation: ", "\n\tObservation: "]。做了以上设定以后,OpenAI仅仅会给到Action和 Action Input两个内容就被stop停止。以下是OpenAI的响应内容:

I need to use the weather tool to answer the first part of the question, and the calculator to answer the second part.
Action: Weather
Action Input: This week

这里从Tools中找到name=Weather的工具,然后再将This Week传入方法。具体业务处理看详细情况。这里仅返回Sunny。 由于当前找到了Action和Action Input。 代表OpenAI认定当前任务链并没有结束。因此向tool请求后拼接结果:Observation: Sunny 并且让他再次思考Thought。开启第二轮思考:下面是再次请求的完整请求体:

Answer the following questions as best you can. You have access to the following tools:

Calculator: Useful for when you need to answer questions about math.
Weather: useful for When you want to know about the weather


Use the following format:

Question: the input question you must answer
Thought: you should always think about what to do
Action: the action to take, should be one of [Calculator, Weather]
Action Input: the input to the action
Observation: the result of the action
... (this Thought/Action/Action Input/Observation can repeat N times)
Thought: I now know the final answer
Final Answer: the final answer to the original input question

Begin!

Question: Query the weather of this week,And How old will I be in ten years? This year I am 28
Thought: I need to use the weather tool to answer the first part of the question, and the calculator to answer the second part.
Action: Weather
Action Input: This week
Observation: Sunny^_^
Thought:

同第一轮一样,OpenAI再次进行思考,并且返回Action 和 Action Input 后,再次被早停。

I need to calculate my age in ten years
Action: Calculator
Action Input: 28 + 10

由于计算器工具只会返回3,结果会拼接出一个错误的结果,构造成了一个新的请求体进行第三轮请求:

Answer the following questions as best you can. You have access to the following tools:

Calculator: Useful for when you need to answer questions about math.
Weather: useful for When you want to know about the weather


Use the following format:

Question: the input question you must answer
Thought: you should always think about what to do
Action: the action to take, should be one of [Calculator, Weather]
Action Input: the input to the action
Observation: the result of the action
... (this Thought/Action/Action Input/Observation can repeat N times)
Thought: I now know the final answer
Final Answer: the final answer to the original input question

Begin!

Question: Query the weather of this week,And How old will I be in ten years? This year I am 28
Thought: I need to use the weather tool to answer the first part of the question, and the calculator to answer the second part.
Action: Weather
Action Input: This week
Observation: Sunny^_^
Thought:I need to calculate my age in ten years
Action: Calculator
Action Input: 28 + 10
Observation: 38
Thought:

此时两个问题全都拿到了结果,根据开头的限定,OpenAi在完全拿到结果以后会返回I now know the final answer。并且根据完整上下文。把多个结果进行归纳总结:下面是完整的相应结果:

I now know the final answer
Final Answer: I will be 38 in ten years and the weather this week is sunny.

可以看到。ai严格的按照设定返回想要的内容,并且还以外的把28+10=3这个数学错误给改正了。通过 verbose=True 可以动态查看上述过程。 PS: 通过prompt 引导llm 进行文字接龙,通过解析文字接龙来进行tool 的调用。

根据输出再回头看agent的官方解释:An Agent is a wrapper around a model, which takes in user input and returns a response corresponding to an “action” to take and a corresponding “action input”. 本质上是通过和大模型的多轮对话交互来实现的(对比常规聊天时的一问一答/单轮对话), 不断重复“Action+ Input -> 结果 -> 下一个想法”,一直到找到最终答案。通过特定的提示词引导LLM模型以固定格式来回复,LLM模型回复完毕后,解析回复,这样就获得了要执行哪个tool,以及tool的参数。然后就可以去调tool了,调完把结果拼到prompt中,然后再让LLM模型根据调用结果去总结并回答用户的问题。

大多数 Agent 主要是在某种循环中运行 LLM。目前,我们使用的唯一方法是 AgentExecutor。我们为 AgentExecutor 添加了许多参数和功能,但它仍然只是运行循环的一种方式。langgraph是一个新的库,旨在创建语言 Agent 的图形表示。这将使用户能够创建更加定制化的循环行为。用户可以定义明确的规划步骤、反思步骤,或者轻松设置优先调用某个特定工具。

原理

在 Agent 应用的开发和实践中,核心挑战之一是如何优雅地实现一个可控的循环(Loop)机制。这个循环机制不仅需要能够自动化地执行任务,还要能够在执行过程中根据反馈进行自我调整和优化(Loop+Feedback )。通过这种方式,LLM 能够模仿人类解决问题的基本方法论,如 PDCA(计划-执行-检查-行动)循环,从而更有效地拆解和解决问题。

认知框架Cognitive Architecture

AgentType 对应一个Agent class,对应一个prompt(又是prompt 起了关键作用),AgentType 有以下几种选择

  1. zero-shot ReAct,完全依靠对所用到的tools 的说明书来理解和使用tools,理论上支持无限多个。
  2. Structured tool chat,跟第一个不同的地方在于接收一个结构化的dict 作为参数且能记住上下文。
  3. OpenAI functions,OpenAI 在大模型层面针对 API的调用做了训练,相当于帮大家做了SFT,可以想象效果必然好。
  4. conversational,类似于第一、二类型,针对对话场景做了优化,比如聊天记录、聊天轮次等meta-data
  5. self-ask,通过自问自答的方式把大问题拆解成小问题之后再组成最终的单子。

ReAct是 Shunyu Yao 等人在 ICLR 2023 会议论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出的,一个关键启发在于:大语言模型可以通过生成推理痕迹和任务特定行动来实现更大的协同作用。具体来说,就是引导模型生成一个任务解决轨迹:观察环境 - 进行思考 - 采取行动,也就是观察 - 思考 - 行动。那么,再进一步进行简化,就变成了推理 - 行动,是一种将推理和行动相结合的思考链模式(PS:知行合一?),以交错的方式产生与任务相关的语言推理轨迹和行动。ReAct 框架会提示 LLMs 为任务生成推理轨迹和操作,这使得代理能系统地执行动态推理来创建、维护和调整操作计划,同时还支持与外部环境(例如 Google 搜索、Wikipedia)的交互,以将额外信息合并到推理中。PS:使用LLM来做ifelse,ReAct提示大型语言模型为给定任务生成口头推理历史步骤和操作。这些提示由少量的上下文示例组成,这些示例指导模型的思考和操作生成。

与CoT推理一样,ReAct 也是一种提示工程方法,它使用少量学习来教模型如何解决问题。CoT 被认为是模仿人类如何思考问题,ReAct 也包括了这个推理元素,但它更进一步,允许Agent操作文本,让它与环境互动。人类使用语言推理来帮助我们制定策略并记住事情,但也可以采取行动来获得更多的信息并实现目标。这就是 ReAct 的基础(PS:知行合一?)。ReAct 提示包括行动的例子、通过行动获得的观察结果,以及人类在过程中各个步骤中转录的思想(推理策略)。LLM 学习模仿这种交叉思考和行动的方法,使其成为其环境中的Agent。

一定要记住,观察结果不是由 LLM 生成的,而是由环境生成的,环境是一个单独的模块,LLM 只能通过特定的文本操作与之交互。因此,为了实现 ReAct,需要:

  1. 一种环境,它采取一个文本操作, 从一组可以根据环境的内部状态改变的潜在操作中返回一个文本观察。
  2. 一个输出解析器框架,一旦Agent编写了一个有效的操作,它就停止生成文本,在环境中执行该操作,并返回观察结果, 一般是将其追加到目前生成的文本中,并用该结果提示 LLM。
  3. 人工产生的示例,混合了思想,行动和观察,在环境中可以使用few-shot,例子的数量和细节取决于目标和开发者的设计

ReAct Agent 的一般提示词结构

前缀:引入工具的描述
格式:定义React Agent的输出格式

问题:用户输入的问题
思考:React Agent推理如何行动
行动:需要使用的工具
行动输入:工具所需输入
观察:行动执行后得到的结果
(按需重复:思考-行动-观察流程)

终点推理:产生最终结论
最后回答:问题的答案

stop token

How to Get Better Outputs from Your Large Language ModelIt is especially useful to design a stopping template in a few-shot setting so the model can learn to stop appropriately upon completing an intended task. Figure shows separating examples with the string “===” and passing that as the stop word.我们知道一般 LLM 都会长篇大论,说一大堆废话,我们希望 LLM 在返回了我们需要的信息后就停止输出,这里就需要用到stop参数,这个参数是一个列表,列表中的每个元素都是一个字符串,代表了 LLM 输出中的某一句话,当 LLM 输出中包含了这句话时,LLM 就会停止输出,这样我们就可以只获取到我们需要的信息了

源码

Agent 可以看做在Chain的基础上,进一步整合Tool 的高级模块。与Chain 相比,Agent 具有两个新增的能力:思考链和工具箱。能根据环境变化更新计划,使决策更加健壮。思考链释放了大模型的规划和调度潜能,是Agent的关键创新,Agent 定义了工具的标准接口,以实现无缝集成。与Chain 直接调用模块/Runnable相比,它只关心tool 输入和输出,tool内部实现对Agent 透明,工具箱大大扩展了Agent的外部知识来源,使其离真正的通用智能更近一步。

LangChain关键组件

  1. 代理(Agent):这个类决定下一步执行什么操作。它由一个语言模型和一个提示(prompt)驱动。提示可能包含代理的性格(也就是给它分配角色,让它以特定方式进行响应)、任务的背景(用于给它提供更多任务类型的上下文)以及用于激发更好推理能力的提示策略(例如 ReAct)。LangChain 中包含很多种不同类型的代理。PS: 一般情况下,一个Agent 像Chain一样,都会对应一个prompt
  2. 工具(Tools):工具是代理调用的函数。这里有两个重要的考虑因素:一是让代理能访问到正确的工具,二是以最有帮助的方式描述这些工具。如果你没有给代理提供正确的工具,它将无法完成任务。如果你没有正确地描述工具,代理将不知道如何使用它们。LangChain 提供了一系列的工具,同时你也可以定义自己的工具,或者将函数转换为tool。
     class BaseTool(RunnableSerializable[Union[str, Dict], Any]):
         name: str
         description: str
         def invoke(self, input: Union[str, Dict],config: Optional[RunnableConfig] = None,**kwargs: Any,) -> Any:
             ...
             return self.run(...)
     class Tool(BaseTool):
         description: str = ""
         func: Optional[Callable[..., str]]
         coroutine: Optional[Callable[..., Awaitable[str]]] = None
    
  3. 代理执行器(AgentExecutor):代理执行器是代理的运行环境,它调用代理并执行代理选择的操作。执行器也负责处理多种复杂情况,包括处理代理选择了不存在的工具的情况、处理工具出错的情况、处理代理产生的无法解析成工具调用的输出的情况,以及在代理决策和工具调用进行观察和日志记录。AgentExecuter负责迭代运行Agent,直至满足设定的停止条件,这使得Agent能够像生物一样循环处理信息和任务。

AgentExecutor由一个Agent和Tool的集合组成。AgentExecutor负责调用Agent,获取返回(callback)、action和action_input,并根据意图将action_input给到具体调用的Tool,获取Tool的输出,并将所有的信息传递回Agent,以便猜测出下一步需要执行的操作。AgentExecutor.run也就是chain.run ==> AgentExecutor/chain.__call__ ==> AgentExecutor._call() 和逻辑是 _call 方法,核心是 `output = agent.plan(); tool=xx(output); observation = tool.run();

def initialize_agent(tools,llm,...)-> AgentExecutor:
    agent_obj = agent_cls.from_llm_and_tools(llm, tools, callback_manager=callback_manager, **agent_kwargs)
    AgentExecutor.from_agent_and_tools(agent=agent_obj, tools=tools,...)
    return cls(agent=agent, tools=tools, callback_manager=callback_manager, **kwargs)
# AgentExecutor 实际上是一个 Chain,可以通过 .run() 或者 _call() 来调用
class AgentExecutor(Chain):
    agent: Union[BaseSingleActionAgent, BaseMultiActionAgent]
    tools: Sequence[BaseTool]
    """Whether to return the agent's trajectory of intermediate steps at the end in addition to the final output."""
    max_iterations: Optional[int] = 15
    def _call(self,inputs: Dict[str, str],...) -> Dict[str, Any]:
        while self._should_continue(iterations, time_elapsed):
            next_step_output = self._take_next_step(name_to_tool_map,inputs,intermediate_steps,...)
            # 返回的数据是一个AgentFinish类型,表示COT认为不需要继续思考,当前结果就是最终结果,直接将结果返回给用户即可;
            if isinstance(next_step_output, AgentFinish):
                return self._return(next_step_output, intermediate_steps, run_manager=run_manager)
            if len(next_step_output) == 1:
                next_step_action = next_step_output[0]
                # See if tool should return directly
                tool_return = self._get_tool_return(next_step_action)
                if tool_return is not None:
                    return self._return(tool_return, intermediate_steps, run_manager=run_manager)
            iterations += 1
            time_elapsed = time.time() - start_time
        return self._return(output, intermediate_steps, run_manager=run_manager)          
    def _take_next_step(...):
        # 调用LLM决定下一步的执行逻辑
        output = self.agent.plan(intermediate_steps,**inputs,...)
        if isinstance(output, AgentFinish): # 如果返回结果是AgentFinish就直接返回
            return output
        if isinstance(output, AgentAction): # 如果返回结果是AgentAction,就根据action调用配置的tool
            actions = [output]
        result = []
        for agent_action in actions:
            tool = name_to_tool_map[agent_action.tool]
            observation = tool.run(agent_action.tool_input,...)
            result.append((agent_action, observation))  # 调用LLM返回的AgentAction和调用tool返回的结果(Obversation)一起加入到结果中
        return result

Agent.plan() 可以看做两步:

  1. 将各种异构的历史信息转换成 inputs,传入到 LLM 当中;
  2. 根据 LLM 生成的反馈,采取决策。LLM 生成的回复是 string 格式,langchain 中ZeroShotAgent 通过字符串匹配的方式来识别 action。 因此,agent 能否正常运行,与 prompt 格式,以及 LLM 的 ICL 以及 alignment 能力有着很大的关系。
    1. LangChain主要是基于GPT系列框架进行设计,其适用的Prompt不代表其他大模型也能有相同表现,所以如果要自己更换不同的大模型(如:文心一言,通义千问…等)。则很有可能底层prompt都需要跟著微调。
    2. 在实际应用中,我们很常定期使用用户反馈的bad cases持续迭代模型,但是Prompt Engeering的工程是非常难进行的微调的,往往多跟少一句话对于效果影响巨大,因此这类型产品达到80分是很容易的,但是要持续迭代到90分甚至更高基本上是很难的。
# 一个 Agent 单元负责执行一次任务
class Agent(...):
    llm_chain: LLMChain
    allowed_tools: Optional[List[str]] = None
    # agent 的执行功能在于 Agent.plan()
    def plan(self,intermediate_steps: List[Tuple[AgentAction, str]],callbacks: Callbacks = None,**kwargs: Any,) -> Union[AgentAction, AgentFinish]:
        #  # 将各种异构的历史信息转换成 inputs,传入到 LLM 当中
        full_inputs = self.get_full_inputs(intermediate_steps, **kwargs)
        # 根据 LLM 生成的反馈,采取决策
        full_output = self.llm_chain.predict(callbacks=callbacks, **full_inputs) 
        # full_output 是纯文本,通过断点调试可以看到,真的就是靠正则表达式提取tool的名称
        # 最后的输出 AgentAction 中会包括:需要使用的 tool,使用该 tool 时候,对应的执行命令。
        return self.output_parser.parse(full_output)

有人希望通过一些开源的 LLM 来实现 ReAct Agent,但实际开发过程中会发现开源低参数(比如一些 6B、7B 的 LLM)的 LLM 对于提示词的理解会非常差,根本不会按照提示词模板的格式来输出(例如不按Action: xx Action Input: xx返回),这样就会导致我们的 Agent 无法正常工作,所以如果想要实现一个好的 Agent,还是需要使用好的 LLM,目前看来使用gpt-3.5模型是最低要求。

Function Calling

ChatGLM3 的工具调用(FunctionCalling)实现原理

使用Function Call功能时,你需要定义(并不是真的写程序去定义一个函数,而仅仅是用文字来描述一个函数)一些function(需要指定函数名,函数用途的描述,参数名,参数描述),传给LLM,当用户输入一个问题时,LLM通过文本分析是否需要调用某一个function,如果需要调用,那么LLM返回一个json,json包括需要调用的function名,需要输入到function的参数名,以及参数值。本质上是LLM(按特定意图)帮我们在做个文本结构化,Function calling 允许开发者更可靠的从模型中获得结构化数据,无需用户输入复杂的Prompt。实现上,把json格式的函数描述直接转换成了字符串,然后和其他输入一并送入LLM,归根到底function call能力就是在prompt上边做了手脚,微调时候有function call格式的数据。

openai like api

以查询天气为例,当我们在openai的请求里添加了funtions相关的字段,他会增加一个判断是否需要调用function的环节。

curl --location 'http://xx:8000/v1/chat/completions' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer xx' \
--data '{
    "model": "xx",
    "messages": [
        {
            "role": "user",
            "content": "10月27日北京天气怎么样"
        }
    ],
    "functions": [
        {
            "name": "get_current_weather",
            "description": "获取今天的天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "获取天气情况的城市或者国家,比如北京、东京、新加坡"
                    },
                    "time": {
                        "type": "string",
                        "description": "时间信息"
                    }
                },
                "required": [
                    "location",
                    "time"
                ]
            }
        }
    ],
    "stream": true
}'

以下以向ChatGPT输入“10月27日北京天气怎么样”为例:

  1. 请求里没有functions字段得到的结果如下,他会告诉你一大段答案(应该是假的),就是走Chatgpt正常的回答。
     根据天气预报,10月27日北京的天气预计为晴到多云,气温较低。最高气温约为16摄氏度,最低气温约为4摄氏度。需要注意保暖措施,适时添衣物。
    
  2. 请求里如果有functions字段,返回了一个json,并帮我们从输入文本里抽取了get_current_weather所需要的location和time的函数值
     {
         "id": "xx",
         "object": "chat.completion.chunk",
         "created": 1718021863,
         "model": "xx",
         "choices": [
             {
                 "index": 0,
                 "delta": {
                     "function_call": {
                         "arguments": "{\"location\": \"北京\", \"time\": \"10 月 27 日\"}",
                         "name": "get_current_weather"
                     }
                 },
                 "finish_reason": "stop"
             }
         ]
     }
    

    OpenAI 原生调用

 from openai import OpenAI
    client = OpenAI(base_url="xx",api_key="")
    completion = client.chat.completions.create(
        model="doubao-pro-4k",
        messages=[
            {"role": "user", "content": "How much does pizza salami cost?"}
        ],
        functions=[{
            "name": "get_pizza_info",
            "description": "Get name and price of a pizza of the restaurant",
            "parameters": {
                "properties": {
                    "pizza_name": {
                        "type": "string",
                        "description": "The name of the pizza, e.g. Salami"
                    }
                },
                "type": "object"
            }
        }],
        temperature=0.3,
    )
    print(completion.choices[0].message)
    # ChatCompletionMessage(content='', role='assistant', function_call=FunctionCall(arguments='{"pizza_name": "Salami"}', name='get_pizza_info'), tool_calls=None)

结合langchain调用

from langchain import LLMMathChain
from langchain.agents import AgentType
from langchain_core.tools import tool

@tool
def get_pizza_info(query: str) -> str:
    """
    Get name and price of a pizza of the restaurant
    """
    pizza_info = {
        "name": query,
        "price": "10.99",
    }
    return json.dumps(pizza_info)

from langchain.agents import create_openai_tools_agent, AgentExecutor
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder, \
    HumanMessagePromptTemplate, SystemMessagePromptTemplate

llm = ChatOpenAI(model=LLM_MODEL)
prompt = ChatPromptTemplate.from_messages([
    SystemMessagePromptTemplate.from_template('You are a helpful assistant'),
    MessagesPlaceholder(variable_name='chat_history', optional=True),
    HumanMessagePromptTemplate.from_template('{input}'),
    MessagesPlaceholder(variable_name='agent_scratchpad')
])
tools = [get_pizza_info]
agent = create_openai_tools_agent(llm, tools, prompt=prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
print(agent_executor.invoke({'input': 'What is the capital of france?'})['output'])
print(agent_executor.invoke({'input': 'How much does pizza salami cost?'})['output'])

代码解释器

ChatGLM3 的代码解释器(Code Interpreter)实现原理:背后的原理其实跟工具调用是一样的。无非就是将普通的函数替换成代码解释器,大模型预测的结果不再是函数的入参,而是具体的代码,根据这些代码我们调用代码解释器执行,然后在界面上面支持显示代码执行的结果。

要了解大模型是如何学会使用代码解释器的,就要先看训练样本是如何构造的。下面是一个官方提供的例子:

<|system|>
你是一位智能AI助手,你叫ChatGLM3,你连接着一台电脑,但请注意不能联网。在使用Python解决任务时,你可以运行代码并得到结果,如果运行结果有错误,你需要尽可能对代码进行改进。你可以处理用户上传到电脑上的文件,文件默认存储路径是/mnt/data/。
<|user|>
帮我画一个爱心
<|assistant|>interpreter
```python
import numpy as np
import matplotlib.pyplot as plt

# 爱心形状的参数方程
def heart(t):
    x = 16 * np.sin(t) ** 3
    y = 13 * np.cos(t) - 5 * np.cos(2 * t) - 2 * np.cos(3 * t) - np.cos(4 * t)
    return x, y

t = np.linspace(0, 2 * np.pi, 1000)
x, y = heart(t)

plt.figure(figsize=(6, 6))
plt.plot(x, y, color='red')
plt.axis('equal')
plt.axis('off')
plt.show()
```
<|observation|>
```result
【image】
```
<|assistant|>
这是一个爱心形状。我使用了参数方程来描述这个形状,并使用matplotlib进行了绘制。如果您有任何其他需求或问题,请随时告诉我。
<|user|>  # End

AgentTuning

finetune 就是让LLM “更懂”特定的instruction。 AGENTTUNING:为LLM启用广义的代理能力 有一点粗糙。工具调用能力的获得离不开模型微调,不同于通过Prompt 诱导llm 按照特定格式 响应tool的名字,通过特定的训练样本(可以练习)强化llm 返回tool的名字(和tool调用参数)。tool 信息入了LLM,意味着平时调用的 Prompt 可以少写点字,提高了执行效率。ChatGLM3的训练工具调用的样本数据是如何构造的?

<|system|>
Answer the following questions as best as you can. You have access to the following tools:
[
    {
        "name": "get_current_weather",
        "description": "Get the current weather in a given location",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {
                    "type": "string",
                    "description": "The city and state, e.g. San Francisco, CA",
                },
                "unit": {"type": "string"},
            },
            "required": ["location"],
        },
    }
]
<|user|>
今天北京的天气怎么样?
<|assistant|>
好的,让我们来查看今天的天气
<|assistant|>get_current_weather
```python
tool_call(location="beijing", unit="celsius")
```
<|observation|>
{"temperature": 22}
<|assistant|>
根据查询结果,今天北京的气温为 22 摄氏度。

应用

大佬:这一波Agent热潮爆发,其实是LLM热情的余波,大家太希望挖掘LLM潜力,为此希望LLM担任各方面的判断。但实际上有一些简单模块是不需要LLM的,不经济也不高效。例如我们要抽取每轮对话的情绪,可以用LLM,其实也可以用情绪识别模型。例如我们希望将长对话压缩后作为事件记忆存储,可以用LLM,也可以用传统摘要模型,一切只看是否取得ROI的最佳平衡,而不全然指望LLM。

一文说清:大模型AI Agent在企业应用中的6种基础类型

  1. 创作与生成类助手,简单的借助Prompt工程即可实现
  2. 企业知识助手,本质上也是一种提示工程:借助于在大模型输入时携带相关的私有知识上下文,让大模型理解、总结、整理并回答用户问题。只是这里的私有知识上下文需要借助嵌入模型(Embedding Model)、向量数据库(Vector Store)、文档加载分割(Document Loader&Splitter)等相关技术来获得。
  3. 数据分析助手,基本以三种方式为主:自然语言转API、转SQL、以及代码解释器(转代码)。DB-GPT、OpenAgents、OpenInterpreter
  4. 应用/工具助手,能够把自然语言转换成对企业应用或者互联网开放API调用的一种基础Agent形式。比如:如果你需要AI帮你在协同办公系统中提交一个付款申请,那么你需要调用办公系统的接口;当然,在复杂任务场景下的这种调用往往不是单一的,复杂性主要体现在大模型对自然语言转API的能力:能否根据上下文理解,精确匹配到需要使用的API(一个或者多个);能否准确地提取或生成每个API的调用参数。LangChain、Assistants API、OpenAgents。
  5. Web操作助手,主要能力是自动化Web网络浏览、操作与探索的动作与过程,以简化web浏览访问与操作。对于个人来说,可以作为个人数字助理,简单对话即可让AI帮你完成Web浏览与操作,比如在线订票。而对于企业来说,则可以作为企业的数字员工,来简化企业日常工作中重复性较高、流程与规则固定、大批量的前端操作性事务。比如批量订单处理、批量客户联络、批量网站抓取等,提高效率,降低错误率。传统的RPA机器人也是用来完成此类工作的AI形式,由于这种AI机器人工作在软件的最上层即操作层面,好处是流程直观、简单、也可以配置化,且对应用无侵入性;但其缺点是与前端应用耦合性大,每个任务需要根据前端应用界面做精心配置与调试,自适应能力较差。在大模型出现以后,给这一类RPA智能也带来了新的优化空间。
  6. 自定义流程助手,严格来说是上面的几种基础Agent能力的组合,理想中的AI Agent是在丢给他一个工具包与一些知识以后,借助于大模型的理解、推理能力,完全自主的规划与分解任务,设计任务步骤,并智能的使用各种工具,检索知识,输出内容,完成任务。但是在企业应用中,由于企业知识、应用、业务需求的千差万别,以及大模型自身的不确定性,如果这么做,那么结果很可能是“开盲盒”一样的不可控。所以这也是越来越多的Agents项目要强调可控性的原因,即能够对AI智能体的执行过程与细节进行更多的控制,来让AI按照人类确认过的工作流程来完成任务。 PS: 人规定流程 + 单个步骤代码化(有些场景代码无法实现 或 个性化成本太高) ==> 人规定流程 + 单个步骤智能化 ==> 自动分析流程 + 单个步骤智能化

从需求满足的角度来聊一聊:我们首先以“用户去某地旅游”为需求来解释LLM、RAG、Agent三者的能力边界以及需求满足度。

  1. LLM:能够生成“无法考证可能正确”以及“不一定及时”的相关行程攻略,景点等信息。
  2. RAG:能够检索一些时效性高、内容可靠的信息源的内容,并生成相关的行程信息。PS:看能召回什么内容了
  3. Agent:能够基于用户的需求目标完成,通过使用各种工具和系统交互完成攻略制定,订票,制定行程日历等过程任务。PS:先去搜一些攻略,再去订酒店 ==> 从景色、经济、时间等各个角度做一些对比。

其它

基于大模型的Agent进行测试评估的3种方案

一句指令帮你操作手机,最新多模态手机助手Mobile-Agent来了!为了便于将文本描述的操作转化为屏幕上的操作,Mobile-Agent生成的操作必须在一个定义好的操作空间内。这个空间共有8个操作,分别是:打开App(App名字);点击文本(文本内容);点击图标(图标描述);打字(文本内容);上翻、下翻;返回上一页;退出App;停止。点击文本和点击图标设计了输入参数。

  1. 在迭代开始之前,用户需要输入一个指令。我们根据指令生成整个流程的系统提示。在每次迭代开始时,Mobile-Agent会获取手机屏幕的截图,通过观察系统提示、操作历史和当前屏幕截图,输出下一步操作。如果Mobile-Agent输出的是结束,则停止迭代;否则,继续新的迭代。Mobile-Agent利用操作历史记录了解当前任务的进度,并根据系统提示对当前屏幕截图进行操作,从而实现迭代式自我规划流程。
  2. 在迭代过程中,Mobile-Agent可能会遇到错误,导致无法完成指令。为了提高指令的成功率,我们引入了一种自我反思方法。这种方法将在两种情况下生效。第一种情况是生成了错误或无效的操作,导致进程卡住。当Mobile-Agent注意到某个操作后截图没有变化,或者截图显示了错误的页面时,它会尝试其他操作或修改当前操作的参数。第二种情况是忽略某些复杂指令的要求。当通过自我规划完成所有操作后,Mobile-Agent会分析操作、历史记录、当前截图和用户指令,以确定指令是否已完成。如果没有,它需要继续通过自我规划生成操作。

别指望 AI 一次生成,其实不论是文本生成,还是代码生成,都涉及到生成式 AI 的能力问题:

  1. 用户无法提供所有上下文给模型。既然能提供,提供的成本往往过高(大于 AI 生成的时间)
  2. 模型无法理解你提供的所有上下文。