AI Sheets 教學：開源模型、本地推論與資料標註流程

AI Sheets 是 Hugging Face 提供的開源無程式資料工作工具，介面接近試算表。它可用 AI 模型建立新欄位，協助做分類、摘要、抽取、轉換、資料清理或模型比較；你也可以逐格編輯、核可結果，再重新產生。對資料標註而言，這種「看得見每一列」的流程，比一開始就把整份正式資料交給模型更容易找出規格與品質問題。

如果你想把 Llama、Qwen 或其他開源模型放進資料工作，核心並不是讓模型填滿欄位，而是先定義每個輸出代表什麼、哪一些情況需要停下來覆核，以及結果能否被程式驗收。本篇說明如何用 AI Sheets 先建立可驗收的小樣本，再評估本地或自訂端點，最後才考慮擴大量。

AI Sheets 適合處理哪些工作

AI Sheets 適合把既有資料匯入後，為每一欄建立明確的 AI 工作。官方示範包括比較模型、改善提示、清理文字、分類、抽取重點、分析資料集與增補資料。它也支援從空白開始建立測試資料集，但若資料正確性、來源或多樣性很重要，應優先使用已取得使用權且可追溯的真實樣本。

資料整理與轉換

• 用一個新欄位做分類、摘要、抽取或格式轉換，原始欄位仍保留作為核對依據。
• 先定義允許值、缺值規則與不能猜測的情況，避免模型以看似合理的文字補齊未知資訊。
• 將來源、穩定 ID 與處理日期留在資料中，才能回查某一列為何得到特定結果。

模型與提示實驗

• 在相同樣本上建立不同模型或不同提示的欄位，直接比較格式、內容、一致性與處理時間。
• 人工修改或核可的格子會成為後續產生時的參考範例；因此先確認這些範例正確，比累積大量未審核輸出重要。
• 不要把模型名稱當成品質保證。繁體中文、專有名詞、否定語、短文本與邊界案例都要出現在驗收樣本中。

擴大量與交付

• 當欄位設定與驗收樣本已穩定，才匯出配置並考慮用 Hugging Face Jobs 或受版本控制的管線處理較長工作。
• 批次大小、併發數、成本上限、失敗重試、版本紀錄與抽樣覆核都需要事先設定，不能交給工具自行決定。
• 高風險資料、重要決策或數十萬筆以上的可恢復任務，通常更適合移到可測試、可觀測的程式化資料管線。

先做可驗收的小樣本，再決定是否擴量

先準備一份已取得使用權、能代表真實情況的小資料集。每列至少保留穩定 ID、原始文字或來源指標、預期輸出欄位，以及錯誤嚴重度。若已有人工正確答案，也應保留在不同欄位，避免模型輸出覆蓋原本的判斷依據。

1. 寫標註指南：定義每一個類別、邊界案例、可接受與不可接受的答案，以及資訊不足時應輸出什麼。
2. 建立最小 schema：例如 category、reason、needs_review，讓下游程式能檢查欄位與允許值。
3. 先跑少量樣本：檢查混淆最多的類別、格式失敗、繁體中文語意與專有名詞，而不是只挑幾筆漂亮結果。
4. 人工核可與修正：將核對過的案例作為少量高品質參考，再重新產生其他列；不要把未確認輸出當成示範答案。
5. 固定版本才擴大：記錄提示、模型、提供者或端點、日期、輸出 schema 與驗收結果。任何一項變更，都應回跑同一組驗收資料。

用 Llama、Qwen 或其他本機模型時，先驗證端點契約

AI Sheets 的自訂文字模型不是為某一個模型品牌寫死的整合。官方 README 說明，若要將文字生成導向自架或其他雲端端點，該端點必須支援 OpenAI API 規格；再以 MODEL_ENDPOINT_URL 指向端點，並用 MODEL_ENDPOINT_NAME 指定實際部署的模型。

MODEL_ENDPOINT_URL=http://localhost:11434
MODEL_ENDPOINT_NAME=本機已部署的模型名稱

Ollama 與 llama3 是官方舉例，不表示每一個 Qwen、Llama 或其他模型都能不經測試直接互換。至少要用一筆資料確認模型名稱、認證、回應格式、逾時、限流與錯誤處理；再檢查它在你的硬體、語言與資料分布下是否真的達到品質要求。

