安装本地模型之前：模型选择背后的记录

Hugging Face 模型卡提供了记录模型用途、限制和评估的场所。[1] 在下载成为业务任务默认选项之前，这份记录值得关注。对于一次 AI Suite 评估，我们的建议是在所选模型旁边保留一份简短的决策记录：它是什么，为什么选择它，以及团队实际检查了什么。

这是八月的编辑补档版，于九月调研并发布。它描述了一种选择方法，而非新发布的模型或声称某模型适合所有用户。

准确识别候选模型

从发布者和模型仓库开始。记录正在评估的版本以及将在本地运行的文件名或变体。将下载来源保存在记录中。应用中方便显示的友好名称固然好，但后续审查者需要一个能区分被评估候选与其他类似标签文件的参考。

添加运行时版本和用于测试的应用程序。如果部署包含转换步骤，记录其输出及起点。目的是可复现性：他人应能识别确切安装，而无需从截图或对话中重建。

不要将此记录视为候选适用性的证明。它确立了正在审查的内容。适用性是另一项决策，由后续检查支持。

模型卡可能描述预期应用、评估证据或已知限制。[1] 将与拟议任务相关的部分转化为问题。如果任务涉及特定语言，测试该语言。如果输出是结构化记录，测试整个工作流是否生成接收应用可接受的记录。

文档未提及的内容应保留空白。“未记录”与“支持”是不同条目。缺失的用例说明应引发测试或询问，而非由评估者乐观假设填补。

通过组织的正常审查流程阅读随附的许可和访问条款。目录标签是发现工具，不是替代具体候选条款的凭证。本文不对特定买家的条款进行解读。

此阶段的有用产出是一份未解决问题的简短清单。该清单使后续演示聚焦于团队需要了解的内容，而非看起来令人印象深刻的内容。

软件 Software Tailor 产品目录按支持的工作对应用程序进行分组。模型评估应紧随该工作之后。日常聊天示例不能证明模型能从长文档中提取正确的信息。看似合理的段落也不能证明数值答案的正确性。

编写一组包含预期结果或评审标准的小型输入集。包括普通案例和一个刻意设计的困难示例。确保输入不包含团队无权用于评估的材料。当需要源文档时，安排评审以便能直接核查相关段落。

在任务层面记录结果。模型可能响应成功，但任务失败：必填字段被遗漏、引用段落不支持答案，或结果无法导入。这些观察很有价值，因为它们指出应用工作流仍需处理的内容。

MLCommons 以定义的工作负载、质量要求和场景描述推理基准。[2] 这提醒我们在选择记录中保留任何性能数据的相关条件。缺少条件的比较难以审计且易被误读。

本地试用时，记录机器、竞争工作及模型是否已在运行。比较替代方案时使用相同的任务输入。若测试中断或请求失败，应保留该观察，而非悄然从报告中删除。

在确认接受度前避免仅凭速度选择。需要大量修正的快速答案即使运行时表现完全符合预期，也可能不合适。相反，偶尔任务的较慢答案可能可接受。决策属于工作流，而非图表上的孤立数字。

记录以选定候选模型、未解决的限制及触发重新评审的条件结束。新模型版本是可能的触发因素。不同的输入语言、更大的文档集合或结果使用方式的变化同样重要。

我们关于保持升级接受记录的文章将相同证据延续到下一次变更。目标不是对模型做出永久判决，而是让决策理由在试验执行者离开后依然可见。

在 AI Suite中选择任务，准确识别候选模型，并保留支持其用于该任务的证据。