本文探讨了 AI 初创公司如何在企业级市场中实现可持续收入 的策略,核心观点是:要在生成式 AI 领域取得商业成功,初创公司必须从一开始就采用 “企业基础设施原生”(enterprise infrastructure native) 的方法。这意味着在设计和开发产品时,优先考虑满足大型传统企业的复杂需求,而不是仅服务于科技公司或个人用户。文章还强调,与其在后期“修补”产品以适应企业需求,不如从一开始就将企业需求融入产品设计中。

此外,文章指出,生成式 AI 初创公司在现阶段更有可能通过服务非科技企业(如金融、医疗等)实现盈利,而不是与大科技公司竞争 B2C 或科技原生 B2B 市场。

  1. 企业基础设施原生的必要性
  • 定义:企业基础设施原生指的是公司从一开始就设计产品以适应企业环境的复杂需求,包括安全性、合规性、个性化、延迟和规模等问题。
  • 原因
    • 企业(尤其是非科技企业)拥有庞大的开发者群体和复杂的基础设施需求。
    • 后期改造产品以满足企业需求会带来巨大的技术和文化挑战。
    • 非科技企业的约束(如安全合规性)比科技公司更复杂,且需要专门的基础设施支持。
  1. 为什么专注于非科技企业
  • 非科技企业的市场潜力
    • 大型非科技企业(如银行、医疗机构)比科技公司雇佣更多开发者,并且更愿意为提高生产力的工具付费。
    • 相比个人用户,企业能带来更高的收入回报。
  • 避开大科技公司的竞争
    • 大科技公司倾向于自己开发生成式 AI 工具,而非购买。
    • 在 B2C 市场中,大科技公司拥有强大的分发渠道,初创公司难以与之竞争。
  • 成功案例:Codeium 专注于解决非科技企业的特定约束,避免了与大科技公司的直接竞争。
  1. 企业基础设施原生的关键要素
  • 安全性
    • 提供自托管或混合部署选项,以满足企业对数据隐私和安全的需求。
    • 获得必要的安全认证(如 SOC2、ISO 27001),并确保不在训练中使用客户数据。
  • 合规性
    • 确保训练数据不侵犯版权,并构建数据溯源和归因系统。
    • 针对不同行业的法规(如医疗的 HIPAA 合规)提供定制化支持。
  • 个性化
    • 利用企业的私有数据(如代码库)进行模型优化,同时确保数据的安全性和访问控制。
    • 构建灵活的角色访问控制(RBAC)系统,以防止数据泄露。
  • 性能和延迟
    • 设计低延迟系统,满足实时应用的需求(如代码自动补全需在毫秒级响应)。
    • 优化模型推理速度,同时兼顾个性化和数据处理。
  • 规模化
    • 针对企业级用户的规模(如数万开发者、数百万代码行)优化系统性能和基础设施。
    • 解决大规模用户群体中的权限管理和数据更新问题。
  1. 生成式 AI 的 ROI 挑战
  • 难以量化的价值
    • 例如,开发者生产力的提升难以用具体指标(如代码量或 PR 周期时间)衡量。
  • 解决方法
    • 提供分团队的使用统计数据,帮助企业管理员识别高效团队和需要支持的团队。
    • 逐步展示工具的价值,帮助客户更清楚地感知投资回报。
  1. 未来展望
  • 尽管目前企业市场是生成式 AI 初创公司最可行的盈利途径,作者希望未来能看到更多初创公司在 B2C 和科技原生 B2B 市场中挑战大科技公司。
  • 文章最后以 Codeium 的成功经验总结,强调了“企业基础设施原生”策略在生成式 AI 初创公司中的重要性。

原文

swyx:再次欢迎 Anshul 作为我们首位“二度回归”的客座作者!他此前关于 AI 产品理念的两篇文章在 Latent Space 和 Codeium 上大获成功,Codeium 的安装用户数增长了十倍,并且自上次交流以来,完成了 6500 万美元的 B 轮融资1.5 亿美元的 C 轮融资今天,他们发布了 Windsurf,一款智能化 IDE(Agentic IDE,指赋予 IDE 智能代理能力),乍一看,它似乎只是众多同类产品中一款简单的 VS Code 分支。我保证,本文并非为了宣传 Windsurf 而写,但作为旁观者,我惊叹于文中原则与 Windsurf 的高度契合——从一开始就更谨慎地规划,并直接面向企业级 AI 应用开发。然而,许多打着“企业 AI”旗号的公司却显得空洞乏味,因为要兼顾产品的吸引力和安全性实在太难了。

