代理评估如何评估质量、成本和延迟

本文介绍了代理评估如何评估 AI 应用程序的质量、成本和延迟，并提供见解来指导质量改进和成本和延迟优化。 其中涵盖以下内容：

• LLM 法官如何评估质量。
• 如何评估成本和延迟。
• 如何在 MLflow 运行级别聚合指标，以达到质量、成本和延迟。

有关每个内置 LLM 法官的参考信息，请参阅 马赛克 AI 代理评估 LLM 评委参考。

LLM 法官如何评估质量

代理评估在两个步骤中使用 LLM 法官评估质量：

1. LLM 法官评估每行的特定质量方面（如正确性和基础性）。 有关详细信息，请参阅 步骤 1：LLM 法官评估每行的质量。
2. 代理评估将单个法官的评估合并为总体通过/失败分数，以及任何失败的根本原因。 有关详细信息，请参阅 步骤 2：合并 LLM 法官评估以确定质量问题的根本原因。

有关 LLM 法官的信任和安全信息，请参阅 有关为 LLM 法官提供支持的模型的信息。

步骤 1：LLM 评委评估每行的质量

对于每个输入行，代理评估使用一套 LLM 法官来评估代理输出质量的不同方面。 每个法官都会生成一个是或否的分数和该分数的书面理由，如以下示例所示：

有关使用的 LLM 法官的详细信息，请参阅 可用的 LLM 法官。

步骤 2：结合 LLM 法官评估来确定质量问题的根本原因

运行 LLM 法官后，代理评估将分析其输出，以评估整体质量，并确定法官集体评估的合格/失败质量分数。 如果整体质量失败，代理评估会确定哪个特定的 LLM 法官导致失败并提供建议的修复。

数据显示在 MLflow UI 中，并且也可以在调用返回的数据帧中从 MLflow 运行中获取 mlflow.evaluate(...) 。 有关如何访问 DataFrame 的详细信息，请参阅 评审评估输出 。

以下屏幕截图是 UI 中的摘要分析示例：

详细信息视图 UI 中提供了每行的结果：

可用的 LLM 法官

下表总结了代理评估中使用的 LLM 法官套件，用于评估质量的不同方面。 有关更多详细信息，请参阅 “响应法官 ”和 “检索”法官。

有关为 LLM 评委提供支持的模型的详细信息，请参阅 有关为 LLM 法官提供支持的模型的信息。 有关每个内置 LLM 法官的参考信息，请参阅 马赛克 AI 代理评估 LLM 评委参考。

以下屏幕截图显示了这些法官在 UI 中的显示方式的示例：

如何确定根本原因

如果所有法官都通过，则认为 pass质量。 如果任何法官失败，则根本原因将确定为根据下面的有序列表第一个失败的法官。 之所以使用此排序，是因为法官评估通常以因果关系方式关联。 例如，如果 context_sufficiency 评估检索器尚未为输入请求提取正确的区块或文档，则生成器很可能无法合成良好的响应，因此 correctness 也会失败。

如果基本真相作为输入提供，则使用以下顺序：

1. context_sufficiency
2. groundedness
3. correctness
4. safety
5. 任何客户定义的 LLM 法官

如果未将地面真相作为输入提供，则使用以下顺序：

1. chunk_relevance - 是否至少有 1 个相关区块？
2. groundedness
3. relevant_to_query
4. safety
5. 任何客户定义的 LLM 法官

Databricks 如何维护和改进 LLM 判断准确性

Databricks 致力于提高 LLM 法官的质量。 通过测量 LLM 法官使用以下指标与人工评价员的同意程度来评估质量：

• 增加了 科恩的卡帕 （一个衡量利率之间的协议）。
• 提高准确性（与人工评分器标签匹配的预测标签的百分比）。
• 提高了 F1 分数。
• 误报率降低。
• 降低误报率。

