安裝本地模型前：模型選擇背後的記錄

Hugging Face 模型卡提供一個記錄模型用途、限制及評估的地方。[1] 在下載成為業務任務的預設之前，這份記錄值得關注。對於一個 AI Suite 評估，我們建議在所選模型旁保留一份簡短的決策記錄：它是什麼，為何被選擇，以及團隊實際檢查了什麼。

這是八月的編輯補遺版，於九月研究並發佈。它描述的是一種選擇方法，而非新發佈的模型或聲稱某模型適合所有用戶。

精確識別候選模型

從發佈者和模型庫開始。記錄正在評估的版本及將在本地運行的檔案名或變體。將下載來源保存在記錄中。應用程式中方便顯示的友好名稱固然重要，但後續審查者需要一個能區分該候選與其他相似標籤檔案的參考。

加入運行時版本及用於測試的應用程式。如果部署包含轉換步驟，記錄其輸出及起始點。目的是可重現性：其他人應能識別精確安裝，而無需從截圖或對話中重建。

不要將此記錄視為候選適用性的證明。它確立的是審查對象。適用性是另一項決策，由後續檢查支持。

模型卡可能描述預期應用、評估證據或已知限制。[1] 將與擬議任務相關的部分轉化為問題。如果任務涉及特定語言，測試該語言。如果輸出是結構化記錄，測試整個工作流程是否產生接收應用可接受的記錄。

當文件未提及時，保留該空白。“未記錄”與“支持”是不同條目。缺少用例說明應導致測試或查詢，而非由評估者提供樂觀假設。

通過組織的正常審查流程閱讀隨附的許可及訪問條款。目錄標籤是發現輔助工具，不能替代附加於精確候選的條款。本文不為特定買家解釋這些條款。

此階段的有用產出是一份未解決問題的簡短清單。該清單使後續演示聚焦於團隊需要了解的內容，而非看起來令人印象深刻的事項。

該 Software Tailor 產品目錄根據所支援的工作對應用程式進行分組。模型評估應該緊隨該工作之後。日常聊天範例並不能證明模型能從長文件中提取正確資訊。合理的段落並不代表數值答案是正確的。

撰寫一組包含預期結果或審核標準的小型輸入集。包括一般情況及一個刻意設計的困難範例。確保輸入內容不含團隊未獲授權用於評估的資料。若需使用來源文件，請安排審核流程以便直接核對相關段落。

在任務層級記錄結果。模型可能已成功回應，但任務失敗：例如遺漏了必填欄位、引用的段落未能支持答案，或結果無法匯入。這些都是有用的觀察，因為它們指出應用程式工作流程仍需處理的部分。

MLCommons 以定義的工作負載、質量要求及場景來描述推理基準。[2] 這提醒我們在選擇記錄中保留任何性能數據的相關條件。缺乏條件的比較難以審核，且容易被誤讀。

進行本地試用時，請記錄機器狀況、競爭工作及模型是否已在運行。比較不同方案時，請使用相同的任務輸入。如測試中斷或請求失敗，請保留該觀察結果，勿在報告中悄然刪除。

在檢查接受度之前，避免僅以速度作為選擇標準。即使運行時間表現完全如預期，一個需要大量修正的快速答案也可能並不合適。相反，較慢的答案對於偶爾的任務可能是可以接受的。決策應屬於工作流程，而非圖表上的孤立數字。

以所選擇的候選模型、未解決的限制及會觸發另一次審查的條件作結。新模型版本是其中一個可能的觸發因素。不同的輸入語言、更大的文件集合或結果使用方式的改變，亦可能同樣重要。

我們的文章關於保留升級接受記錄將相同的證據帶入下一次變更。目標並非對模型作出永久判決，而是作出一個決定，其理由在執行測試的人離開後仍然清晰可見。

選擇一個任務於 AI 套件，準確識別候選項，並保留用於該任務的證據。