作者：来自 Elastic Chris Blaisure

为什么要采用“构建与采购”相结合的 AI 策略

作为 Elastic 的技术领导者，我的团队负责在集中式架构上构建 AI 体验，使我们的销售和客户支持团队能够扩大影响力并更快利用 AI。我们面临的两难境地 —— 也是每个技术团队都会面临的 —— 不再是我们该构建还是采购 AI 应用，而是：如何设计一个稳健的企业架构，在利用现有 SaaS 投资的同时，构建复杂且符合业务需求的 AI 应用，以实现最大化影响？

许多 SaaS 应用内置了 AI 功能和体验，帮助用户加速工作流。然而，这些 AI 功能分散在彼此独立、与企业相关上下文和系统脱节的应用中。根据麻省理工学院的一项最新研究，95% 的企业 AI 投资都失败了，毫无回报。这并不是资金问题，而是架构问题，表现为低使用率。当 AI 无法提供正确答案或动作时，用户就会停止使用，预期的业务影响也随之丧失。

技术团队不应在 “构建” 与 “采购” 之间做选择，而应构建一个稳健的企业架构。这样，组织就能创建自定义的 AI 体验，将所有相关的分布式源系统和 SaaS 应用的上下文连接起来，从而提供准确且可信的输出。SaaS 应用仍然有其价值 —— 它们带来特定用例的知识，提供工作流引擎，并作为记录系统存在。

通过在企业架构中构建一个上下文检索机制，从 SaaS 应用中提取知识，技术团队可以构建具备上下文感知能力的 AI 应用。通过叠加性能可视化技术，他们还可以跟踪用户参与度、准确性和业务影响。

耐久的企业级 AI 架构组件

耐久的 AI 架构是实现“自建与购买”策略的关键。它让团队能够从简单、低复杂度的 AI 用例扩展到高度复杂的智能代理工作流。该架构主要聚焦于两个方面：上下文检索与性能监控。

上下文检索组件

高价值 AI 的关键在于确保 AI 模型能通过访问高质量数据，获得关于企业的深度、准确且安全的上下文。上下文检索机制通过上下文工程构建，它是一套让大语言模型（LLM）能够访问完成任务所需正确信息的实践与能力集合。

• 企业知识来自 SaaS 应用：通过集成（integrations）与连接器，在开放的向量数据库中大规模摄取、统一与存储来自 SaaS 应用和企业系统的非结构化、半结构化和结构化业务数据。这包括标准操作流程、公司政策和业务流程等额外信息，使 AI 响应建立在企业逻辑与专有数据之上。

• 信息安全：通过文档级与字段级安全控制以及基于角色的访问控制（RBAC），实施并执行数据安全，确保只有正确的用户能访问相关信息。

• 搜索检索：为了让 LLMs 获取最相关的上下文，团队需要使用先进的搜索技术，将用户查询意图与源系统中的相关上下文匹配。这包括多种搜索与排序技术——基于机器学习（ML）的语义搜索、混合检索、高级相关性调优与重排序 —— 以驱动能提供精确结果的 AI 应用。

• AI/ML 集成：采用平台化方法，企业 IT 团队能快速访问首选的 LLM 与 AI 开发框架，加速开发。借助 ML 模型，团队还能进一步调优相关性，将最相关的上下文传递给 LLM，从而提升准确性、用户体验与输出可信度。

提供的上下文越多，响应与行动就越准确。随着用例复杂度的提高，添加上下文也会增加上下文工程与架构的复杂性。然而，提前投资构建能从源系统中提取分布式数据与上下文的架构，将在后续构建更多用例时显著减轻技术负担。

技术性能监控组件

没有 AI 性能管理，IT 团队将缺乏可视性，无法信任或推动 AI 体验的采用。因此，在架构中加入可观测性是 “自建与购买” 策略中的关键支柱。

• 应用性能监控（APM）：APM 提供关键洞察，包括响应时间、错误率与资源使用率，帮助跟踪支持 AI 应用的服务与基础设施性能。通过监控瓶颈与异常，团队能快速定位问题，并在影响客户体验前解决潜在事件。

