惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tailwind CSS Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
雷峰网
雷峰网
量子位
有赞技术团队
有赞技术团队
阮一峰的网络日志
阮一峰的网络日志
The Cloudflare Blog
博客园 - Franky
罗磊的独立博客
宝玉的分享
宝玉的分享
博客园_首页
腾讯CDC
The GitHub Blog
The GitHub Blog
D
DataBreaches.Net
IT之家
IT之家
D
Docker
Microsoft Security Blog
Microsoft Security Blog
博客园 - 司徒正美
V
V2EX
月光博客
月光博客
N
Netflix TechBlog - Medium
爱范儿
爱范儿
I
InfoQ
P
Proofpoint News Feed

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
你需要的不是智能体,而是工作流
赛博禅心 · 2024-08-19 · via 人人都是产品经理

在AI技术飞速发展的今天,智能体(AI Agent)的概念备受关注,被一些人视为解决复杂问题的万能钥匙。然而,智能体并非万能,其应用需要结合实际问题和工作流程设计。本文深入探讨了智能体的实质和如何设计适合AI的工作流,以实现问题的有效解决。

现在 AI 智能体(AI Agent)的概念很火,似乎智能体是用 AI 解决问题的银弹,有了智能体就可以解决很多问题。但也有很多人有不同意见,认为智能体不过是噱头,并没有看到靠谱的应用场景。

一个被提及很多的是吴恩达老师写的多智能体翻译的例子,简单来说就是用三个智能体:一个直译智能体、一个审查智能体、一个意译润色智能体,确实可以大幅提升翻译质量。但并非一定要三个智能体才能提升翻译质量,我以前也提出过基于 Prompt 的翻译方法,让 LLM 在翻译时,使用直译 + 反思 + 意译三个步骤输出,也可以得到高质量的翻译结果。

本质上,使用大语言模型(LLM)来解决问题,思维链(COT, Chain of Thought)是一种有效提升生成质量的方法,也就是说,之所以翻译质量能提升,不是因为有了智能体,而是因为有了思维链。至于思维链的每个环节是用一个独立的智能体,还是输出的一个步骤,并没有太本质的差别。

其实大部分 AI 应用场景都类似:要用 AI 解决问题,核心不在于智能体,而在于设计出一个适合 AI 的工作流。

那么怎么才能设计一个适合 AI 的工作流呢?我认为有几个因素需要考虑:

一、不要局限于人类现有方案

有时候我们过于将 AI 拟人化,会不自觉的用人类解决问题的方式来套用在 AI 上,有时候确实有效,但很多时候并不一定是最优解。就像专业的翻译员,他们并不需要直译反思意译三个步骤,他们可以一步到位,直接输出高质量的翻译结果,所以最开始让 AI 翻译,Prompt 都是直接一步输出翻译结果,而不是分步骤输出,结果翻译出来的比较生硬。而当我们发现思维链是大语言模型的一种有效提升方法后,就可以设计出更适合 AI 的工作流,分成几步来解决问题。

包括我看到一些智能体项目,尝试模拟人类软件开发的分工,使用项目经理、产品经理、架构师、程序员、测试等等智能体角色去尝试解决复杂的软件项目,同样也是一个过于拟人化而不一定适合 AI 解决问题的思路,所以也只能出现在论文中,而无法在实际项目中落地。相反像 GitHub Copilot 这样辅助生成代码的工具倒是真正适合当前 AI 编程的工作流,能实实在在提升开发效率。

二、不必完全依赖 AI 做决策

去年有一个超级火爆的项目叫 AutoGPT,就是你输入一个任务,GPT-4 会将任务分解,制定计划,调用外部工具,比如 Google 搜索,甚至执行代码,最终完成任务。这也算是 AI 智能体的先驱项目之一,但现在已经很少有人提及了,因为以现在 AI 的智能程度,还不足以对开放性的任务做出靠谱的决策,最终除了帮 OpenAI 卖了大量的 Token 外,并没有解决什么实际问题。所以现在 AI 应用的主流是把 AI 当“副驾驶(Copilot)”,只是让 AI 辅助人类完成任务,主要还是人在做决策。

另外就是自己设计工作流,让 AI 在工作流中完成一部分工作,并不过于依赖 AI 做决策,或者只需要做简单的决策。比如说商家借助 AI 处理差评的工作流:

  • 程序抓取评论信息
  • AI 分析每一条评论的情感,筛选出差评
  • AI 生成回复(可能需要人工审核)

这是一个典型的设计好流程的适合 AI 的工作流,AI 只需要做简单的情感分析和回复生成,而不需要做复杂的决策,这样的工作流可以很好的提升效率,并且结果也相对靠谱。

