【译】软件开发的历史告诉我们企业采用LLMs的障碍

作者：JooHo Yeo 和 Matt Kinsella

麦肯锡的一项研究显示，生成式 AI 预计每年将为全球经济增加 4.4T 美元的价值。然而，企业对该技术的采用进展缓慢，而且大多处于试验阶段。 Menlo Ventures 最近的一项调查显示，与传统人工智能（700 亿美元）和云软件（4000 亿美元）相比，企业对生成式人工智能的投资仍然小得惊人（25 亿美元）。

那么，是什么阻碍了企业大规模采用LLMs呢？

 由 DALL-E 生成

为了回答这个问题，我们回顾了历史以及从事企业LLM应用程序工作的 35 名机器学习工程师。

我们认为，工程师在整个LLM应用程序开发生命周期中测试和评估模型和应用程序的质量选项的短缺是采用的一个重大障碍，因此，对于初创公司来说，这是一个解决的绝佳机会。

传统软件开发生命周期 (SDLC)

现代软件开发流程的出现可以追溯到 20 世纪 70 年代，当时 Winston Royce 博士在他题为“管理大型软件系统的开发”的论文中首次引用了瀑布模型。这种方法将软件开发定义为一系列连续的阶段，其中每个阶段都依赖于前一个阶段的输出，类似于当时的制造过程。该模型很快就获得了管理者的支持，因为它为软件开发带来了结构，确保有明确的规范可供遵循。

资料来源：Winston Royce 博士的《管理大型软件系统的开发》

然而，该模型也有其局限性，例如无法获取用户的反馈，并且会因延迟测试而给整个流程带来风险。随着互联网的兴起，软件开发也开始发生变化。随着人们对更快地将软件推向市场的期望越来越高（以及能够加快步伐的开发工具和平台），瀑布模型的刚性和开销成为了开发人员速度的障碍。 2001 年，由 17 名开发人员组成的小组发布了“敏捷软件开发宣言”，该文件概述了敏捷开发的 12 条原则。该模型强调适应不断变化的需求的迭代版本，彻底改变了软件开发。这种转变放弃了僵化的结构，有利于加强开发团队和业务利益相关者之间的协作。交付最小可行产品（MVP）和迭代成为敏捷方法的核心部分。

 来源：TrustRadius

随着敏捷方法的兴起，出现了一个新的挑战：运营必须能够快速部署并向用户交付软件。基于他对开发和运营团队之间需要更多协同作用的观察，Patrick Debois 在 2009 年创造了“DevOps”一词。DevOps 的目标是敏捷方法的扩展：促进功能的持续交付、错误修复和开发。更新。 DevOps 需要传统上独立的单位（开发、质量保证、运营、安全等）之间的和谐协作。为了将这些功能整合在一起并持续交付给用户，需要采取新的步骤。

 资料来源：维基百科

DevOps 工具的兴起导致软件在 2010 年代席卷了整个世界（正如 Marc Andreesen 所说）。到 2010 年代末，“每个企业都变成了软件公司”。十年来，全球企业软件支出增长了 129%，从 2011 年的 $269B 增长到 2021 年的 $615B。DevOps 工具提高了支持云和移动平台转变所需的开发人员生产力。随着客户对可靠性的期望不断提高，满足测试和监控需求的工具对于不断增长的企业采用尤为重要。

随着软件开发生命周期的成熟，每一步都让位于成功的初创公司。这里仅仅是少数：

机器学习开发生命周期 (MLDC)

随着机器学习进入主流软件开发，它与传统软件开发有着不同的要求，这使得将机器学习解决方案应用和扩展到业务应用程序变得具有挑战性。 2015 年，“机器学习系统中的隐藏技术债务”一词被创造出来，这篇研究论文将上述问题引起了人们的关注。

• 数据收集、注释和管理被作为关键步骤引入。标记数据对于训练和评估模型至关重要。
• 跨各种模型类型的模型训练和评估需要利益相关者之间的迭代和协作。需要评估模型的准确性并以客观的方式相互比较。
• 部署后，需要持续监控模型的可靠性和准确性，而对于传统软件，维护的需要仅在于可靠性。随着时间的推移，训练、验证和生产数据的分布可能会发生各种变化，从而降低预测的性能。

一批新公司的出现来支持这些新的开发人员需求。

