自 ChatGPT 发布以来，科技公司高管们纷纷追逐这一热点：我环顾四周，又一家公司在吹嘘其开创性的 AI 功能。但真正的商业价值来自于提供对用户有意义的产品能力，而不仅仅是使用热门技术。
我们通过从用户对产品需求的核心原则出发，构建支持该愿景的 AI 能力，然后衡量采用情况以确保其达到预期目标，从而实现了工程投入回报 10 倍的提升。
我们的首个 AI 产品功能并未契合这一理念，在回归用户核心需求的指导原则后，我们花了整整一个月时间才使回访用户的采用率仅达到令人失望的 0.5%。随后，我们确立了“AI 作为智能体（agent）”的方法，并推出了一项新的 AI 能力，首周采用率便激增至 5%。这种 AI 成功公式几乎可应用于任何软件产品。
炒作与仓促带来的浪费
许多初创公司（包括我们）常常被整合最新技术的诱惑所吸引，却缺乏清晰的战略。因此，在 OpenAI 陆续发布各种版本的生成式预训练变换器（GPT）模型之后，我们开始寻找在我们的产品中使用大语言模型（LLM）AI 技术的方法。很快，我们就搭上这趟炒作列车，在生产环境中推出了一个全新的 AI 驱动元素。
这项最初的 AI 能力是一个小型摘要功能，它利用 GPT 为用户上传到我们的产品中的每个文件撰写一段简短的描述性文字。这让我们有了宣传的话题，我们也制作了一些营销内容，但它并未对我们的用户体验产生实质性影响。
我们从关键指标中得知了这一点：没有任何关键指标显示出显著变化。在第一个月内，仅有 0.5% 的回访用户与该描述进行了互动。此外，用户激活率没有改善，用户注册速度也没有变化。
当我们从更广阔的视角审视时，很明显这个功能永远无法推动这些指标的增长。我们产品的核心价值主张在于大数据分析以及利用数据来理解世界。
仅仅对上传的文件生成寥寥数语，无法带来任何重要的分析洞察，这意味着它并不能真正帮助用户。我们在急于交付某种 AI 相关功能的过程中，错过了提供实际价值的机会。
以“AI 作为智能体”取得成功：回报提升 10 倍
为我们带来成功的 AI 方法是“AI 作为智能体”原则，它赋予用户通过自然语言与产品中数据进行交互的能力。这一方法几乎可应用于所有基于 API 调用构建的软件产品。
在推出我们的首个 AI 功能后，我们虽然完成了既定目标，但并不满意，因为我们知道能为用户做得更好。于是，我们采取了软件工程师自编程语言发明以来一直采用的做法——举办黑客松（hackathon）。在这次黑客松活动中，我们实现了一个代表用户执行操作的 AI 智能体。
该智能体通过调用与我们 Web 前端相同的 API 端点来使用我们的产品。它基于与用户的自然语言对话构建 API 调用，试图满足用户的请求。这些 API 调用的结果体现在我们的 Web 用户界面中，其效果等同于用户亲自执行了这些操作。
这种“AI 作为智能体”的能力产生了深远影响。对用户而言，最大的好处是他们不再需要理解我们界面中的各项控件即可分析数据。我们投入了大量精力打造我们认为直观的用户界面，但即便如此，也难以超越直接在文本框中输入自己想要的内容，并让 AI 完成其余工作的简洁性。
为了验证这一功能是否带来了积极影响，我们查看了相关数据。成功的第一个迹象是：在不到一周的时间内，5% 的回头客开始使用该功能；这一采纳率是我们首个功能的 10 倍，到第一个月结束时更是达到了 20 倍。
我们在发布时未提供任何产品内引导、提示或营销推广，因此初期的采用完全来自有机增长，且发布后我们的用户激活指标有所提升。我们将部分提升归因于智能体带来的训练效应：用户在纠正 AI 操作的过程中，逐渐更深入地了解了如何使用我们的产品。“AI 作为智能体”的方法不仅对用户来说非常成功，也让我们的工程团队得到了更高效的利用。
与同行进行验证
来自其他专业人士的轶事报告也验证了“AI 作为智能体”方法的可行性。例如，一个用于编目参考文献的产品可能会引入 AI 以实现自然语言检索。这将使 AI 服务于其核心用户价值，并可运用“AI 作为智能体”的原则，将自然语言检索查询转化为 API 操作，以检索匹配的内容。
我听到过多个行业领域的技术领导者分享成功案例，表明这种方法对他们的用户产生了积极影响。相比之下，当 AI 功能仅是产品的附属特性而非核心价值时，其影响则不那么显著。
超越用户采纳的收益
“AI 作为智能体”方法具有多项超越用户采纳的优势。对我们而言，一个重要方面是它缓解了关于提示注入（prompt injection）的安全担忧。在设计良好的面向公众的 API 中，无论请求来源如何，所有输入都被视为不可信。
这是因为攻击者可以拦截来自浏览器的调用，并发送带有恶意输入的修改后调用，因此 API 本身需要清理和防范不良行为者。我们的 AI 代理就像用户亲自发起调用一样进行 API 调用，无需对内部系统拥有特殊访问权限。因此，所有相同的 API 安全策略都会得到应用，任何数量的提示注入都无法获得任何形式的提升访问权限。由于 API 是安全的，提示注入变得无关紧要。
我们的产品支持大数据，真的是非常大的数据，例如单个电子表格中包含十亿行。这突显了“AI 作为代理”架构的另一个优势。在一些其他用于数据分析的 AI 应用中，完整的数据集必须作为提示的一部分提供给大语言模型（LLM）。
对我们来说，这是不可接受的。虽然具有较大提示尺寸的大模型可能能够处理我们部分用户较小的数据集，但即使是最大容量的上下文窗口也无法支持我们最大的数据集。而我们的产品的核心价值之一在于，当数据量变大时，您无需做出任何妥协。相比之下，AI 代理与数据的交互方式类似于人类分析师的操作方式。
这意味着检查元数据（如列标题）、查看选定行的样本值、计算聚合统计信息，或执行我们 API 支持的其他分析操作。通过这种方式，10 行数据与十亿行数据之间的差异仅仅是在元数据的“行数”字段中多添加八个零，因此规模大小对提示尺寸的影响微乎其微。
一个相关的好处是我们能为用户提供更好的隐私保护。虽然我们的一些用户并不太关心他们的数据去向，但另一些用户对数据共享的位置及其隐私权有着合理的关切。
尽管 OpenAI 提供了在训练数据中使用用户输入的退出选项，但由于担心自己的整个数据集已被输入某个神秘的“黑盒”中且永远脱离掌控，用户往往对使用 AI 持谨慎态度。而在“AI 作为代理”的模式下，数据始终保留在我们这边，代理只是一个位于我们基础数据存储和数据库层之外的辅助工具，在任何时候都不需要直接访问用户的整个数据集。
最后值得一提的是，这也提高了我们对 AI 如何生成答案的透明度。通常情况下，人们很难信任 AI 的输出，这一点在早期版本的 GPT-3 中常见的“幻觉”现象中尤为明显。我们的 AI 代理会返回一份项目符号列表，列出其根据我们 API 文档所采取的所有操作。
通过查看此输出结果，用户能够立即判断结果是否合理；如有需要，还可以进行调整以进一步优化分析。这也有助于我们之前观察到的用户培训收益，即提升用户激活率，因为用户可以看到该产品支持哪些操作。AI不再是一个黑盒，因为它会自我报告所执行的每一步骤。
我毫不怀疑，初创公司中AI的应用将持续演进。回顾过去，我很高兴我们发布了所有已推出的AI功能，但 hindsight 表明，作为智能体（agent）的AI方法始终会对我们的用户产生更大的影响，如果我们一开始就直接采用这种方法，本可以避免许多麻烦。
我邀请技术领导者、产品负责人和高管将我们的故事视为一条路径，以便在大家共同探索未来的过程中，借助AI赋能您的用户。