https://blog.gby.ai/tags/agent/ Recent content in agent on GbyAI Hugo -- gohugo.io zh Content under license [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/) Tue, 29 Oct 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/about-gcc/ Tue, 29 Oct 2024 00:00:00 +0000 https://blog.gby.ai/about-gcc/ GCC 进化史 API 层面调用 > RPA 固定工作流 > 视觉模型推理 API 层面：基本不可能哈哈，能做也是像支小宝这种，大厂直接入场。第三方开发者指望微信、支付宝等软件开放 API 基本不现实。当然也有部分开放的 API, 大概能实现的场景和 OpenAI 之前演示的差不多，是有很大局限的。 RPA 固定流程：类似影刀等。内部小 team 也一直在研究 RPA 的流程（Sonic 云真机）针对小红书等大流量平台，做起号、截留评论等。RPA 确实稳定，但是不灵活，兼容性较差。 视觉模型推理：荣耀手机、智谱的 AutoGLM，我理解是 AI 对 RPA 的升级版。通过手机系统级别的 无障碍服务（AccessibilityService） 和 OCR 提供视觉推理与操作。 GCC 概念 以下为 AIPM 技能树文档整理有关 GCC 的截图： 我认为的 GCC = LLM 分析 LUI 输入形成拟人化流程（大脑） + 界面内容识别模型（眼） + 多 Agent 判别（Tools 调用）+ 最终操作程序（手） 画个简图↓ 借着 AutoGLM 这个产品逐步分析一下 输入 LUI 作为输入端，目前来看无论 computer use 还是 phone use 基本上都是文本+语音的模式了，这个没什么可聊的。 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/2024-01-agent-paper/ Mon, 05 Feb 2024 00:00:00 +0000 https://blog.gby.ai/2024-01-agent-paper/ 原文 论文地址：arxiv 译文：人工智能 agent 勘测多模态交互的前景 读后感