LLM 应用程序开发生命周期 (LLMADC)

与机器学习类似，LLMs 改变了应用程序的开发方式。最值得注意的是，数据障碍已被消除。开发人员不再需要预先收集大量标记数据来训练机器学习模型。预训练的 LLMs 足以用于演示甚至某些 MVP。然而，数据仍然是必要的，不仅可以评估定制模型的输出，还可以评估整个LLM应用程序的输出。

文本生成任务也比分类任务更难评估。分类任务要么正确，要么不正确，而生成的文本有多个维度需要评估，例如事实一致性、相关性和连贯性。不仅要全面评估输出质量，而且要系统地衡量它们以利于比较，这是一项艰巨的任务。

由于 LLMs 可以将非结构化数据作为输入，因此应用程序面临着基于意外用户输入而出现意外行为的风险。监视和评估用户如何与 LLM 应用程序交互的需求变得更加重要。

测试、评估和监控到底是什么？

开发团队需要评估和提高项目质量的方法。测试工具可帮助开发人员收集有关其软件的功能、可用性和性能的信息。测试工具的一些示例包括用于集成测试、错误跟踪、自动化测试和性能测试的工具。除了测试之外，这些工具还包含更广泛的测试管理解决方案，这些解决方案具有协作功能，可促进测试人员和开发人员之间的有效沟通。

评估工具可帮助团队在开发阶段部署不同版本并选择最佳变体以交付生产。评估衡量并比较对公司重要的各种业务指标，例如转化率或客户参与度。这使得软件工程团队能够将其技术进步转化为业务价值，从而在所有团队之间创建通用语言。

监控和可观察性工具有助于确保软件在生产中可靠运行。监控是指观察一组指标来检测故障和性能问题。这些性能指标包括网络流量、延迟和错误率。监控工具提供有关所发生事件的信息。可观察性将监控的概念更进一步，为工程师提供日志和跟踪以了解问题的根本原因。可观察性工具提供了有关问题发生原因以及解决方法的见解。

测试、评估和监控历来都是大型市场

测试、评估和监控对于提供软件产品的公司始终至关重要。虽然软件开发过程的所有步骤都很重要，但开发软件的最终目标是可靠地为用户提供价值。测试占据了企业软件开发预算的很大一部分（20-30%），这反映了其重要性。

特别是随着软件测试从手动向自动化的转变，像 Browserstack、Postman 和 SmartBear 这样的软件独角兽已经能够利用越来越快和全面的测试需求。自动化测试市场规模为 $15B，预计复合年增长率为 18.8%。

除了在软件开发过程中进行测试之外，企业还必须监控其软件部署后的情况，以确保其按预期运行。随着云基础设施变得越来越复杂，可观测性解决方案对于调试可靠性和延迟问题以及主动消除它们变得至关重要。可观测性产品还可以帮助企业更好地分析，从而减少基础设施支出。据 Honeycomb 称，公司将高达 30% 的基础设施成本用于可观察性。这一领域已经出现了几家价值数十亿美元的公司，包括 Datadog、New Relic 和 Dynatrace。

公司不仅仅关注确保功能，现在还衡量其产品提供的价值并量化其软件项目的投资回报率。包括 AB 测试软件在内的在线评估软件市场规模超过 10 亿美元，其中包括 LaunchDarkly、Optimizely、Split.io 和 Statsig 等公司。

对于LLM应用程序开发，评估和监控将继续至关重要，新公司将在这个领域涌现。为了了解 LLM 评估的未来前景，我们调查了在大公司 [JO1] [JY2]（拥有超过 20 名开发人员）工作的 25 名 ML 从业者，这些公司正在开发 genAI 支持的产品。除了调查之外，我们还采访了该领域的 10 名工程师。

 调查结果

我们要求专家将他们在生产中部署 LLMs 的最大障碍从一到六排序（其中一个是最高的，六个是最低的）。

超过三分之一的专家将“评估模型质量”视为将LLMs部署到生产中的最大障碍。当查看每个障碍的平均排名时，我们发现模型质量评估同样是首要关注的问题。

这些定量结果与我们从专家访谈中了解到的情况一致，其中工程师强调了减轻幻觉的重要性，特别是在金融和医疗保健等对错误容忍度较低的受监管行业中开发软件时。

将 LLMs 部署到生产环境的障碍（平均排名）