在众多外观相似的 AI 产品中(Codeium 的开发 最初也是从模仿 Copilot 开始的),Codeium 却独树一帜,我们非常荣幸能邀请他们分享他们的开发历程和经验。

以下内容由 Anshul 撰写。所有插图均为 swyx 创作。

2022 年 11 月,我在 Latent Space 发布了我的第一篇客座博文,并(或许有些乐观地)计划将其扩展成一个三部曲:

我们的企业级产品在不到一年时间里,年度经常性收入 (ARR,Annual Recurring Revenue) 就突破了千万美元大关,所以是时候进入第三部分了。出乎意料的是,这与 enterpriseready.io 等网站上的建议大相径庭。

早在 2022 年 11 月,我就构思好了这三篇文章的论点,但在撰写第一篇文章时,我们面临一个挑战:Codeium 刚刚发布,虽然我能论证强大的产品战略源于对市场经济和具体应用场景的深刻理解,但当时我们的产品与其他 AI 代码助手并没有太大区别(那时,所有工具都只是简单的自动补全功能),而且我们尚未实现盈利。两年后,我们发现,为了提升产品质量和降低成本,企业需要超越简单的模型 API 调用,特定任务模型、开源模型托管、RAG(检索增强生成)等技术开始蓬勃发展。

到了 2023 年夏天,我们的 IDE 内置聊天功能正式上线,其代码镜头和代码直接插入等功能在当时是独一无二的(试想一下没有这些功能的日子)。GitHub Copilot 的聊天功能在几个月后才上线。那时,我对第二点论断——用户体验是构建长期竞争优势的关键充满信心。一年多过去,这一论断更加得到了验证。人们越来越重视直观强大的用户体验,它可以有效隐藏底层模型和推理的复杂性。Perplexity、Glean,甚至是我们领域的 Zed 或 Cursor,都是很好的例子:技术过硬,用户体验更佳。

然而,在撰写关于盈利模式的第三篇文章时,我仍然面临挑战:面向个人的 Codeium 仍然是免费的,企业级产品也刚刚上线,因此尚未实现盈利。因此,我当时无法就如何从 AI 产品中盈利给出有说服力的论述。

但正如前文所述,我们的企业级产品年度经常性收入在不到一年时间里就达到了千万美元级别。在 B2B 软件领域,这堪称神速。所以,一年后,我将再次阐述我对生成式 AI 产品的见解。

我的第三个论点是:要想在生成式 AI 领域持续盈利,就必须成为“企业基础设施原生 (enterprise infrastructure native)”的。

什么是企业基础设施原生?

“企业基础设施原生”指的是公司从一开始就具备在各种复杂的企业环境中部署产品的能力。 这包括《财富》500 强企业、受监管行业以及那些拥有百年历史的企业。

在硅谷,我们常常囿于自身认知。例如,如果我们只针对硅谷企业开发代码助手,就会忽略更大的市场。美国前十大银行雇用的软件工程师数量,就远超所有 FAANG 公司的总和,这仅仅是美国银行部门的一个缩影。仅摩根大通就拥有超过 4 万名技术人员,而 Meta 的软件工程师数量也大约在 3.2 万左右。

现实情况是,这些非科技企业面临着许多科技公司,尤其是那些以数字技术为核心的硅谷公司所没有的限制。为了快速迭代、推出 MVP 并吸引用户,我们往往会选择忽略这些限制,只专注于硅谷用户。

而“企业基础设施原生”的公司则从一开始就正视这些限制。 为什么?因为事后弥补这些限制的难度要大得多。

这确实更难,因为你可能会做出错误的设计决策。例如,你的系统架构可能难以容器化,也难以部署到企业自有的服务器环境(典型的 SaaS 向本地部署的转换难题),而许多大型受监管企业都更倾向于此。又或者,你可能会忽略基于规则的访问控制和安全考虑,默认所有员工都能访问所有数据;或者使用了不符合 HIPAA 合规性要求的系统,忘记了审计机制,或者没有建立完善的监控系统。

此外,事后弥补还有其他一些更深层次的原因。首先,你的迭代可能无法完全反映现实情况,因为企业与消费者有根本的不同。例如,在 AI 代码领域,如果你只针对个人开发者迭代,就永远无法意识到,一个强大的推理系统对于处理大型、复杂的、过时的代码库有多么重要。这与那些在硅谷开发零到一项目的开发者所面临的挑战完全不同。

