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





prompt：提示词；

Chain: 将多个任务或操作按照一定的顺序组合起来，以实现特定目标的方法；

LLM：大模型基座；

Tools: Tool的参数定义、描述定义和逻辑实现；

业务背景：电商；

知识结构：知识库（QA形式维护，且有相似问）；

用户群体：售前咨询/下单顾客；

3.1.1 原因

1.数据训练不足或质量不高：模型可能基于有限或不准确的数据进行训练，导致其生成的内容缺乏真实依据；

2.模型复杂性：复杂的模型可能更容易产生不合理的联想和推断；

3.1.2 RAG增强

• 通过基于知识召回的RAG，初步解决80%的幻觉问题；

• 通过prompt提示，在RAG也没相关的情况下，给出没知识不要硬达或者乱达的提示，缓解幻觉问题；

• 语料训练，通过算法的微调让模型学习真实的正确小二回答数据；

3.1.3 Memory补充

user: 我的XX卡折扣是多少？aiAssistant: ?

Query: 我的XX卡能打几折？

（相似问：XX卡的折扣是多少？XX卡怎么打折的......）

Answer: 对于初级会员打5折，对于高级会员打6折，对于XX会员打XX折；

user: 我的XX卡折扣是多少？aiAssistant: 您好，我们的会员卡对于不同会员折扣不同，初级会员是5折，.....

user: 我的XX卡折扣是多少？aiAssistant: 您好，您是尊贵的高级会员，XX卡可以享受6折的折扣优惠；

3.1.4  工程优化

user: 我买了个糕点吃不完了aiAssistant: 您好，您是买的哪一款糕点，有什么问题呢？user: 保质期多久呢

user: 我买了个糕点吃不完了aiAssistant: 您好，您是买的哪一款糕点，有什么问题呢？user: 糕点的保质期有多久呢？

3.2.1. 问题

3.2.2 解法思路：语言化



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"            + "}"

user: 我买的苹果保质期多久aiAssistant：请问您是要确认XX时间买的XX元的XX商品订单吗？(目前这个订单状态是XX)user: 是的，我就是确认这个XX商品订单的问题

• 可以基于占位符做快速的生成（较好的做法是为卡片加一个大模型属性，可以生成其toPromptString()的结果）；

• 减少token，LLM调用速度加快；

• 大模型理解文本，回答的效果变好；

3.2.3 需要优质的打标体系

• 需要标注同学的精准打标；

• 支持小二（AI托管后 1VN 模式的监管员）自主托管阶段对于异常点的判断打标，尤其是有些bad case，小二业务的直觉是更有经验和指导意义的，每次的bad case解决都是稳定性逐步提升的台阶；



3.3.1 控制循环轮数

• 通过限制轮数/设定时间上限上限解决死循环问题；

• prompt中说明同一个Tool，一轮ReAct两次调用仍未拿到结果时，不再重复调用该Tool（因为这种情况大概率是接口成功，但是数据字段缺失）避免这种常见的陷入循环case。

3.3.2 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 的兜底------人工托管

• 异常情况，比如非handle异常，需要人工介入，和用户继续聊天；

• 未覆盖情况；

• 业务场景未覆盖，那么需要人工处理；实操上，大模型识别用户意图但是没法处理到之后，不是抛出异常，而是抽象为一个统一的转人工工具，由人工进行接管；

• 多模态基座未接入，那么对于用户发图片、视频和语言就需要人进来处理；

3.3.4 Agent输出格式的兼容



 "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 参数的值让结果更稳定。