AI 在数据应用中的我知我行—LLM 实战学习笔记 3

周末和一个朋友又一起捋了一遍各自在 LLM 落地方向做的事情，有一些碰撞，虽然大家方向不一致，但是里面也依然存

周末和一个朋友又一起捋了一遍各自在 LLM 落地方向做的事情，有一些碰撞，虽然大家方向不一致，但是里面也依然存在一些共识。想着自己在这个方向也做了两个季度的时间了，就借此篇记录一下把 AI 「编织」在数据应用过程中的我知我行。

💥 何谓编织？过程→中间件→结果

💥 值得重视的中间件

💥从原子价值单元切入

💥愚昧之巅→绝望之谷

何谓编织？

7 个月前，看到过下面这篇文章，当时觉得这个分类很精妙。人机协同的三种范式，Embedding、Copilot 和 Agent。后续，这个分类结构出现在了无数的行业分析和各类媒体文章中。这个结构当时很有启发，但是当我实际跑完一些研发过程的时候，我想从其他的角度来微调这样的分类。

首先是"embedding"模式，你可以将其理解为我们通过与AI进行语言交流，使用提示词来设定目标，然后AI协助我们完成这些目标。

其次是"Copilot"模式，在这种模式下，人类和AI各自发挥作用。AI介入到工作流程中，从提供建议到协助完成流程的各个阶段。

第三种模式是"Agent"模式，由人类设定目标并提供资源，这些资源通常是计算能力，然后监督结果。在这种情况下，Agent承担了大部分工作。

VION WILLIAMS，公众号：VION WILLIAMSAI智能体与人类的未来协作方式、合作组织与生产空间（万字长文）

原因也很简单，实际在研发落地的过程中，并不是从人类和AI 两个宏观主体去思考和构建了，而是从整体的研发视角出发，包裹着LLM 接口的研发能力到底面向用户能输出些什么。所以下图中的分类结构是从用户视角下，能获得什么类型的加持出发进行的分类 。

分类的逻辑也相对简单，先有两极，过程和结果：

过程加持 ：其实就是现在各种 Embedding/Copilot 在做的事情，体现在数据应用领域，当前看到的就是查数、写 SQL 和找知识库
结果加持 ：虽然好理解，但是并不是一个简单的 Agent 或者 Multi Agents 就能直接完成的事情，尤其是在实际业务探索中，这个事情的完成度没有大家想的那么乐观，虽然在市面上也会有各种“数据分析师”自称的 Agents 在做数据分析报告这样的产品形态，甚至不如AI 搜索靠谱
中间件加持 ：中间件的定义更像是可以用来直接组成结果的元素或者组件，借助LLM 能力的加持，能生产出组成结果能力的元素，无论是图标、总结还是特定的前端组件，处于过程和结果中间的一种状态

而所谓的编织，则特指包裹着 LLM 能力和工程能力作为整体的研发能力。 只是在这三个类别中，LLM 能力的占比有所不同。在过程辅助中，LLM 的能力可能占比更高；在中间件，LLM 和已有的工程能力是能紧密配合的，无论是已有的组件、接口还是权限能力；在结果输出上，当前自己探下来发现实际有效的是把中间件的元素拼接，而如果 LLM 倚重过高的话，在稳定性和输出上一定会给用户带来较大的困惑。

值得重视的中间件

现在大行其道的其实是 Copilot 的产品形态，但是这样的产品形态导致的一个问题是，输入和输出这两端都是极不收敛的状态，所以当用户对输出有明确预期的情况下，用户的体验和感知就会不如预期。而数据场景，恰好用户的第一诉求其实是准确和可用，就会导致在这个产品形态中，需要打很多补丁，比如映射、查询释义等等，甚至做了很多补丁，用户也不一定买单。

上图中左侧的例子是朋友在自己业务过程中的建构逻辑，预期是希望将 Jason 作为中间形态，LLM 负责的是 NL2Jason 的过程，然后 Jason 封装组件的这个步骤，其实是依赖原有的组件能力进行了一层包裹，面向实际的生产和研发过程进行提效。

上图中右侧的例子是我在实际落地过程中在尝试跑通的路径，AI+数据最后输出的结果，但是并不是直接输出结果，而是输出中间件，包括图表、总结、文字和表格各种类型，最后工程能力汇总成一个文档，直接面向用户去做输出和流通。

当时碰撞的时候就觉得这两个case 虽然业务形态和想达到的目的完全不一样，但是共通的点就在于找到中间件的支撑。按照收敛输入，让 LLM 输出中间件；再基于中间件，结合工程能力放大输出的方式，真正支撑 LLM 业务应用的落地和应用。

从原子价值单元切入

上次听了郭东白老师的分享之后，特意发了一条即刻的动态，大意是说应该围绕「原子价值单元」做功，仅用大模型创造的能力来构建应用和投入。如果还过渡依赖已有工程能力，只是一层包装而已，可能随时被洗刷掉。

如果从这个角度看，这个逻辑和中间件的逻辑恰恰是相反的。坦率讲，其实这个问题我到现在也没有自己明确的答案。只是在评论区，一个也是在做 AI 数据探索的朋友打了个比方。是否加上工程能力的包裹，有点像增程和纯电的区别，这个过程中增程可能是更快能落地和应用的，但是如果只做纯 LLM 衍生的应用，可能还得依赖LLM 的迭代和周边的配套。非常有趣的比方，也对思考 LLM 应用的时候是否包裹工程能力有很大的启发。

愚昧之巅→绝望之谷

春节后在部门内部做了个简单的分享，聊自己做 AI 探索的事情以及感受，我用的标题叫「从愚昧之巅到绝望之谷」。这个标题并非是为了讨巧或者博取流量，而是真实反映了在这样的技术趋势下，推动新技术在研发实践中落地的曲折。

从愚昧到绝望的过程，既是认清楚LLM 能力边界的过程，又是更好地围绕用户需求解决问题的过程。经常听到大家雨基于大模型有非常绚丽的想法和额想象，我觉得倒不如把手弄脏，亲自下场去体验下用户对于应用的感知和诉求 。

时至今日，我觉得我依然在绝望之谷，只是隐约看到走向开悟之坡的方向。回到起点，基于用户-需求-场景的基础逻辑，帮助用户在什么场景下解决什么问题。这个基础的原则是有可能帮助我们找到迭代的方向和进化的规则。