https://blog.gby.ai/tags/toc/ Recent content in ToC 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, 13 Aug 2024 00:00:00 +0000 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/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 统一进行回复 每日主动推送，以下内容随机推送一条 功能推荐消息 拟人话术举例： "嘿，跟你说个事儿 你发我一个正面照片儿 我能帮你检测检测皮肤奥" 。基于以上的内容，需保证询问的随机性 了解用户消息