你的Agent稳定吗?——基于大模型的AI工程实践思考

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 本文总结了作者在盒马智能客服的落地场景下的一些思考,从工程的角度阐述对Agent应用重要的稳定性因素和一些解法。

一、背景

随着大模型技术的发展,越来越多的大模型应用开始涌现,并且应用到越来越多的业务场景中,比如AIGC生图、小蜜机器人、客服机器人、自动文档处理等等;并且Agent的planning能力使得基于大模型的底座,AI应用可以处理越来越高级的事情。但是随着大模型的广泛应用,在面对各种复杂的场景时,其稳定问题也变得凸显,比如Agent的回答幻觉问题、知识语料训练质量问题、工程重试和异常处理问题,都对Agent的稳定性有影响;当然基座的能力也至关重要,但是本人从工程的角度来阐述同样对Agent应用重要的稳定性因素和一些解法。

本人目前在参与盒马AI智能应用的项目中,包括智能小蜜机器人、智能客服、AIGC等项目,本文也是在盒马智能客服的落地场景下的一些思考。  

image.png

二、Agent的简单介绍

AI Agent,即人工智能代理,是一种能够感知环境、做出决策并执行操作的智能实体。与传统的人工智能不同,AI Agent 具备自行思考并使用工具逐步实现目标的能力。举例来说,如果你告诉 AI Agent 代理的退款系统进行退款办理,它可以通过意图确认(退款哪个商品、退款原因、退款是否和比例判断)和用户进行交互,并自动调用退款系统进行退款,无需人工指定每个步骤。

image.png

其中关键模块:

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的语料以自然语言为主,但是在客服、小蜜等大量的语料场景中,卡片非常多。比如类似这种:

image.png

那么在语料中,可能就是(随意以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运转抽象如下:

image.png

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格式,实际的格式还是会在单模型中有随机性,并且在不同模型的回复中有明显的差异性;适配变得很重要。

image.png

比如一个两级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 参数的值让结果更稳定。

最近业界进展:

image.png


OpenAI近日在其API引入了结构化输出,这应该会缓解JSON解析的问题,待更新和跟进验证其效果。

四、监控

首先从监控的视角,一个系统,无非是很多点连成的线,对于每个点的监控以及端到端的监控,是常见的思路;目前这里先focus在重要节点的监控,其维度如下:


4. 1 LLM维度的监控

image.png


4.2 Tool调用监控

这里有的Tool耗时慢,因为背后是大模型的服务。

image.png


4.3 RAG监控

 image.png

核心的目标,就是监控大模型的调用情况,Tool的调用情况,目前先用Sunfire做一版简单的版本。





来源  |  阿里云开发者公众号

作者  |  庭初




相关文章
|
11天前
|
人工智能 Java 测试技术
低成本工程实践-AI帮我写代码做需求
本文主要讲述,以“无需训练模型”的方式实现:AI智能分析功能需求、写代码、review代码解决特定业务问题的实践过程
低成本工程实践-AI帮我写代码做需求
|
9天前
|
人工智能 自然语言处理 搜索推荐
如何让智能客服像真人一样对话?容联七陌揭秘:多Agent大模型
科技云报到原创。 经历了多年的“答非所问”、“一问三不知”,很多人已经厌倦了所谓的“智能客服”。哪怕是技术已经非常成熟、可以模拟真人发音的外呼机器人,也会因为“机感”重而被用户迅速挂机或转向人工客服。 智能客服似乎遇到了一道坎,在理解用户、和用户对话方面,始终无法实现真正的“智能”。然而大模型技术的出现,让智能客服看到了前所未有的曙光——基于大模型特有的生成式技术和智能的涌现,让智能客服越来越逼近人们想象中的样子。 但问题是,仅有大模型就够了吗?大模型技术要如何引入智能客服才能落地?落地后的大模型究竟如何在智能客服具体场景中发挥作用?又能为客服行业带来了哪些改变?更进一步,对于企业和
如何让智能客服像真人一样对话?容联七陌揭秘:多Agent大模型
|
2天前
|
人工智能 搜索推荐 算法
AI与未来教育:个性化学习的实践
【10月更文挑战第3天】在21世纪科技浪潮中,人工智能(AI)正重塑教育领域,尤其在个性化学习方面展现出巨大潜力。本文探讨了AI如何通过智能评估、定制化学习路径、情感识别及虚拟助教等方式,提升教育质量和效率,激发每个学生的学习潜能。尽管面临数据隐私和技术普及等挑战,AI与未来教育的融合正开启新篇章,有望实现真正的“因材施教”。
|
10天前
|
人工智能 安全 算法
5年数据观巨变,这家公司如何在AI和大模型数据赛道遥遥领先?
5年数据观巨变,这家公司如何在AI和大模型数据赛道遥遥领先?
|
7天前
|
存储 人工智能 弹性计算
函数计算部署 AI 大模型解决方案测评
函数计算部署 AI 大模型解决方案测评
|
8天前
|
人工智能 运维 大数据
阿里云“触手可及,函数计算玩转 AI 大模型”解决方案评测报告
阿里云“触手可及,函数计算玩转 AI 大模型”解决方案评测报告
21 1
|
9天前
|
人工智能 自然语言处理 API
深入浅出 LangChain 与智能 Agent:构建下一代 AI 助手
我们小时候都玩过乐高积木。通过堆砌各种颜色和形状的积木,我们可以构建出城堡、飞机、甚至整个城市。现在,想象一下如果有一个数字世界的乐高,我们可以用这样的“积木”来构建智能程序,这些程序能够阅读、理解和撰写文本,甚至与我们对话。这就是大型语言模型(LLM)能够做到的,比如 GPT-4,它就像是一套庞大的乐高积木套装,等待我们来发掘和搭建。
|
7天前
|
人工智能
AI工具:Gnomic智能体
AI工具:Gnomic智能体
17 0
|
8天前
|
人工智能 Cloud Native 调度
阿里云容器服务在AI智算场景的创新与实践
2024年云栖大会,我们总结过往支持AI智算基础底座的实践经验、发现与思考,给出《容器服务在AI智算场景的创新与实践》的演讲。不仅希望将所做所想与客户和社区分享,也期待引出更多云原生AI领域的交流和共建。
|
8天前
|
数据采集 机器学习/深度学习 人工智能
云栖实录 | GenAI 时代 AI Infra 工程技术趋势与平台演进
本文根据2024云栖大会实录整理而成,演讲信息如下: 演讲人:林伟 | 阿里云智能集团研究员、阿里云人工智能平台 PAI 负责人;黄博远|阿里云智能集团资深产品专家、阿里云人工智能平台 PAI 产品负责人 活动:2024 云栖大会 - AI Infra 核心技术专场、人工智能平台 PAI 年度发布专场
下一篇
无影云桌面