https://blog.gby.ai/tags/%E6%99%BA%E8%83%BD%E5%AE%A2%E6%9C%8D/ Recent content in 智能客服 on GbyAI Hugo -- gohugo.io zh Content under license [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/) Mon, 01 Jul 2024 00:00:00 +0000 https://blog.gby.ai/medical-beauty-aigc-agent/ Sun, 12 Nov 2023 00:00:00 +0000 https://blog.gby.ai/medical-beauty-aigc-agent/ 自 23 年 1 月 OpenAI 爆火之后，体验过由 AI 带来的转变，于 23 年 6 月转入 AI PM。在当时的所思所想所做，部分落地思路以及效果是领先于行业的。我认为像是医疗相关的垂直行业如果可以做的好，那么别的也不在话下。有可能目前我们的技术达不到产品想要的效果，但是我理解并且坚信奥特曼所说： “以通用人工智能的实现为前提进行创业和技术开发” “最正确的做法是设想一个上帝般的模型正在运作，然后基于这种设想来构建最好的产品” 一、背景 年初以来 ChatGPT 迅速走红后，成功引爆了人工智能行情。人工智能板块行情的涨幅以及持续时间都远超最初的市场预期。 比尔·盖茨认为，“ChatGPT 的重要性不亚于互联网的发明”。同样，ChatGPT 即将创造的新业态、新模式也不会亚于互联网。 AI 正在掀起第四次工业革命，AI 大模型的竞争是下一代信息分发获取方式的竞争，基于认知智能等新技术可实现更高效的信息整合和知识推荐，让信息获取更加高效，内容更加精准。 大模型的成熟加速了 AI 技术向各场景的应用。 医美行业作为第三产业，其作为涵盖人数最多，覆盖面最广的行业之一，医美数智化转型是大势所趋。 撇开 ToC 的场景，针对 B 端需求来说，场景太多了，每一个都值得深挖： 企业知识库：网易 QAnything、Danswer、AnythingLLM 等 OA 办公方面各种助手：Microsoft 365 Copilot、WPS AI、百度如流、飞书智能伙伴等 底层模型 SaaS 服务：minimax、文心一言、OpenAI API 等 HR 方向：MOKA 简历自动筛选匹配 低代码和 RPA：fastGPT、dify、coze、N 8 N 等 电商：虚拟换装、秒出营销文案、辅助创造营销设计图、一键制定和分发优惠券、形成趋势分析等 辅助诊断：讯飞医疗、skinGPT（皮肤诊断+电商）、medGPT、宠物医疗 AI 在线问诊等 CRM：商机线索、潜客挖掘、销售预测、智能客服、数字员工、数字人、数据分析等 ... 智能客服是自擅长多轮对话的 ChatGPT 推出以来，被人们最先联想也是最容易业务对接的领域。也是一个老生常谈经久不衰的领域，大模型到底能为智能客服带来什么新生？ 二、难点 它山之石可以攻玉 那么既然大家都能想到智能客服，那么为什么到现在能够成功商业化的 AI 智能客服还没有批量涌现？ https://blog.gby.ai/medical-beauty-agent-review/ Mon, 01 Jul 2024 00:00:00 +0000 https://blog.gby.ai/medical-beauty-agent-review/ 有一些动作在规划中没有实际动作，因为后期智能客服项目有交接，不过作为一个真心喜欢 AI 行业的 PM，思考是不能停的，时刻保持空杯的心态 老规矩先总结：效果还是不错的嘿😁 “屎上雕花“ 是必不可少的，快速达到 80%的预期效果，剩下的 20%就需要沉下心来，深入到业务场景，不要觉得很细碎，好与不好就在这细碎之间，所有做的事情做好归类，最后来看的时候会发现，这也不少啊，而且多数经验在以后的 AI 项目中都可以用到。 一定要把 LLM 当做发动机的引擎，引擎必不可少但是并不代表全部车的性能，自己脑子里面要有整个架构，这样才不会一次模型的更新迭代就导致你做了一个笑话，你需要替换的只是现阶段你能用到的最好引擎，或者跟引擎有关的部分零件，而不是整车。多 workflow 多 LLM 配合一定程度上能够解决大部分问题，就好像油电混合?? 非常小且快速的意图识别分类模型，相当于是路由，用来做的事情有很多。 前置回复的判断, 例如：正品验证固定话术，销售话术触发 function call 的补充调用，例如：调用外部地图 API 查询路线信息 加载指定知识库内容，例如：询问最近的店内优惠，某医生的坐诊信息 对话内容变量提取模型和策略，用来做什么呢？ 推荐机构内符合提取变量的案例，商品，医生，例如：推荐一个价格在 1w 的注射除皱商品 重心放在做知识图谱，做长远的规划，而不是纯 RAG，数据是 LLM 的天花板，高质量的有结构数据是板中板。在去年的时候就跟公司申请要做但是一直没有批下来唉。 如果要做好智能客服这种项目，一个专业的金牌销售是你最终要达成的目标，团队里面具有这样的一个人用来分析构建 agent 的 workflow 是一大幸事，然而我并没有哈哈哈，辛亏自己也做过一阵子潘家园摆摊文玩的销售。 做机构独有数据整合，大部分回复差的 case 都是因为信息的缺失以及不准确 根据对话中的标志比如商品 id, 来聚合所有相关商品的问题，能收拢回复 90%以上的问题 自然私信中产生的问题 QA 依赖提示词+大模型不断提取 电话销售产生的录音记录也可以提取优质对话 机构未上商品到平台，但机构内有的商品 机构的预约信息处理 院内具有的仪器信息 院内定期活动优惠信息 光回复问题达不成销售的目的，需要归类优质的引导销售话术，金牌销售都是有套路的，可以基于大的类目，每一个类目做一个提示词上的 few-shot 示例 可以尝试做人的 RAG, 大部分的人具有相似的问题，把知识库挂在人的概念上，以对话内容做向量匹配不同人的问题库 对召回内容增加一个 workflow 判断信息点是否和聊天内容相关，避免非相关内容影响答案 每一个问题，先结合上下文重新思考与拆分之后，重新生成，再去检索。单独模型，用来改写 query，使用历史的相关问题作为数据集 例如： 用户： 约个时间注射 20U 单位的伊婉C AI 客服：亲，好的您直接下单到院即可，我们会有专人客服接待 用户：我上次注射的那个现在多少钱？ 最后一个问题，“我上次注射的那个商品还有么？ ”，是模糊的。 最后一个问题应该被重写为：“上次注射的 20 U 单位的伊婉 C 现在多少钱” 方式一直接在当前prompt中增加一个工作流提示词节点： Query 改写： rephrase an improved and expanded version of user question. https://blog.gby.ai/llm-pk-tradition/ Fri, 26 Jan 2024 00:00:00 +0000 https://blog.gby.ai/llm-pk-tradition/ 一、LLM 改变 AI 客服构建知识的过程 LLM现有对客服质量提高主要体现在构建知识上 体现AI客服构建差异主要有几个点：构建的速度和质量，以及AI将答案吐出去的效果和带来的用户体验的提升。 **从效果来看，最重要的是工单解决率。**解决率的定义一般是AI回复最后一轮后，用户间隔一段时间不再发文就可视作为工单已解决。在不同行业和客户意图下，解决率的差异非常大。 如3C卖家产品的排故相比游戏攻略咨询的解答难度就高很多，游戏攻略咨询可以轻松达到90%+的解决率，但3C排故解决率做到70%就很难。以3C类的Trouble Shooting为例，目前如果是传统的FAQ Bot，解决率能够达到70%-80%。这是一个比较高的解决率，达成有很多前置关键因素和条件，抛开算法效果优化等，最关键的是FAQ的构建质量。 LLM Bot可以做到在70-80%解决率情况下，比FAQ Bot花费更少的构建精力。在知识更新上，比FAQ Bot更加容易。 LLM可以提高知识构建的速度和质量 传统的AI客服需要花费大量的人力进行业务梳理和交付，需要逐条构建出QA List。而大模型本质上是一个生成模型，只要提供合适的语料和设计出COT（Chain of Thought），就能快速地构建知识。 对于大模型来说，输入来源可能是用户历史积攒的语料、用户网站的帮助中心，甚至之前客服的沟通记录，借助大模型可以快速将知识库拉到不错的基线水平。然后基于这个基线水平，再往上做精做细，从而提升知识的质量。 达到相同的解决率，基于大模型的构建ROI会比传统AI客服高很多。例如，如果都需要达到70%的解决率，之前的方案需要花费很长时间梳理和构建知识，需要设计一套Dialog Flow模板配置，此类的模板可能非常复杂。现在基于大模型方便很多，可以用几百条语料做到过去几千上万条语料的效果。 LLM可以加速FAQ的构建过程，但目前尚不能实现全部流程的自动化，需要行业的专业客服人员介入一起构建。如果客户对回答质量要求非常高，专业客服必须要介入构建的过程。 在大促和上新快的场景应用大模型构建尤其方便 传统的AI客服构建方法提供知识库给商家，商家按照知识库模板，商品粒度加上每个商品下面挂FAQ的方式构建结构化知识库。例如，一万个商品乘以每个商品对应的上百FAQ，FAQ的整体数量就会到百万级，整体量级太大造成非常难维护。在每次上新和活动期间，也都需要人工去动态配置。 LLM将传统非结构化知识变成结构化知识的过程跳过，可以直接基于非结构化知识进行构建。可以通过更原始的生产资料进行构建，例如Excel文档或者DOC文档。 以Excel为例，不同商家和供应商虽然都是Excel，但是表格中每个cell的粒度和内容都不同。行业属性，比如数码行业和服装行业，表格Schema格式不同。传统方法是将Excel转换为FAQ工作，现在可以通过LLM直接消化Excel文件，理解不同表格中的内容的含义以及每个cell的内容，然后就可以通过大模型进行商品信息问答。相当于商家上传Excel后直接基于Excel进行对话，这是工作上的极大简化。 **对于很多电商客户来说，运营的时效性要求很高，尤其是大促的时候。**不同电商平台的大促活动相关信息更新频繁，大促期间商品的卖法也会有变化，客户很难及时更新传统的知识库，这已经成为不少商户客服运营时候的瓶颈。LLM的出现可以节省人员和时间，在大促期间可以使知识库的更新更加灵活。 在尝试根据图片来构建，但还无法达到商用效果 现在也有一些尝试使用大模型将图片作为输入直接构建问答，依托商品的规格图和说明书PDF等。 这些图片和PDF没有必要翻译成文字，再翻译成FAQ提供给机器人。LLM模型能够在这个领域实现，可以直接通过看图说话。 这里的商业价值非常明确，但从实际效果来看，测试过许多开源模型，目前效果仍然不能达到商用，需要继续打磨。 二、LLM 客服的其他优势 LLM客服在语言、情绪帮助很大 出海场景上，很多客户需要提供多语言支持，同时需要提供8-9种语言的情况非常常见，LLM天生具备多语言转换能力。在传统的FAQ Bot上，针对不同语言、不同国家都需要重复配置，LLM可以只需配置一次。 特别对于SMB客户，成本不允许其在海外搭建客服中心，对于SMB出海客户的帮助是非常大的。 在不同场景意图下，解决情绪相关的问题也有一定的价值价值，例如在客户投诉意图下，情绪安抚就非常重要。从效果上来看，LLM的效果远远超过过去的NLP情绪识别，在回复上也更加贴合场景。 另外，当LLM识别出用户情绪变得越来越差时候，仍可将其转移到人工客服作为兜底的办法，进一步降低业务风险。 准确性与LLM的关联不大 LLM的方案仍然是进行知识召回，Ranking排序，然后提炼答案。这套体系在FAQ Bot和LLM Bot上差别不大，仍然是传统排序算法。 基于这套方法论后，最终答案是否出现在Top5或者Top10，称之为最终答案的hit rate，这体现了回答的准确性。LLM的工作主要体现在上游的构建内容，和下游的提炼总结、互动。 归根结底，准确性取决于知识库内的知识准不准，准确性的前提是标准答案存在。 LLM客服更容易获得更高的客户满意度 在关注ROI之外，也需要关注客户满意度指标，客户满意度很难直接用财务体系去换算。 例如LLM客服可以更加人性化，在沟通时候让客户觉得更加舒服，增加了复购，满意度本身的价值比较难量化。 在售前环节，LLM也可以提高转化率，也需要从GMV视角去折算成本。 三、LLM 客服在 Agent 上的探索 LLM客服的Task Bot需要用到Agent AI客服分为FAQ Bot和Task Bot，需要用到Agent，目的是解决用户业务查询和办理的需求。 以Trouble Shooting为例，如果排故排不了，需要补单退货，这时需要用户告知AI订单号，才能继续使用接口识别用户进行处理。 许多场景用户可能只能拍一张小票，实际订单号在小票里面，需要通过多模态模型验证订单号，例如现在应用GPT4就可以识别订单号了，就可以把整个流程走完。 因此在Task Agent形态里面，不光Agent非常重要，多模态也非常重要。对于AI客服公司来说，不会去挑战自研多模态这类这么困难的场景，更多是依赖目前领先的商业模型。 Task Bot仍然面临很多技术难点 幻觉在FAQ Bot和Task Bot中都存在，在检索问题和提问问题时候，存在问题未被覆盖时模型开始瞎编的情况，这是所有LLM Bot都会面临的长期挑战，但随着模型迭代，目前看到已经得到了很大幅度的优化。 在业务中，例如售后问题上，需要收集大量信息，去整合信息，并调用大量系统协同完成。以退款意图为例，，需要收集客户信息，包括订单、物流凭证单号等。同时，还需要处理这些单子并进行判责，判断是消费者还是商家的问题。内部还需要串联一系列系统，调用商家后台信息和物流信息，甚至还需要商家和消费者双方的历史信用、交易记录。在判责完成后，可能还涉及打款和结算。 另外，Agent的目的是提高整体的自动化率水平。目前已经有客户上线Task Bot了**（例如安克创新上线了Shulex Task Bot）**，在过程中需要通过邮件来询问用户的订单号和售后地址，中间可能还需要手机验证，每个环节都可能造成流程的中断。这方面的创业软件公司需要摸清楚每个场景下的所有流程，还需要与客户进行甲乙方联调，才能做到好的效果。 四、将 LLM 应用在电销上难度更大 电销有很多AI实践，但LLM替换比例仍然比较低