1）评估模型质量（2.04）

2）数据隐私和安全（3.08）

3) 测试和质量保证 (3.48)

4) 培训和服务成本 (3.72)

5）模型可靠性（3.84）

6) 摄取数据预处理 (4.92)

LLM 评估目前是一个耗时的过程。当被问及他们花在测试和评估上的时间比例是多少时，受访者表示他们花费了 35%。此外，他们当前的LLM评估流程的首要问题是需要“太多的工程资源”（76％）和“太多的时间”（68％）。

目前评估很耗时有两个原因。

1) 该过程是手动的。离线手动评估（由 ML 工程师或团队成员完成）是迄今为止从业者注意到的最常见的评估LLMs形式，占 64%。这与我们在采访中多次听说“目测”是“足够好”的解决方案是一致的。缺乏工具和标准流程还会导致重复性工作，使体验更加耗时。

2) 将临时工具拼接在一起非常耗时且不可扩展。 40% 的受访者表示，他们的组织使用内部开发的解决方案进行测试和评估，而只有 4% 的受访者表示他们正在评估外部解决方案。由于缺乏可用的外部选择，公司不得不构建自己的解决方案。例如，一家大型科技公司花费了八名工程师九个月的宝贵时间来开发一个内部评估平台。构建和维护LLM评估工具可能会带来重大的工程提升。

从选择LLMs到监控生产中的应用程序，评估会影响LLM应用程序开发生命周期的每个阶段。 80% 的受访者表示，他们在流程的多个阶段进行评估，68% 的受访者回答说，他们至少在下列六个主要步骤中的三个阶段进行评估。在LLM应用程序开发中，评估和测试不再是单个步骤，而是持续执行。

当被问及为什么LLM评估很重要时，专家们的回答是用户信任和持续改进是最重要的两个答案（分别为 84% 和 76%）。虽然利用评估的力量来实现排名靠前的迭代，但只有 40% 使用评估来做出运输决策，这表明当今流程和工具存在差距。事实上，对于缺乏测试和评估的效果问题，最高的回应是对产品缺乏信心（86%）。虽然基于LLM的应用程序开发仍处于早期阶段，但我们相信评估将为增强创新带来信心。

如前所述，目前很少有公司使用外部工具进行评估。

通过调查和采访，我们试图了解他们对现成解决方案的标准是什么。

我们一直听到的是，工程师正在寻找一种一体化解决方案，涵盖从开发测试到生产监控的所有内容。当被问及考虑外部选择时考虑哪些品质时，“评估和可观察性”排名最高（80%）。买家寻求的不是单点解决方案，而是可以支持工作流程所有部分的端到端解决方案。我们还认为，从业者优先考虑可观察性，因为由于输入空间不受约束，很难预测用户将如何与 LLM 应用程序交互。因此，虽然在开发过程中通知工程师的离线评估是关键，但在线评估能力也是必要的。

第二高的期望质量是可定制性（72%）。虽然默认测试集和指标很有帮助，但从业者正在寻找还可以添加特定于其业务需求的测试和评估方法的解决方案。这一结果并不令人意外，因为许多工程师对评估 LLMs 在其特定用例中的潜力的通用基准的不可靠性表示沮丧。对于外部解决方案，买家将寻找行业和应用（即总结、问答等）特定的数据集、测试用例和评估指标。根据主题专家输入和实际用户输入生成测试用例也将有助于满足这些可定制性需求。

LLM 评估市场规模估计

虽然我们仍处于 LLM 应用程序开发的起步阶段，但我们相信，根据我们对软件开发历史和从业者输入的研究，评估 LLMs 存在数十亿美元的市场机会。

根据我们的调查，96% 的受访者表示愿意购买外部 LLM 评估产品。大约一半的受访者处于 10-5 万美元和 50-10 万美元的范围内，这与我们采访的LLM评估初创公司与其较小规模客户签订的合同规模一致。 LLM 评估软件提供商在开始与商业和企业客户打交道时正在观察六位数的合同，这也反映在调查回复中，因为超过三分之一的受访者表示他们愿意支付六位数的费用七个数字。

为了估计 LLM 评估的市场规模，我们计算了调查回复的加权平均值，约为 32.6 万美元。有许多不同的方法可以考虑目标客户群的规模：

