AIAGENT开发

框架React从执行工具的结果进行思考plan and execute 规划和执行优点不会跑偏缺点不够灵活self-ask回路验证允许大模型自问自答。回答一个问题时发现缺少信息会自己找。运行模型基于结果再去提出问题。自己追问更能理解问题。自己内部去找答案偏差修正 Think and Self-Reflection思考并自我反思不断自我评估和调整性能优化1.线程池2、大模型规划把工具描述都给它会出问题工具的描述可以进行摘要或者分类不是让大模型去摘要是人工摘要。3、用户自然语言提需求没那么专业相似度匹配不准确。用大模型做查询改写。比如用工具的描述当模板调用大模型要有提示词提示词交给大模型执行大模型答复要做结果提取大模型返回的结果一定要做校验内部重试机制如果因为限流导致的要有退避机制休眠一个随机数。放到循环里面有异常处理模型的切换有复杂业务或者流传的不是切换名字就行的1.切模型切不动同一个查询换了模型结果却截然不同。解决方案每个模型都有自己独特的提示词代码实现的时候不想所有的函数、提示词都重复去写。通用的提示词模板 -变更模型之间不同的部分即可。Agent工程化场景化的Prompt体系1.系统/核心基础提示词角色的定位、合规红线、权限的边界2.场景化的分支prompt3、辅助型提示词格式校验、合规校验、前置处理意图识别、敏感词过滤、4、版本管理回滚AB测试的需要上下文超长不同业务场景选择不同的方案1、压缩/摘要 大模型帮我们摘要 成本高、耗时。 文本超长又非得做摘要分批进行。讲第一个做完的摘要和第二个文本一起给大模型如果信息量太多用户也不会看没有太多业务意义不如直接截断2、加参数/分页3、截断 (同质化内容太多用户不需要看 假设是多任务 单任务截断假设单任务太多又超出了大模型的窗口这时候需要做摘要大模型的上下文 注意力集中 30000个tokens超过会断崖式下降大模型选择工具1.可以用语义检索进行粗筛工具提高ai选择工具的准确性2.参数的提取大模型提取参数有可能出错检查参数是否缺失对不对补全参数的一个流程工程化的项目里对于大模型返回的结果一定要做检查异常/重试/补全参数3.工具的调用4.任务的摘要、自然语言描述将工具调用的结果信息拼接到message里面返回给大模型当大模型遇到不认识的专业名词时关键字检索混合检索 / 向量模型微调单任务业务api(完成用户的请求参数api补全业务api所缺失的参数用户的原始请求直接拿到无法直接获得参数api的名字查询改写自然语言的描述要把工具的简单描述一起传给大模型知道有哪些能调用 -- 产生一段描述词到向量库中检索大模型精选参数api的执行需要名字也需要可执行的参数参数缺失的情况补全参数不要从技术角度从业务角度直接不做了成本太高太复杂、工具执行大模型的注意力首先在开头其次结尾。中间可能会注意力涣散当工具在中间的时候。重排序用重排序模型对候选工具进行重排序参数补全RestGPT1.reverse chain 逆向推理参数补全。调用其他api进行参数补全2.直接提取3。询问用户Function call 函数调用模型调用外部工具1.交互数据格式2.编写函数规范使用tools参数传递外部函数信息加载Function calling功能把函数调用后的信息追加给大模型的信息里面去让大语言模型调用外部函数的能力。 即模型可以不再仅仅根据自身的知识进行回答而是可以额外挂载一个函数库。 1、大模型应用/AIAgent将用户提问和函数说明一起告知大模型 2、大模型判断并回复具体调用函数和参数 3、在按照实际需求调用外部函数并获取函数运行结果后将结果告知大模型 4、大模型再基于函数运行结果进行回答。工具调用要遵守格式tools[ { type: function, function: { name: check_tick, description: 给定日期查询有没有票, parameters: { type: object, properties: { date: { type: string, description: 日期, }, start: { type: string, description: 出发站的地址编码, }, end: { type: string, description: 终点站的地址编码, } }, } } }, { type: function, function: { name: check_date, description: 返回当前的日期, parameters: { type: object, properties: { str: { type: string, description: 返回今天的日期, } } } } } ]数据库mongdb文档型数据库向量数据库分层存放数据向量簇。FLAT暴力搜索nlist聚类中心的数量规定有几个聚类nprobe:搜索精度和范围安全层面的考虑多层、防御纵深1.用户的原始请求 判定一次输入侧拦截2、只要是和大模型沟通的位置都要进行提示词注入检测/安全检查 /越狱攻击3、AI应用执行侧校验 权限检查、高风险的二次确认4、第三方系统本身权限检查5、输出侧审核6、人工复核多任务单任务的组合1、循环处理每次处理一个子任务单任务2、任务拆解 将每次单任务解决后把api调用信息和用户的问题传给大模型再进行规划判断plan and excute 是比较明确的可以最开始都拆解掉3、产生死循环的任务 大模型的能力不足用户的请求不对连续出现相同的API且结果相同时4、总任务再摘要《压缩》/单任务摘要。单任务可以截断但总任务累加起来可能上下文超长分段压缩提纯工具执行前后关联的情况下怎么去做上下文的管理将前面执行的结果一起传给大模型引入人类干预 human_in_the_loop分级权限管理 -- 上级主管审核之后才能执行任务多了等待人类反馈的状态判断是不是新请求还是人类 的一个反馈自然语言描述用户的意图是什么。判定分层次:1.关键字或者正则2.正则不到使用模型进行语义理解2.1 小模型 Bert投票机制2.2 走大模型3.前端提供按钮高频 标准化:规则50% 小模型50% 可微调 、中频规则20% 小模型50%大模型30%、低频 复杂少见小模型大模型收集问题要全面 常见用例 正向用例负向用例异常用例 安全用例 300条以上意图的判断一定要有个兜底机制无法判断时归纳为意图不明确。让你的业务能进行下去兜底很重要意图识别 体系顶层意图 -- 子意图 --原子意图工具是否执行 运行 拒绝参数的补全工具的选择是否正确 对 不对 新的工具小心注入问题把用户的请求直接拿过来执行不做任何的校验恢复上下文。将信息存入到任务状态中