耳光可响战队方案介绍
本次比赛做了两套方案
- 方案一是在b榜答疑前写的
- 方案二是后面看了回放想的新方案
- 当前使用的是方案二
方案一介绍
创建了三种角色
- supervisor 用于任务分解
- 各类worker 用于完成不同的子任务。拥有了不同工具包。
- tester 测试最终答案是否成功
方案流程
supervisor 创建了一个任务列表，任务列表包含了三种信息【子任务，哪个worker解决，优先推荐用什么工具解决】
worker根据任务列表，拿着自己的工具不断改写，添加新的子问题到任务列表中。
完成所有的子问题回答，就把所有信息交给supervisor总结答案。
答案成功了就输出，否则循环这个过程。
ps. 工具除了官方提供的工具，还做了python的沙箱环境用于进行各类计算。
方案一代码
代码入口：agents/chat_router.py 可以运行单个问题。
方案二介绍
为什么要新做一个方案二
方案一采用的工具是经过我多次深加工的代码，比如输入公司名字，会把公司的注册信息、上市信息、限制高消费信息一并返回，具体想法是一个实体的输入，返回这个实体的所有数据。类似的还有案号，会把所有输入为案号的所有信息一并返回。
但是在看完答疑的回放后，貌似主办方不太希望我们整合函数，希望由大模型自主的进行工具的组合，所以有了方案二。几乎所有的工具都是官方提供的工具，不再进行组合了。
方案角色
同方案一
方案流程与方案一的区别
几乎没有大的区别。
区别点是：
- supervisor会看到所有的工具包，由supervisor来统一调度优先工具。
- supervisor在创建任务列表前，会多一步称为"预思考"的过程。要求大模型先吧解决问题的思路写下来，再完成任务列表的创建，因为创建任务列表这步我是希望输出一个json，所以不会显式的写下解题思路。所以多新增了一步让把解题思路显式的写下来。
- 子任务的worker不再进行改写，和新增子任务的操作。如果本轮任务失败了，会把失败的信息交给下一轮的supervisor来重写新的子任务。
- 比较trick的地方是，单独会运算api的调用情况，每个任务出现统计字眼，会调用python工具进行一次运算。当任务出现python运算是，会在最终子任务加一个用python运算原始问题的子问题。
- 方案二维护的任务列表格式如下
| 问题序号 | API解决的子问题 | 调用的工具 | 调用工具的输入字段 | 工具输入来源 | 输入来源字段 | 输入来源序号 | 工具输出的字段 | |-|-|-|-|-|-|-|-| | 0 | 查询公司名称| getcompanyinfoservices | 公司代码| 主要问题 | 300077 | 0 | 公司名称 | | 1 | 查询公司涉及的法律文书信息 | getlegaldocumentlistservices| 公司名称| getcompanyinfoservices | 公司名称 | 0 |法院代字 | | 2 | 根据法院代字查询法院名称| getcourtcodefromcourtcodeservices | 法院代字 | getlegaldocumentlistservices | 法院代字 | 1 | 法院名称 | | 3 | 查询法院成立日期 | getcourtinfoservices | 法院名称| getcourtcodefromcourtcode_services | 法院名称 | 2 |成立日期 |
这个表格是通过supervisor输出的。后续的子问题答案也维护在这个表格内，最后交给supervisor回答最终答案
方案二代码
代码入口：agents/chatrouterpure.py 可以运行单个问题。
回答所有问题 answer.py
评论