你无法用 AI 建立护城河 [译]
使用 LLM 已经不足以让你的产品与众不同
去年春天，我们写过一篇名为《你无法用 AI 建立护城河》（参见附录）的文章。那篇文章提到，虽然 Prompt 工程很重要，但由于在 LLM 上进行实验非常容易，想靠 Prompt 工程来建立长期壁垒并不现实。因此，要想实现差异化，必须专注于应用所能访问的数据质量以及对这些数据的使用方式。
我们之前的观点至今仍然适用，但随着 DeepSeek R1 和 o3-mini 等模型的发布，AI 应用如何建立壁垒的争议又再度浮现。最近几周，我们听到的许多问题都围绕着：“如果 LLM 变得越来越便宜、越来越好，大家的应用也都会提升，那么该如何继续实现差异化？” 对于每位应用构建者而言，仔细思考这个问题很重要。
简而言之，除非你在构建或托管基础模型，否则单纯地把“AI”当作差异化因素，就像说“我的 SaaS 产品因为用了某种数据库而独树一帜”一样：没有人会关心。
最基本的假设是，更好的模型就像潮水上涨会把所有船都托高一样。对 AI 应用而言，当更强的模型出现通常是好事，因为它提供了一个更强大的底层引擎。但这不会成为你建立护城河的依据。确实，刚有新模型发布后的一段时间内，某个团队也许能找到更巧妙的使用方法从而领先，但这种优势会很快被稀释。网络上有大量信息、教程和讨论，优势很容易被复制。这与我们之前谈的 Prompt 工程壁垒完全相似。如果你指望它来维持差异化，很快就会被竞争对手赶超。
当然，有了好工具并不意味着万事大吉——如何使用这个工具同样重要。然而，你也无法再自信地宣称“我的应用比竞争对手更聪明”。所以，你需要从别的方向入手。我们会再次提醒你回顾去年的文章，里面详细讲解了构建技术壁垒的方法。但鉴于近期模型的进一步发展，我们想从产品和市场的角度来思考如何保持竞争力。
我们认为，护城河主要取决于以下三个方面：
1. 用户体验（User Experience）
为了让应用看起来“有 AI 而 AI”，我们已经多次批评过这种做法，就不再赘述。正如我们最近反复提到的，我们认为，大多数用户体验都需要针对 AI 应用进行重新思考。以前我们需要用户手动输入的信息，现在或许可以通过推断自动完成。在很多场景下，AI 应用的意义就在于让人们不再手动操作某些繁琐的工作，而是一键自动化，同时保证结果“看起来像是真人做的”。如果你只是想在传统 UX 上“加一点 AI”，那只是一个起步的权宜之计，称不上可持续的护城河。但如果你思考如何满足用户实际需求、融入他们的工作流程，并让那些繁琐的步骤在他们几乎无感的情况下就被完成，这就真正改变了 UX。好体验当然也能被模仿，但能在用户体验上不断创新的团队往往还能继续保持创新（参考：Snap）。对于企业级应用，重点应该是提供真正能完成工作的功能。
集成和工作流程（Integration and Workflows）
我们是做企业级产品的，你们很多人可能也是。我们常开玩笑说，每家企业软件公司要么会变成一家数据库公司，要么会变成一家做集成的公司——而大多数 AI 应用公司大概都会走向“集成”这条路。上面提到的“为用户提供实际的帮助并融入他们的工作流程”，这就意味着你必须能够与客户的通讯工具、文档系统、任务管理工具等等进行对接。听起来可能很繁琐（确实是），但这也是关键所在。那些能够深入融入客户工作流程的产品黏性非常高。当客户考虑是否替换你的产品时，新产品不仅要在价值上至少与你持平，还得值得他们投入重新做所有集成配置的成本。这个壁垒相当强大。
3. 数据输入与数据输出（Data in, Data out）
AI 说到底还是离不开数据。我们在之前的文章里已经详细聊过如何使用数据。简单概括就是：有数据本身还不够，难点在于在正确的时间使用正确的数据（提示：只用向量搜索并不够）。从商业角度看，数据输出也同样重要。在 RunLLM，我们每个月回答超过 10 万个问题。这些问题背后的数据可以帮助客户做很多事，比如：了解他们用户使用了哪些功能，追踪不同工作负载的使用热度，发现潜在的 Bug，等等。有了适当的标注后，我们也能分析回答过程中有哪些问题可以做得更好。并不是每个应用都会在第一天就实现这些功能，但随着时间推移，这些收集到的数据最终都会成为一大资产。你如何收集、如何利用这些数据，将会对你的长期竞争力产生巨大的影响。
总而言之，我们的观点是，AI 不再是一个值得夸耀的差异化标签。它最多只是一个“不断缩小的优势”，糟糕点说，它甚至意味着你没有真正为未来做打算。几乎每个应用都或多或少会使用 AI，关键在于你是否足够了解用户需求，以及你能否有效地让应用满足这些需求。AI 如今已如此普及，它理应被视作一种常规工具——就像木匠不会因为自己使用了锤子就沾沾自喜，你也没必要因为用了 GPT 而大肆宣扬。
附录：你无法用 AI 建立护城河（旧文）
一切都与数据息息相关
如何让 AI 应用差异化是当下热议的话题，但这并不容易。是不是所有东西都不过是一个 RAG（Retrieval-Augmented Generation）应用？（不全是。）如果一家公司在某个领域把 RAG 做得足够好，这份能力能否自然而然地转移到另一个领域？（也许能！但我们还不确定。）难道所有的 AI 应用都将由 OpenAI 来构建？（大概不会。）
对初创企业来说，如何在技术和市场推广中建立差异化一直是个永恒的问题。有些人认为，一切都在于技术；也有人认为，一切都在于执行。无论事实如何，我们已经清楚地看到，单靠大型语言模型（LLMs）本身并没有太多你可以用来实现差异化的东西1。真正的差异化在于你将什么数据输入模型。
一开始这听起来可能有些令人意外，毕竟正是 LLM 引发了当下的 AI 热潮。如果 LLMs 不那么重要，那……我们现在都在做什么？
当然，LLMs 非常强大，但我们相信其核心模型以及它们的使用方式在同类产品中会逐渐同质化。在这个情况下，如果你只是在使用一些巧妙的 LLM 用法（尤其是只依赖单次 LLM 调用），那很可能不足以形成长期竞争优势。相反，你需要仔细思考你用来构建应用的数据。这就是原因：
每个人都在用同样的模型。无论你认为哪种 LLM 是最好的——我们大多认为是 GPT-4——在某些主要任务上，总有一个模型比其他模型表现更优。当前来看，大部分用例很可能还是 GPT-4 表现最佳，但 Claude 的进步也很快。如今任何团队都可以轻松切换不同模型来实验，看看哪种最适合他们的应用。所以，不管你在构建什么，因为大家都能“挑选”出最合适的模型，所以你从“选对模型”中获得的优势就很小。
从主流选择中偏离也存在风险——在某些情况下，你可能会得到意料之外的好结果，但也可能在其他情况下得到意料之外的糟糕结果。如今很多 AI 初创公司都在努力建立用户信任，这么做风险很大。结果就是，大部分团队还是会回到使用那些更可靠的主流模型。这也意味着你输入模型的数据比以往更加重要。
而你的 Prompt 设计并不是核心知识产权。也许你会觉得自己设计的 Prompt 或者 Prompt 模板有一定的差异化价值。毕竟，你的顶尖工程团队花了好几天时间来调试，只为获得特定的回答风格、语气和输出形式。当然，如果你把自己的 Prompt 完整地交给竞争对手，的确会加速他们的进度，但只要对方的工程团队不差，他们很快就能摸索出一个可行的 Prompt。原因在于，这种实验（只要评估数据对了）其实并不难——尝试新 Prompt 模板的成本并不比写一个新 Prompt 高多少。它所需要的不过是一些耐心、一点创意，以及更多的 Azure OpenAI 额度。
或许你的 Prompt 今天要好一些，但可以肯定地说，这种优势不会持久。你不得不寻找其他方向。
所以（一如既往）问题还是归结到数据上。如果模型被同质化、Prompt 也被同质化，那么你想通过 AI 应用实现差异化就只剩下你输入 LLM 的数据了。值得庆幸的是，数据的确能带来巨大差别。无论你构建什么应用——尤其是面向企业——都需要利用客户的数据来驱动应用的回答和决策。每个团队拥有的数据以及对数据的使用偏好都会有所差异。
LLM 的好处在于它对任意的非结构化数据都有不错的处理效果。但问题在于客户往往拥有海量的非结构化数据。其中有些是“金矿”，有些则毫无价值。作为应用构建者，你的责任就是找出如何有效地利用这些数据。
当然……垃圾输入就会得到垃圾输出。和任何 AI 模型（甚至任何系统）一样，LLM 也是“垃圾进，垃圾出”。这就要求你必须具备强大的能力来找出并利用合适的数据。举个例子，在 RunLLM，我们在过去一个季度里大约 70% 的工程时间都花在了数据工程上——从数据导入时的预处理，到实现混合搜索，再到对结果进行再排序。无论我们遇到客户抱怨还是需求，最先的解决方案通常都是改进数据工程流程。
最终我们构建了一条相当复杂的数据处理流水线，它能根据客户需求进行优先级排序，处理多种不同的数据类型，并生成下游复杂推理任务所需要的元数据。要复制这样的系统，仅仅“尝试一些新方法”是远远不够的。这完全依赖于我们与客户深度接触并持续获得的反馈。而正是这套流程，让我们在生成简洁、贴合事实的回答上不断保持差异化，同时有效减少了幻觉（hallucination）的出现。
我们坚信，对于当今的 AI 应用来说，真正的护城河就在数据和数据工程上。也许未来某天，构建定制化 LLM 的过程会变得既快速又轻松，以至于所有人又会回到自己训练模型的路线。但至少在当下，情况并非如此。
这也意味着，你并不一定需要成为 AI 领域的大牛才能成功构建应用。事实上，在某个阶段，把全部精力都放在 AI 本身上，反而可能会阻碍你的差异化。通过专业的软件工程和对客户数据的专注，你能在长期中建立起自己的护城河。
1当然，这不适用于模型提供方；他们可以在模型中玩出各种专业或功能差异。如果事情按我们预期发展，我们或许会看到每个模型提供方在某些特定技能上各有所长。