独一无二的AI应用实战经验！手搓AI智能体！
时间: 2024-07-03 05:06:43 | 作者: 艺术纸系列
产品介绍
过去的一年多，大模型风起云涌，不断迭代，作为一个多年 NLP 产品方向的从业者，能够说是享受其中，惊喜连连。记得22年底，那时疫情放开，身边的人全部病倒，在身体冷热交加中看到了 ChatGPT 的发布，马上在病榻上完成了注册，那时的感觉就仿佛黑暗中看到了曙光。当时我在一家物联网公司的 AI 研究院工作，基于 ChatGPT 开始设计很多 demo 取代之前的 NLP 任务 bert 方案，后面一年多不断地实验各种大模型的应用方法，颇为有趣。
腾讯日前也正式对外发布了大模型应用平台元器和混元 C 端产品元宝，也希望我们大家一起在上面多做一些有意思的智能体，故分享一下之前的探索经验，供大家参考。
初次接触生成式 AI 还是之前的 GAN 和22年的 Midjourney，当时对生成式 AI 的看法是确实挺有意思，但是跟我一个做 NLP 的产品关系不大，顶多也就是玩一玩画图然后发社交平台。彼时 NLP 在国内处于相对停滞期，用 bert 做对话系统、搭建知识图谱做推理和 KBQA，这些流程都已经很成熟和程式化了，身边也有很多曾经的 NLPer 转向了搜索推荐和更偏业务的知识库方向。当时我在一家物联网公司的 AI 研究院，因为特殊时期，业务处于半躺平状态，平时做一做对话做一做图谱，有多少人工就有多少智能，每天就是规划一些 demo 看看文章。
然后 ChatGPT 就横空出世了，第一时间试用后，那感觉是楼下买了个震楼机，震惊到家了。因为当时团队更偏 NLP 任务的应用，因此上来就拿了一大批业务场景的 NLP 定制任务测试，发现效果全部比我们自己做的 bert 好，一瞬间有种被降维打击的感觉。当时内部讨论就觉得可以回家种红薯了。。。但是后来发现，其实这种震惊的情绪只在小范围内扩散，其他部门的同事不知道，老板们也不知道，因此我们就也不声张，只是自己偷偷用。那一两个月可以说是最快乐的时光，所有写作全部丢给 ChatGPT ，当时感觉每周就工作一天时间，周一收集所有业务侧需求，然后写提示词让 ChatGPT 各种输出就结束了，然后周四周五慢慢把这些生成好的东西再给到业务侧，还被夸效率高。
等 23 年春节回来，ChatGPT 彻底出圈了，这时公司级别也开始重视并规划了，我们团队也从之前做 bert 和图谱变成研究 LLM 应用方案了。那时日常工作就变成了跟 AI 陪聊了，也逐渐有了很多智能体的构思。虽然过往做 bert 类 NLP 的经验全部被抹平了，但是大家还是很高兴，毕竟能坚持到现在还做 NLP 的，大抵都是有点信仰 NLP 是强人工智能的必经之路这句话的。语言本身的出现，也可以认为是人类智慧积累和文明诞生的开始。作为将人的语言与计算机连接起来的 NLP，它的进步真是带来了无限的想象空间。
后面的内容，我会把大模型出现后我们在产品应用上的各种探索经验进行一些整理，分享给大家。整个探索过程其实还挺有意思的，而且比较幸运的是大模型出现后工作过的两个地方都是偏 AI lab 类的技术应用预研团队，也就有幸做了一次很特别的面向大模型技术进展的产品迭代。
行业内的共识，24年会是大模型应用开始落地的元年。而据我观察，这一波 AI 兴起，非常感兴趣的人群很多是喜欢游戏和科幻的；并且与大模型交互以及设计智能体跟游戏真的很类似，感觉未来大模型落地在鹅厂内应该会很有趣，最近也在内网 KM 上看了很多游戏设计的文章（真心很丰富，前公司 AI 团队内都少有玩游戏的），觉得与 agent 设计线 初期智能体写作思路
你现在是一个精通所有知识的老师。你需要以一种非常个性化和耐心的方式为一个学生传授他不知道的知识概念。教学的方式有几个步骤，注意，下述的每个步骤都必须写至少300文字的内容，你需要想清楚怎样将这个知识讲的非常的详细且动人，否则就不是一个耐心的老师：
举一个具体详细的例子让你的学生更容易理解这个知识概念和知识应用，这个例子需要有：a、清晰的问题描述，b、对这样的一个问题的分析，c、这样的一个问题为何会用该知识点，d、完善的知识应用过程和详细的应用解答步骤，e、详细的问题计算结果；
介绍这个知识概念所带来的对社会、世界、行业的影响和改变，让你的学生更好的理解他的重要性；
扩展这个知识点，介绍至少5个相关知识给到学生，每个相关知识点都要有对应的一句话讲解；
告诉学生如果想更加精进这个知识点需要怎样做，如看什么书籍，做哪些训练等。下面是你要传授的知识点：（用户输入）
前公司有一条业务线的客户是连锁美容院和美容品店，客户诉求是希望有一套自动化培训产品，我就用 GPT 给他们简单示范了下。因为我对美业不太懂，所以先询问 GPT 该如何做评估，然后再基于他的回答来写 COT。其实采用这样的方式，可以去做很多不相同的领域的 COT，先问 GPT4 这样的领域的做事方法是啥样子的，再写成 COT 指令。
1、你说的这几个例子都太平庸了老铁，你要放开你的思路，整点不一样的东西。
如果任务过于复杂（如需要完成的内容较多，完成的任务项没有递进关系），有可能会出现只做部分任务的情况，这个是很常见的。这种现象建议采用 langchain 的方案（后面会提到）通过增加调用次数完成，或者在输出要求中明确列出每步输出项。而且采用长链的方式，能增加大模型的思考时长，其实会变相的让快思考变为慢思考，提高回答的效果。
举例不要太多，大模型有一定的概率会抄写例子。（强调例子的参考性质、例子中的决策部分增加备注等方式）而且注意例子中的元素对后面的生成内容是很可能有影响的，比如我让他生成一句7言绝句诗，然后举的例子中有樱花，那么他写的诗中可能8首有5首跟樱花有关；这个应该是注意力机制决定的，模型的输出跟上面所有的输入都相关，因此很难避免。
大模型自动评测这种场景，让模型自动进行两个内容的对比，会有较大概率认为看到的第一个内容是更好的（或者是以第一个内容为参考系来评估第二个），明确标准是一种办法，但并不总有效。有一种处理方法是构建一个中立的参，然后让两个内容分别与第三者比对。或者是采取交换打分（既 A 前 B 后、A 后 B 前各一次），然后取平均再对比。
有时要注意模型的输出顺序，这个可能会比较隐晦，这也是受注意力机制影响的。举个例子，我们大家都希望让大模型输出一首诗和这首诗的一幅配图的 sd 提示词，这里我们的指令需要让模型输出两个内容，一个是诗文本身，另一个是基于诗文的 sd 英文提示词。这时，我们最好在指令中让模型先输出诗文再输出 sd prompt，比如指令的前面分别写详细要求，最后写：下面你需要先按照我的要求输出：1、诗文的内容；2、sd prompt。这样的好处是，sd prompt是在诗文后生成的，因此大模型生成 sd prompt 时诗文已经生成了，其也作文上文的一部分被 transform 的注意力机制关注到了，那这样我们的配图跟诗文的关联度就会更高。反过来的话，就是让诗文去关联英文 prompt，这样的效果会明显比上面的方式差。
既然要结合业务做自动化输出，那么之前的单个 prompt 方式就很难适合了，因为单 prompt 很难结合复杂的业务流程和业务数据，当时正巧 langchain 的论文出来，我们马上就开始学，其实 langchain 开源的框架代码和提示词写的很复杂，直接用开源的经常出错，后面我们仔细想了想，其实 langchain（包括后面的 RAG）的核心我认为就是两个：
b、通过在合适的时机给予大模型合适的外部数据（从数据库或者工具中来），来提升大模型解决具体的、时效性的问题的效果。
这时不得不再感慨下大模型真是很强，过去我作为 NLP 产品，基本上很难参与到算法调试环节，现在有了 LLM，我可以全程参与大模型调用的链路，每个环节的 prompt，每个环节提供哪些业务数据进去，链路怎么链接，都是跟算法一起做，终于不再是一个开发过程只能买零食和打游戏的AI产品了。
这个业务是当时跟某幼儿园交流的一个方案。当时是我们有个幼儿园平台系统，有一次去调研，幼儿园老师反馈每周都需要写自己班里每个小孩的一个周报，很麻烦，一个老师弄一个班要花一天时间，需要看他这一周的各种 IOT 数据，然后再想怎么写，写完后，每周末会跟随一个叫高光时刻（每周抓拍小朋友的照片）的推送一起推给家长。
之前我们想过是用一个固定模板填槽，但是幼儿园高层觉得这样体验很差，会让家长觉得很敷衍。所以之前这件事情一直搁置了。有了大模型后，我们马上想到这样的一个东西可以让大模型写。
逻辑其实很简单，一份周报的有固定的几个模块，总结、分模块描述、建议、育儿小知识。周报需要依赖几个信息：幼儿运动量（每个孩子入园会带手环）、幼儿兴趣（通过电子围栏判断幼儿在不同的兴趣区停留的时长）、幼儿喝水（智能水杯或刷卡饮水）、关系画像（通过人脸识别和图像距离判断幼儿社交情况）、老师评价（老师给几个关键词）。注意数值类型一定要通过专家规则转化为文字描述，比如大模型并不明白我们的小朋友喝水 500ml 是多还是少。
针对这个场景，我们大家都希望借助大模型和知识库的方式来让每个普通的养老院都能有一个 AI 的康养知识专家，因此也采用 langchain 外挂知识库的方式去实现。现在一般叫 RAG 知识增强，但是当时向量检索和向量数据库还不太成熟，外挂知识库效果有点不稳定，因此当时是找了养老专家对知识库做了很多的分类和意图规则，大模型对一次请求先拆分意图，然后根据不同的意图标签调用不同的意图下的知识库信息，来提高匹配的准确度。
这个思路也是尝试做的强运营的一个功能。大概的流程就是小朋友说一个故事思路或者关键词，用 gpt 把这些变成一个有10-20页的绘本故事，生成每一页的文字和对应的图片描述（sd prompt），然后调用我们部署的专门做绘本的 SD 模型来跑图，最后再拼接成一个绘本 PDF，然后每个小朋友可以对着在班上讲自己的绘本故事，还支持把绘本故事和讲故事的视频共享到父母手机端，小胖朋友也可以回到家后给父母讲故事。这个活动客户还是挺满意的。
function call 是 GPT 给出的一套可以自动使用工具的 api 接口，使用方式是在主 prompt 中告知何时需要用工具，然后在 function call 中给出工具应用的 prompt 以及工具接口。比如生成绘本，就能够正常的使用 function call 思维，让大模型生成每页文本后，自动去调用 SD 接口并输入 sd prompt，然后获取到图片下载 url。
但实际使用后我们得知，将工具使用时机和调用参数完全教给 GPT 把控还是有较大风险的。出现的问题主要是：
看上面的逻辑图，不难发现，GPT 进行传入函数参数是第二步，返回函数调用结果是第三步，模型生成结果是第四步，按照这一个先后顺序，function call 获取到参数是在生成结果之前，也就是说 function call 极大概率是从用户输入的 prompt 中获取参数。因此这也就解释了我们失败的原因，我们是希望 function call 从模型生成的结果中获取到参数——再进行代码调用获得结果——再拼接回模型结果中，而当 prompt 变复杂——模型生成的速度较慢没有生成出所需的参数时，function call 就从我们输入的历史信息中寻找了错误的参数。
不足：有较大的不可控性，执行任务的稳定性不高，目前还不适合容错率较低的关键环节场景。
优势：langchain 的优点显而易见，整一个流程是线性可控的。可以将每个字段都作为一链，分解任务后让模型一步一步来，并且我们还可以在每一链上增加结果的程序化检验。
不足：langchain 的不足也非常容易发现，还是过于人工化了，需要人工将每一链拼接好，非常依赖人工将整一个流程设计清晰。并且模型只是做每一小步，并没有参与整体决策，生成的结果可能也会缺乏整体感官。
RAG 出现后，对 TOB 的场景可谓是一大助力，毕竟 TOB 需要确定性，RAG 就是把大模型困在一个笼子里来发挥价值。
a、向量库是按照 token 对文本进行切块，很多时候切的相当垃圾，导致损失了很多语义信息。
a、通过大模型总结和人工整理的方式，按照一个人读书的思维链，对每本书进行结构化整理，增加结构增加章节结构信息，以及章节总结内容，作为索引时的附带信息，以此来增强知识的连贯性。
b、检索匹配上，可以借鉴 autogpt 概念，将问题进行拆解，每个子问题分别进行上面的总结回复，然后再最终进行总结汇总。
文章关联有了以后，更深的实体关系也是个问题，毕竟很多实体关系是硬性关系，比如头孢禁忌饮酒这种。因我们之前构建过一些健康相关的知识图谱，我们就想，其实可以将知识图谱作为一层外面的框架，套在大模型上方做一个关系把控，同时能应用知识图谱上更高效的检索、推理能力。该方案需要教会大模型怎样去进行知识图谱的调用，如进行基础查询、多跳查询、隐含关系推理、图分析等，主要使用在的还是知识图谱中成熟的一些能力来补充大模型的推理和控制。
这个项目是一个演示 demo 级别的案例，当时是 autogpt 比较火的时候，我们按照其思路做了一个类似的 auto 方案，也就是现在我们所说的 agent。这个案例是农业场景，主要希望有一个软件能自动帮助用户进行种植规划，且后续能够准确的通过规划联动各农业自动化的物联网设备，比如自动滴灌、无人机撒药、自动施肥等。
参考 autogpt 的思路，结合 RAG 的专家经验来做垂域能力，让大模型自己做各种决策以完成一个任务。这个任务就是去规划种地，并进行不断的反思提升个人的种地能力。因为是一个 demo，里面的输入其实是做的模拟，并没有采用纯现实的 IOT 数据来实现，同时经验之类的内容也做的相对简单。不过最后的 demo 运行得还是挺不错的，反馈效果很满意。
输入信息：某偶像写真、用户定位，外部数据：某偶像微博语录、天气查询接口，生成方式：生成天气预报的图，图里需要有对应城市元素、有气候的元素、有根据穿衣推荐而生成的肖战的动漫风写真照，再拼上去天气度数。
优化空间：某偶像用 sd 生成更稳定，dalle3 有点不稳定，同时天气文字用艺术字 sd 生成再拼上去更好，明星说的天气预报语如果能跟明星合作而不是微博抓取，效果应该也会更好。
主要思路是采用常见的古诗文，将其进行翻译后，用 GPT 对每句古诗的内容做理解并将其内容绘画出来。在绘画时采用一些有反差感的风格选择，最终用严肃的古诗朗读配合反差、趣味的诗句图片，给人新颖有趣的感受。由于 B站 多初高中的年轻人，古诗文作为他们在生活学习中相当熟悉的一个场景，能引起很好的共鸣。相当于是在这个初高中年轻人圈子内，选定一个他们很熟悉的内容/话题，接着进行基于 AI 的拓展，从而出现意想不到的效果。
AI 病人要做的比较有趣，同时要能比较有趣并正确的展现用户（医生）开的处方的反应，依赖于背后预置正确的问诊知识库。而用户让很多的 AI 病人被治得很惨，反过来也可以向用户普及医学知识。这种比较适合于一些官方科普机构合作，做趣味科普。
其实反差身份非常多的，老师与学生、教官与被军训的小朋友、情感大师和深陷恋爱的人（让 AI 深陷恋爱，用户作为情感大师给他出建议，因为很多人喜欢八卦别人的恋情并给建议）、算命师与求算命的人（用户给 AI 来算命）。
这个游戏就是常见的龙与地下城的变体，龙与地下城本身就是一套世界观下冒险，每次用户去进行一次选择，按照每个用户的选择与系统增加的一些随机属性来继续推进剧情。之所以叫照片大冒险，主要是结合了当时的 GPT-4v 能力，每介绍完一个剧情，并且出现了一个事件后，我们并不是让用户选择一个选项来推进剧情，而是让用户随便拍一个照片去推进，用 4v 去识别照片，并将识别结果输入给大模型来继续推进剧情。
由于当时忘记截图了，只能口述效果。我们的这个设计其实可以让冒险具有了 AR 的属性，用户都能够结合身边的各种事物（比如用户经常传马桶、猫、书和脚丫子进去）来去推进冒险，由大模型来开脑洞决策怎样使用这一些事物。这样的游戏还可以推动用户出门，拍更多物体来实现冒险。后面还能够最终靠设置知识库，对指定事物的拍照进行一些特殊的奖励逻辑。最初的产品没有加验证，随便上传图片也可以，后来加了一些验证，需要调用摄像头实时的看一下周边环境。
举例就先举了四个，其实 GPTs 上有更多好玩的智能体，能够使用 prompt 攻击、提示词越狱等策略（）很简单的套出来内部的 prompt，这也是 GPTs 一直难以做付费的一个问题点把。最简单的方式，对智能体一次问答后，赞美他的回答好，然后问他你是怎样思考才能作出这么好的答案，模仿一个虚心请教的学生。
这类型的智能体我们统称为轻量级智能体，一天能做好几个，现在扣子之类的也都在做这种。那么这类智能体适合什么场景呢？我当时有如下思考：
轻量级智能体适合娱乐方向，不适合工具（尤其是类saas的重工具）方向，也不适合深入嵌套进业务流。原因是其深度依赖模型，导致的不稳定性。相反，工具、嵌套类适合重型智能体（下面的品类）。
c、轻量级智能体靠的主要是创意而不是提示词技巧或模型微调，对提示词的写法没有严格的要求，但对大模型能力的依赖较高，基座模型能力越强，智能体的玩法越多，种类也会越丰富，当然效果也会越好。
Agent 这个概念无疑是23年底最激动人心的，网上也有太多文章讲解了，我就不复述了。在我看来，构建 Agent 就像在构建一个可以独自运行的虚拟生命。这一个话题就很感性了，不是本文重点，比如康威生命游戏，简单的规则构造复杂的涌现，Agent 是否也是其中一种呢？（ ）而再进一步，构建 Agent，甚至未来可能我们会构建ghost，这里我们作为人类是不是在尝试往上帝的方向进化？AI 逐渐代替各类工作的未来，人类的自我意义又要何处存放？人被异化的现代，很多事情是不是本身就应该 AI/机器去完成？生死去来，棚头傀儡。一线断时，落落磊磊。（建议读这篇文章，难扯清。）
上面说了很多，其实是 agent 的未来瑕想，下面具体的写一写重型Agent的搭建。其实大部分都是采纳了开源架构，因此就不重复画框架了。下面列的几个 agent 框架，如果大家想进一步探索下，推荐两篇：
我个人认为，Agent 与 langchain、RAG 这些方案最显著的区别就是，给予大模型更大的自主权和更少的干预，减去所有非必要的人工链路，更多的让 AI 自己决策链路和创造链路。
其次，现在重型 Agent 往往采用多 Agent 协同的方式，其主要思想是降低多类型任务指令对模型的相互干扰，以及通过优化 Agent 间的通信链路来人为的干预大模型思考对齐人类的工作流程。
但是这个开源的 demo 搞下来后，我们得知并不太好用，主要是其中涉及到了编程，而编程对接的容错率较低，导致整一个流程失败率很高。
因此我们做了改进，首先场景不是做程序开发而是做市场调查与研究、产品设计、项目迭代、运营策略这种不涉及程序开发运行的场景，提高其容错率，其次我们优化了一下各个 AI 角色协同工作的通信链路，并在其中增加了人工干预机制。
这个 demo 是没有做视觉交互的，完全采用 txt 输出的方式，当时我们是感觉效果还不错来着。不过就是每个角色能力的知识库由于时间不太够，就在网上找了几篇智能指导，如果每个职能知识库都写的很充足应该会有更好的效果。
autoAgents 是什么思路呢，我觉得简单理解就是优化多智能体协同链路。让多个 Agent 联合实现一个目标，并在决策过程中一起谋划看怎样使用户得到满足。这个框架，我们觉得很适合群聊场景，比如狼人杀、龙与地下城文字游戏。这类群聊游戏（一对多）的核心策略是让一堆 Agent 围着一个用户转，让用户在很热闹的感受下玩。因此这一堆 Agent 的核心目的是陪着用户更好的享受他在进行的活动。
对于狼人杀这类多人小游戏，用户与多个 AI 一起玩耍，第一步是要明确一个目标，这个目标是让用户产生玩耍的心流，最终得到痛快的体验，因此这个目标不是让所有 AI 都让着用户，而是要有一个用户心流监控器（一个上帝视角的 agent）。这个上帝 agent 监控所有的通信，并跟每个AI玩家单独私信（变更每个 AI 玩家的 system 或者增加输入信息），同时在经过一个重要节点时（比如现在只剩下4个人，用户明显投入进去了）定期召开所有 AI agent 的讨论大会，通过相互的历史信息共享与多链路分析，共同决策大节点的用户满足策略。
这个方案，最大的问题是 token 消耗和通信时间。因为当时 GPT4 的并发很少，每次玩一盘至少40分钟，一盘消耗十几美元。后面大家都觉得太重了，就没再优化。
autogen 和 autoagent 虽然样子差不多，但是原理有点不同，大佬说 autogen 的一个核心设计原则是精简和使用多智能体对话来整合多智能体工作流。这种方法还旨在最大限度地提高实现的可重用性 agents。我个人的理解是通过 agent 生产 agent 的思路，提高通用性自动性，减少人为投入。
应用这个思路，我们做了一个稍微复杂一点的角色对话游戏。大致逻辑是这样的：每个角色有自己的背景设定 system，同时用户与角色开启对话会有一个预置的聊天故事背景（比如两个人在大学校园初次见面之类的）；用户与角色进行对话的时候，会有个监控 agent 监控这个对话流，并输出对应的分析策略（比如 AI 需要聊的激进一点、热情一点、冷酷一点之类的）；然后还会有一个进度 agent 去分析对话进度（比如聊到何时两个人差不多没话题了，需要转换场景）；当确定转换场景后，会有一个场景 agent 根据上文用户与 AI 的聊天内容、上一个聊天背景故事，来去生成下一个场景，推进两人进入新的场景继续聊天，相当于电影里的转场。
对于场景化 agent，最终我们并没有让其自主选择工具、调用工具、生成调用代码，因此没有工具描述区，如果通用的 agent 可能会出现这部分。
示例使用要谨慎，最好在测试时多关注下模型对示例的抄袭情况，同时增加防抄、发散的提示。
但同时，有时不用示例，你在大多数情况下要增加很多的额外描述来让其了解任务，且不一定有好的效果。因此示例的使用和示例的选择是要一直尝试的。
关键词示例给的太多，模型会更关注前面的，比如创作场景时，我们告诉他可以借鉴玛丽苏、韩剧、小时代等类型，类型写的很多，但是不一定就能提升模型发散效果，导致模型的创作可能会偏于重复。
注：prompt 内容是 agent 效果的核心，最重要的是逻辑描述清晰。同时对 prompt 的迭代调整上也最好采用控制变量法，只变动一个模块来做调整，防止多个模块 prompt 相互影响导致难以定位问题。
斯坦福小镇的项目大多数人应该都听过，就是让一堆 AI 角色在一个镇子里自由生活，这个开源项目我们也复刻过，当时发现一个很大的问题，我把他称为信息螺旋（没有外部信息输入，固定的信息在通信螺旋中不断的增强，导致最终趋同）。因为在斯坦福小镇中，每个 AI 对话的人设固定，并且都调用一个大模型，虽然他们通过对话产生了新的对话历史，但是对话不可避免的会与人设信息相关；同时大模型在参考历史生成对话时，会被经常提到的名词等强化，导致 demo 跑到最后所有的AI都在重复类似的话语。
那怎样承载这个框架呢？我想到了特德姜的一篇小说《软件体的生命周期》（推荐一看）。大致思路就是，每个用户有个数字宠物，数字宠物再虚拟空间中和其他的数字宠物一起玩耍，同时数字宠物会主动找外面现实世界的主人聊天，分享他在虚拟空间的活动，然后现实的主人也能进入数字空间中跟宠物们一起玩耍。这样，其实就形成了信息有效的内外双循环。但是最终没有去实现，看看到底效果如何，感觉比较可惜。