MLflow GenAI 怎样用 trace 做回归测试并断言评分

如果一个 GenAI 应用曾经把“支持时间”回答成多句话，修完提示词后不能只在页面上点一次确认。更稳妥的做法是把那次真实 trace 对应的输入固定下来，交给 MLflow GenAI 的 scorer，再让 pytest 对评分结果做断言。

官方地址：https://mlflow.org/docs/latest/genai/eval-monitor/regression-testing/

这套方案的核心不是追踪一个总分，而是把一个已知失败行为变成可重复的二值门禁：@mlflow.test 标记测试，mlflow.genai.evaluate() 运行 scorer，最后用 assert result.passed, result.reason 让 CI 在回归时直接失败。

下面只讨论 trace、scorer 和断言的组合，不展开生产监控告警。

先把 trace 变成一个可复现的回归样本

一条 trace 里可能有用户输入、最终答案以及工具调用等中间信息。回归测试不需要把整段生产数据复制进仓库，而应挑出一个明确的失败边界：例如固定问题、期望语言和回答长度。这样测试守护的是行为，不是某次生成文本的逐字相等。

如果已经把 trace 存在 MLflow 后端，也可以用 mlflow.search_traces() 找到样本，再把返回的数据交给评测函数。写入测试前先缩小到一个具体行为，避免一个测试同时承担语言、事实、格式和延迟四种职责。

让 pytest 认识 @mlflow.test

@mlflow.test 运行在 pytest 插件之上。项目级配置可以放在 pyproject.toml，临时试跑则把插件参数写在命令行：

[tool.pytest.ini_options]
# 让 pytest 自动加载 MLflow 的 GenAI 回归测试插件
addopts = ["-p", "mlflow.pytest.plugin"]

# 只在本次执行中启用插件，便于先确认测试入口
pytest -p mlflow.pytest.plugin tests/regression/test_support_agent.py

官方设计是让一个测试会话中的回归测试记录到同一条 MLflow 运行记录里。这样 CI 的绿灯和 MLflow 页面中的测试历史来自同一套断言，而不是两套容易漂移的脚本。

用 scorer 评测输出，再把结果变成断言

测试函数只需要提供一个应用入口、固定输入和 scorer。下面用两个 Guidelines 分别约束语言和句子数量；agent 是项目自行提供的 pytest fixture。

import mlflow

from mlflow.genai.scorers import Guidelines


@mlflow.test
def test_support_answer_is_concise(agent):
    # 固定曾经出错的用户问题，避免测试目标随样本漂移
    result = mlflow.genai.evaluate(
        predict_fn=agent.invoke,
        data=[{"inputs": {"question": "What are your support hours?"}}],
        scorers=[
            Guidelines(
                name="is_english",
                guidelines="The answer must be written in English.",
            ),
            Guidelines(
                name="is_concise",
                guidelines="The answer must be a single sentence.",
            ),
        ],
    )

    # passed 汇总所有 scorer 与所有数据行，失败时保留 judge 理由
    assert result.passed, result.reason

result.passed 只有在每一行的每个 scorer 都通过时才为真；失败时，result.reason 会列出失败 scorer 及其理由。因此断言消息不应只写一段模糊的“评测失败”，否则 CI 仍要回到 MLflow 页面人工猜原因。

不要把回归门禁和数据集评测混为一谈

数据集评测回答的是“这批样本的正确性或安全性平均是多少”；回归测试回答的是“这个已知问题是否又出现了”。前者适合看整体指标，后者适合在每次改提示词、换模型或重构工具后阻止特定行为悄悄回来。

当评分标准需要检查 trace 的中间步骤时，scorer 可以读取完整 trace，而不是只看最终文本。此时仍要把测试边界写清楚：只断言本次要保护的工具调用、路由或输出属性，不把所有观测字段都变成脆弱的快照。

常见问题

为什么不直接比较完整回答字符串？

生成式输出可能有多种同样合格的表达。用 scorer 描述行为边界，比把一次答案当成唯一快照更能容纳合理变化。

失败时先重跑还是先看 reason？

先看 result.reason 指向的 scorer 和理由，确认是目标行为回归、样本问题还是评测服务问题，再决定是否修代码或调整测试边界。

落地时可以从一条真实失败 trace 开始，只写一个窄断言；等它稳定进入 CI 后，再为新的失败模式增加独立测试。这样 MLflow trace 负责提供上下文，scorer 负责表达标准，pytest 断言负责把标准接入发布门禁。