2026年6月1日

第 11 章: ドメインデータ工程

第 10 章では微調整コストを下げましたが、能力の出所はまだ解いていません。ドメイン小規模モデルが強くなるのは、多くの場合 adapter 技法そのもののためではありません。データがタスク境界、用語、形式、拒否、評価目標を明確に定義するからです。

第 11 章: ドメインデータ工程

1. この章が本当に解く問題

ドメインデータ工程は「多ければ多いほどよい」ではありません。法律や医療のような高リスク場面では、汚いデータ、漏洩したデータ、匿名化されていないデータ、誤ったラベルが、そのままモデルの振る舞いのリスクになります。

中心的な問い:

ドメインモデルの能力は主にどこから来るのか。モデルか、それともデータか。

2. 問いの連鎖

LoRA は訓練コストを下げるが、訓練目標は依然としてデータが決める。
生のドメイン文書をそのまま SFT サンプルにはできない。
データには出所記録、ライセンス境界、クリーニング、重複除去、匿名化、品質フィルタが必要である。
SFT、RAG、蒸留、評価には異なるデータ形態が必要である。
高リスク領域では、拒否、不確実性、人間レビュー境界を明示的にラベル付けする必要がある。
データバージョンが再現できなければ、モデルバージョンを説明できない。
次章の問い: データがモデルパラメータに入っても、知識は古くなる。モデルが回答前に資料を調べるにはどうするか。

3. Concept Card

概念	数学的対象	Shape	コード上の対象	実験で見る対象
raw document	原資料	text / PDF / HTML	`raw/`	出所一覧
cleaned text	クリーニング済みテキスト	text chunks	`cleaned/`	ノイズ率
SFT example	指示サンプル	messages	`sft.jsonl`	schema check
eval item	評価サンプル	input + expected	`eval.jsonl`	カバレッジ
metadata	データ血統	dict	`source`, `license`	追跡可能性
risk tag	リスクカテゴリ	labels	`risk_tags`	高リスク slice

4. データ階層

ドメインプロジェクトでは、少なくともデータを 4 種類に分けます。

raw data:      原文書。できるだけ変更せず、出所メタデータだけを追加する
cleaned data:  クリーニング、重複除去、匿名化済みテキスト
sft data:      instruction / messages / response
eval data:     訓練には参加せず、能力とリスク評価にのみ使う

同じサンプルをコピーし、一方を train、一方を eval と呼んではいけません。評価セットは訓練過程から独立していなければなりません。そうでなければ、モデルが答えを記憶したことしか証明できません。

この 4 層はライフサイクルが異なります。Raw data は追跡のためにできるだけ不変に保ちます。cleaned data は清掃ルールの更新に伴って再生成できます。SFT data は訓練目標です。eval data は受け入れ基準です。これらを 1 つのディレクトリに混ぜると、後続の訓練が毎回考古学になります。

同じ契約条項も、段階ごとに異なるデータ形態になります。

raw doc -> cleaned chunk -> SFT message -> eval item -> distill prompt

たとえば「赔偿一切损失，包括间接损失、可得利益损失及律师费」:

形態	保存するもの	用途
raw doc	元の匿名化契約、出所、バージョン	追跡とライセンス審査
cleaned chunk	条項テキスト、条項番号、source_id	RAG 検索
SFT message	user 指示 + assistant risk JSON	出力形式と境界の訓練
eval item	input、expected_behavior、risk_tags	評価と回帰
distill prompt	query + retrieved_context + teacher config	候補蒸留サンプルの生成

これらを互いの代替にしてはいけません。SFT サンプルは RAG 知識ベースではなく、eval item は訓練サンプルではありません。

実用的な原則は次です。モデルパラメータに入るデータについては、どの raw source 由来か分かること。評価に使うデータについては、訓練に入っていないことを証明できること。

eval set は早めに固定する

多くのプロジェクトは、まず訓練し、良さそうな結果を見てから急いで eval set を作ります。これは危険です。訓練中にすでに見た、調整した、人手で選んだサンプルを評価に入れやすいからです。

より安定した方法は次です。

まず intended use / out-of-scope use を定義する
-> 小さな eval set を先に書く
-> その後で SFT / RAG / 蒸留データを作る
-> 各訓練後に同じ eval を実行する

eval set は最初から大きい必要はありませんが、独立し、追跡可能で、バージョン固定されている必要があります。そうでない評価レポートは「今回選んだ例は良さそう」ということしか示さず、モデルが本当に改善したとは言えません。

5. データ記録フィールド

各ドメインサンプルには、少なくとも次を含めることを推奨します。