1）根据 Gartner 的数据，到 2026 年，超过 80% 的企业将使用 genAI API 或模型，和/或在生产环境中部署支持 genAI 的应用程序。如果我们将企业定义为员工超过 1000 人的公司，那么大约有 8000 家企业在美国。

2）根据 Tracxn 的数据，美国大约有 14,700 家人工智能公司。

3) 在微软 2023 年 10 月的财报电话会议上，Satya Nadella 表示，超过 37,000 个组织订阅了 Github Copilot for Business。

采用选项一最保守的方法（8000 家企业中的 80%），我们可以估计国内市场规模约为 $2.1B。

估计市场规模的另一种方法是查看企业预算。 Menlo Ventures 估计，2023 年企业在 genAI 上的支出约为 2.5B 美元，而所有 AI 支出约为 70B 美元。由于公司过去将 20-30% 的软件开发预算用于质量保证和测试，因此我们预计 LLM 评估预算将在 5 亿至 7.5 亿美元范围内。如果企业LLM支出随着LLM市场增长率以两位数复合年增长率增长，我们可以预计LLM评估市场规模将在2019年超过10亿美元。未来几年。

为什么LLM评估阻碍了采用：

评估是整个开发生命周期的瓶颈。与模型训练和部署等更性感的部分相比，测试/评估可能看起来很无聊，但它们对于支持LLM应用程序开发生命周期的每一步（从模型选择到实验，最后到监控）至关重要。公司正在寻找能够提供超越单点解决方案的每一步功能的解决方案。一致性是版本控制和统一评估形式的关键。

• Langfuse 是一家初创公司，提供从概念验证阶段到全面部署的测试和评估解决方案。其与模型和框架无关的产品跟踪功能使工程师可以更轻松地在整个开发过程中进行调试。虽然有些人可能会认为企业考虑可观察性还为时过早，但 Langfuse 正在构建一个数据架构来支持整个LLM应用程序开发生命周期，以满足不可避免的需求。

通用 LLM 基准不足以评估特定的业务用例。即使不考虑自定义，LLM 在一般任务与特定业务用例之间的表现也可能非常不同。借用 David Hershey 的比喻，基准测试就像 SAT 考试：它们有助于评估一个人在一系列科目上的技能。但对企业来说重要的是工作面试：候选人如何在该环境中执行与特定业务用例相关的任务。

• 像Patronus AI这样的初创公司可以通过在特定的现实场景中生成对抗性的、全面的测试用例并对模型性能进行评分，让企业更有信心部署LLMs。
• 特定行业的数据集可能是评估提供商的初始优势。 Patronus AI 发布了 FinanceBench（基于公开财务文档的高质量、大规模的 10,000 个问答对），作为对财务问题LLMs的第一线评估。

在离线评估方法中，人工评估是最常见的，但人工审查成本高昂、速度缓慢且容易出现人为错误——所有这些因素都会减慢开发过程。确定性和模型驱动的评估可以更便宜、更快，并提供公正的替代方案。缩短迭代周期可以加速软件开发。

• 正如调查分析部分提到的，已经构建内部解决方案的公司经历了构建综合评估平台所需的大量时间和人力资本投入。在模型、架构甚至评估方法经常发生变化的LLM世界中维护这些内部工具需要大量的专业知识和开销。购买外部解决方案可以缓解开发团队的这些头痛问题。
• Confident AI 提供了一个用于单元测试 LLM 应用程序的 Pytest（称为 DeepEval），它支持各种指标，例如幻觉、答案相关性、RAGAS 等。Confident AI 还实现了最先进的 (SOTA) ）基于LLM的评估方法，例如G-Eval，并构建专有的基于多智能体的评估方法（JudgementalGPT），以解决基于LLM的评估的局限性，例如位置和冗长偏差。
• 目前，由于成本和延迟问题，使用 SOTA 模型大规模运行自动化评估存在障碍。 HoneyHive AI 等评估初创公司正在投资研发特定于评估的基础模型，这些模型可用作离线和在线评估器，以极低的价格和速度提供符合 GPT-4 的性能。

用户如何使用LLM产品的不可预测性对于企业软件来说是一个挑战，因为企业软件几乎没有犯错的余地。在线评估对于了解用户如何使用产品并提前解决质量问题变得尤为重要。

