这个成熟阶段是一个受欢迎的发展，因为它给CIO一个机会，可以将GenAI的承诺转化为业务价值。虽然大多数CIO知道试点项目不反映真实的场景——毕竟这不是试点的真正目的——他们往往低估了将GenAI投入生产所需的工作量。最终，要充分利用GenAI，公司需要重新设计工作方式，而建立一个可扩展的技术基础是这一过程的重要组成部分。
在我们之前的文章中，我们探讨了许多关键的初始技术问题。在这篇文章中，我们希望探讨关于用“Shaper”方法（公司通过将大型语言模型（LLM）连接到内部应用程序和数据源来开发竞争优势）扩展GenAI的七个真相。以下是Shapers需要知道和做的七件事：
1. 消除噪音，专注于信号。诚实地评估哪些试点项目有效。减少实验。将努力集中在解决重要的业务问题上。
2. 关键在于如何组合，而不是单个部分。评估GenAI引擎的各个组件花费了太多时间，更重要的是弄清楚它们如何安全地协同工作。
3. 在成本拖累你之前掌握成本。模型仅占GenAI应用程序总体成本的约15%。了解成本所在，并应用合适的工具和能力来控制它们。
4. 控制工具和技术的扩散。基础设施、LLM和工具的扩散使得大规模部署不可行。缩小到那些最能服务于业务的能力，并利用现有的云服务（同时保留你的灵活性）。
5. 创建能够构建价值的团队，而不仅仅是模型。实现规模化需要一个拥有广泛技能的团队，不仅能构建模型，还能确保它们安全、可靠地产生预期的价值。
6. 关注正确的数据，而不是完美的数据。瞄准最重要的数据并在时间上投资其管理，对你能多快实现规模有很大影响。
7. 重用。可重用代码可以将GenAI用例的开发速度提高30%到50%。
1. 消除噪音，专注于信号
尽管许多业务领导者承认需要超越试点和实验，但这并不总是反映在实际情况中。即使GenAI的采用增加了，其对实际收益的影响实例仍然很少。在我们最新的AI调查中，只有15%的公司表示GenAI的使用对他们公司的EBIT产生了有意义的影响。
这种情况加剧了领导者从实验中得出误导性教训的问题。他们试图将本质上是聊天界面试点的项目转变为应用程序——这是典型的“为技术寻找解决方案”的陷阱。或者一个试点可能被认为是“成功的”，但它并没有应用到业务的重要部分。
失败实现规模化的原因有很多，但最主要的是资源和高管的关注分散在几十个正在进行的GenAI项目上。这并不是一个新现象。当其他技术（如云计算和高级分析）出现时，我们也看到了类似的模式。然而，这些创新的经验教训并没有被牢记。
CIO需要做出的最重要决定是消除表现不佳的试点项目，并扩大那些在技术上可行并有望解决重要业务领域同时最小化风险的项目。CIO需要与业务单元领导密切合作，设置优先级并处理他们选择的技术影响。
2. 关键在于如何组合，而不是单个部分
在许多讨论中，我们听到技术领导者对交付GenAI（GenAI）解决方案所需的组件部分——LLM、API等——反复纠结。然而，我们了解到，解决这些单个部分相对容易，而将它们集成起来则非常困难。这在GenAI的规模化过程中创造了一个巨大的障碍。
挑战在于协调范围广泛的交互和集成。每个用例通常需要访问多个模型、向量数据库、提示库和应用程序。公司必须管理各种来源（如云端、本地、供应商处或其组合），保真度的程度（包括延迟和弹性），以及现有的协议（例如访问权限）。添加一个新的组件来提供解决方案，会对系统中的所有其他组件产生连锁反应，增加整体解决方案的指数级复杂性。
有效协调的关键在于将企业的领域和工作流程专业知识嵌入到应用程序在云基础上运行时的模型、数据和系统交互的逐步流程和顺序管理中。有效协调引擎的核心组件是API网关，它负责验证用户、确保合规、记录请求和响应对（例如，帮助团队计费），并将请求路由到最佳模型，包括第三方提供的模型。网关还支持成本跟踪，并为风险和合规团队提供了一种可扩展的使用监控方式。这个网关功能对于实现规模化至关重要，因为它允许团队独立操作，同时确保他们遵循最佳实践。
然而，要有效协调交付GenAI能力所需的众多交互，没有有效的端到端自动化是不可能的。“端到端”是这里的关键短语。公司通常会自动化工作流程的某些元素，但只有通过自动化整个解决方案，从数据处理（清理和集成）和数据管道构建到模型监控和通过“代码即政策”进行风险审查，才能真正获得价值。我们的最新研究表明，GenAI高绩效者在发布过程中的测试和验证嵌入率是其同行的三倍多。现代MLOps平台对于帮助管理这种自动化流程至关重要，根据麦肯锡的分析，它可以加快生产速度十倍，并提高云资源的使用效率。
由于其概率性质或基础模型的频繁变化，GenAI模型可能会产生不一致的结果。模型版本可能每周更新一次，这意味着公司不能仅仅设置其协调能力并让其在后台运行。他们需要开发超高敏感的观察和分类能力，以快速、安全地实施GenAI。可观察性工具实时监控GenAI应用程序与用户的交互，跟踪响应时间、准确性和用户满意度等指标。如果应用程序开始生成不准确或不适当的响应，该工具会提醒开发团队进行调查，并对模型参数、提示模板或协调流程进行必要的调整。
3. 控制成本，避免成本失控
GenAI数据使用和模型交互的规模庞大，意味着成本可能迅速失控。管理这些成本将对CIO是否能够在规模上管理GenAI项目产生巨大影响。但了解是什么驱动成本对GenAI项目至关重要。例如，模型本身仅占典型项目工作量的约15%。随着时间的推移，LLM成本显著下降，并继续下降。
CIO应将精力集中在以下四个现实上：
- 变更管理是最大的成本。我们的经验表明，管理GenAI成本的一个好经验法则是，每花费1美元开发模型，您需要花费约3美元进行变更管理。（相比之下，对于数字解决方案，这一比例通常接近1美元开发1美元变更管理。）纪律性管理变更操作范围，从培训人员到角色建模到主动绩效跟踪，对于GenAI至关重要。我们的分析表明，高绩效者在绩效管理基础设施（如关键绩效指标（KPI））方面的可能性几乎是其他人的三倍，以衡量和跟踪GenAI的价值。他们也更有可能培训非技术人员，让他们足够了解使用GenAI的潜在价值和风险。
公司在处理变更管理成本方面取得成功，主要集中在两个领域：首先，从一开始就让最终用户参与解决方案的开发（公司往往只是为GenAI应用程序创建一个聊天界面）；其次，邀请他们最优秀的员工来训练模型，以确保模型正确且快速地学习。
- GenAI应用程序的运行成本大于构建成本。我们的分析表明，运行模型的费用远高于构建模型。基础模型的使用和劳动力是成本的主要驱动因素。大部分劳动力成本用于模型和数据管道的维护。在欧洲，我们发现风险和合规管理也会产生显著的成本。
- 降低模型成本是一个持续的过程。例如，如何设计GenAI的架构决策可能导致成本差异达10到20倍，有时甚至更多。现有一系列成本削减工具和能力，例如预加载嵌入。这不是一次性的工作。成本优化过程需要时间和多种工具，但如果做得好，可以将成本从每次查询一美元减少到不到一美分。
- 投资应与投资回报率（ROI）挂钩。并非所有GenAI交互都需要同等对待，因此它们的成本也不应相同。例如，GenAI工具响应客户的实时问题，对于客户体验至关重要，需要较低的延迟率，因此成本更高。但代码文档工具则不需要如此高的响应速度，可以以更低的成本运行。云在推动ROI方面起着至关重要的作用，因为其主要价值来源于支持业务增长，尤其是支持大规模的分析解决方案。目标是开发一种建模纪律，在不陷入无休止分析的情况下，将ROI聚焦于每个GenAI用例。
4. 控制工具和技术的泛滥
许多团队仍在推动自己的用例，并且通常设置了自己的环境，导致公司不得不支持多种基础设施、LLM、工具和扩展方法。事实上，在最近的麦肯锡调查中，受访者将“平台过多”列为实施GenAI规模化的首要技术障碍。基础设施和工具越多，操作的复杂性和成本就越高，这反过来使得大规模推出变得不可行。这种状况类似于云和软件即服务（SaaS）的早期阶段，当时访问技术变得如此容易——通常只需一张信用卡——导致工具泛滥，造成混乱和风险。
要实现规模化，公司需要一套可管理的工具和基础设施。但如何选择供应商、主机、工具和模型？关键在于不要在无关紧要的决策上浪费时间（例如，选择LLM的重要性越来越低，因为它们逐渐变成商品），或者在根本没有多少选择的情况下浪费时间——例如，如果你的主要云服务提供商（CSP）拥有大部分数据并且你的团队熟悉该CSP的工作方式，那么你应该选择该CSP的GenAI服务。事实上，主要的CSP正在推出新的GenAI服务，这些服务可以帮助公司改进一些用例的经济性并开放新的访问。公司如何利用这些服务取决于许多变量，包括其自身的云成熟度和云基础的实力。
需要详细考虑的是如何以灵活的方式构建基础设施和应用程序，使其相对容易地切换供应商或模型。可以考虑采用供应商广泛使用的标准（如KFServing，一种用于部署GenAI模型的无服务器解决方案），Terraform用于基础设施即代码，以及开源LLM。
值得强调的是，过度设计灵活性最终会导致收益递减。解决方案过多会变得维护成本高昂，难以充分利用服务提供商提供的服务。
5. 创建能够创造价值的团队，而不仅仅是构建模型的团队
公司面临的最大问题之一是他们仍将GenAI视为技术项目，而不是广泛的业务优先事项。然而，过去的技术努力表明，创造价值从来不仅仅是“技术”问题。要让GenAI产生真正的影响，公司必须建立能够超越IT功能并将其嵌入业务中的团队。过去的经验教训也适用。例如，敏捷实践加快了技术开发。但只有当企业的其他部分（如风险和业务专家）与产品管理和领导团队一起整合到团队中时，才会产生更大的影响。
为了确保更广泛的企业整合，有多种原型可以使用。一些公司建立了卓越中心，作为优先考虑用例、分配资源和监控绩效的中枢。其他公司则在团队之间分配战略和战术职责。哪个原型适合某个特定企业，取决于其可用的人才和本地实际情况。但关键是，这一集中职能部门能够促成技术、业务和风险领导者之间的紧密合作，并严格遵循驱动成功项目的成熟协议。这些可能包括季度业务审查，以根据特定目标和关键结果（OKR）跟踪项目进展，并采取干预措施解决问题、重新分配资源或关闭表现不佳的项目。
这个治理结构的一个关键角色是确保有效的风险协议得以实施和遵循。例如，构建团队需要绘制每个用例相关的潜在风险；在整个用例生命周期中，需要实施技术和“人机协作”协议。这个监督机构还需要管理GenAI风险，通过评估暴露点并实施缓解策略来进行管理。
一个需要防范的问题是仅仅管理战术用例的流量，特别是在数量大的情况下。这个中央企业需要授权将相关用例聚集在一起，以确保大规模影响并推动大型创意。这个团队需要充当价值的守护者，而不仅仅是工作的管理者。
一家金融服务公司为高级管理层制定了明确的治理协议。由CIO和首席战略官赞助的指导小组专注于企业治理、战略和沟通，推动用例的识别和审批。由CTO赞助的赋能小组则专注于数据架构、数据科学、数据工程和核心赋能能力的决策。CTO还要求至少一名有经验的架构师早期加入用例团队，以确保团队使用既定标准和工具集。这种监督和治理的明确性在帮助企业从管理5个用例到超过50个用例的过程中起到了关键作用。
6. 选择合适的数据，而不是完美的数据
很多人误以为GenAI可以简单地收集必要的数据并加以理解。但没有清晰准确的数据，高性能的GenAI解决方案是不可能的，这需要实际的工作和关注。那些投资于数据基础设施以生成优质数据的公司，会有更明确的目标。
以标签处理为例，这个过程往往在为所有数据追求完美和完全忽视之间摇摆。我们发现，针对用于增强生成（RAG）的数据进行有针对性的标签处理，可以显著提高GenAI查询答案的质量。同样，花时间为内容来源的重要性进行评级（“权威加权”）也很关键，这有助于模型理解不同来源的相对价值。做到这一点需要具有相关专业知识的人的大量监督。
由于GenAI模型非常不稳定，公司需要在添加新数据时维护其平台，这种情况经常发生，并且会影响模型的表现。在大多数公司，这变得极其困难，因为相关数据分散在许多不同的地方。那些投资于创建数据产品的公司处于领先地位，因为他们有一个企业良好的数据源，可以用于长期训练模型。
例如，在一家材料科学产品公司，各个团队访问产品信息，但每个团队都有不同的版本。研发部门有材料安全表，应用工程团队（技术销售/支持团队）开发自己的版本以解决特定客户的问题，商业化团队有产品描述，客户支持团队有一套特定的产品详情来回答查询。随着每个团队更新其版本的产品信息，出现了冲突，使得GenAI模型难以使用这些数据。为了解决这个问题，公司将所有相关的产品信息集中到一个地方。
7. 重复利用
可重复使用的代码可以将GenAI用例的开发速度提高30%到50%。但是，由于急于取得有意义的突破，团队往往专注于单个用例，从而导致规模化的希望破灭。CIO需要将业务的精力转向构建能够服务于多个用例的跨领域解决方案。实际上，我们发现，表现突出的GenAI团队在构建战略性基础设施以实现跨解决方案重用方面的可能性几乎是其他团队的三倍。
然而，在致力于重用时，很容易陷入构建抽象GenAI能力的陷阱，这些能力虽然在技术上很容易实现，但却没有得到实际使用。一种更有效的构建可重用资产的方法是对一组用例（通常是三到五个）进行有纪律的审查，以确定它们的共同需求或功能。团队可以将这些共同元素构建为可轻松重用或组合在一起以创建新功能的资产或模块。例如，数据预处理和摄取可以包括数据分块机制、结构化数据和元数据加载器以及数据转换器等独立模块。一家欧洲银行审查了其能力在广泛用例中使用的可能性，并投资开发了一个合成器模块、一个翻译模块和一个情感分析模块。
CIO不能期望这一切自然发生。他们需要指定一个角色，比如平台所有者，并指定一个跨职能团队，任务是为产品团队开发可重用资产，这些资产可以包括经过批准的工具、代码和框架。
GenAI可能带来的价值是变革性的。但要捕捉到全部价值，公司需要在规模上利用GenAI，这要求CIO不仅要承认这些艰难的现实，还要准备采取行动，引领企业前进。
企业网D1net(www.d1net.com)：
国内主流的to B IT门户，同时在运营国内最大的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。同时运营19个IT行业公众号(微信搜索D1net即可关注)。
版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。
京公网安备 11010502049343号