在Doctrine上扩大生成式AI

生成式人工智能的兴起为许多公司带来了巨大的创新机遇，包括Doctrine在内。

在过去的一年中，我们一直在研究、完善并发布基于大型语言模型（LLMs）的更多先进功能。我们为我们最新的项目感到非常自豪。

在我们发布过程的最后一步中，我们面临的挑战之一是：一旦您拥有适用于少数用户的功能，如何将其扩展至成千上万的用户？

特别是，我们很早就决定没有用户数据会离开欧盟。这给我们使用的供应商施加了限制。

我们面临的挑战既涉及财务（运行LLMs可能会迅速产生较大费用），又涉及技术（我们遇到了限制，如速率限制和使用配额）。

我想分享一些关于这些挑战的见解，以及对我们有效的一些方法：通过适当的测量来预测使用情况，处理令牌使用，挑战我们的云提供商，以及持续升级模型。

限制

考虑到生成式人工智能的成本，我们不会立即向所有用户部署新的生成功能。相反，我们首先向一小部分用户开放这些功能。

在对这项功能的价值有信心后，我们开始向我们的客户群推出。对我们来说，这意味着从几十个用户增加到一万以上。

在实践中，这并不像把刻度推到100%那么简单。当需要扩展规模的时候，你可能会面临两个主要的限制：

• 成本：您需要确保您可以预计和确保您功能所需的预算。如果功能太昂贵，您将无法部署它。如果它太昂贵而您没有预料到，您将超支。



• 使用额度/速率限制：服务欧盟地区的LLM供应商，由于计算能力有限，因此会限制您在任何时候可以使用多少LLM容量。这通常表示为“每分钟令牌”（TPM）限制。如果超出了可用容量，您的功能将停止响应，LLM将无法继续运行。

这里有一些方法帮助我们在推出Doctrine的生成式功能时管理这些风险。

使其运作

知识就是力量

成功发布的第一个关键是确保您收集到所有需要的数据，以便做出相关选择。最重要的测量数据可分为两类：

• 运营指标：每个请求的功能成本是多少？如果您有测试用户，他们使用频率是多少？这将帮助您确定是否有问题需要解决。
• 质量：特征的输出有多相关？绩效评估在开发的每个阶段都至关重要。您需要从一开始就进行评估，以确保您的特征是好的。但是如果您开始关注成本或对特征进行迭代，您也需要进行评估，以确保不会降低答案的质量。衡量gen AI性能有很多方法。您应该尽可能地让这个过程自动化，尽管有时候您确实需要一个专家参与（这本身就是一个丰富的话题，也许值得在未来的文章中讨论！）。拥有良好的绩效评估还可以让您比较并选择最适合您需求的最便宜的模型。

有了这些度量指标，您将了解成本或速率限制是否确实是风险因素。实际操作中，您不应该遇到太多麻烦：

• 如果您的输入和输出非常小（通常每个请求几十到几百个令牌，尽管这也取决于功能的流量）。在这种情况下，您可能不会遇到大额费用或令牌使用量。
• 如果您使用较便宜的模型。“小型” LLM（如GPT3）在成本和可用容量方面与最昂贵的模型（如GPT4）相比有数量级的差异。这也是为什么在将它们用于生产之前，您应该花时间确保您确实需要最先进的模型。有时候，您却无法绕过它。

一些我们的生成特性实际上成本微乎其微，并在完全发布之前不需要我们采取任何特殊行动。

减少令牌使用

输入和输出的大小通常以“令牌”来计算。

每个令牌都需要一定金额，并计入您的使用配额（至少在通过云提供商时是如此-如果您自己托管，则关系不太明确，但仍然存在）。

这意味着一个非常重要的指标是：每次使用此功能时我消耗多少令牌？

它对成本和使用均有重大影响。

这里没有灵丹妙药，解决方案将在很大程度上取决于您的使用情况。一些对我们有效的方法包括：