• 像 Athina AI 这样的初创公司现在正在对用户查询进行主题分类，以帮助客户了解模型如何在不同类型的查询上实时执行。
• 最终，对公司来说重要的是LLM产品为用户提供了多少价值。为了衡量 LLM 产品对整个业务 KPI 的影响，可以利用 Statsig 和 Eppo 等 A/B 测试平台。

组织内各个利益相关者不断变化的需求需要新的解决方案。 ‍

• LLM 应用程序不仅由传统的机器学习从业者开发，而且越来越多地由产品工程团队和通才软件工程师开发。与传统的软件开发相比，非技术利益相关者（例如产品经理）也更容易参与prompt工程和监控等开发流程步骤。主题专家的意见在整个LLM应用程序开发周期中也始终至关重要。如今，工作流程的转变是通过将电子表格、内部仪表板和产品分析软件等各种互不相关的工具拼接在一起来解决的，这会导致效率低下和风险。像 HoneyHive AI 这样的公司正在构建一个统一的工作流程，以满足每个利益相关者的新工作流程需求，从而实现各方之间的无缝协作。

 资料来源：HoneyHive

为什么评估会随着时间的推移变得更加重要：

根据我们的采访，我们发现企业工程师目前专注于交付由自上而下影响力驱动的 MVP。

• 为了迭代（以降低成本、提高准确性并为用户提供附加价值），公司将需要能够持续跟踪性能并并行进行实验。
• 明确投资回报率对于进一步投资至关重要。

越来越多的利益相关者及其不同背景（技术和非技术角色）造成的复杂性不断增加，将使电子表格的目视和跟踪无法扩展。

LLM 系统是“脆弱的”，因为新模型和架构以及其他依赖性的快速引入。如果没有在单元和系统级别进行严格的测试，事情必然会崩溃并占用本已稀缺的机器学习工程时间。

• 依赖其他公司预先训练的模型会带来企业不太可能承担的风险。企业不会希望依赖模型提供商的沟通来了解这些风险，例如模型不可用和模型更新。
• 为了支持 LLM 应用程序架构不断变化的复杂性，包括 UpTrain 在内的初创公司不仅仅提供对响应和检索上下文的质量和适当性的基本评估。他们正在构建判断人工智能驱动对话的质量和人工智能代理行为正确性的能力。

虽然 OpenAI 和 Anthropic 等专有模型占据主导地位，但趋势正在转向使用多种模型的公司（甚至像 Martian 这样根据用例将提示路由到最佳模型的初创公司也开始出现）。去年 11 月的 OpenAI 恐慌导致数百名 OpenAI 客户在那个周末向其竞争对手伸出援手。

• 随着多种模型的使用，选择、试验和监控的需求将会增加。模型选择和架构的日益复杂性导致了更多的评估需求。

LLM评估初创公司的市场地图

这是在 LLM 评估空间中工作的初创公司的不全面可视化，这些空间由他们解决的问题组成。该线表示开发和生产阶段之间的区别。安全和路由也被包括在内，因为评估工程师在生产阶段面临着邻近的需求。

 最后的想法

思想领袖预测，2024 年我们将看到公司从原型转向生产以采用 genAI。 Matt McIlwain @ Madrona 说得很好，转变将从“‘让我们尝试’到投资回报率”。评估将是评估过去项目的投资回报率和预测未来项目所需投资所需的第一步。

虽然 genAI MVP 项目是由自上而下的决策驱动的，但 LLM 应用程序开发流程将像系统的传统软件开发流程一大模型样成熟。为了实现大规模企业采用，该过程不仅需要用于客观比较的定量数据，还需要用于利益相关者协调的广泛协作能力。这些额外的需求将使本已耗时的评估过程变得更加漫长，除非有工具来支持它们。解释指标的能力对于使不同的利益相关者达成一致至关重要。

评估需求将变得越来越针对特定行业和应用，而一般评估基准最多只能提供建议。随着公司不断为其不断发展的业务用例定制LLM应用程序，定制测试和评估指标的能力将势在必行。

我们对这一领域的初创公司持乐观态度，因为企业已经表达了购买而不是建设的积极初步信号。根据我们的调查和访谈，我们验证了痛点评估有多大，构建内部解决方案有多麻烦，以及为外部解决方案付费的意愿有多高。此外，提供评估工具的初创公司表示，他们本季度正经历一波入站潮。我们很高兴能够继续密切关注这个领域。