Databricks 上生成式人工智能的实用 MLflow 指南 (Chinese Edition)

第 10 章. 使用 MLflow统一 生成式 AI 系统

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在本书的整个过程中，我们探讨了使用 MLflow 开发、部署和管理生成式 AI 应用程序的主要环节。从 prompt 工程和版本控制，到追踪、评估、部署和持续改进，您现在已经具备了构建端到端生成式 AI 系统的基础。

当生成式AI应用进入生产环境时，调用模型通常是相对简单的一环。更棘手的问题在于如何让众多动态组件协同运作。您的应用框架、代理运行时、检索层、工具、后台服务、IDE助手以及评估堆栈虽然都能产生有用的信号，但如果它们各自“说着不同的方言”，那么每次故障的排查都会变得更加困难，每次改进的验证也会更加棘手。

这正是 MLflow 作用范围扩展之处，也是本章的主题。MLflow 不仅可以独立作为追踪库、prompt 工具或评估 API 使用，还充当了生成式 AI 系统的集成平台：它为追踪提供统一的追踪项，为运行时访问提供服务接口，并为评估和优化提供一致的工作流。

实际应用中，这表现为：可以在一个地方观察请求，助手可以通过编程方式调查相同的证据，编码代理可以遵循可重复的修复工作流，第三方评估器可以接入一个通用的评估循环。图 10-1从宏观层面展示了这一理念，将运行时执行、服务、助手工作流和评估连接成一个统一的运行模型。

图 10-1. MLflow 作为追踪、助手、编码代理和评审员的集成平台

MLflow 追踪作为共享的集成 artifacts

前几章主要将追踪视为可观测性资产。在本章（最后一章）中，更重要的理念在于组织层面：追踪是使系统其余部分更易于运维的共享 artifacts。产品工程师可以检查请求和最终响应。平台团队可以分析延迟、故障和执行路径。代理开发人员可以追踪工具调用、检索步骤和中间决策。 评估工作流可以在后续对同一 artifacts 进行评分，而无需从分散的日志中重建上下文。追踪成为记录应用程序中实际发生情况的权威系统。

这一点在异构架构中尤为重要。现代生成式人工智能系统很少仅基于单一语言或框架构建。单个用户请求可能依次经过 Typescript 前端、Python 编排层、Java 检索服务，以及用于工具或策略检查的 Go 后端。随着系统多样性不断增加，通用的追踪格式将迅速展现其价值。

MLflow 在此处大显身手，因为它为团队提供了一种以跨工作流通用形式保存执行历史的方法。同一条跟踪记录可同时支持调试、生产环境监控、数据集构建、人工审查和自动化评估。当可观测性、开发和质量保证都基于同一项成果时，它们之间就不会再出现脱节。

共享追踪存储库的实用性取决于其背后的规范。 我们建议团队一致地使用跨度类型（如AGENT、TOOL 和RETRIEVER），为重复性操作选择稳定的名称，并附加可搜索的元数据或标签（如user_id、session_id、environment 或app_version）。这些规范 使得查找可比的追踪记录、检查不同版本间的回归问题，以及将一次性事件转化为可重用的工程证据变得更加容易。

用于跨栈追踪的 OpenTelemetry

当您的系统范围超出直接使用 MLflow 构建的组件时，共享的追踪模型就显得尤为重要。许多生产环境应用已经使用 ...