<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>复盘 on GbyAI</title>
    <link>https://blog.gby.ai/series/%E5%A4%8D%E7%9B%98/</link>
    <description>Recent content in 复盘 on GbyAI</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh</language>
    <copyright>Content under license [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)</copyright>
    <lastBuildDate>Mon, 01 Jul 2024 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.gby.ai/series/%E5%A4%8D%E7%9B%98/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>现阶段做智能客服 agent 的复盘（持续补充）</title>
      <link>https://blog.gby.ai/medical-beauty-agent-review/</link>
      <pubDate>Mon, 01 Jul 2024 00:00:00 +0000</pubDate>
      <guid>https://blog.gby.ai/medical-beauty-agent-review/</guid>
      <description>有一些动作在规划中没有实际动作，因为后期智能客服项目有交接，不过作为一个真心喜欢 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.</description>
    </item>
  </channel>
</rss>
