概述
GitHub Models 提供了一个简单的评估工作流，可帮助开发人员比较大型语言模型（LLM）、优化提示并在平台中 GitHub 做出数据驱动的决策。 可以使用GitHub Models 来试验新功能或验证模型更改，并通过结构化评估工具分析性能、准确性和成本。
提示
可使用 gh models eval 命令直接从命令行执行评估。 该功能采用与 UI 相同的评估程序：字符串匹配、相似度比对、自定义 LLM-as-a-judge 评估程序等，因此你可以在本地或 CI 环境中测试 .prompt.yml 文件。
用例 GitHub Models
模型行为可能会因提示、输入或配置的不同而异。 GitHub Models 帮助你：
- 跨实际用例测试和比较多个 LLM。
- 优化提示短语、温度和其他参数。
- 使用结构化的可重复指标评估模型输出。
- 将 AI 开发集成到开发工作流中。
示例方案
设想这样一个应用方案：你正在构建一个功能，用于汇总客户通过支持票证提交的反馈。 这些汇总结果将用于生成内部报表和票证，因此输出的数据需要清晰、相关且简洁。
您想要：
- 尝试不同的模型和提示配置。
- 基于质量、一致性和效率，评估出性能最优的配置。
- 将配置保存到存储库，以便重复使用及在协作中使用。
在操场中进行提示测试
若要熟悉如何在操场中创建和管理提示 GitHub Models，请参阅 “在操场中测试提示”。
通过使用操场，可以并排比较模型、调整其参数和测试提示变体。
在此步骤中，要配置一个模型来生成客户支持反馈摘要。 将定义系统提示，使用示例输入对其进行测试，并对其进行优化，以确保输出简洁且相关。
定义系统提示
基于当前目标，定义模型行为。 在本例中，目标是总结客户反馈。 ** **在“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”视图。 将自动预填充系统提示内容。
在“用户提示”字段中，输入提示，其中包括用双花括号括起的一个或多个变量占位符****。 例如：
Travel or shopping assistants using {{city}}, {{intent}}, and {{budget}} to tailor recommendations.
提示中列出的每个变量都将在比较模式下显示为参数。 运行评估时，系统会提示你为每个变量提供值。 这样就可以在不同输入中重复使用提示，而无需修改提示内容。
或者，可以在 .prompt.yml 文件系统或用户提示中添加变量，以便将来自动执行使用多个变量进行计算的过程。 请参阅 在 GitHub 存储库中存储提示。
添加测试输入
**
**在“Prompts”视图顶部，选择“Compare”以切换“Comparisons”视图。 通过此视图，可跨多个提示或模型运行结构化比较，并应用评估程序来度量性能。
在“Comparisons”视图中，表中的每一行表示一个测试用例，其中包含特定的输入和预期输出。 每一列提供不同的提示配置，用于通过评估程序比较各种不同模型或提示样式的性能。
单击添加行以输入测试数据。 输入值模拟真实支持消息，预期输出值代表模型应返回的理想摘要。 下表提供用于评估的示例测试输入及其相应的预期输出。
| 行 | Input | 预期输出 | |-----|--------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------| | 1 | 我每次尝试从手机中上传 PDF 时，应用都会崩溃。 它可以在桌面上正常使用，但在移动设备上不运行。 | 用户报告称该移动应用在用户每次上传 PDF 时都会崩溃，而桌面版可正常运行，不发生问题。 | | 2 | 两天前我联系了支持人员，但一直未收到回复。 我需要相关帮助以尽快恢复我的帐户。 | 用户在等待支持响应，并迫切需要帮助以恢复帐户。 | | 3 | 请添加深色模式。 它在夜晚难以使用。 长时间使用后我的眼睛受到损伤。 | 用户在夜间使用时眼睛疲劳，请求获取深色模式。 |
调整模型参数
在表格右侧，单击 以添加新的提示配置。
在新提示配置中，可使用可用的参数设置来更新模型并微调其行为。 这些设置控制模型如何生成文本，包括其长度、随机性和重复性。
配置模型
从“Model”下拉列表中，选择“PHI-4”以创建不同的配置以用于比较。
可调整以下参数来影响模型输出：
- 最大标记数****：设置模型可返回的最大标记数。 值越大，允许的输出越长。
- 温度****：控制响应的随机性。 较低值 (0.2–0.4) 生成更聚焦、更具确定性的输出。 较高值 (0.8–1.0) 引入更多的变化和创造性。
-
**Top P**：通过从最有可能的下一个词的集合中进行选择来控制输出的多样性。 值越低，变化程度越低，与降低温度类似。 -
**出现惩罚**：抑制模型引入新主题。 值越高，施加的惩罚越强。 值 0 通常适合用于摘要。 - 频次惩罚****：减少词语重复的可能性。 值越高，施加的惩罚越强。 取值在 0 到 0.5 之间有助于让摘要保持清晰且无冗余信息。
-
**停止字符**：指定一个或多个字符串，当模型生成的文本中出现这些字符串时，将截断模型的响应。 使用此选项可防止输出过长或强制实施格式规则。
下表提供了一个参数配置，用于在模型比较期间生成简洁摘要。
| 参数 | 值 | 原因 |
|---|---|---|
| 最大标记数 | 128 | 使响应保持简短并贴合主题 |
| 温度 | 0.3 | 确保输出具有确定性和重点 |
| Top P | 1.0 | 允许使用完整词汇库，但保持选择受引导 |
| 出现惩罚 | 0 | 无惩罚 - 摘要不需要主题变化 |
| 频率惩罚 | 0.3 | 减少紧凑摘要中的重复表述 |
| 停止 | （可选） | 在需要在关键字或符号之后结束输出时使用 |
应用参数后，可以添加更多列，并行比较更多模型或提示配置。
评估输出
配置提示后，运行结构化评估，使用实际数据和可重复指标比较模型输出。
借助模型评估，可了解不同模型和提示配置在应用各实际输入值后的性能。 在“Prompt”视图中，可并行向多个模型应用评估程序，并查看相似度、流畅性、连贯性、相关性及有据性等指标。
以下有可用的评估者：
-
相似度****：度量模型的输出与预期响应或参考响应的匹配程度。 如果要确认模型会返回与已知结果一致且准确的响应，这会非常有用。 分数范围为 0 到 1，值越高，表示相似性越高。
-
流畅性****：评估响应的语言质量，包括语法、连贯性和可读性。 这可促进生成语言上正确的响应。
-
连贯性****：评估 LLM 在其答复中生成内容自然、行文流畅、类似真人语言的文本的能力。 在实际应用中测试模型生成的答复的可读性和用户友好性时使用。
-
相关性****：指响应对问题的有效解答程度。 它仅基于给定信息评估响应的准确性、完整性和直接相关性。 分数范围为 0 到 1，值越高，表示与输入的意向更一致。
-
有据性 ****：度量答案在给定上下文中的锚定程度，仅基于该上下文评估其相关性、准确性和完整性。 它评估答案不引入无关或错误信息、全面回答问题的程度。 分数范围为 0 到 1，值越高，表示准确性越高。
-
自定义提示****：可用于为一个 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 |
<think> 好的了解，用户尝试从手机中上传 PDF 时遇到问题，应用会崩溃。 它可以在桌面上正常使用，但在移动设备上不行。 让我来详细分析。 首先，主要问题是应用崩溃，特别是从移动设备中上传 PDF 时。 桌面设备可以正常运行的事实表明，这是一个移动设备特有的问题。 潜在原因可能与移动应用版本、手机 OS、移动设备上的文件大小限制或移动设备上某些 PDF 格式的兼容性问题相关。 我需要确保摘要中提到移动设备上传 PDF 时发生崩溃，并注明桌面版上传正常。 |
| Phi-4 | 应用在尝试从移动设备中上传 PDF 时发生崩溃，但在桌面版上可正常上传。 |
| 型号 | 相似度 | 相关性 | 有据性 | 输入令牌 | 输出标记 | 延迟 |
|---|---|---|---|---|---|---|
| GPT-4.1 | 100% | 50% | 100% | 61 | 20 | 918毫秒 (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 |
<think> 好的，用户希望添加深色模式，因为在夜间使用存在困难，他们的眼睛会疲劳。我需要作一个简明的总结。先明确主要请求：增加深色模式。然后说明原因：在夜间长时间使用眼睛会疲劳。用一句话表述。可将其表述为“请求实现深色模式，以减少夜间使用时眼睛疲劳的情况”。这概括了关键点，无任何多余细节。检查是否符合字符数限制。符合，看上去不错。</think> 摘要：请求实现深色模式，以减少夜间长时间使用时导致的眼睛疲劳。 |
| Phi-4 | 客户要求添加深色模式功能，以减少夜间使用该产品时眼睛疲劳的情况。 |
| 型号 | 相似度 | 相关性 | 有据性 | 输入标记 | 输出标记 | 延迟 |
|---|---|---|---|---|---|---|
| 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”。 这会将模型、提示、参数设置和关联的数据集保存为存储库中的可重用配置文件。
提交提示配置，可以方便地在不同的模型设置中重复使用、协同利用和进行迭代。 这样可以更轻松地重新运行评估并跟踪一段时间内提示配置的性能。
其他阅读材料
-
[AUTOTITLE](/github-models/use-github-models/storing-prompts-in-github-repositories) -
[AUTOTITLE](/github-models/use-github-models/integrating-ai-models-into-your-development-workflow)