• LLM 可观测性：LLM 可观测性提供关于 AI 模型性能、上下文准确性与使用模式的重要业务洞察，如用户参与度、响应准确性、对话质量与用户情绪。按用例对这些对话与交互分组，可进一步了解用户的参与方式。这些洞察为开发者提供关键信号，帮助他们快速微调体验、扩展成功用例，并优化符合真实用户需求的解决方案，从而进一步提升满意度并加速采用。

• 云监控：大多数 AI 应用托管在云端，因为其工作流资源密集且动态。云端提供企业级 LLM 与 AI 框架的便捷访问、自动伸缩基础设施、基于 SLA/SLO 的应用可用性以及成本管理。通过云监控，团队可关联云基础设施的性能与成本，快速诊断与基础设施相关的瓶颈并优化资源使用。

借助可观测性工具，开发团队能轻松跟踪 AI 应用的性能与准确性。

注意：通常情况下，SaaS 应用并不会提供有关用户参与度或响应准确性的 AI 洞察。由于在 SaaS 应用中对 AI 性能的可视性有限，企业必须投资于可持续的 AI 企业架构，以便构建自定义 AI 解决方案。通过可观测性工具对这些解决方案进行监控，企业才能获得有关 AI 性能的深入洞察。

在架构复杂性与投资回报率之间取得平衡

可持续架构的目标不是快速构建最复杂的 AI 用例，而是有目的地构建，并在长期内推动投资回报率（ROI）。在简单的 AI 用例上进行初始投资可能会迅速带来业务影响，因为这类用例通常只需要从源系统中提取少量上下文。

然而，当转向中等或高复杂度的用例时，开发团队需要投入更多精力来实现上下文检索机制和监控层，从而增加总体拥有成本（TCO）。但一旦架构建立完成，基于相同上下文构建的每个后续 AI 用例都会更快、更低成本地部署，随着团队规模扩大，ROI 将呈指数级增长。

在 Elastic，我们在自己的 AI 用例中看到了这一点。通过使用 Elastic Observability 构建统一的、具备上下文感知的架构和监控，我们的内部 Support Assistant 在第一年通过减少工单转交实现了约 170 万美元的成本规避。此外，30% 的支持已通过 Support Assistant 实现数字化交付。这证明了当你专注于统一的上下文和技术性能时， ROI 可以快速扩大。我们现在正使用相同的架构来部署销售用例，例如基于账户的洞察、 RFP 自动化以及 AI 账户计划。

Elastic 让耐用的 AI 架构成为可能

“构建并购买” 方法对于从短期项目思维转向长期 AI 战略至关重要。现有的 SaaS 投资可以也应该被用来为 AI 体验提供所有相关的上下文，以生成准确的输出。通过优先采用架构优先的方法，你的组织可以超越碎片化的 AI 功能，构建可扩展的 AI 解决方案。

在 Elastic，我们使用我们的 Search AI Platform 构建耐用的企业级 AI 架构。我们通过 Elasticsearch 利用上下文工程构建上下文检索机制，为 LLM 提供最相关的数据和工具，使我们的 AI 体验能够生成准确的响应和操作。而借助平台内直接访问的 Elastic Observability，我们可以监控技术性能，从而交付可靠的 AI 应用，实现业务影响。

了解我们如何在 Elastic 的 Search AI Platform 上为 Support Assistant 构建耐用的企业架构。

本文所述功能或特性的发布时间和发布内容完全由 Elastic 自行决定。目前尚未提供的功能或特性可能不会按时发布，甚至可能不会发布。

本文可能使用或提及了第三方生成式 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 无法控制这些第三方工具，也不对其内容、运行或使用承担任何责任或义务，也不对因使用此类工具而造成的任何损失或损害负责。在使用 AI 工具处理个人、敏感或机密信息时，请务必谨慎。你提交的任何数据可能被用于 AI 训练或其他用途，不能保证你提供的信息会被安全或保密地保存。在使用任何生成式 AI 工具前，你应熟悉其隐私政策和使用条款。

Elastic、Elasticsearch 及相关标志是 Elasticsearch B.V. 在美国及其他国家的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

原文：https://www.elastic.co/blog/build-and-buy-ai-strategy