评估 AI 模型

概览

GitHub Models 提供了一套简洁的评估工作流，帮助开发者比较大型语言模型（LLM），优化提示，并在 GitHub 平台内基于数据做出决策。您可以使用 GitHub Models 通过结构化评估工具分析性能、准确性和成本，来实验新功能或验证模型更改。

GitHub Models 的使用案例

模型行为会因提示、输入或配置的不同而有很大差异。GitHub Models 帮助您

• 在真实使用场景中测试并比较多个 LLM。
• 优化提示措辞、温度等参数。
• 使用结构化、可重复的指标评估模型输出。
• 将 AI 开发融入您的开发工作流。

示例情景

设想一种情形：您正在构建一个功能，用于总结通过支持工单提交的客户反馈。这些摘要将用于生成内部报告和工单，因此输出需要清晰、相关且简洁。

您想要

• 尝试不同的模型和提示配置。
• 根据质量、一致性和效率评估表现最佳的配置。
• 将配置保存到仓库以便重用和协作。

在 Playground 中测试提示

要熟悉如何在 GitHub Models 中创建和管理提示，请参阅 在 Playground 中测试提示。

Playground 让您可以并排比较模型、调整参数，并测试提示的变化。

在本步骤中，您将配置一个模型，以生成客户支持反馈的摘要。您需要定义系统提示、使用示例输入进行测试，并对提示进行细化，以确保输出简洁且相关。

定义系统提示

为当前目标定义模型行为。本例的目标是对客户反馈进行摘要。在 Parameters 下，输入以下系统提示

You are a helpful assistant that summarizes support ticket responses into concise summaries.

保留其余设置为默认值。

编写用户提示

模型配置完成后，将以下客户反馈输入到 Prompt 对话框中

The app crashes every time I try to upload a PDF from my phone. It works on desktop but not on mobile.

模型可能会生成如下响应

The user experiences consistent app crashes when attempting to upload a PDF from their phone. Uploading PDFs works normally on desktop. They request an investigation into the issue.

在提示中使用变量

此时，配置会生成一个清晰简洁的摘要。在 Parameters 设置的底部，点击 Create prompt.yml file 打开 Prompt 视图。系统提示会自动预填。

在 User prompt 字段中，输入包含一个或多个双大括号占位符的提示。例如

Travel or shopping assistants using {{city}}, {{intent}}, and {{budget}} to tailor recommendations.

提示中列出的每个变量都会在比较模式下作为参数出现。运行评估时，系统会提示您为每个变量提供值。这样可以在不修改提示内容的前提下，用不同输入重复使用提示。

或者，您也可以在 .prompt.yml 文件的系统或用户提示中添加变量，以在未来自动化多变量评估流程。参见 在 GitHub 仓库中存储提示。

添加测试输入

在 Prompts 视图顶部，选择 Compare 切换到 Comparisons 视图。该视图允许您在多个提示或模型之间进行结构化比较，并应用评估器来衡量性能。

在 Comparisons 视图中，表格的每一行代表一个测试案例，包含特定输入和期望输出。每一列展示一种不同的提示配置，用于比较各模型或提示风格在评估器下的表现。

点击 Add rows 输入测试数据。输入模拟真实的支持消息，期望输出代表模型应返回的理想摘要。下表提供了用于评估的示例测试输入及其对应的期望输出。

行	输入	预期输出
1	每次我尝试从手机上传 PDF 时，应用都会崩溃。桌面端可以正常工作，但移动端不行。	用户报告移动端在上传 PDF 时应用崩溃，桌面端则没有问题。
2	我两天前联系了支持，但还没收到回复。我需要尽快恢复我的账户。	用户正在等待支持回复，急需账户恢复帮助。
3	请添加暗模式。夜间使用非常困难，长时间使用后我的眼睛会疼。	用户因夜间使用导致眼睛疲劳，请求添加暗模式。

调整模型参数

在表格右侧，点击以添加新的提示配置。

在新建的提示配置中，您可以使用可用的参数设置更新模型并微调其行为。这些设置控制模型生成文本的方式，包括长度、随机性和重复度。

配置模型

在 Model 下拉框中，选择 PHI-4 以创建一个用于比较的独立配置。

您可以调节以下参数来影响模型输出