为了衡量这些指标，Databricks 使用来自学术数据集和专有数据集的多样化、具有挑战性的示例，这些数据集代表客户数据集来对评委进行基准测试，并针对最先进的 LLM 法官方法改进法官，确保持续改进和高准确度。

有关 Databricks 如何衡量和持续提高法官质量的更多详细信息，请参阅 Databricks 宣布对代理评估中的内置 LLM 法官进行重大改进。

尝试使用 SDK 的 databricks-agents 法官

databricks-agents SDK 包括用于直接调用用户输入的法官的 API。 可以使用这些 API 快速轻松地进行试验，了解法官的工作方式。

运行以下代码以安装 databricks-agents 包并重启 python 内核：

%pip install databricks-agents -U
dbutils.library.restartPython()

然后，可以在笔记本中运行以下代码，并根据需要对其进行编辑，以便根据自己的输入尝试不同的法官。

from databricks.agents.eval import judges

SAMPLE_REQUEST = "What is MLflow?"
SAMPLE_RESPONSE = "MLflow is an open-source platform"
SAMPLE_RETRIEVED_CONTEXT = [
        {
            "content": "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
        }
    ]
SAMPLE_EXPECTED_RESPONSE = "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."

# For chunk_relevance, the required inputs are `request`, `response` and `retrieved_context`.
judges.chunk_relevance(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For context_sufficiency, the required inputs are `request`, `expected_response` and `retrieved_context`.
judges.context_sufficiency(
  request=SAMPLE_REQUEST,
  expected_response=SAMPLE_EXPECTED_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For correctness, required inputs are `request`, `response` and `expected_response`.
judges.correctness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  expected_response=SAMPLE_EXPECTED_RESPONSE
)

# For relevance_to_query, the required inputs are `request` and `response`.
judges.relevance_to_query(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

# For groundedness, the required inputs are `request`, `response` and `retrieved_context`.
judges.groundedness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For safety, the required inputs are `request` and `response`.
judges.safety(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

如何评估成本和延迟

代理评估度量令牌计数和执行延迟，以帮助了解代理的性能。

令牌成本

为了评估成本，代理评估计算跟踪中所有 LLM 生成调用的总令牌计数。 这近似于总成本，令牌越多，通常导致的成本越多。 令牌计数仅在可用时 trace 计算。 如果在 mlflow.evaluate() 调用中包含 model 参数，则自动生成跟踪。 还可以直接在评估数据集中提供 trace 列。

为每个行计算以下令牌计数：

执行延迟

计算整个应用程序的跟踪延迟（以秒为单位）。 仅当跟踪可用时，才计算延迟。 如果在 mlflow.evaluate() 调用中包含 model 参数，则自动生成跟踪。 还可以直接在评估数据集中提供 trace 列。

计算每行的以下延迟度量值：

如何在 MLflow 运行级别聚合指标，以达到质量、成本和延迟

计算所有每行质量、成本和延迟评估后，代理评估会将这些评估聚合到 MLflow 运行中记录的按运行指标中，并汇总所有输入行中代理的质量、成本和延迟。

代理评估生成以下指标：

以下屏幕截图显示了指标在 UI 中的显示方式：

有关为 LLM 判定提供支持的模型的信息

• LLM 判定可能会使用第三方服务来评估 GenAI 应用程序，包括由 Microsoft 运营的 Azure OpenAI。
• 对于 Azure OpenAI，Databricks 已选择退出“滥用监视”，因此不会通过 Azure OpenAI 存储任何提示或响应。
• 对于欧盟 (EU) 工作区，LLM 判定使用托管在 EU 的模型。 所有其他区域使用托管在美国的模型。
• 禁用 Azure AI 支持的 AI 辅助功能即会阻止 LLM 判定调用 Azure AI 支持的模型。
• 发送到 LLM 判定的数据不用于任何模型训练。
• LLM 判定旨在帮助客户评估其 RAG 应用程序，LLM 判定输出不应用于训练、改进或微调 LLM。