https://www.m1ke.org/tags/knowledge-distillation/Recent content in Knowledge-Distillation on M1KE BL0GHugo -- gohugo.ioja-jpmikeSun, 25 Oct 2026 09:50:00 +0900https://www.m1ke.org/p/%E3%83%87%E3%83%BC%E3%82%BF%E7%94%9F%E6%88%90%E5%B7%A5%E5%A0%B4%E3%81%AE%E8%A8%AD%E8%A8%88%E6%96%B9%E6%B3%95/Sun, 25 Oct 2026 09:50:00 +0900https://www.m1ke.org/p/%E3%83%87%E3%83%BC%E3%82%BF%E7%94%9F%E6%88%90%E5%B7%A5%E5%A0%B4%E3%81%AE%E8%A8%AD%E8%A8%88%E6%96%B9%E6%B3%95/<img src="https://www.m1ke.org/p/%E3%83%87%E3%83%BC%E3%82%BF%E7%94%9F%E6%88%90%E5%B7%A5%E5%A0%B4%E3%81%AE%E8%A8%AD%E8%A8%88%E6%96%B9%E6%B3%95/factory.jpg" alt="Featured image of post データ生成工場の設計方法" /><h2 id="背景">背景</h2> <ul> <li>日本語G2P（Grapheme-to-Phoneme：文字から読みへの変換）モデルの学習用に、教師データを100万件ほど生成しようと考えた</li> <li>目的は、漢字の読み分けベンチマークで高い精度を出せるモデルを作ること</li> <li>例えば「人気」という漢字には、「ニンキ」と「ヒトケ」という読みがある <ul> <li>この店は人気がある → ニンキ</li> <li>夜の公園には人気がない → ヒトケ</li> </ul> </li> <li>同じ漢字でも文脈によって読みが変わるため、こうした読み分けを学習させるには、漢字と指定読み・その読みが自然に成立する例文・文章全体のかな読みをセットにした教師データが必要になる</li> <li>そこで、RTX 5090を8枚搭載した環境でQwenやDeepSeekなどのLLMを動かし、大量に生成する構想を進めていた</li> <li>最初は「どのLLMを使えば最も高品質な例文を大量に作れるか」を考えていたが、調べていくうちに、100万件のデータを生成することと、100万件の高品質な教師データを手に入れることはまったく違うと気づいた</li> <li>この問題は「工場」に例えると理解しやすかったので、その考え方を整理する</li> </ul> <h2 id="教師データ生成を工場として捉える">教師データ生成を工場として捉える</h2> <ul> <li>Claude Opusのような高性能なモデルで少数の高品質な見本を作り、それをもとにローカルLLMで大量の例文を生成する、という流れ自体は分かりやすい</li> <li>しかし、LLMが生成したデータをそのまま教師データとして採用できるわけではない <ul> <li>指定した漢字の読みが間違っている</li> <li>文章としては自然でも、指定された読みでは成立しない</li> <li>対象漢字の読みは正しくても、全文のかな読みに誤りが含まれる</li> <li>同じような構文や表現ばかり生成される</li> </ul> </li> <li>つまり、LLMが作ったデータには不良品が混ざる</li> <li>データ生成の工程を、工場の工程に置き換えて考えると整理しやすい</li> </ul> <table> <thead> <tr> <th>工場の工程</th> <th>AIによる教師データ生成</th> </tr> </thead> <tbody> <tr> <td>設計図・見本品</td> <td>Claude Opusなどで作る高品質な見本</td> </tr> <tr> <td>製造ライン</td> <td>RTX 5090 × 8で動かすローカルLLM</td> </tr> <tr> <td>検品</td> <td>G2Pエンジンや判定用LLMによる評価</td> </tr> <tr> <td>不良品の廃棄</td> <td>基準を満たさないデータを除外</td> </tr> <tr> <td>抜き取り検査</td> <td>人間による一部データの確認</td> </tr> <tr> <td>歩留まり改善</td> <td>プロンプトや見本を改善して合格率を上げる</td> </tr> </tbody> </table> <ul> <li>やるべきことは、単に大量生成することではなく、生成・検証・選別・改善という工程全体の設計</li> </ul> <h2 id="歩留まりが重要になる理由">歩留まりが重要になる理由</h2> <ul> <li>工場では、製造した製品のうちどれだけが良品として出荷できるかを「歩留まり」と呼ぶ</li> <li>教師データ生成でも同じ考え方が使える。合格率が低いほど、同じ件数の良品を得るために必要な生成数が増える</li> </ul> <table> <thead> <tr> <th>合格率</th> <th style="text-align: right">100万件の良品を得るための生成数</th> </tr> </thead> <tbody> <tr> <td>30%</td> <td style="text-align: right">約333万件</td> </tr> <tr> <td>50%</td> <td style="text-align: right">200万件</td> </tr> <tr> <td>70%</td> <td style="text-align: right">約143万件</td> </tr> <tr> <td>80%</td> <td style="text-align: right">125万件</td> </tr> <tr> <td>90%</td> <td style="text-align: right">約111万件</td> </tr> <tr> <td>95%</td> <td style="text-align: right">約105万件</td> </tr> </tbody> </table> <ul> <li>LLMの推論にはGPUの計算資源が必要なので、生成件数が増えればそれだけ時間と電力を消費する</li> <li>合格率を改善することは、GPUを増設することに匹敵するほど重要になる場合がある。例えば合格率を50%から80%に改善できれば、100万件の良品を得るための生成量は200万件から125万件に減り、75万件分の生成を削減できる</li> <li>ただし、合格率を高めるために検証コストが大幅に増える場合もあるため、実際には採用データ1件あたりの総コストで評価する必要がある</li> </ul> <h3 id="歩留まりが低い時にすること">歩留まりが低い時にすること</h3> <ul> <li>不良品が多いからといって、ただ生成量を増やすだけでは効率が悪い</li> <li>まず、なぜ不良品が発生するのかを調べる <ul> <li>指定読みを間違えているのか</li> <li>全文のかな読みが間違っているのか</li> <li>例文が不自然なのか</li> <li>似た文章ばかり生成しているのか</li> </ul> </li> <li>原因によって改善すべき工程は変わるため、大量生成する前に、少量のデータを試作して歩留まりを測るのが最初にやるべきこと</li> </ul> <h2 id="既存の技術との対応">既存の技術との対応</h2> <ul> <li>この「工場」の仕組みは、AI開発の世界ですでに研究されており、工程ごとに名前がついている</li> </ul> <h3 id="synthetic-data-generation合成データ生成">Synthetic Data Generation（合成データ生成）</h3> <ul> <li>LLMなどを使って、機械学習のためのデータを人工的に生成すること</li> <li>今回の例では、漢字と指定読みを入力して自然な日本語の例文を作る工程がこれに当たる</li> </ul> <p>入力:</p> <ul> <li>漢字: 人気</li> <li>読み: ヒトケ</li> </ul> <p>出力:</p> <ul> <li> <p>例文: 夜更けの商店街には人気がなかった</p> </li> <li> <p>対象読み: ヒトケ</p> </li> <li> <p>全文かな読み: ヨフケノショウテンガイニワヒトケガナカッタ</p> </li> <li> <p>このようなデータを大量に生成する。ただし、生成された全文かな読みも検証対象であり、LLMが出力しただけでは正解とは限らない</p> </li> </ul> <h3 id="knowledge-distillation知識蒸留">Knowledge Distillation（知識蒸留）</h3> <ul> <li>高性能な教師モデルの知識を、より小さな生徒モデルに移す手法</li> <li>例えば、Claude Opusのような高性能モデルで高品質な例文や読みを生成し、それを使って小型G2Pモデルを学習させる</li> <li>厳密には、単なる合成データによる学習と、教師モデルの出力分布などを利用する知識蒸留は区別されることもある</li> <li>しかし、強いモデルの出力を教師信号として小さなモデルを育てるという点では、今回の構想と密接に関係している</li> </ul> <h3 id="self-instruct">Self-Instruct</h3> <ul> <li>少数の見本や指示から、LLM自身に新しい学習用データを生成させる手法</li> <li>今回のように漢字と読みのペアがすでに決まっている場合は、完全なSelf-Instructというより、条件付きの合成データ生成に近い</li> <li>それでも、少数の高品質な例文を参考にして多様な文脈を大量に作るという発想は応用できる</li> </ul> <h3 id="llm-as-a-judge">LLM-as-a-Judge</h3> <ul> <li>LLMを評価者として使う方法</li> <li>生成した例文を別のLLMに渡して、自然さや指定読みの妥当性を評価させる</li> <li>例えば「夜更けの商店街には人気がなかった」という文章だけを渡し、「人気」の自然な読みを判定させる</li> <li>このとき、正解として指定した「ヒトケ」を検証モデルに教えないことが重要。答えを先に見せると評価が引っ張られる可能性がある</li> <li>ただし、LLMによる評価も間違えるため、辞書や既存G2Pエンジンとの照合、人手による確認を組み合わせる必要がある</li> </ul> <h3 id="rejection-sampling棄却サンプリング">Rejection Sampling（棄却サンプリング）</h3> <ul> <li>大量に候補を生成し、条件を満たすものだけを採用する手法</li> <li>例えば、次のような条件を設定する <ul> <li>指定された漢字が正しく含まれている</li> <li>指定読みが文脈上自然に成立する</li> <li>全文のかな読みに誤りがない</li> <li>日本語として自然である</li> <li>既存の教師データと重複していない</li> </ul> </li> <li>これらの条件を満たしたものだけを教師データとして残す。工場でいえば、不良品を除外して良品だけを出荷する工程</li> </ul> <h3 id="data-flywheelデータフライホイール">Data Flywheel（データフライホイール）</h3> <ul> <li>データ生成とモデル改善を繰り返し、性能向上につなげる循環的な仕組み</li> <li>例えば、次のような流れになる <ol> <li>教師データを10万件生成する</li> <li>G2Pモデルを学習する</li> <li>読み間違いが多い漢字を分析する</li> <li>苦手な漢字・読みの例文を追加生成する</li> <li>教師データを検証して追加学習する</li> <li>再評価して改善を確認する</li> </ol> </li> <li>これを繰り返す</li> </ul> <h2 id="読みごとに歩留まりを管理する">読みごとに歩留まりを管理する</h2> <ul> <li>全体の合格率だけを見ていると、別の問題が起きる</li> <li>ある漢字の一般的な読みは、LLMでも簡単に正しい例文を生成できる。一方、珍しい読みや文脈依存の読みでは、正しい例文を生成するのが難しい</li> <li>そのため、簡単な読みのデータばかりが大量に採用され、難しい読みのデータが不足してしまう</li> <li>しかし、読み分けの評価で本当に重要なのは、むしろ難しい読みのほうかもしれない</li> <li>そこで、漢字・読みペアごとに歩留まりを管理する必要がある。例えば次のような状況があったとする（仮の数字だが、読みの難易度によって生成品質が変わることは十分考えられる） <ul> <li>一般的な読み: 合格率95%</li> <li>文脈依存の読み: 合格率70%</li> <li>難読・低頻度の読み: 合格率30%</li> </ul> </li> <li>この場合、全体の生成量を一律に増やすのではなく、難しい読みだけ生成モデルやプロンプトを変える <ul> <li>簡単な読みは小型Qwenで高速生成する</li> <li>難しい読みは大型QwenやClaude Opusで生成する</li> <li>曖昧な読みは複数モデルで独立検証する</li> <li>何度も失敗する読みは人間が見本を作る</li> </ul> </li> <li>これにより、高性能モデルの推論コストを本当に難しい部分に集中できる</li> </ul> <h2 id="100万件を一度に作らないという選択">100万件を一度に作らないという選択</h2> <ul> <li>最初は100万件をまとめて生成するつもりだったが、Data Flywheelの考え方を知ると、段階的な生成という別の方法が見えてくる</li> </ul> <h3 id="第1段階-1000件の試作">第1段階: 1,000件の試作</h3> <ul> <li>複数のLLMで同じ漢字・読みペアの例文を生成し、自然さ・指定読みの正確性・全文かな読みの正確性・重複率を測る</li> <li>ここで、モデルごとの得意不得意を把握する</li> </ul> <h3 id="第2段階-1万件のパイロット生成">第2段階: 1万件のパイロット生成</h3> <ul> <li>プロンプトや検証ルールを改善して、もう少し大きな規模で生成する</li> <li>漢字・読みペアごとの合格率を記録し、問題が多い読みを特定する</li> </ul> <h3 id="第3段階-10万件の教師データを作る">第3段階: 10万件の教師データを作る</h3> <ul> <li>品質検証を通過したデータでG2Pモデルを学習し、評価用ベンチマークとは独立した検証データで誤りを分析する</li> <li>そのベンチマークを最終評価に使うなら、その評価例文や言い換えを教師データに混入させないことも重要になる</li> </ul> <h3 id="第4段階-弱点を重点的に補強する">第4段階: 弱点を重点的に補強する</h3> <ul> <li>モデルが間違えやすい漢字・読みを特定し、その読みについて異なる文脈や構文を持つ例文を追加生成する</li> </ul> <h3 id="第5段階-100万件まで拡張する">第5段階: 100万件まで拡張する</h3> <ul> <li>生成と評価を繰り返しながら、必要なデータを増やしていく</li> <li>この方法なら、100万件を生成し終わってから品質の問題に気づくリスクを減らせる</li> <li>また、途中の学習結果によっては、100万件すべてを作る必要がない可能性もある</li> </ul> <h2 id="教師データの価値をどう測るか">教師データの価値をどう測るか</h2> <ul> <li>当初は、RTX 5090を8枚使って1時間に何件生成できるかが重要だと思っていた。生成速度はもちろん重要だが、それだけでは足りない</li> <li>本当に測るべき指標は、以下のようなもの</li> </ul> <table> <thead> <tr> <th>指標</th> <th>意味</th> </tr> </thead> <tbody> <tr> <td>生成速度</td> <td>1時間に生成できる候補数</td> </tr> <tr> <td>歩留まり</td> <td>生成候補のうち採用できる割合</td> </tr> <tr> <td>良品生成速度</td> <td>1時間に採用できる教師データ数</td> </tr> <tr> <td>読み別カバレッジ</td> <td>各漢字・読みペアの採用件数</td> </tr> <tr> <td>多様性</td> <td>似た文脈や構文への偏りの少なさ</td> </tr> <tr> <td>ラベル精度</td> <td>対象読み・全文かな読みの正確性</td> </tr> <tr> <td>学習効果</td> <td>追加データによるG2P精度の改善</td> </tr> </tbody> </table> <ul> <li>特に重要なのは「学習効果」。仮に10万件の教師データを追加しても、G2Pモデルの性能がほとんど改善しなければ、そのデータの価値は低いかもしれない</li> <li>逆に、難しい読みの高品質な例文を1万件追加するだけで、読み分け精度が大きく改善する可能性もある</li> <li>目指すべきなのは、最も多くのデータを作ることではなく、最も効率よくモデルの弱点を減らすこと</li> </ul> <h2 id="data-centric-aiという考え方">Data-Centric AIという考え方</h2> <ul> <li>こうした発想は、Data-Centric AIという考え方にもつながっている</li> <li>従来のAI開発では、モデルのアーキテクチャやパラメータ数、学習方法を改善することに注目が集まりやすかった</li> <li>しかし、モデルを変えなくても、学習データの品質や構成を改善することで性能が向上する場合がある</li> <li>Data-Centric AIは、データの品質、ラベルの正確性、カバレッジ、一貫性などを重視する考え方</li> <li>今回のG2Pモデル開発でも、モデルを大きくすることだけが正解ではない <ul> <li>誤った読みの教師データを減らす</li> <li>難しい読みの例文を増やす</li> <li>文脈の多様性を高める</li> <li>全文かな読みの表記規則を統一する</li> <li>学習後の失敗例から追加データを作る</li> </ul> </li> <li>もちろん、データ改善だけでモデルの能力上限を超えられるわけではないが、学習データの品質を高めることは、モデルの能力を十分に引き出すうえで欠かせない</li> </ul> <h2 id="gpuリソースの使い方">GPUリソースの使い方</h2> <ul> <li>この考え方を取り入れると、GPUの使い方も変わる</li> <li>単純に最も大きなLLMを8枚のGPUで動かし、100万件を一気に生成する方法だけが最適とは限らない</li> <li>例えば、4枚で大型Qwenを動かして例文を生成し、残り4枚で小型モデルを並列実行して読みを検証する構成も考えられる</li> <li>あるいは、生成工程と検証工程を時間帯ごとに切り替え、GPUを柔軟に配分する方法もある</li> <li>重要なのは生成モデル単体の速度ではなく、パイプライン全体の処理能力 <ul> <li>どれだけ速く生成できても、検証工程が遅ければデータが滞留する</li> <li>検証が速くても生成品質が低ければ、ほとんどが廃棄されてしまう</li> </ul> </li> <li>工場と同じように、工程ごとの処理速度と歩留まりを測り、ボトルネックを改善する必要がある</li> <li>RTX 5090を8枚使う目的は、単に大きなLLMを動かすことではなく、高品質な教師データを安定して生産できる仕組みを構築すること</li> </ul> <h2 id="クラウドapiとローカルgpuを組み合わせる">クラウドAPIとローカルGPUを組み合わせる</h2> <ul> <li>工程ごとに必要な品質とコストは異なるため、すべてを同じモデルでやる必要はない。工程に応じてクラウドAPIとローカルGPUを組み合わせるのがおすすめ</li> </ul> <ol> <li>カタログ・タクソノミーを設計する <ul> <li>見本を作る前に、そもそもどういう種類の読み・文脈をカバーすべきかというクラス設計（タクソノミー）を先に決める</li> <li>例えば、読みの種類（一般的な読み・文脈依存の読み・難読・低頻度の読み）や、文脈のカテゴリ（口語・文語・ニュース文体など）を、カタログとして整理しておく</li> <li>これを先に決めないと、次の見本作りの段階で、カバー範囲が偏った見本しか作れなくなる</li> <li>このとき、カバレッジ（タクソノミーの各セルを1件以上埋められているか）とデンシティ（各セルをどれだけ厚く・多様に埋められているか）という2つの軸で、カタログの充実度を確認する</li> <li>対象の漢字・読みペアのように母集団（取りうる組み合わせの全体）があらかじめ分かっている場合は、カバレッジとデンシティの両方を100%に近づける、いわば「C100D100」を目標にできる</li> <li>カバレッジだけを追うと、各セルに1件ずつしかなく多様性がないデータになる。デンシティだけを追うと、すでに多いセルばかりが増え、タクソノミー全体では穴が残る。両方を意識する必要がある</li> </ul> </li> <li>見本だけClaude Opusで作る <ul> <li>カタログの各カテゴリについて、1,000〜1万件程度の質の高い見本を、Claude Opusで作る（目安コストは数十〜100ドル程度）</li> <li>見本は量より質が重要な工程なので、最も高性能なモデルに任せる価値がある</li> </ul> </li> <li>大量生成は手元のGPUで作る <ul> <li>その見本を手本として、ローカルのモデルで100万件規模の候補を生成する</li> <li>ここはコストより量が重要な工程なので、ローカルGPUの計算資源を使う</li> </ul> </li> <li>品質チェックは安いモデルに任せる <ul> <li>全件の採点をHaiku 5.5のような軽量モデルに任せ、基準を満たさないものを捨てる（全件でも目安100〜200ドル程度）</li> <li>検品は全件に対して行う必要があるが、1件あたりの判定自体は軽量なモデルでも十分なことが多い</li> </ul> </li> </ol> <ul> <li>このように、設計（カタログ・タクソノミー）、見本づくり（少量・高品質・高コスト）、量産（大量・低コスト）、検品（全件・中コスト）という工程ごとの特性に応じてモデルを使い分けることで、全体のコストを抑えながら歩留まりを上げられる</li> <li>工場でも、まず設計図を描き、試作品の設計は熟練の技術者に任せ、量産は自動化されたラインで行い、検品は専用の検査装置で全数チェックするのが普通。モデルの役割分担も同じ発想</li> </ul> <h2 id="まとめ">まとめ</h2> <ul> <li>高性能なLLMで見本を作り、ローカルLLMで大量生産し、別のモデルや辞書で検品して基準を満たさないものを除外する、という一連の流れが「工場」と捉えると整理しやすい</li> <li>歩留まりを測り、不良品が多い工程を改善することが、GPUの増設に匹敵するほど効果を持つ場合がある</li> <li>この一連の流れは、Synthetic Data Generation・Knowledge Distillation・LLM-as-a-Judge・Rejection Sampling・Data Flywheelといった既存の技術・概念に対応している</li> <li>完成した教師データでG2Pモデルを学習し、苦手な読みを発見して次のデータ生成に反映する、というData Flywheelを回し続けることが本質</li> <li>最初は「どのLLMを使えば100万件を速く作れるか」を考えていたが、今は、必要なデータを見極め、品質を測定し、継続的に改善できる仕組みのほうが価値があると考えている</li> <li>その仕組みが完成すれば、100万件は最終目標ではなく通過点になる</li> <li>G2Pに限らず、LLMを使って専門分野の教師データを生成するプロジェクトでは、この「工場」と「歩留まり」の考え方が重要になるはず</li> </ul> <h2 id="参考文献">参考文献</h2> <ul> <li><a class="link" href="https://arxiv.org/abs/2212.10560" target="_blank" rel="noopener" >Self-Instruct: Aligning Language Models with Self-Generated Instructions</a></li> <li><a class="link" href="https://arxiv.org/abs/1503.02531" target="_blank" rel="noopener" >Distilling the Knowledge in a Neural Network</a></li> <li><a class="link" href="https://datacentricai.org/" target="_blank" rel="noopener" >Data-Centric AI - DataCentricAI.org</a></li> </ul>