「本機」不等於整個流程都不出站

自訂端點只影響文字生成的路徑，不能直接推論所有功能都在本機執行。若開啟網路搜尋、使用雲端推論提供者、使用文字轉圖片，或讓反向代理、日誌、備份與監控服務接觸資料，資料仍可能離開原本預期的環境。官方 README 也說明，文字轉圖片目前仍使用 Hugging Face Inference Providers，而不是上述自訂文字端點。

因此，在匯入個資、客戶內容、合約或受管制資訊前，應先畫出實際資料流：哪些欄位送進哪一個端點、由誰持有 token、會留下哪些應用程式或伺服器日誌、資料保存多久、誰可以匯出或刪除。模型在內網不是隱私或合規的自動證明，存取控制、留存政策與人工覆核仍不可省略。

一個可操作的欄位設計範例

假設要將客服來訊分成「帳務、帳號、技術問題、其他」，保留 message 作為原始欄位，再新增模型產生的 category、needs_review 與人工覆核欄位。提示需要明確要求：只能輸出允許的類別；資訊不足、同時落在多類或出現未定義主題時，將 needs_review 設為 true。

產生結果後，先用規則檢查輸出是否可解析、category 是否位於允許清單、必要欄位是否缺漏；再把 needs_review=true、高影響客戶或規則檢查失敗的列送給人工。自然語言看起來通順，不代表它符合資料庫、營運或法遵流程。

比較模型時，先看四種錯誤成本

格式錯誤

例如 JSON 無法解析、欄位缺漏或答案混入額外解釋文字。這類錯誤可用 schema 驗證攔下，失敗列應進入明確的重試或人工佇列，而不是靜默寫入正式資料。

內容錯誤

例如錯分、杜撰、忽略否定語或誤解繁體中文語意。抽樣時要依類別與嚴重度分層，並保留錯誤案例做回歸集，避免下一次調整提示或模型後又重新犯同樣的錯。

一致性錯誤

同義句、近似案例或同一客戶的多筆訊息若得到互相矛盾的標籤，代表標註指南、提示或模型行為仍不穩定。加入對照組與邊界案例，比只看平均正確率更能找出問題。

營運錯誤

逾時、限流、成本突然上升、模型更新後退步，都可能讓原本可用的流程失效。記錄模型版本、端點、執行時間、失敗原因與可重跑輸入，才有能力定位問題與回復。

何時該改用程式化資料管線

AI Sheets 的優勢在於快速看見、修正與比較每一列結果，適合探索與小批量驗證。當工作需要排程、資料血緣、嚴格權限、數十萬筆以上的可恢復任務或多階段審核時，應將已通過驗收的提示與 schema 移到受版本控制的資料管線，並把 AI Sheets 留作設計、抽樣檢視與模型比較介面。

常見問題

AI Sheets 可以直接把所有資料自動標成正確答案嗎？

不能保證。它能加速產生候選標籤與整理工作，但仍需要標註指南、可驗收輸出、抽樣與高風險案例的人工作業。先從小樣本建立基準，再擴大範圍。

我可以用 Qwen 取代 Llama 嗎？

可以評估，但這不是固定的「一鍵切換」承諾。關鍵是端點是否支援所需的 OpenAI API 規格、模型名稱是否正確，以及它是否通過格式、品質、延遲、安全與成本測試。

資料放在本機，就一定不會外流嗎？

不一定。要看實際啟用的端點、搜尋、圖片功能、資料目錄、日誌、備份與帳號設定。先釐清資料流，再決定哪些功能適合處理敏感資料。

結論

AI Sheets 的價值是把模型選擇、提示、人工修正與資料欄位放在可見的工作台上。可靠的做法不是追求一次大量生成，而是先定義標準、比較模型、修正小樣本、建立回歸集，最後才把通過門檻的設定帶到批次工作。這樣比較容易得到可用、可追溯且能維護的資料。

參考資料

• Hugging Face：Introducing AI Sheets
• Hugging Face AI Sheets README：本機與自訂 LLM 設定