• 具有详细的测量数据：除了上述提到的高级指标外，我们还非常精确地测量我们的LLM提示的结构。如果我的输入/输出很大，那是为什么？我的用户输入了大量输入吗？我是否为模型提供了大量的上下文？如果是的话，哪些文档最长？我能否生成更小的输出？您希望尽可能详细地分解这些问题，以了解您在哪里可以发挥影响力。
• 分块：一个用例是输入往往很大的地方是检索增强生成（RAG），在这里您提供有用的上下文以及用户查询。如果上下文文档很大，您应该花一些时间将这些文档分解成较小的部分，并只传递相关段落作为上下文，而不是整个文档。
• 缓存：在某些情况下，您将一遍又一遍地执行相同的生成（无论是最终结果还是中间步骤）。在这种情况下，将输出存储起来并避免不必要的开销是非常有效的。例如，如果允许用户总结一篇公共文档，您可能希望在完成后将摘要存储起来并在之后重复使用。
• 处理子案例：一些功能具有非常开放的输入方式（尤其是类似聊天的输入）。这意味着用户可能会尝试通过在同一输入框中输入内容来满足各种需求。在实践中，这是一个既可以降低成本又可以增加相关性的机会。一些查询可能完全超出范围，检测到它们将使您可以避免浪费资源，而是返回一个标准答复。有些查询可能非常简单，不需要您的RAG工作流的全部功能。一个例子是：我们的聊天功能会检测用户询问一个特定文件问题而不是在广泛话题上寻找信息的情况（这种检测是通过一个初步的查询理解步骤完成的，也使用LLM）。在这些情况下，我们不会将多个文件传递给LLM作为上下文信息，而是只使用一个文件。这会大大降低这些查询的成本，还能帮助我们提供更加专注的答复并提高功能质量。这是一个双赢的情况！

与您的云服务提供商要求严格

对于我们大部分的功能，我们使用由OpenAI（GPT3.5，4等）提供的模型。为了将我们的数据保存在欧盟境内，我们不直接通过OpenAI的API，而是使用微软Azure。他们提供相同的模型，托管在欧盟境内的服务器上。

然而，由于这些地区的计算能力一直受到很大压力，他们难以满足对LLM使用的需求。因此，他们最初给了我们非常低的配额，几乎不允许我们在内部使用我们的功能。

它花费了我们的CTO和平台团队大量的时间，坚持不懈甚至固执地逐渐解锁更多的配额，降低被限制速率的风险。这里的教训是：知道自己需要多少，并且不要害怕反复要求。

另外，在选择模型和供应商时，请考虑到配额的可用性。

基准，升级，重复

LLM的竞争环境并不是静态的。每个月都会有新的、更好、更便宜的模型出现。有时候，升级到更好的模型会比几周的研究更有利于降低成本和提高特性质量。例如，新的gpt4o比之前的gpt4-turbo型号便宜一半（并且对我们的使用来说，性能相当）。

要做到这一点，您需要能够自信地比较模型然后再进行切换。这就是为什么有必要投资于基准测试能力，如上所述。

在这里，如果做得对，这可以让您在成本降低的同时，功能不断提升的双赢局面。

踏出飞跃

无论你为准备工作付出了多少努力（计算成本、减少成本、预测用户在功能上的活动），你仍然会遇到困难的问题。

一旦我们发布，该功能的使用率将达到峰值。我们确定能避免速率限制吗？

如果有些人喜欢这个功能，并且使用它的次数是目前具有访问权限的用户的十倍，那会怎么样呢？

你永远无法完全了解你的生产使用会是什么样子。你可以逐渐推出，测量所有可能的东西，并确认你的假设是正确的：我们没有超出预算，并且我们不会受到速率限制。

只要你一步一步走，你就能够应对任何意想不到的情况，并回到我之前概述的步骤，然后再广泛推广。

最后但并非最不重要的是：请记住，如果整个公司都对这些主题达成了一致意见，所有这些都会得到最好的发挥：我们在这些功能上的定价策略是什么（这对我们的预算意味着什么）？其他团队是否正在推出一项创造性功能（因此希望为自己使用一些配额）？

只有在整个组织中采取理性、一致的方法，您才能成功地扩展AI。