其次,你的团队发展速度可能会太快,以至于缺乏应对这些限制的专业知识。例如,为了满足安全要求,在本地部署生成式 AI 需要使用本地 GPU,这意味着计算资源会受到限制(几乎没有人会为大多数应用购买大规模的 H100 集群)。这就需要我们进行大量的基础设施优化,以弥补无法随意扩展计算资源的不足。如果团队主要由产品人员构成,而非具备 GPU 基础设施专业知识的垂直团队,那么就很难取得成功。如果为了速度而忽略了众多限制,最终构建的架构和团队都将无法适应企业级市场的需求。这与许多非生成式 AI 公司难以适应新范式的原因类似——它们缺乏具备生成式 AI 核心能力的团队。

某些产品天生就需要“企业基础设施原生”的团队,因为它们的目标用户群体就是这类企业,例如 Harvey 就只面向企业用户。但大多数应用场景都有选择:一开始就考虑这些限制,还是选择忽略。而“企业基础设施原生”的公司,会主动应对所有的这些挑战。

需要明确一点的是,“企业基础设施原生”确实意味着产品迭代会更加艰难,因为限制更多。但如果这种理念从一开始就融入公司文化,它就会成为一种工作方式,你最终会建立起相应的系统,从而在应对这些限制的同时提升迭代效率,并避免日后出现巨大的文化冲突。这并不意味着要等到一个功能完全满足所有企业需求才能发布。例如,我们可以优先在 SaaS 企业级客户群体中快速部署新功能并收集反馈。“企业基础设施原生”意味着公司中至少有人会思考如何让新功能最终惠及所有企业。

之所以强调“基础设施原生”,而不是简单的“企业原生”,是因为绝大多数额外限制都体现在技术软件基础设施层面。这表明,要想做好,就必须将大量精力投入到基础设施建设上,我们稍后会详细讨论。

enterpriseready.io 等网站上的建议,常常忽略了这一点。虽然这些建议确实强调了变更管理、基于规则的访问控制、SLA 和支持等企业级需求,但它们更像是在说明“如何修补已有的产品”,而不是“如何从一开始就构建正确的产品”。事实上,有时过早优化确实会有回报。在生成式 AI 领域,采取“事后补救”的方式比传统 SaaS 产品更危险,因为限制更加复杂,市场变化也更快,你可能根本来不及改进产品,就已经被其他公司抢占了市场。

为什么只关注非科技企业?

你可能会有疑问:只关注非科技企业,那 B2C 市场或那些数字化程度高的科技公司呢?为什么似乎忽视了在这些市场盈利? 必须明确一点,在可预见的未来,生成式 AI 初创公司的收入将主要来自非科技企业。

首先,企业一直都是软件市场的主要资金来源。Microsoft 拥有庞大的 B2B 业务,Google 和 Facebook 也从企业广告中获得巨额收入。对于今天的生成式 AI 产品而言,其价值主张在于提升效率和创造力。企业愿意为此支付高昂的费用,说服少数几家大型企业,就相当于说服数万甚至数十万的个人用户。

其次,大型科技公司都在大力发展 AI,并拥有雄厚的资金实力。这不仅仅是 FAANG 公司,开源 LLM 和易于使用的相关框架也使得这些公司更倾向于自行构建,而非购买。所有大型科技公司都在争夺市场份额。试想一下,我们去向 Microsoft 推销 Codeium,结果可想而知。

大型科技公司对 AI 的关注,也让那些面向 B2C 的初创公司感到担忧,因为这些公司已经拥有庞大的用户群和强大的分销能力。Perplexity 正试图在 B2C 搜索市场挑战 Google,为此甚至使用了 Google 的后端服务。而 Glean 选择进军 B2B 搜索市场,并取得了不错的成绩,因为大型科技公司还没有完全进入这一领域。

大型科技公司的介入也加剧了技术原生企业的竞争,因为这些企业通常面临的限制更少。大型科技公司可以快速解决简单的限制,而初创公司则可以通过解决那些非技术原生企业面临的更复杂限制来实现差异化。在 Codeium,我们经常遇到这种情况。虽然几乎每家大型科技公司都有代码助手产品,但我们却很少与它们在非技术原生企业市场上竞争,因为我们的产品能够有效应对这些企业面临的独特限制。接下来,我们将详细探讨这些限制以及我们的应对方法。

你可能在想 OpenAI。他们凭借 ChatGPT 在 B2C 市场取得了巨大成功。我承认,OpenAI 是一个特例,因为他们在这个领域已经耕耘多年,而对于现在才开始创业的公司来说,这是难以企及的。而且,人们开始质疑 OpenAI 是否能长期留住用户,因为用户会尝试其他模型(例如 Anthropic 的 Claude 3.5 Sonnet 就受到开发者的欢迎),也会尝试其他的聊天产品(例如 Perplexity)。B2C 市场非常残酷。