{
  "id": "contract_000123",
  "source_id": "doc_2026_001",
  "source_type": "contract_clause",
  "created_by": "manual|rule|teacher_model",
  "license": "internal_review_only",
  "usage_scope": ["train", "eval", "rag"],
  "contains_personal_data": false,
  "risk_tags": ["contract", "liability", "needs_human_review"],
  "messages": [
    {"role": "system", "content": "你是谨慎的合同风险分析助手。"},
    {"role": "user", "content": "分析以下条款的风险：..."},
    {"role": "assistant", "content": "该条款可能存在..."}
  ]
}

これらのフィールドは煩雑に見えますが、後で 3 つの重要な問いに答えます。

この能力はどのデータ群から来たのか。
エラー時にサンプルの出所を特定できるか。
このサンプルは訓練、評価、公開に使ってよいか。

raw data は訓練可能データと同じではありません。特に法律・医療領域では、技術的に訓練できることと、ライセンス、プライバシー、リスク上許されることは別です。ライセンスと使用境界は manifest とデータ品質レポートに書き込みます。

6. クリーニングと重複除去

クリーニングはテキストを美しくすることではなく、訓練ノイズを下げることです。

ヘッダー、フッター、目次、透かし、文字化けを取り除く。
全角/半角、空白、改行、番号形式を統一する。
重複段落と近似重複サンプルを削除する。
法律条文や医療ガイドラインなどの構造化番号は残す。
出所が不確かなものはラベル付けし、高品質訓練セットへ直接混ぜない。

近似重複は完全重複より危険です。契約条項、医療 QA、法規抜粋は、少数の語だけが違うことがよくあります。近似重複が train/test の両方に入ると、評価が不自然に高くなります。

重複除去では「意味的重複」と「構造的重複」も区別する必要があります。法律契約では多くの条項テンプレートが似ていますが、金額、責任範囲、例外条件が違うことがあります。医療資料では同じ症状でも、成人、子ども、妊婦で処理境界が違います。過度な重複除去は重要な差異を削除し、不足した重複除去は漏洩を招きます。

そのためデータ品質レポートには、最終件数だけでなく、削除サンプルと削除理由を記録します。

近似重複チェックは工程化する

近似重複は目視だけに頼ってはいけません。少なくとも一層の粗いスクリーニングを行います。

文字 n-gram overlap
MinHash / SimHash
source_id / source_group による重複除去
タイトル、番号、条項番号のルールマッチ

法律・医療データでは、「見た目は違うが実質同じ」サンプルが特に発生しやすいです。

同じ契約テンプレートで金額だけが違う
同じ医療ガイドラインでタイトルだけが違う
同じ teacher prompt から複数の近い回答が生成される

これらの近似重複が train と test の両方に入ると、評価は不自然に高くなります。重複除去レポートには次を記録します。

重複タイプ
削除サンプル id
保持サンプル id
削除理由

7. 匿名化とリスク制御

法律・医療データには、デフォルトでプライバシーリスクがあると考えるべきです。匿名化では少なくとも次を対象にします。

氏名、身分証番号、電話番号、住所、病歴番号、契約番号。
組織内部番号と営業秘密。
組み合わせると個人識別につながる珍しいフィールド。

匿名化後も、タスクに必要な構造は残します。たとえば契約金額は <AMOUNT>、日付は <DATE> として残せます。そうしないと、モデルはリスク判断に必要な文脈形状を失います。

高リスクサンプルには明示ラベルを付けます。

needs_human_review
medical_emergency
legal_advice_boundary
privacy_sensitive
insufficient_context

これらのラベルは後で評価、安全な拒否、model card に入ります。

8. SFT データ構築

具体的な構築に入る前に、コンポーネント境界を固定します。

コンポーネント	使用するデータ形態	主な役割	代替できないもの
SFT	approved messages	出力形式、語調、拒否境界を学ぶ	事実の新鮮さや citation の真実性は保証できない
LoRA	SFT / distill train split	訓練コストを下げる	汚いデータは修復できない
RAG	cleaned chunks + metadata	更新可能な根拠を提供する	モデルが根拠を正しく使う保証はない
蒸留	teacher outputs + filters	検証可能な振る舞いサンプルを拡張する	teacher を事実源として扱ってはいけない
Eval	frozen eval items	失敗と回帰を露出する	訓練に参加してはいけない

SFT サンプルは文書要約の適当な書き換えではありません。各サンプルは観察可能な能力に対応しているべきです。

形式能力: 固定 JSON または表で出力する。
用語能力: ドメイン概念を正しく使う。
引用能力: 根拠がどの資料から来たかを示す。
拒否能力: 根拠不足時に分からないと言う。
境界能力: 弁護士や医師の最終判断を代替しない。

低品質な SFT サンプルは、モデルを「流暢に間違える」よう訓練します。追跡不能な弱いサンプル 2 万件を混ぜるより、まず高品質な 200 件を作る方がよいです。

9. 蒸留データ構築

蒸留データは teacher model から来ますが、teacher は事実源ではありません。蒸留サンプルにはフィルタが必要です。

