重要
弃用通知:Databricks 不再自动填充 payload_request_logs 和 payload_assessment_logs 表。 这些表已 弃用。
需要执行的作:
- 建议: 升级到 MLflow 3 以使用实时跟踪,这为统一日志记录提供了更好的性能。
- 替代方法:如果必须继续使用 MLflow 2,请参阅 备用解决方案 来维护对数据的访问权限。
时间线:
-
2025 年 12 月 4 日:
- 通过 agents.deploy() 新部署的代理将不再生成 request_logs 或 assessment_logs 数据表。
- 马赛克 AI 不再填充旧版的 request_logs 和 assessment_logs 表。 可以使用具体化视图创建自己的替换表。 请参阅 MLflow 2 的替代解决方案。
- 对于使用最新版本的 databricks-agents 部署的代理,将不再支持用于日志记录反馈的旧 实验 API 。 请改用 MLflow 3 评估 API 。
部署 AI 代理时,Databricks 会创建三个推理表,用于自动捕获代理的请求和响应。 这些表可帮助你监视性能、调试问题和分析用户反馈。
| 推理表 | Azure Databricks 表名称示例 | 表内容 |
|---|---|---|
| 有效负载 | {catalog_name}.{schema_name}.{model_name}_payload |
原始 JSON 请求和响应有效负载 |
| 载荷请求日志 | {catalog_name}.{schema_name}.{model_name}_payload_request_logs |
格式化的请求和响应。 MLflow 追踪。 派生自原始有效负载表。 |
| 有效负载评估日志 | {catalog_name}.{schema_name}.{model_name}_payload_assessment_logs |
针对每个请求的带格式反馈(在评审应用中提供) 派生自原始有效负载表。 |
- 原始 JSON 数据会在代理收到请求后一小时内输入有效负载表。
- 请求日志和评估日志表处理有效负载表中的数据并设置数据格式。 这需要额外的时间。
- 如果需要,可以从有效负载表手动提取和处理数据。
- 对有效负载表的更改(删除或更新)不会自动同步到派生表。
有什么变化?
Databricks 不再自动填充 payload_request_logs 和 payload_assessment_logs 表。
仍然有效:原始 payload 表继续从新请求接收数据。
迁移到 MLflow 3 并使用实时跟踪来统一代理日志
Databricks 强烈建议迁移代理终结点以使用 MLflow 3。 MLflow 3 实时追踪通过在一个追踪位置统一所有代理日志,无需单独的 request_logs 和 assessment_logs 表。
| 旧版可观测性 | MLflow 3 可观测性 | |
|---|---|---|
| 数据收集延迟 | 1 小时以上 | <10s |
| 数据组织 | 跟踪和用户反馈(评估)被提取到各自的 Unity Catalog 表(request_logs 和 assessment_logs)中。 |
可以在同一实验中轻松访问所有可观测性相关数据,例如跟踪、反馈和评估。 |
| 反馈集合 | 支持不足。 使用实验性反馈 API,该 API 将数据放入有效负载推理表中。 | MLflow 3 提供了简化的 API,用于运行评估、人工标记和管理评估数据集。 |
| 监控 | 支持不足。 支持仅限于现已弃用的旧监控系统,该系统仅适用于旧的内置判断模块及准则判断,并且不支持自定义指标。 旧式监控是基于有效负载请求日志运行的,因此代理响应的评估需要超过1小时。 |
监控与 MLflow 3 本地化集成,支持任何评分器:
包括指标回填功能,以追溯方式将新指标应用于历史跟踪。 从 MLflow 读取跟踪数据进行评估,监视延迟减少至 15 至 30 分钟。 |
MLflow 3 将评估附加到跟踪中,然后将跟踪以及所有有效负载、响应和中间步骤日志一起记录到 MLflow 跟踪服务器。 在开发期间查看标签和概念与数据模型。
迁移步骤
- 升级到 MLflow 3:确保代理使用 MLflow 3.1.3 或更高版本。 使用 MLflow 3 部署代理时,将自动启用跟踪。
# Install prerequisites
%pip install mlflow>=3.1.3
# Restart Python to make sure the new packages are picked up
dbutils.library.restartPython()
- 记录代理:像平常一样记录代理,确保它需要 MLflow 3.1.3 或更高版本。 然后,将模型注册到 UC。
# Log your agent
with mlflow.start_run():
logged_agent_info = mlflow.pyfunc.log_model(
name="my_agent",
pip_requirements=[
"mlflow>=3.1.3",
],
...
)
# Register your model to UC
uc_registered_model_info = mlflow.register_model(
model_uri=logged_agent_info.model_uri, name=UC_MODEL_NAME
)
- 部署代理: 像平常一样部署代理。 (可选)在部署前设置 MLflow 实验,以控制日志记录的位置。 如果不这样做,日志将被记录到当前活动的 MLflow 实验中。
import mlflow
from databricks import agents
# Set experiment for trace logging
mlflow.set_experiment("/path/to/your/experiment")
# Deploy with automatic tracing
deployment = agents.deploy(uc_model_name, uc_model_info.version)
# Retrieve the query endpoint URL for making API requests
deployment.query_endpoint
注释
MLflow 3 目前每个服务终结点最多支持 100,000 个跟踪。 如果预计需要更高的限制,请联系 Databricks 帐户团队。
有关详细信息 ,请参阅 Databricks 上部署的跟踪代理 。
继续使用 MLflow 2 的替代选项
重要
MLflow 2 替代方法不支持启用了代理监视的终结点。 如果使用监视,则必须迁移到 MLflow 3,并将监视器重新创建为 MLflow 3 记分器。
如果无法升级到 MLflow 3,Databricks 将继续填充原始 payload 表。 但是,Databricks 不再将此数据处理到payload_requests_logspayload_assessment_logs表中。
相反,Databricks 会基于数据负载表生成视图,以提供相同格式的数据。 有两个选项可用于访问此数据。 使用提供的视图或创建物化视图。
选项 1:使用提供的视图
最简单的方法是使用生成的视图 payload_request_logs_view 并 payload_assessment_logs_view 代替已弃用的表。
这些视图查询有效负载表以提供相同的格式化数据,并且它们可立即工作,无需设置。
(可选)重命名视图以匹配原始表名,以最大程度地减少代码更改。
选项 2:创建物化视图
提供的视图(payload_request_logs_view 和 payload_assessment_logs_view)通过查询有效负载表实时计算数据。 对于需要物理 Delta 表(如实时监视)的方案,请改为创建具体化视图。
运行以下笔记本,将视图转换为具体化视图:
为代理推理日志创建具体化视图
常见问题解答
现有请求日志和评估日志中的数据会发生什么情况?
推理表中的现有数据将继续可访问。 但是,从 2025 年 12 月 4 日起,不会在 request_logs 和 assessment_logs 表中填充任何新数据。
代理部署是否中断?
否,旧代理的部署将继续正常运作,有效负载推理表会继续被填充。 但是,在弃用日期之后,你不会在request_logs和assessment_logs表中收到数据。 使用提供的视图或迁移到 MLflow 3 来维护等效的功能。
如果需要迁移方面的帮助,请联系 Databricks 支持团队。