怎么样成为“企业基础设施原生”公司

我希望我已经说服你,成为“企业基础设施原生”公司是多么重要。但这究竟意味着什么?从一开始就需要考虑哪些方面呢?

接下来,我们来探讨 Codeium 的经验教训。

数据是许多“企业基础设施原生”考虑因素的根本原因。与传统的 SaaS 应用不同,传统应用的数据虽然可能敏感,但可以追踪;而 LLM 的“黑盒”特性则增加了许多不确定性,包括训练数据和生成数据追踪的模糊性。

安全

生成式 AI 工具需要处理私有数据。每家企业都有关于数据隐私和安全的既定策略。例如,Codeium 处理代码,如果企业使用自托管的代码管理系统,那么他们已经表明,他们的默认策略是不将代码发送到第三方服务器,即使该第三方拥有 SOC2 等资质认证。

从基础设施角度来看,最重要的考虑因素是部署选项。通常需要提供完全隔离的自托管部署选项,或者至少是混合部署选项,确保所有持久化的私有数据(或衍生数据)都保留在客户的租户中。需要将服务器端容器化,以便于部署(单节点系统使用 Docker Compose,多节点系统使用 Kubernetes/Helm),并确保客户端能够安全地连接到客户的服务器实例。这些部署,尤其是自托管部署,挑战重重,包括:

  • 建立自己的镜像扫描机制,以防范安全漏洞(例如,Google Artifact Registry)。客户也会使用自己的扫描器,而且种类繁多。
  • 建立持续更新和发布机制(大多数客户更倾向于“拉取镜像”的更新方式)。更新频率取决于产品迭代速度——如果用户体验变化频繁,则可能需要几周更新一次;如果用户体验相对稳定,则每月或更长时间更新一次即可。快速更新的好处在于,一旦发现错误,可以更快地发布修复。
  • 确保产品能够在各种云服务和本地服务器环境中运行。不同云服务商提供的 GPU 实例类型和数量可能不同,因此需要仔细规划以最大限度地降低成本。
  • 为客户提供 GPU 部署方面的支持。

即使你认为自托管或混合部署过于复杂,也需要考虑一系列认证,例如 SOC2 Type 2(这是最低要求,需要数月时间获得认证)、ISO 27001(尤其受欧洲公司青睐)以及 FedRAMP(面向美国联邦政府机构)。获得这些认证通常需要进行容器化等操作,这在事后补救会非常困难。

最后,也是最重要的,如果你处理客户数据,千万不要用这些数据来训练模型。这听起来很简单,但却是客户最担心的问题。大多数合同都会明确要求这一点,我们也从未考虑过以获取训练数据为条件来提供折扣。

还有一个现实问题:企业对初创公司的安全性通常持怀疑态度,因此对安全的要求会高于大型科技公司。因此,你需要诚实地说明产品在不同部署选项下的能力。自托管版本的功能通常不如 SaaS 版本丰富,因此,在试用自托管版本与大型科技公司 SaaS 版本之间,你需要权衡利弊。

合规性

搜索“生成式 AI 诉讼”,你就会明白其中的风险。LLM 使用大量数据进行训练,而且无法追踪输出与训练数据的具体对应关系,因此带来了许多新的合规性问题。

许多模型的训练数据可能存在版权问题,例如受版权保护的图像或非许可的代码。许多企业法律团队担心使用这些模型会引发诉讼。 因此,“企业基础设施原生”的公司需要能够控制训练数据,无论是训练自己的模型,还是对开源模型进行微调。需要建立数据清理机制,向客户保证不会使用受版权保护的材料。需要更进一步——例如,我们不仅会删除所有非许可代码,还会删除所有与非许可代码编辑距离相似的代码。即使模型本身是概率性的,这种主动细致的措施也能提升客户的信任度。

另外,不要违反其他服务条款。例如,OpenAI 的服务条款明确禁止将 OpenAI 模型的输出用作训练数据。

企业会意识到模型的概率性,并希望获得数据可信度方面的保证。这就需要构建相应的归因系统,例如,基于编辑距离和相似度分数的启发式方法。我们构建了比简单字符串匹配方法更高级的归属过滤,但这通常还不够。我们还为许可代码匹配构建了归属日志,为特定行业构建了审计日志,并为医疗保健公司提供业务关联协议 (BAA,Business Associate Agreement) 支持等。所有这些都与基础设施建设密切相关。

作为初创公司,你需要提供与大型科技公司相当的赔偿条款,才能获得客户的信任。除非你对这方面有足够的信心,否则不要轻易承诺。

