指令與 SFT 資料
示範您想要的行為的提示–回應配對，可從零撰寫，也可由既有內容改寫而來。
- 任務示範
- 改寫與摘要配對
- 領域問答
- 格式受限的輸出
LLM 與生成式 AI
日文 LLM 訓練資料——SFT、偏好與 RLHF
指令–回應配對、排序比較、多輪對話與安全性資料，由在日本作業的標註人員依貴團隊簽核過的風格指南撰寫。
日文指令資料的難處不在於寫出一則答覆，而在於用同樣的語體、把同樣的答覆寫上一萬次——並且能以書面說明為什麼選擇那個語體。
日文指令資料為什麼會出問題
由多人撰寫的指令資料會偏移。一位標註人員每則回應都以ですます結尾，另一位在技術說明寫到一半改用である，第三位則用聊天助理那種簡短口吻。以這種混合資料訓練出來的模型，會學到三種都可以接受，然後想用哪種就用哪種——這正是我們聽到最多的日文微調抱怨。
會偏移的不只有語體，拒絕的表達更糟。日文的拒絕是間接的，沒有被告知「拒絕該長什麼樣子」的標註人員，寫出來的可能是斬釘截鐵的お断りします，也可能是柔和到不像拒絕的それは難しいかもしれません。如果有一半的安全性資料柔和到會被誤讀成同意，模型學到的就是打太極，而不是拒絕。
因此交付物從來不只是資料本身，而是資料加上產出它的那些書面決策：風格指南、拒絕範本、排版規則，以及某一批資料所依據的各項版本。
重點速覽
- 資料集類型
- 指令／SFT、偏好配對與排序、多輪對話、安全性與拒絕資料、RAG 依據資料集。
- 撰寫者
- 在日本作業的母語標註人員，並由第二位標註人員與一位資深審查者複審。
- 語體控管
- 書面風格指南在量產前先固定禮貌程度、句尾形式、代名詞用法與排版規則。
- 典型格式
- JSONL——SFT 使用 messages 陣列，偏好資料使用 chosen／rejected 配對。
- 來源紀錄
- 每一筆紀錄都帶有其標註規範版本、撰寫者角色與審查狀態。
資料集類型
我們建置什麼
五類資料集，通常會組合使用。每一類對「正確」的定義都不同，因此各有專屬的規範章節與獨立的審查流程。
偏好與排序資料
依書面標準比較兩個以上的候選回應，並記錄下選擇的理由，而不是事後推測。
- 成對 chosen／rejected
- N 選排序
- 各項標準的分數
- 每次比較附書面理由
多輪對話
脈絡會逐輪累積的對話——第一輪設定的語體必須撐到第八輪，而這正是多數日文對話資料崩壞的地方。
- 任務導向對話
- 澄清與修正輪次
- 脈絡延續檢查
- 人設與角色一致性
安全性、拒絕與紅隊資料
應該被拒絕的提示、看起來該被拒絕但其實不該拒絕的提示，以及區分兩者的拒絕措辭。
- 依類別區分的拒絕範本
- 過度拒絕的反例
- 對抗式與越獄提示
- 日文敏感議題的處理
RAG 與依據資料集
問題、檢索到的段落與有依據的答覆三元組，以及段落其實並不包含答案的負例。
- 可回答／不可回答配對
- 引用範圍標記
- 干擾段落
- 日文文件的依據標註
日文特有事項
為什麼這是日文特有的問題
以下四項決策若懸而未決，就會產出一份審查時看似無誤、進了模型卻表現不佳的資料集。
禮貌語體
敬語日文在每一個句尾都強迫做出禮貌程度的選擇。ですます、である與常體並非可以互換，以混合資料訓練出來的模型會在同一則回應內混用。
我們的處理方式 風格指南為每個產品介面固定一種預設語體，列出例外，並附上各種情形的實作範例。語體一致性在審查中是計分項目，不是品味問題。
間接拒絕
断りそれはちょっと難しいです是一種拒絕，而不是在陳述困難。照字面標註的標註人員，等於在教模型把拒絕讀成中性的陳述。
我們的處理方式 拒絕的類別與措辭事先定義，並標明各自的強度。安全性資料會特別針對「這句拒絕在日文母語者聽來是否真的像拒絕」進行審查。
主詞省略
主語省略日文會省略脈絡上顯而易見的主詞。在多輪資料中，指涉對象可能出現在四輪之前，孤立撰寫某一輪回應的標註人員就會猜錯。
我們的處理方式 多輪項目一律以整段對話為單位撰寫與審查，絕不逐輪處理。當指涉對象確實有歧義時，該段對話不是修正就是捨棄——不會靠猜測貼上標籤。
文字與排版變異
表記ゆれ同一個詞會以漢字、平假名或片假名出現；數字與標點會有全形與半形之別。若不加控管，等於在教模型排版是隨機的。
我們的處理方式 正規化慣例涵蓋常用詞的文字選擇、數字、標點、拉丁字母前後的空白與清單排版方式。撰寫時即套用，並在交付前自動檢查。
流程
一份資料集是怎麼建起來的
試辦的目的是擊破規範的第一版草稿。要等到它不再被擊破，才開始量產。
-
01
界定目標行為
我們一起確認對貴產品而言什麼是好的回應：語體、長度、排版、該拒絕什麼與如何拒絕，以及模型不知道答案時該怎麼做。
-
02
草擬風格指南
這些決策會化為一份附有實作範例與反例的書面文件。您尚未決定的模糊地帶會在此浮上檯面，而不是被默默吸收。
-
03
試辦與校準
由數位標註人員各自獨立撰寫一小批資料。凡是出現分歧之處，就代表規範不夠清楚——我們修正的是規範，不是標註人員。
-
04
量產撰寫與審查
每一筆項目由一位標註人員撰寫、另一位審查，並由資深審查者抽樣並以書面裁定分歧。
-
05
打包與版本管理
交付內容包含資料、標註規範版本、每筆紀錄的來源資訊、品質報告，以及相對於前一批的異動紀錄。
交付
您會收到什麼
欄位於啟動會議中議定；當您沒有既有 schema 需要對應時，以下是預設的結構。
| 資料集 | 預設格式 | 紀錄包含 |
|---|---|---|
| 指令／SFT | JSONL，messages 陣列 | system／user／assistant 輪次、任務標籤、規範版本 |
| 偏好配對 | JSONL，chosen + rejected | 兩個候選回應、各項標準分數、書面理由 |
| 多輪對話 | JSONL，每行一段對話 | 完整輪次清單、人設備註、語體標籤 |
| 安全性與拒絕 | JSONL | 提示、類別、預期行為、實際使用的拒絕措辭 |
| RAG 依據 | JSONL | 問題、段落、答覆、引用範圍、可回答旗標 |
品質
針對這類工作的控管措施
通用的標註品質檢查抓不出語體偏移，也抓不出過於柔和的拒絕。以下這些檢查可以。
- 語體一致性逐則回應計分，並涵蓋對話中的每一輪。
- 拒絕強度由第二位母語者依既定類別複審。
- 交付前自動檢查文字、數字、標點與空白的正規化。
- 跨批次偵測重複與近似重複，避免資料集在無聲無息中失去多樣性。
- 依任務標籤分類追蹤提示的多樣性，避免任何類別意外被過度取樣。
- 由資深審查者對保留樣本進行盲審複核，據以產出該批次的品質數據。
常見問題
關於 LLM 訓練資料
團隊在規劃第一次日文微調時最常提出的問題。
兩者都可以。日文專案經常需要從零撰寫，因為可用的日文開源指令資料很少，而機器翻譯的資料會把英文的句構帶進模型。當您已經有內容——客服紀錄、手冊、內部文件——我們比較常從中改寫，這能讓資料扎根在您真正的領域裡。
靠一份附有實作範例的書面風格指南、量產前的校準回合（由數位標註人員各自獨立撰寫相同項目），以及把語體一致性列為審查中明確計分的項目。一致性在這裡是可量測的性質，不是願望——我們盯的就是標註人員之間的分歧，而每一次解決掉的分歧都會回寫進指南。
不會拿它當最終資料的來源。翻譯而來的指令資料會繼承英文的語篇結構、英文的禮貌預設與英文的排版習慣，用它訓練出來的模型所產出的日文，母語讀者一看就說是翻譯腔。我們確實會用翻譯來輔助發想提示，但回應一律由日文母語者以日文撰寫。
只有在您同意的情況下才可以，而且一定要再經過人工改寫與審查——絕不會未經審查就直接沿用。是否使用了 AI 協助會逐筆記錄，讓您日後可以篩選或稽核。若您要求完全由人工撰寫的資料，我們就以那種方式執行專案，來源紀錄欄位可資佐證。
比多數團隊預期的還少。幾千筆用心撰寫、語體一致的資料，通常比十倍量的雜訊資料更能推動日文微調，因為模型學的既是任務，也同樣是一種風格。我們會先以幾百筆的試辦驗證規範，再依試辦量測到的結果估算量產規模。