三、可以结合多种 AI或工具

去年起 AI 大热,一个很重要的原因是大语言模型的出现,这些模型一方面确实能力强大,有一定的通用性,有简单的推理能力,另一方面使用也简单,无论是通过聊天机器人,还是通过 API 调用,都能很方便的使用。即使像我这样不是人工智能专业的人,也能很容易的使用这些模型。而在以前,人工智能相对来说是个高门槛的领域,需要筛选数据、需要训练,还需要调参,对于非专业人士来说是很难使用的。

但这也导致一个问题,就是很多解决方案过于依赖大语言模型,而不知道或者不会使用其他领域的 AI 模型,但当你能够根据任务,将不同领域的 AI 模型或者工具结合起来,设计出合适的工作流,就能够得到更好的解决方案。

四、回归问题本质,AI 只是锤子

上面提的几点都是容易犯的一些错误,之所以容易犯这些错误,恰恰是因为我们有时候过于关注一些流行的概念或技术,而忽略了要解决的根本问题是什么,将 AI 变成了目的而不是手段。如果你有了解马斯克的第一性原理思维,其强调的就是回归事物最基本的条件,把其解构成各种要素进行分析,从而找到实现目标最优路径的方法。

而运用第一性原理通常有三个步骤:

第 1 步:定义清楚你要解决的根本问题。

第 2 步:拆解问题。

第 3 步:从头开始创建解决方案。

而这也个思路也适用于我们去借助 AI 解决问题,设计出适合 AI 的工作流。

举两个设计合适 AI 工作流解决问题的例子

一个例子是 PDF 转 Markdown。

做过 PDF 翻译的有经验,要得到好的翻译结果,将 PDF 的内容整理成 Markdown,再让大语言翻译,效果是相当好的。但这个不好做,因为 PDF 是用来打印的格式,并不是结构化的数据,很难直接提取成 Markdown,再加上各种图表、表格等,更是复杂。

最近看到一个项目叫 PDFGPT,它就做的很巧秒,本质上是基于 GPT-4o 和 PyMuPDF 设计了一个工作流:

用一个 PDF 操作库 PyMuPDF 检测 PDF 中的图片、图表、表格等,提取成图片并保存

每一页 PDF 生成一张图片,将图片、图表、表格等位置用红框标记出来,并附上对应的图片名称

借助 GPT-4o 的视觉能力,解析标注后的图片,生成对应的 Markdown

如果你纯粹依赖大语言模型,恐怕无法完成这样的任务,一方面受限于上下文窗口的长度限制,一次无法处理多页 PDF,另一方面对于图片、图表、表格等内容无法嵌入 Markdown 中。如果结合 PyMuPDF 这样的库和一个简单的工作流,就可以方便的实现 PDF 转 Markdown,生成的结果也挺不错。

另一个例子是漫画的翻译。

有很多那种气泡文字的漫画,如果要翻译成其他语言,就需要将气泡文字提取出来,翻译后再放回去。漫画翻译的难点在于:

因为漫画的气泡文字位置不固定,有时候还会有重叠,不好提取;

翻译的时候,如果只是把提取出来的文字按字面翻译,但不知道当前画面的内容,翻译的结果可能会不通顺;

翻译后要对图片进行处理,抹掉原来的文字,将翻译后的文字放回到原来的位置。

如果人工做会怎么做?可能是读懂漫画,翻译,然后用 Photoshop 这个样的工具抹掉原来的文字,再放上翻译后的文字。可以想象这样的工作量还是不小的。

有一个开源项目 comic-translate,就做的很好,它也是设计了一个适合漫画翻译的工作流:

用一个专业模型做气泡检测,找出文字气泡的位置

用 OCR 做气泡内文字的提取

用一个专业模型移除气泡内的文字

借助 GPT-4o 的视觉能力,根据漫画内容,翻译气泡内的文字

用程序将翻译后的文字绘制到原来的气泡位置

如果不考虑翻译质量的话,这几乎是一个全自动的工作流,效率相当高,成本也很低,最贵的部分是 GPT-4o 的 API,一页也才 $0.02 左右。就算加上人工审核对翻译结果和图片生成结果的处理,也是能比以前的人工翻译效率高很多。

从上面的例子可以看出,真正要用好 AI,让 AI 发挥最大效能,核心是还是要基于你要解决的问题,重新设计一个适合 AI 的工作流,让 AI 在工作流中完成它最擅长的工作,至于是不是智能体,是不是大语言模型,是不是 AI 帮你决策,都不是最重要的。

本文由人人都是产品经理作者【赛博禅心】,微信公众号:【赛博禅心】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。