https://blog.gby.ai/series/%E4%BA%A7%E5%93%81/ 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/) Thu, 20 Mar 2025 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/aipm-skills/ Tue, 19 Mar 2024 00:00:00 +0000 https://blog.gby.ai/aipm-skills/ 随着机器学习、深度学习等 AI 技术的突破和应用场景的不断拓展,市场对能够将 AI 技术转化为实际产品和服务的人才需求急剧增加。 关于 AI PM 掌握算法知识的必要性 传统的软件/互联网 PM 在面对 AI 产品时,需要具备更专业的技术知识和独特的产品思维,因此 AI PM 作为一个更加专业化的 PM 角色逐渐形成。 AI 产品通常涉及复杂的算法、大数据处理等技术,同时又需要考虑用户体验、商业模式等因素。这就要求 PM 具备跨学科的知识背景,能够在技术和业务之间进行有效沟通和决策。 理解产品核心技术 了解基本的机器学习算法原理,有助于PM更好地理解AI产品的核心技术,从而做出更合理的产品决策。 与技术团队有效沟通 掌握一定的算法知识,可以帮助PM与开发团队进行更有效的沟通,减少信息不对称带来的误解。 评估技术可行性 在产品规划阶段,PM需要评估某些功能的技术可行性。了解算法知识可以帮助PM做出更准确的判断。 把握产品发展方向 AI技术发展迅速,了解算法前沿可以帮助PM更好地把握产品的未来发展方向。 提升产品竞争力 了解算法可以帮助PM发现产品的独特优势,提出创新的产品特性,从而提升产品的竞争力。 数据分析能力 很多AI算法都涉及到数据处理和分析,掌握相关知识可以提升PM的数据分析能力。 自身成长 对于自身来说能有效的对抗 AI 时代下的 信息流沙。 尤其是在这个新技术井喷的时代，每个人每天都会不停的接触新的知识。 在海量信息的环境下，信息超载和碎片化使我们对信息的质量和真实性难以辨别，有时候会产生一些无力感。 所以梳理一下目前自己接触或者学习过的一些知识，梳理成树🌲，也相当于一个便于查询的数据库，本人会一直归类和更新，欢迎留言共建。 知识分布 主要分为两部分，地基和新知 地基：主要为一些AI、NLP、算法等的基础知识。 新知：主要为最近两年直到当前比较新的知识内容，包括了深度的框架理解，优秀的产品和工具等。 全脑图（好像一个五彩斑斓的蝴蝶啊😆） 展开部分翅膀 飞书 WaytoAGI 地址: https://waytoagi.feishu.cn/wiki/VxO4wsOQyi6sLtkOPN4cT8OKnnd GitHub 文件地址（欢迎 star）： https://github.com/hellloveyy/AIPM-Skills-Tree 语雀实时更新链接 (啊，迁移到飞书太难了)：[AI 产品技能树]( https://www.yuque.com/gbyai/enltfn/hmzh5f3msehsvokb?singleDoc# 《AIPM_Skills》) https://blog.gby.ai/wechat-bot/ Thu, 20 Mar 2025 00:00:00 +0000 https://blog.gby.ai/wechat-bot/ 最近一段时间调研个微、企微机器人的结论，和一些结合微信比较好的项目 叠甲: 仅代表此时此刻 2025 年 3 月，调研不易，需要的盆友们各取所需吧。 开源项目 ： Wechaty 大部分微信机器人项目的基石，很多开源项目都是来源于此，支持的协议也是最多的，目前试用了它的网页版，基本的收发消息是可以用的，但是限制 2017 年之前注册的个微。iPad付费版慎用，听说被腾讯告了。 https://wechaty.js.org Wechat4u 支持个微，使用 Webhook 协议，github star 1.8 k https://github.com/nodeWechat/wechat4u ，大部分个人开发者使用的项目，包括 idoubi 开发的知了阅读（转发文章获取总结） Gewechat 支持个微，免费版 pad 协议，github star 2.5 k https://github.com/Devo919/Gewechat ，根据当前项目延伸出 dify-on-wechat, coze-on-wechat 等，gewechat要求必须搭建服务到同省服务器或者电脑里方可正常使用 Chatgpt-on-wechat 使用公众号、企微自建应用、钉钉、飞书等接入通道，其他通道为历史产物已不维护。感觉基本已经废废了，在 ChatGPT 火起来的时候狂飙 35 k star https://github.com/zhayujie/chatgpt-on-wechat ，当时还是支持个微的，企微是单独收费。前两天部署试了一下，历史的 Webhook 协议通道登录就被踢下线了。不过感觉可以联系一下官方使用收费版的 Pad 协议，替你们问过了专业版 7980+托管费 5000/账号/年 Dify-on-wechat 支持个微，继承自 Chatgpt-on-wechat，支持 itchat 协议（已废弃）、Gewechat 协议，Github star 2 k https://github.com/hanfangyuan4396/dify-on-wechat. Wechat-bot 基于wechaty 框架，支持企微和个微。建议使用 Pad 协议，Github star 8 k https://github. https://blog.gby.ai/a-brief-interpretation-of-deepseek-r1-from-the-perspective-of-aipm/ Thu, 06 Feb 2025 00:00:00 +0000 https://blog.gby.ai/a-brief-interpretation-of-deepseek-r1-from-the-perspective-of-aipm/ 近期，国内大模型公司DeepSeek发布的V3和R1模型引发了广泛关注，甚至被部分媒体称为“国运级创新”。我自己也深度体验了一下确实能力近似追平了 o1，阅读了不少文章，简单说说对产品上的影响，做个记录 一、核心创新：用更少的算力做更多的事 DeepSeek的核心突破在于提升大模型的效率，通过架构优化降低算力需求，这对产品落地成本有直接意义。 1. MLA（多头潜注意力）：压缩计算过程的“内存杀手” 问题：传统模型在生成文本时需反复调用历史数据（KV缓存），占用大量内存和算力。 解决方案：MLA通过数学压缩技术（低秩近似），将历史数据体积缩小至原来的1/4-1/8，同时保持关键信息。类似将高清视频转为压缩文件，既节省存储空间，又能快速解压使用。我的理解像是 comfyui 里面的 latent space 通过降维减少计算量 效果：计算效率提升2-4倍，长文本处理能力更强，适合需要多轮对话的场景（如客服、长文档分析）。 2. MoE（混合专家）架构：让模型“按需调用专家” 传统问题：通用大模型处理所有任务时需激活全部参数，算力浪费严重。 DeepSeek改进： 细粒度专家：将模型拆分为大量小型专家（100+个），每个任务仅调用少数相关专家（类似“分科室会诊”）。 负载均衡：动态调整专家调用频率，避免某些专家被过度使用（如“避免所有病人都挂同一个专家的号”）。 效果：相比传统模型，训练算力节省10倍，推理效率提升4倍以上，尤其适合通用场景（如搜索引擎、多任务助手、类似 ChatGPT 官网），但是并不适用 ToB 方向严重依赖 RAG 的场景 3. 训练框架优化：硬件利用率提升的“幕后功臣” FP8低精度训练：用8位浮点数替代传统16/32位计算，减少显存占用并加速训练（类似用简谱替代五线谱，保留核心信息但更高效）。 通信优化：通过定制化调度策略，减少GPU间的数据传输瓶颈（如优化物流路线，避免堵车）。 成果：万卡集群训练成本降低40%，模型迭代速度显著提升。 4. R1 的训练路径简图 二、对产品落地的实际意义 1. 成本优势 训练成本下降：V3模型的训练算力需求仅为同类模型的1/10，降低企业自研大模型的门槛。 推理成本优化：MoE架构在通用场景下激活参数更少，适合高并发服务（如智能客服）。 2. 场景适配性 To B场景：Dense架构（非MoE 的稠密架构，目前绝大多数模型的架构）在垂直领域仍具优势（如医疗诊断模型），需结合业务需求选择。 To C场景：MoE模型在通用问答、内容生成等场景性价比更高。 3. 长期技术红利 开源生态：R1模型性能接近OpenAI闭源模型，为中小团队提供高质量基座，对于输出质量的提升尤为明显，但是建议蒸馏一些小的开源模型效果会更佳，例如 32b 的 qwen 等 技术复用：MLA、MoE等优化方法可迁移至其他模型，推动行业整体效率提升。 三、澄清市场误读：技术突破≠颠覆生态 1. “打破CUDA垄断”？尚未实现 现实：DeepSeek仍依赖英伟达GPU，其底层优化基于CUDA生态的PTX指令（类似在Windows系统内做优化，而非自研操作系统）。 挑战：国产GPU尚未形成完整开发生态，短期难以替代。 2. “引发英伟达市值大跌”？过度关联 技术视角：MoE是行业常规演进方向，DeepSeek的优化反而验证英伟达GPU的潜力。 市场主因：股价波动更多源于美国政策风险及行业周期调整（算力显卡卖不到中国着急了哈哈） 3. “算力霸权转移”？为时尚早 算力需求仍在增长：模型效率提升会刺激更大规模应用，而非减少需求。 存储瓶颈更关键：未来竞争焦点可能是显存带宽（HBM），而非单纯算力。 四、给 AIPM 的行动建议 关注成本结构变化：MoE模型可降低通用场景的推理成本，在预算规划中预留架构切换空间。 评估场景适配性：To B垂直领域还是优先采用Dense模型，To C通用场景试点MoE。 跟踪开源生态：DeepSeek-R1的开源版本可作为低成本试错工具，快速验证产品需求。 Get your hands dirty 五、聚合一波了解 deepseek 最好的文章、视频、播客 了解渠道分类 地址 视频+文本非技术人员解读（非常推荐非常推荐） https://mp. https://blog.gby.ai/agent-platform/ Tue, 13 Aug 2024 00:00:00 +0000 https://blog.gby.ai/agent-platform/ 对目前市面上构建 agent 的平台和工具的一些思考 目前构建 agent 的产品形态越来越丰富了： 编码（langchain，metagpt） 拖拽工作流+插件（coze，dify，comfyui） 画布（flowith，glif） Prompt（gpts，glms） 文档（wordware） 最近 Product Hunt 上大火的 Wordware，其目的是降低 agent 构建门槛，让创建 agent 像 notion 文档一样简单，不需要懂 workflow、不需要懂代码即可完成复杂的 agent 构建。 列举一下目前比较火的其他 agent 构建平台 GPTs coze 以及类似大厂推出的平台（ModelScope，飞桨等） dify fastgpt glif AutoGPT 最新版支持模块化设置 Comfyui_LLM_party 以 comfyui 的形式构建类似 dify 的 agent 工作流 ... 是不是眼花缭乱，但是其实这些平台的目的也是为了降低构建 agent 的门槛，但是自从这些平台初始推出至现在，我就一直在想这类产品的构建者用户群体到底是谁呢？ 是对 AI 有兴趣的普通人吗？ 好像不是，因为对于这些人来说光是理解代码、工作流、记忆、变量等，这些概念就得好一阵子了 是专业的 LLM 研发工程师？ 好像也不是，因为他们看不上这些玩意儿，太低级了😁 那究竟是谁呢？ 我仔细想了想，代入了一下自己。好像更多的是我们这些 PM 渣渣，用来满足自己对于 AI 的一些探索乐趣，同时做一个 MVP。 最早的 agent 构建工具是 GPTs，通过自然语言描述来生成一个 agent 同时也带来了提示词工程的兴起。但是有一个弊端就是不可控，那时候即使在提示词中写好了 workflow 也有一大定的几率不按照规则去执行，尤其是较差的 LLM 那更是忽略你的 prompt 跟吃饭一样（比如那时候的文心一言 hhh） https://blog.gby.ai/linkedin-agent/ Wed, 31 Jul 2024 00:00:00 +0000 https://blog.gby.ai/linkedin-agent/ 基于 LinkedIn 上的信息流和职位，借助 AI 帮助用户评估是不是和职位匹配、了解某个公司的最新动态、面试和修改个人简历方面的建议，以及其他一些功能。 原文： https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product 他们做的产品时基于 LinkedIn 上的信息流和职位，借助 AI 帮助用户评估是不是和职位匹配、了解某个公司的最新动态、面试和修改个人简历方面的建议，以及其他一些功能。 从技术架构上来说，是一个多智能体的技术架构，主要分成三步： 路由：确定查询是否在范围内，并决定将其转发给哪个 AI 智能体。智能体的例子有：职位评估、公司理解、帖子总结等。 检索: AI 智能体决定调用哪些服务以及如何调用（例如 LinkedIn 用户搜索，Bing 搜索 等）。 生成: LLM 根据获取到的信息、原始问题和上下文去生成答案。 这其中路由、检索可以使用小模型，但生成内容需要使用大模型，这样才能有比较好的生成效果。 在整个项目的开发过程中，挑战是多方面的，有来自团队协作的，有来自大语言模型本身的 团队协作的挑战 首先在团队协作方面，最开始他们是按照智能体划分小组，各自负责，这样优点是开发速度快，但缺点是各自的提示词、对话历史、越狱防护等这些需要重复建设，用户体验不一致。 所以他们后来将组织架构进行了调整： 一个小组负责公共和底层框架，并且保证提供一致的体验，这样可以共享提示词模板、集中解决安全防护、统一用户体验等 多个小组负责垂直方向的智能体，基于公共组提供的框架优化提示词、连接后端 API等 数据检索的挑战 LinkedIn 有大量的用户资料、公司信息、还有一些其他的信息，这些数据更新很快，并且没有被大语言模型训练过，所以当用户请求时，需要能检索到用户想要的数据，而基于生成式 AI 产品的交互，不再是传统的关键字+选项的检索，而是完全自然语言的检索，这就需要先调用一次 LLM 帮助将自然语言转化为 API 调用。另外传统的 API 是给传统的 App 使用的，返回的数据冗余很多，并不适合 LLM 使用，所以需要针对 API 做一些针对 LLM 的优化。 举例来说，用户可能会询问：“请给我推荐西雅图的待遇好的公司”，那么针对这样的查询，首先需要去根据用户的身份找出来用户自己的职业（比如Java后端开发工程师），然后将用户资料+咨询的问题+可用的检索API，一起交给 LLM，LLM 将请求分解成适合 API 查询的参数： 职位搜索 API * 职位：Java 后端开发工程师 * 地点：西雅图 * 排序：工资由高到低 然后去调用 API，API 返回结果后，将返回结果、用户原始问题、历史对话一起交给 LLM，最终生成答案。 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/toc-partner/ Fri, 08 Mar 2024 00:00:00 +0000 https://blog.gby.ai/toc-partner/ 持续更新中... 文字后续补充 一、产品框架脑图 区别于目前 ToB 智能客服： 意图识别需要更为精细，涵盖范围更广 增加调用工具模块，包括但不限于多模态介入、输出 记忆能力 实时搜素 二、功能架构图 三、业务流程图 SOP 四、功能详述 Ⅰ. 企微部分 公众号： 增加菜单 私人医美伴侣 角色选择（内置）: 点击进入落地页，展示不同人设的企微个人微信二维码 提供不同的捏人选择 添加好友 触发介绍语 存储用户唯一标识 企业微信接口对接 账号：需企微公司账号 服务商后台：https://open.work.weixin.qq.com/wwopen/developer#/sass/apps/list 注意！需要实现企微个人号，目前咨询企微内部人员并未开通企微个人号收发消息接（一期如果企微个人号暂时无法实现，可用微信个人号暂时代替，目标为打通整体流程，但是个人号封号风险较高） 自研调研： https://github.com/cheungchazz/WeChat-AIChatbot-WinOnly?tab=readme-ov-file https://wechaty.readthedocs.io/zh-cn/latest/ https://github.com/wechaty/wechaty#readme https://github.com/wechaty/puppet-padlocal 官方discard ：https://discord.gg/72VjQGzm https://github.com/leochen-g/wechat-assistant-pro?tab=readme-ov-file 第三方采买： 集简云AI智能销售/客户服务/内部咨询解决方案 LinkAI Ⅱ. 微信交互 用户输入发送内容 文字：支持 链接url：支持 语音：支持 图片：支持 前置回复：“嗯嗯 好漂亮啊，我能测脸型、发型、眼型、颜值、皮肤、眉形，还能模拟整形和 美妆模拟，所以你想测测啥😁” 用户回复内容判断意图识别调用不同的图像能力 tools 文件（Word、Pdf、Excel）：一期不支持 视频：一期不支持 其他：一期不支持 输出内容 拆分回复 多模态回复 语音回复调研 https://github.com/RVC-Boss/GPT-SoVITS/blob/main/docs/cn/README.md 粘性追问 延迟等待 3s 统一进行回复 每日主动推送，以下内容随机推送一条 功能推荐消息 拟人话术举例： "嘿，跟你说个事儿 你发我一个正面照片儿 我能帮你检测检测皮肤奥" 。基于以上的内容，需保证询问的随机性 了解用户消息 https://blog.gby.ai/wang-hui-wen/ Wed, 31 Jan 2024 00:00:00 +0000 https://blog.gby.ai/wang-hui-wen/ 原文 王慧文清华产品课 读后感 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替换比例仍然比较低 https://blog.gby.ai/lixiang-product/ Mon, 22 Jan 2024 00:00:00 +0000 https://blog.gby.ai/lixiang-product/ 01 | 导论：回归本质做产品 欢迎来到我的产品实战课，我是李想。 这一讲是课程的导论，在展开讲理想汽车的具体经验之前，我想先跟你讲一讲我们做产品的基本方法论。 你可能也知道，汽车是这个世界上最大件、最复杂的大众消费品。而智能电动车，因为智能化和电动化，复杂度又上了一个数量级。 2015年，我带领理想汽车开始造车的时候，团队是全新的团队，没人知道智能电动车应该怎么做，整个行业又是一片空白，很快就涌进了上百个新玩家，竞争异常激烈。在这种情况下，我们应该怎么去做产品？ 现在，理想汽车已经有4款产品，团队也已经超过两万人。站在今天的角度去回顾和总结，帮助我们走到现在的产品方法论，只有特别简单的两条： 第一条，关注用户价值，超越用户需求； 第二条，把组织也当产品来做，用组织的成长来支撑产品的成长。 就是这么简单的两条。所谓大道至简，越是复杂的事情，方法论反而不能复杂，而是需要足够简单，否则，目标就容易在复杂的细节中丢失，团队就不容易协同。 那这两条简单的方法论，是怎么作为总纲领来指导我们造车的？下面，我就来展开讲一讲。 关注用户价值，超越用户需求 先来讲第一条方法论，关注用户价值，超越用户需求。 产品肯定是要满足用户的需求，这是所有人做产品的基本出发点。 但是，在各行各业竞争越来越激烈的今天，这还不够，还得向前一步，超越用户的需求。智能电动车赛道上尤其是这样。为什么这么讲？有两个原因： 首先，智能电动车是一个超级热门、新技术又密集的新赛道。这你肯定也有感受，这个行业里充斥着各种各样的流行概念。用户的真实需求，特别容易被这些概念遮蔽。 比如，2015年，国内的智能电动车创业开始集中涌现的时候，大家对车讨论最多的，还是百公里加速这样的技术指标。那个时候，市场上没有卖得好的增程电动车，没有六座SUV，也不会有任何调研告诉你，用户需要这些。 其次，智能电动车又是耐用消费品，一辆车买回去，用户至少要用五六年。如果我们只满足用户眼前的功能需求，就很容易过时，被后边的新产品超越。 那怎么超越用户需求？ 没有特殊的方法，实事求是地讲，就是回归本质，认认真真回答两个最基本的问题： 我们的用户到底是谁？ 我们为用户创造的价值到底是什么？ 这是两个最基本的问题，也是最重要的问题。因为如果连用户是谁都没有定义清楚，怎么可能超越用户的需求？ 其实，这个道理每个做产品的人都知道。但在执行过程中，真正能做到的人，却很少。因为我们得跟人性的贪婪作斗争。 在创办理想汽车之前，我也有过一些投资经历，看过不少创业公司。我看到，很多创业公司的产品之所以失败**，其实都不是因为产品功能没做好、质量不够好，而是因为一开始就太贪心，既想服务A人群，又想服务B人群，还想服务C人群。**结果是，每个人群的需求都只覆盖了一部分，但哪个人群都没有完全满足，更别提超越他们的需求了。 在这一点上，理想汽车可以说是比较幸运的，我们从一开始，就坚定地选择了只服务家庭用户。甚至我们会讨论什么样的用户算家庭用户，比如一对新婚夫妻、没有孩子，算不算？或者夫妻俩没有孩子但养着一条狗，算不算？ 因为目标用户足够清晰，我们就能围绕着用户，做更深的研究洞察，我们才能设计出六座SUV这样的创新性功能，才能超越用户需求。关于这一点，我在后面市场选择、品牌定位、体验设计和用户研究这四讲，会展开来讲。 好，目标用户确定了，这是回答了第一个问题，用户到底是谁。但做产品还容易陷入的一个误区是，只满足用户表面上的需求，把这个当做用户价值。 就比如，手机普及之前，很多有绳电话的用户会提意见说，希望电话绳加长一些，因为他们打电话的时候，喜欢到处走。 但是，今天我们都知道，如果电话公司真去加长电话绳，就算加到10米，用户最后也会抛弃你，而去选择购买手机。因为用户真正的需求，不是更长的电话绳，而是打电话的时候可以自由走动，不受空间限制。手机才是根本的解决方案。 这个案例告诉我们什么？真正的用户价值，一定是帮助用户解决了某个问题，或者完成了某项任务，而不是仅仅提供了某个简单的功能。 但很多产品经理，特别容易把用户提出的方案，也当成他们的需求。这也是每个产品人都知道的那个经典理论，用户需要的不是钻头，那是他们自己的方案，他需要的其实是墙上的那个洞，甚至是他想挂上去的那幅画。 所以，在理想汽车，**我们会顺着用户提出来的方案，去找他内心更底层的动机成因，从而创造性地去满足用户最底层的需求。**在后面的课程中，我也会跟你分享，我们是怎么通过超越用户需求、关注用户价值，来设计出增程电动、六座 SUV 等创新性产品功能的。 打造组织产品：对抗惰性、惯性和无知 好，这是第一条方法论，再来跟你讲理想汽车打造产品的第二条方法论，把组织也当产品来做，用组织的成长来支撑产品的成长。 为什么这么说？如果是其他相对简单的产品，或许依靠一两个人就能做成，但是智能电动车这样复杂的产品，不存在一两个英雄单打独斗的可能性。更何况，智能电动车已经像智能手机一样，需要不停地升级迭代，这就需要持续成长的组织来支撑。 那怎么打造这样的组织？ 在理想汽车，我们有三个立足点，分别是对抗惰性、对抗惯性和对抗无知。 首先来看对抗惰性。 不管是做什么事儿，克服惰性，才会有基础的效率，做产品的当然也不例外。根据我的经验，产品要保证60分，不需要任何特殊的技巧，产品定义的每一步做扎实，用户需求验证的每一步做到位，该做的复盘、该做的迭代一步也不跳过去，就绝对可以保证合格线。 那怎么让团队能够克服惰性呢？个人层面靠好的工作习惯，组织层面靠流程。这两个专门的课题，后面团队标准和流程两讲中，我会专门跟你来讲。 再来看对抗惯性。 惯性我们一点也不陌生，不管你工作年限长还是短，平时开会、讨论问题，你一定会经常听到这样两句话：“大家都是这么干的”“过去一直都是这么干的”。 但做产品，最怕的就是这两句话。因为我们的目标是超越用户的需求，那就必须打破惯性。怎么打破？ 我的办法是，多思考“必要性”。也就是说，过去怎么干、别人怎么干不重要，唯一重要的是，要想超越用户的需求，什么事儿是必须干的。 看起来是非常简单的一个思维切换，但是对于从0到1做出有竞争力的产品，以及从1到10规划产品成长的节奏，都至关重要。这些我在后面讲产品节奏规划的时候，也会详细再讲。 最后再来看对抗无知。 什么是无知？这里我想说的是，当我们向前探索产品的新可能，进入“无人区”时，会遇到的挑战。这个时候，最大的难点在于，我们不知道自己不知道什么。 怎么突破这种无知？ 方法其实有很多，比如有必要借助一下“它山之石”，拓展学习的范围，不把视野局限在汽车行业。产品在这个行业进入了“无人区”，可能没有同行的经验可以参考，但并不代表没有其他行业公司的经验可以学习。 就比如，在智能化方面、在用户体验方面，华为和苹果，比我们走得更远、走得更快，他们就可以成为我们认真学习的对象。 再比如，**在组织内部，建立一种积极反思的氛围。**在理想汽车，有一点我还是挺自豪的，就是这些年下来，团队内部有一种时常相互挑战的氛围。我们的同事也经常会站在外部视角，来给自己的产品“挑刺”，这就能避免我们自己成为自己的限制，井底之蛙，王婆卖瓜。 这些方法，在后面的课程，我也会详细讲到，我们是怎么建立成长的氛围，对抗这种无知的。 课程地图 以上就是过去这些年，我带领理想汽车做产品的两条基本方法论，也可以说，是贯穿我们这门课程的两条主线。 那接下来，我就给你讲一讲，沿着这两条线索，接下来的课程咱们怎么学习。 在课程的第一模块，我会先带你解决产品的顶层设计。对于一个创业者，一个CEO，或者产品负责人来说，这是我们要做好产品的第一步。 其中定位、品牌、产品标准这三讲，就是在解决产品战略问题；而文化、团队标准两讲，是组织战略问题。产品和组织两个方面都做好顶层设计，团队才能把劲儿往一处使，都把功夫花在做好产品上。 接下来的第二模块，重点是产品的落地，我会跟你详细分享，理想汽车怎么从0到1打造出来第一款爆品，理想ONE。相对第一模块，这个模块讲的是具体战术，主要包括几个问题：用户需求分析、用户体验打造、技术路线选择、产品定价。 有了第一个爆款产品之后，第三模块，我们的重点又会回到组织，来看看怎么延续一款产品上的成功，从单一爆品，到多个爆品。实际上，这就是在看，怎么让成功经验，变成组织的能力。 在这个模块，我会重点跟你讲，从1到10的阶段，目标应该怎么定，节奏应该怎么安排，组织流程应该怎么优化，以及最后一个环节，怎么完成产品商业化闭环，也就是把产品卖出去的两个关键动作，门店管理和利润控制。 最后，我会跟你分享，如果我们能从10走向100甚至更多，我们是怎么构建“成长”这个核心驱动力的。 小结 好，这就是这门课程的学习地图。小结一下，这一讲，我们主要讲了理想汽车做产品的两个基本方法论： 一个是，聚焦用户价值，从而超越用户需求，打造出真正有产品力的产品； 第二个是，把组织也当作产品来打造，然后用组织的成长来支撑产品的成长。