一、背景
随着大模型技术的发展，越来越多的大模型应用开始涌现，并且应用到越来越多的业务场景中，比如AIGC生图、小蜜机器人、客服机器人、自动文档处理等等；并且Agent的planning能力使得基于大模型的底座，AI应用可以处理越来越高级的事情。但是随着大模型的广泛应用，在面对各种复杂的场景时，其稳定问题也变得凸显，比如Agent的回答幻觉问题、知识语料训练质量问题、工程重试和异常处理问题，都对Agent的稳定性有影响；当然基座的能力也至关重要，但是本人从工程的角度来阐述同样对Agent应用重要的稳定性因素和一些解法。
本人目前在参与盒马AI智能应用的项目中，包括智能小蜜机器人、智能客服、AIGC等项目，本文也是在盒马智能客服的落地场景下的一些思考。
二、Agent的简单介绍
AI Agent，即人工智能代理，是一种能够感知环境、做出决策并执行操作的智能实体。与传统的人工智能不同，AI Agent 具备自行思考并使用工具逐步实现目标的能力。举例来说，如果你告诉 AI Agent 代理的退款系统进行退款办理，它可以通过意图确认（退款哪个商品、退款原因、退款是否和比例判断）和用户进行交互，并自动调用退款系统进行退款，无需人工指定每个步骤。
其中关键模块：
prompt：提示词；
Chain: 将多个任务或操作按照一定的顺序组合起来，以实现特定目标的方法；
LLM：大模型基座；
Tools: Tool的参数定义、描述定义和逻辑实现；
Actions: Agent Planning下一步做的事情；
三、Agent面临的稳定性问题
首先从业务场景来看，本人以客服机器人这个典型应用场景为例：
业务背景：电商；
知识结构：知识库（QA形式维护，且有相似问）；
用户群体：售前咨询/下单顾客；
Agent功能：作为人工客服回答用户问题；
3.1. 幻觉问题
3.1.1 原因
幻觉问题在LLM（大型语言模型）应用开发中是一个常见的问题。幻觉指的是模型在生成文本时产生的错误信息、无根据的断言或不真实的内容。这些内容虽然可能看起来表面上合乎逻辑和流畅，但它们并不基于事实或现实的数据。其原因包括：
1.数据训练不足或质量不高：模型可能基于有限或不准确的数据进行训练，导致其生成的内容缺乏真实依据；
2.模型复杂性：复杂的模型可能更容易产生不合理的联想和推断；
3.语言和语义的复杂性：自然语言本身具有模糊性和多义性，这可能导致模型产生误解。
3.1.2 RAG增强
- 通过基于知识召回的RAG，初步解决80%的幻觉问题；
- 通过prompt提示，在RAG也没相关的情况下，给出没知识不要硬达或者乱达的提示，缓解幻觉问题；
- 语料训练，通过算法的微调让模型学习真实的正确小二回答数据；
说明：不同业务场景对于RAG的要求有区别，像内外小蜜等小蜜系列，关于RAG非常深的研究，包括检索、生成等，小蜜场景更多是一问一答，对于RAG的知识质量要求非常高；而在Agent的场景中，Agent重点是planning能力和Tool精准调用的，但是RAG仍然是Agent重要的模块，是Agent稳定性的保障。较好的RAG实践可以参考：《RAG优化方案与实践》
3.1.3 Memory补充
对于业务场景，很多时候用户本身的信息，决定了回答的准确度。比如一个简单的case：
user: 我的XX卡折扣是多少？ aiAssistant: ?
知识库中的信息假设是：
Query: 我的XX卡能打几折？ （相似问：XX卡的折扣是多少？XX卡怎么打折的......） Answer: 对于初级会员打5折，对于高级会员打6折，对于XX会员打XX折；
那么当没有用户身份的时候，进入大模型的回答，基于RAG成功召回的case，大概率会是对于Answer的改写。
user: 我的XX卡折扣是多少？ aiAssistant: 您好，我们的会员卡对于不同会员折扣不同，初级会员是5折，.....
少数情况会直接吐出一个折扣或者反问；直接吐出的情况就有概率错误；反问的话，其实逻辑上没问题，但是对于可以直接获取的信息，其实增加了Agent对话的复杂度，不够智能。优化：1.将memory信息代入用户的prompt，构建对于业务有判断作用的信息，包括用户信息、订单信息（咨询主体）、店铺信息，用于帮助RAG发挥更大的效果，比如用户是高级会员的信息代入memory并进入prompt，最后的效果就是如下：
user: 我的XX卡折扣是多少？ aiAssistant: 您好，您是尊贵的高级会员，XX卡可以享受6折的折扣优惠；
2.其中某些对象可能会随着用户的咨询而更新，比如用户的咨询主体，要保证memory有每轮次ReAct前更新的操作。
3.1.4 工程优化
1.query重写辅助RAG更好的召回进行query重写，补全语句缺失实体，或者错误语义改写一下，提升RAG召回的成功率；技术方案也是走LLM的；比如：
user: 我买了个糕点吃不完了 aiAssistant: 您好，您是买的哪一款糕点，有什么问题呢？ user: 保质期多久呢
改写之后：
user: 我买了个糕点吃不完了 aiAssistant: 您好，您是买的哪一款糕点，有什么问题呢？ user: 糕点的保质期有多久呢？
2.知识的脏数据和及时性问题这是比较棘手的问题，知识库中有一些过时的数据，但是其关键字又很像，结果被embedding召回回来产生了干扰，RAG的质量，还是较强的依赖源头本身知识的质量；需要业务配合进行正确维护和管理。
3.2. 语料质量问题
核心：尽可能获得高质量的线上业务数据，用于微调。
3.2.1. 问题
在电商领域为例，现阶段的核心数据是语料，但是其中包含大量的卡片，大模型对于卡片的理解能力偏弱。
3.2.2 解法思路：语言化
因为LLM的语料以自然语言为主，但是在客服、小蜜等大量的语料场景中，卡片非常多。比如类似这种：
那么在语料中，可能就是(随意以JSON举个例子，实际要复杂)：
user: 我买的苹果保质期多久 aiAssistant："{\n" + " \"type\": orderSelector,\n" + " \"width\": 5,\n" + " \"height\": 3,\n" + " \"orderId\": 12345,\n" + " \"showXXX\": false,\n" + " \"title\": \"请问是。。。。。\",\n" + " \"itemName\": \"\",\n" + " ....\n" + "}" user: "{\n" + " \"type\": \"XX\",\n" + " \"isSelect\": true,\n" + " \"content\": \"orderId: XXXX\",\n" + " \"content\": \"orderName: XXXX\",\n" + " ....\n" + "}"
那么这样的语料灌进LLM推测或者训练，对于大模型就很吃力了。那么"化个妆"呢，我们再看一下这样的：
user: 我买的苹果保质期多久 aiAssistant：请问您是要确认XX时间买的XX元的XX商品订单吗？(目前这个订单状态是XX) user: 是的，我就是确认这个XX商品订单的问题
好了，这时候大模型不用去管无聊的JSON结构和Id这种字段了。并且可以通过拼接直接实现，可以对整个电商的所有卡片，基于type格式，在Agent运转层/语料层进行重写；大大提升电商卡片场景的理解程度。总结一下优点：
- 可以基于占位符做快速的生成（较好的做法是为卡片加一个大模型属性，可以生成其toPromptString()的结果）；
- 减少token，LLM调用速度加快；
- 大模型理解文本，回答的效果变好；
3.2.3 需要优质的打标体系
- 需要标注同学的精准打标；
- 支持小二（AI托管后 1VN 模式的监管员）自主托管阶段对于异常点的判断打标，尤其是有些bad case，小二业务的直觉是更有经验和指导意义的，每次的bad case解决都是稳定性逐步提升的台阶；
3.3. 工程稳定性
由于agent并不是永远稳定，其输出的内容和格式存在一定的随机性，对于ReAct模式，可能会有陷入循环的问题，导致Agent智能体不响应；其次Agent可能会遇到较多的异常case，其表现可能是未知的，所以需要对于Agent框架进行异常的处理和兜底；一个简单的Agent运转抽象如下：
3.3.1 控制循环轮数
首先，Agent的rethink模式，决定了一些异常case下大模型是可能陷入循环问题（比如成功调用Tool输出，但是没有相关数据，Agent可能会一直调用）。
- 通过限制轮数/设定时间上限上限解决死循环问题；
- prompt中说明同一个Tool，一轮ReAct两次调用仍未拿到结果时，不再重复调用该Tool（因为这种情况大概率是接口成功，但是数据字段缺失）避免这种常见的陷入循环case。
3.3.2 Agent异常时如何合理的尝试？
对象包括组装prompt、LLM调用、输出解析、Tool调用，这边Agent建议按照特点决定是否重试某些模块。定义重试异常类型：
- RPC/HSF调用失败（认为HSF的超时是偶发波动，毕竟1-3s的HSF出现是低概率情况，从HSF自身治理解决）；
- 1s以内的Http服务调用失败；
定义非重试异常类型：
- 重试代价高的（超过1s的）；
- 有幂等性的Tool；
- 其他handle不了的异常；
重试的主体有哪些？
- Agent-LLM调用超时重试否？
- 不重试，抛异常，加监控，观察LLM基模稳定性；
- Tool调用异常重试否？
- 使用LLM的Tool客服场景不重试，这里为了功能的丰富性，有的Tool背后不是RPC而是LLM；（考虑用户体验问题，LLM每次的调用都是秒级的，不断重试，会让时间到十几秒甚至20s；ps: 目标10s以内回复）；
- 其他场景，比如使用RPC的Tool调用，都是可以使用重试框架的；
- prompt组装模块是否重试；
- prompt的RAG模块目前是LLM接入，暂不重试；
那么有些异常不重试的情况怎么办呢？
3.3.3 代替人的Agent 的兜底------人工托管
重要场景下的AI应用一定是要有人工托管的，从copilot模式像AI托管模式迈进，这是渐进的必要灰度保障和最后兜底；就像武汉的萝卜快跑背后是有人工监管的，在重要的情况完成接管。在电商客服Agent场景也是，在无法解决的场景和异常时，Agent通过返回接管信号，让背后的小二进入接管AI，恢复人工对话模式。Agent主动要求人工介入的时机：
- 异常情况，比如非handle异常，需要人工介入，和用户继续聊天；
- 未覆盖情况；
- 业务场景未覆盖，那么需要人工处理；实操上，大模型识别用户意图但是没法处理到之后，不是抛出异常，而是抽象为一个统一的转人工工具，由人工进行接管；
- 多模态基座未接入，那么对于用户发图片、视频和语言就需要人进来处理；
总之，人工托管的兜底，给了Agent应用可以先灰度上线积攒宝贵经验的可能，再通过扩大Agent基座能力和业务场景，逐步完善Agent能力。
3.3.4 Agent输出格式的兼容
和孔乙己回字的N种写法一样，在实际很多Agent中，期望大模型的回复是一个JSON的String格式，实际的格式还是会在单模型中有随机性，并且在不同模型的回复中有明显的差异性；适配变得很重要。
比如一个两级JSON实际返回的结果有四种情况：
"Tools": { "api_name": "XXTool", "parameters": [ { "name": "xxId", "value": "12345" } ] }
"Tools": [{ "api_name": "XXTool", "parameters": [ { "name": "xxId", "value": "12345" } ] }]
"Tools": [{ "api_name": "XXTool", "parameters": { "name": "xxId", "value": "12345" } }]
"Tools": { "api_name": "XXTool", "parameters": { "name": "xxId", "value": "12345" } }
- JSON兼容那么对于LLM输出，一开始头疼的就是，为了Agent功能的强大，其实LLM本身是多个JSON结构嵌套，但是JSONObject和JSONArray；这边就是在工程侧进行了兼容；
- 异常LLM输出的拯救：比如JSON格式基本都对了，但是来个中文的引号，就又不行了，所以对于有些细碎的场景，做了补丁，尽可能把bad case解决；异常处理的实现细节：
1.构建清晰和典型的few-shot，在prompt中给出示例；
2.实现一个异常处理链路，比如先做剔除前后空字符的直接JSON解析，再进行中文冒号的异常case替换尝试解析，再进行花括号缺失情况的异常case匹配(补充花括号)；那么所有链式节点尝试都失败了，那就报错；（链太长时也可以考虑并发一下）
3.如果还是不稳定。尝试降低 temprature 参数的值让结果更稳定。
最近业界进展：
OpenAI近日在其API引入了结构化输出，这应该会缓解JSON解析的问题，待更新和跟进验证其效果。
四、监控
首先从监控的视角，一个系统，无非是很多点连成的线，对于每个点的监控以及端到端的监控，是常见的思路；目前这里先focus在重要节点的监控，其维度如下：
4. 1 LLM维度的监控
4.2 Tool调用监控
这里有的Tool耗时慢，因为背后是大模型的服务。
4.3 RAG监控
核心的目标，就是监控大模型的调用情况，Tool的调用情况，目前先用Sunfire做一版简单的版本。
来源 | 阿里云开发者公众号
作者 | 庭初