• Max Tokens：设置模型可以返回的最大 token 数。数值越高，输出越长。
• Temperature：控制响应的随机性。较低的数值 (0.2–0.4) 产生更聚焦、确定性的输出；较高的数值 (0.8–1.0) 则引入更多变化和创造性。
• Top P：通过从最可能的下一个词池中选择来控制输出多样性。较低的数值降低变异性，类似于降低 Temperature。
• Presence Penalty：阻止模型引入新话题。数值越高，惩罚越强。摘要任务通常使用 0 为佳。
• Frequency Penalty：降低重复词语的概率。数值越高，惩罚越强。0~0.5 的取值有助于保持摘要的简洁和避免冗余。
• Stop：指定一个或多个字符串，一旦生成即截断模型的响应。可用于防止输出过长或强制格式规则。

下表提供了在模型比较期间生成简洁摘要的参数配置示例。

参数	值	原因
最大 Token 数	128	保持回复简短且聚焦主题
温度	0.3	确保确定性、聚焦的输出
Top P	1.0	在使用完整词汇的同时保持引导选择
Presence Penalty	0	无惩罚——摘要不需要主题变化
Frequency Penalty	0.3	减少紧凑摘要中的重复用语
停止	（可选）	如果想在关键字或符号后结束输出，请使用此项

应用参数后，您可以添加更多列，以并排比较更多模型或提示配置。

评估输出

提示配置完成后，运行结构化评估以使用真实数据和可重复的指标比较模型输出。

模型评估帮助您了解不同模型和提示配置在真实输入下的表现。在 Prompt 视图中，您可以对多个模型并排应用评估器，并审查相似度、流畅度、连贯性、相关性和真实性等指标。

以下评估器可供使用

• Similarity：衡量模型输出与期望或参考答案的相似程度。当您需要确认模型返回的响应与已知结果一致、准确时非常有用。分数范围 0~1，值越高相似度越高。
• Fluency：评估响应的语言质量，包括语法、连贯性和可读性，从而产生语言上正确的回复。
• Coherence：评估大型语言模型生成的文本是否自然流畅，是否具有人类语言的可读性。当您关注模型回复的可读性和用户友好度时使用此评估器。
• Relevance：衡量响应对问题的有效回应程度。依据给定信息评估答案的准确性、完整性和直接相关性。分数范围 0~1，值越高表明与输入意图的对齐度越强。
• Groundedness：衡量答案在提供的上下文中保持的可信度，评估其相关性、准确性和完整性，仅基于该上下文判断答案是否完整回答问题而未引入无关或错误信息。分数范围 0~1，值越高表示准确性越高。
• Custom prompt：允许您为一个 LLM 定义自定义评估标准，以评估另一个 LLM 的输出。您可以基于自己的指南对模型输出打分，支持通过/不通过或打分评估，非常适合标准指标无法覆盖的测试场景。

准备评估时，点击 Run 生成并比较所有提示配置的输出。运行结束后，GitHub Models 会显示每个提示配置的输出以及评估器得分。

测试案例：PDF 上传崩溃

输入: The app crashes every time I try to upload a PDF from my phone. It works on desktop but not on mobile.

下表显示了每个模型的输出及其评估器得分

模型	输出
GPT-4.1	用户报告移动端在上传 PDF 时应用崩溃，而桌面端上传正常。
DeepSeek-R1	好的，用户在尝试从手机上传 PDF 时遇到应用崩溃的问题。桌面端可以正常工作，但移动端不行。让我拆解一下。首先，主要问题是在移动端进行 PDF 上传时出现崩溃。由于桌面端能够正常工作，这表明问题可能是移动端特有的。可能的原因包括移动应用版本、手机操作系统、移动端的文件大小限制，或者某些 PDF 格式在移动设备上的兼容性问题。我需要确保摘要提到移动端 PDF 上传时的崩溃，注明桌面端正常工作，并
Phi-4	应用在尝试从移动设备上传 PDF 时崩溃，但在桌面版本上能够正常工作。

模型	相似度	相关性	真实性	输入 token 数	输出 token 数	延迟
GPT-4.1	100%	50%	100%	61	20	918ms
DeepSeek-R1	50%	50%	75%	52	128	2285ms
Phi-4	75%	100%	100%	61	66	1117ms

使用评估器得分可在表面文字之外评估并比较响应。

相似度

评估每个模型的输出与期望摘要的契合程度。下表展示了每个模型的相关性得分。

