GPT Agent

大模型有很多，基础是Completion模式，即补全模式。

你给了开头/结尾，LLM(大语言模型)会自动补全空缺。

可是补全内容有一定的随机性，如果是写文章等工作，它的这种方式非常好。但是，用于和其他程序/模块交互，就存在很多的不确定性。

为了更好的得到预期的结果，就有了prompt engineer。通过它，给gpt赋予角色，让gpt知道它要干什么，这样，gpt就能更好的理解上下文，输出更符合预期的结果。

后来就有人更近一步，不仅仅让gpt只简单的输出一个内容，而是希望更程序结合起来，通过不断的与gpt交互，完成更加复杂的工作。于是就有了langchan。

也有对应的很多的论文，如ReAct等，langchain上面的实现，很多都是基于论文的。

比较早的就是ReAct，现在的方式可以用openai的function calling。

场景

一个智能客服系统，需要对用户输入的内容进行处理，然后输出。 它集成公司的api，能够更加契合公司的内容。

实现

1. 首先，需要给gpt一个角色，告诉它你们公司的业务是什么，你们公司有什么内容。
2. 其次，可以将api转成一个函数列表，让gpt知道都有哪些接口（gpt有token限制，不能全部给它，否则token消耗太多且容易超过限制）
3. 接着就是给它一些例子，让gpt知道怎么使用这些接口。例子包含问题和需要调用的接口。
4. 最后，就是让gpt自己来完成任务。

上面仅仅是一个基础流程，实际的流程会更复杂。 比如：

1. 需要对gpt的输出进行评估，判断是否符合预期。
2. 用户的问题是否简单问题，如果是复杂问题，需要拆分为多个子问题，每次处理一个子问题，然后将结果合并。
3. 第一次调用的接口得不到想要的答案，是否需要换成其他接口。
4. 如果处理一个问题，涉及到多个接口，它们之间是否存在依赖关系，参数如何传递。

个人的建议

1. 能用gpt的function calling，就不用其他的agent。这样能够减少很多的异常场景。
2. 尽量让agent第一次强制使用function，langchain默认没有这个限制，所以有时候会出现gpt将内容以文本的形式输出，而不是function的方式。
3. 尽量让agent一次只处理一个任务，不要让agent同时处理多个任务，虽然现在的gpt已经比较智能，但gpt每次调整，都可能影响它的能力，不确定性比较大。
4. 能够用程序实现的功能，尽量不要让gpt处理。gpt即使再智能，准确度也不可能比程序高。

参考方案

上面的例子，我这边写个简单的参考方案，这是我现在正在做的，仅供参考。

1. 第一层agent：
   1. 角色：智能客服系统
   2. 功能：
      1. 识别用户输入内容，判断是否为问题
      2. 使用api，回答用户的问题
      3. 如果缺少信息，应该尝试询问用户
   3. 函数列表：
   4. 自动加载openapi文档，输出api列表，每个function的格式为：function_name(arg1,arg2,…) description…
   5. 例子：
   6. 问题：查询我的仓位，actions:get_active_positions
   7. 问题：查询我的订单，actions:get_orders
   8. 问题：帮我卖出1000个bnb，actions:get_price(bnb),sell_token(bnb_usdt,1000)
   9. 为agent提供一个function，gpt的function calling将使用该function。
   10. 该function的输入是gpt的output，即actions：需要调用的api列表。
   11. 该function输出后，会交给gpt。gpt基于这些结果，判断是否能够解决问题，如果不行，继续调用其他function或尝试让用户提供更多信息。
2. 第二层agent：
   1. 角色：函数执行者
   2. 功能：
      1. 提取api需要的参数，调用api
      2. 判断api是否成功，如果失败，尝试修改参数，再次调用
   3. 实现
      1. 可以将标准openapi转成function calling的方式
      2. 如果可以，应该给api提供背景知识、使用说明和例子。
      3. api大部分都是返回json的，可以转成yaml再交给gpt，这样既能减少token，也更容易让gpt理解。
      4. 如果api只会调用一次，可以立即结束，直接返回结果。不需要agent再与gpt交互，减少gpt交互次数。
3. 所有的gpt交互，时延都是以秒为单位
   1. gpt4会比gpt3.5慢很多。
   2. gpt4比gpt3.5聪明很多，费用也高。
   3. 可以先以gpt3.5尝试解决，如果失败再用gpt4。大部分问题能够解决，少部分需要gpt4，时延更长。
   4. 尽量结合embedding，使用更相近的例子和知识，gpt给的答案会更准确。
   5. 可以考虑增加feedback的功能，这样整个系统可以实现自我迭代升级
      1. 所谓feedback，就是答案给到用户，用户可以评分。
      2. 优质答案的处理流程可以保存，通过embedding，将actions和api args等信息存储下来，后续遇到类似问题，可以直接参数或复用。
      3. 不带参数的api，可以直接复用。带参数的api，需要慎重，直接复用可能传递错误参数。
   6. 如果整个系统已经稳定可靠，且向量数据库里面的例子比较多（至少几百条，能覆盖大部分场景），可以考虑fine tuning
      1. fine tuning可以提高gpt的准确率，但是需要大量样本。
      2. 它可以减少大量的token，例子和function list都可以减少。

• Previous
  Go Call C
• Next
  Webauthn