这些工作可能并不“令人兴奋”,但对于产品的成功至关重要。

个性化

你是否认为一个使用大量公开数据训练的通用系统就能满足企业需求?

大多数企业都认为自身数据具有独特性,即使它们的 IT 架构并不独特,它们也拥有大量与 AI 系统高度相关的私有数据。对于 Codeium 而言,现有的私有代码库对于生成高质量、减少幻觉至关重要,因为它包含了关于现有库、语义和最佳实践的知识。

安全问题再次出现。你不可能在每次推理中都处理所有原始私有数据,因此需要进行预处理,并将结果持久化存储。这再次凸显了纯 SaaS 解决方案的局限性。说服企业客户允许初创公司访问和控制其数据非常困难,这限制了个性化程度。

这不仅关系到知识产权的安全性,基于角色的访问控制 (RBAC) 也至关重要,因为 AI 工具本身可能会导致数据的泄露。生成式 AI 具有将现有数据整合的能力,而这需要谨慎对待。例如,对于政府项目而言,一些单独看起来不属于机密级别的数据,组合在一起后可能会构成机密信息1

在利用私有数据时,需要考虑许多因素,特别是对于老牌企业而言,数据质量对输出质量至关重要。数据的年龄、与当前任务的相关性、哪些数据源更重要以及如何平衡来自多个数据源的信息,都需要认真评估。

个性化是初创公司需要重点关注的领域,因为它可以带来差异化价值,而大型竞争对手往往难以快速跟进。但是,需要认识到,要实现有效的个性化,需要投入大量基础设施建设。

分析与 ROI 报告

虽然分析对于任何企业软件来说都很重要,但对于生成式 AI 而言,尤其关键,因为市场对其期望值过高。虽然这种过高期望可能会逐渐降低,但这并不意味着客户能清晰地了解生成式 AI 的价值,以及如何衡量其 ROI。

证明 ROI 非常困难。即使是代码生成这样相对明确的场景,也难以衡量开发人员的生产力。是拉取请求周期时间?还是接受的代码量?这些指标都存在许多干扰因素,难以准确评估 AI 工具的实际贡献。

尽管如此,大多数领导者都相信生成式 AI 能够提升价值,并相信员工的反馈。作为供应商,你应该帮助企业客户逐步实现更多价值。例如,可以按团队划分使用统计数据,以便管理员了解哪些团队受益更多,从而总结最佳实践,并帮助那些受益较少的团队。

延迟

延迟对于生成式 AI 至关重要,因为它直接影响模型的选择。例如,代码自动补全需要在数百毫秒内完成,这限制了可以使用的大模型。量化、推测解码等技术都无法解决大模型本身带来的延迟问题。

模型推理并非延迟的唯一来源。个性化、检索和推理过程都会影响延迟。将数据发送到远程服务器也会引入网络延迟,尤其是在处理视频等密集型数据时。对模型输出进行后处理(例如,归属过滤)也会增加延迟。

这些都是软件基础设施问题。再好的系统,如果速度跟不上,也是无用。

规模

这是一个综合性的问题,它放大了上述所有挑战。这些挑战在面对大型企业的用户规模、数据规模和基础设施复杂性时会更加突出。我们的客户拥有数万个代码库、数亿行代码和数万名开发者

你建立了用于个性化的代码库索引系统吗?那么,如果客户拥有数万个代码库,该如何处理?如何让客户指定哪些代码有用,哪些没用?如何管理如此规模的索引更新?如何确保在数万名开发者同时使用时不会影响延迟?如何管理数千个用户组和访问控制?

我没有时间详细解答这些问题,但如果你不想日后措手不及,就需要提前思考这些问题。

本文在某种程度上解释了 Codeium 的 B2B 成功,也展现了我们的思考过程。同时,我希望我的这个论断是错误的

我希望看到初创公司能够在 B2C 和技术原生 B2B 市场挑战大型科技公司。我希望看到各种类型的企业最终将 AI 视为提升自身技术水平的契机。而且,我希望看到像 Codeium 这样的 B2B 公司被视为创新型 AI 公司,而非仅仅是“企业就绪型解决方案”。

但如果你想在生成式 AI 领域获得持续盈利,希望本文能有所帮助!要做好“企业基础设施原生”的准备,并勇于应对挑战。

swyx:正如上一篇文章中所说,你可以了解Codeium 企业版,也可以观看Codeium 最新产品 Windsurf 的发布视频。是的,它也是一个 VS Code 分支,但它是一个基于 Anshul 和Varun 理念构建的智能化 IDE。我们将录制后续讨论,欢迎提出你的问题和想法!