模型	相似度分数
GPT-4.1	100%
DeepSeek-R1	50%
Phi-4	75%

虽然所有模型都包含了输入的关键信息，但 DeepSeek-R1 的相似度分数显著偏低，因为其内部冗长的注释偏离了预期的简洁摘要格式。相比之下，GPT-4.1 的回复在措辞和结构上与参考输出相匹配。

相关性

评估每个模型对输入核心意图的捕捉程度。下表展示了每个模型的相关性得分。

模型	相关性分数
GPT-4.1	50%
DeepSeek-R1	50%
Phi-4	100%

所有三种模型都识别出移动端 PDF 上传时应用崩溃的关键问题。Phi-4 因更完整地反映了用户视角而获得更高的相关性分数。DeepSeek‑R1 因加入了原始输入未提及的推测性技术原因而失分。

真实性

评估每个模型的输出是否忠实于输入且未引入不支持的信息。下表展示了每个模型的真实性得分。

模型	真实性分数
GPT-4.1	100%
DeepSeek-R1	75%
Phi-4	100%

尽管 DeepSeek‑R1 增加了内部注释，但并未引入幻觉事实。其最终的摘要句子正确地反映了原始输入。

测试案例：暗模式请求

输入: Please add dark mode. It's very hard to use at night. My eyes hurt after prolonged use.

下表显示了每个模型的输出及其评估器得分

模型	输出
GPT-4.1	用户因夜间使用时感到不适和眼睛疲劳，请求添加暗模式功能。
DeepSeek-R1	好的，用户想要添加暗模式，因为在夜间使用时很难操作，眼睛也会疼痛。我需要给出一个简洁的摘要。先写出主要请求：添加暗模式。然后说明原因：夜间长时间使用导致眼睛疲劳。保持一句话。可以表述为“请求实现暗模式，以降低夜间长时间使用导致的眼睛疲劳。”这样既涵盖关键要点，又不出现多余细节。检查字符数，符合要求，看来可以。摘要：请求实现暗模式，以降低夜间长时间使用导致的眼睛疲劳。
Phi-4	用户请求添加暗模式功能，以减少夜间使用产品时的眼睛疲劳。

模型	相似度	相关性	真实性	输入 Token 数	输出 Token 数	延迟
GPT-4.1	100%	75%	100%	57	18	1286ms
DeepSeek-R1	50%	0%	25%	49	128	1946ms
Phi-4	100%	75%	100%	58	20	899ms

相似度

评估每个模型的输出与期望摘要的契合程度。下表展示了每个模型的相关性得分。

模型	相似度分数
GPT-4.1	100%
DeepSeek-R1	50%
Phi-4	100%

虽然所有模型都包含了输入的关键信息，但 DeepSeek‑R1 的相似度得分仍然显著偏低，因为其内部冗长的注释。

相关性

评估每个模型对输入核心意图的捕捉程度。下表展示了每个模型的相关性得分。

模型	相关性分数
GPT-4.1	75%
DeepSeek-R1	0%
Phi-4	75%

GPT-4.1 和 Phi-4 都捕捉到了用户请求的核心意图：需要暗模式以降低眼睛疲劳并提升夜间可用性。DeepSeek‑R1 因其冗长的内部注释而在相关性上得分为 0%，未能专注于实际输出。

真实性

评估每个模型的输出是否忠实于输入且未引入不支持的信息。下表展示了每个模型的真实性得分。

模型	真实性分数
GPT-4.1	100%
DeepSeek-R1	25%
Phi-4	100%

DeepSeek‑R1 由于其冗长的 <think> 块而得分较低，块中包含了原始输入未出现的推测性推理。

保存配置

完成评估后，最后一步是为特定使用场景选择表现最佳的模型。上述示例中，Phi-4 和 GPT-4.1 在所有评估器上均表现稳健、结果一致。DeepSeek‑R1 由于冗长的推理和输出不够聚焦而得分较低。

选择完首选模型和提示配置后，为提示文件添加描述性名称，然后点击 Commit changes。这将把模型、提示、参数设置及关联数据集保存为仓库中的可复用配置文件。

提交提示配置可方便复用、协作和在不同模型设置间迭代。这样可以更轻松地重新运行评估并随时间跟踪提示配置的性能表现。

延伸阅读

• 在 GitHub 仓库中存储提示词
• 在 GitHub Copilot 中配置 AI 模型访问