teacher は与えられた資料を引用しているか。
存在しない条項、疾病、法規を作っていないか。
不確実性を表現しているか。
法律/医療助言の境界を越えていないか。
目標出力形式に合っているか。

蒸留サンプルには、teacher model id、prompt version、生成パラメータ、フィルタ状態を残します。

10. 評価データ構築

評価セットは成功と失敗の両方を覆う必要があります。

通常能力: 正しい抽出、説明、要約。
事実能力: 回答が根拠に支えられているか。
形式能力: 出力がプログラムで parse できるか。
拒否能力: 情報不足時に拒否するか。
リスク能力: 高リスク場面で人間レビューを促すか。
ロバスト性: 誤字、欠落フィールド、超長文脈。

評価データは訓練データを書き換えただけで作るべきではありません。source group による分割を優先し、同じ raw document が train と test の両方に入らないようにします。

11. データ品質レポート

各訓練前にデータ品質レポートを生成します。

サンプル数
出所分布
長さ分布
重複率 / 近似重複率
匿名化 hit 数
リスクタグ分布
train/val/test 分割ルール
schema error 数
人手抽検の結論

レポートは飾りではありません。モデルの振る舞いを説明するための証拠鎖です。

データ品質レポートは、訓練失敗後に補うものではなく、訓練前に生成するべきです。レポートは早期に次を発見できます。

特定の出所の比率が高すぎて、モデルが偏る可能性がある
高リスクタグが少なすぎて、安全評価が失敗しやすい
サンプル長が max_length を超え、回答が切り落とされる
重複率が高く、val loss が不自然に低くなる
匿名化 hit が異常で、プライバシー漏洩の可能性がある

後続の eval report と model card は、データ品質レポートを参照するべきです。そうすればモデル効果は孤立した数字ではなく、データソース、クリーニング、リスクタグと結びつきます。

最小の data_quality_report.md は、まず次のフィールドだけでも構いません。

# Data Quality Report

- dataset_version:
- raw_sources:
- license_or_usage_scope:
- split_rule:
- train_count / val_count / test_count:
- duplicated_or_near_duplicated_count:
- privacy_redaction_summary:
- risk_tag_distribution:
- max_length_overflow_count:
- schema_error_count:
- manual_spot_check_result:
- known_limitations:

このレポートは最初から長い必要はありませんが、訓練前に生成され、訓練設定、eval report、model card から参照される必要があります。

12. 必須実験

SFT jsonl に schema validation を行い、不正 role、空回答、超長サンプルを集計する。
train/test の重複と近似重複を確認する。
センシティブフィールドに対する匿名化 hit test を行う。
訓練前にデータ品質レポートを出力し、レポートパスを訓練設定に書き込む。
拒否サンプル群を構築し、それらが train だけでなく eval に入ることを確認する。
同じ契約条項から SFT サンプル、RAG chunk、蒸留 prompt、eval item をそれぞれ構築し、フィールドがどう変わるかを見る。

13. 失敗パターン

データ出所を追跡できない: モデルが失敗した後、原因サンプルを特定できない。
train/test 漏洩: 評価指標は高く見えるが、本当の汎化は悪い。
過度なクリーニング: 番号、金額、時期など重要なリスク情報を削除してしまう。
正例だけを集める: モデルがいつ拒否すべきか分からない。
teacher 蒸留を審査しない: hallucination をドメイン知識として扱ってしまう。
データバージョンを固定しない: 同じ訓練コマンドで次回は別のモデルができる。

14. テストによる受け入れ

この章の tests では、少なくとも次を検証します。

各 SFT / eval サンプルに一意な id と source_id がある。
message role は system/user/assistant のみ許可する。
train / val / test に重複 id も重複 source group もない。
匿名化関数がテストサンプル内の電話番号、身分証番号、住所プレースホルダーを置換できる。
データ品質レポートにサンプル数、長さ分布、リスクタグ、重複率が含まれる。

15. この章の記憶のアンカーと境界

この章で最も重要な一文は次です。

ドメインモデルの振る舞いはまずデータによって定義され、微調整手法はその定義をモデルまたは workflow に書き込むだけである。

覚えておくこと:

raw、cleaned、SFT、RAG、distill、eval は異なるデータ形態である。
各サンプルは source、license、risk_tags、使用境界を追跡できる必要がある。
eval set は訓練から独立し、早めに固定する。
匿名化はタスクに必要な構造を壊してはいけない。
データ品質レポートは訓練前 gate であり、訓練後の飾りではない。

この章では知識のリアルタイム性と追跡可能な回答はまだ解いていません。次章では RAG に進みます。

16. 次章

データ工程がうまくできても、すべての知識をパラメータに書き込むのは現実的ではありません。ドメイン知識は更新され、根拠も追跡可能である必要があります。次章では RAG に入り、モデルが回答前に外部資料を検索するようにします。