信頼できるRAG回答のための小規模ブラウザモデルのファインチューニング
ある開発者は、モデルサイズを増やすのではなく学習データのスタイルを改善することで、0.6Bパラメータのモデルにおけるハルシネーション(誤情報生成)を削減し、ブラウザベースの検索でより優れた拒否率を達成しました。
英語の原文から自動翻訳されました。
Bart de Goede氏は最近、ブラウザ内で直接検索拡張生成(RAG)を改善するために小規模言語モデルをファインチューニングする実験の結果を発表しました。ローカルMac上で4つの異なる訓練データセットを反復処理することで、ハルシネーションを起こしやすい0.6Bパラメータのモデルを、答えられない質問を正確に拒否するより信頼性の高いアシスタントに変換しました。最終的なモデルであるQwen3-0.6Bは、彼のブログの検索機能を支えており、ベースバージョンと比較してエラーが大幅に減少しています。
何が起きたか
セマンティック検索結果の要約に小規模言語モデルを使用しようとした最初の試みは、モデルがソーステキストに存在しない詳細を頻繁にハルシネーションするため失敗しました。De Goede氏は、ファインチューニングによってモデルに提供されたパッセージに厳密に従うこと、または情報が不足している場合に明示的に述べることを教えられると仮説を立てました。評価時のデータリークを防ぐため自身のブログ記事は避け、Go、Rust、Pythonコミュニティからオープンライセンスの技術文書を使用してデータセットを作成することにしました。
このプロセスには4ラウンドの訓練が含まれており、各ラウンドでは小規模モデルが合成データから学ぶ際の特定の落とし穴が明らかになりました。最初のバージョンは教師モデルの冗長なスタイルを模倣したためパフォーマンスが悪化しましたが、その後のイテレーションでは回答形式をより短く事実重視のものに調整しました。第3バージョンは最も効果的なバランスを示し、場合によっては技術的には答えられる質問でも拒否することがありましたが、ベースモデルと比較して誤答を3分の2に削減しました。
すべてのコード、データセット、および最終的なモデル重みは公開されました。これにより、他の開発者がセットアップを再現したり、独自のドキュメントでテストしたり、カスタムシステムプロンプトでモデルを再訓練したりできます。全訓練パイプラインはM4 Mac mini上でローカル実行され、特定のRAGタスクに対する高品質なファインチューニングには大規模なクラウド計算リソースが必要ないことを実証しました。
仕組み
このシステムは、ドキュメントをチャンク化し、セマンティック検索用に埋め込む検索メカニズムを使用します。ユーザーが質問をすると、システムは関連性の高い上位4つのパッセージを取得します。これらのパッセージと厳格なシステムプロンプトは、WebGPUまたはWebAssembly経由でブラウザ内で実行されるQwen3-0.6Bモデルに入力されます。プロンプトは、モデルに対して提供されたテキストのみを使用して最大2文で回答するか、パッセージが不十分な場合は回答を拒否するように指示します。
訓練は蒸留(distillation)に依存しており、より大きなモデルであるClaude Opus 5.5が数千の合成質問に対する理想的な応答を生成しました。De Goede氏はmlx-lmライブラリを使用してLoRA(Low-Rank Adaptation)を適用し、小規模モデルをファインチューニングしました。各訓練ランは4,500例に対して1エポック行われ、約80分かかりました。重要な発見は、小規模モデルは複数のパッセージ間で情報を統合できないことで、単一のパッセージから具体的な事実を抽出するか、拒否することしかできませんでした。
主要な詳細
- 最終的なモデルはQwen3-0.6Bであり、取得した4つのパッセージから事実を抽出するために特別にファインチューニングされています。
- 訓練には、寛容なライセンスの下にあるGo、Rust、Pythonのブログからの2,193件のドキュメントが使用されました。
- バージョン3は30問中16問で忠実な回答を達成し、ベースモデルの精度と同等ですが、誤答は9問から3問に減少しました。
- ソース資料でカバーされていない15問すべてに対し、モデルは正しく回答を拒否しました。
- 各訓練イテレーションは、24 GB RAMを搭載したM4 Mac miniで約1時間20分かかりました。
- データセットとコードは公開されており、ドキュメントサイトなど異なるドメイン向けにモデルを再訓練することができます。
なぜ重要なのか
RAGシステムを構築するエンジニアにとって、この実験は特定の抽出タスクにおいてモデルサイズよりもデータ品質の方が重要であることを強調しています。ブラウザで動作する小規模モデルはプライバシーと低遅延という利点を提供しますが、複雑な回答を統合するための推論能力には欠けています。タスクを単純な抽出と拒否に制限することで、開発者はサーバーサイド推論のコストを必要とせず、ハルシネーションに対して堅牢な軽量モデルを展開できます。
検証損失(validation loss)が実際の性能を予測できなかったことも重要な教訓です。標準的な指標は改善を示しましたが、モデルの実用的な有用性は低下しており、自動的な損失曲線が保持テストセットでの手動評価を置き換えることはできないことが証明されました。開発者は一般的な言語流暢性ではなく、正しい拒否などの望ましい特定の挙動に基づいてチェックポイントを評価する必要があります。
このアプローチはまた、ファインチューニングの民主化にも寄与します。消費者向けハードウェアで2時間未満で効果的なモデルを訓練できることを示すことで、チームが独自のナレッジベース向けにオープンソースモデルをカスタマイズする障壁を下げています。焦点は、より大きなモデルの獲得から、小規模アーキテクチャの認知限界に合ったより良い訓練データの設計へと移行しています。
やれること
- ブラウザベースのアプリケーションで即座に使用するために、Hugging Faceから
bartdegoede/qwen3-0.6b-small-ragモデルをダウンロードしてください。 - ベースライン性能をテストするために、回答できない質問も含めた独自ドキュメントに関する30〜50問の小規模な評価セットを作成してください。
- 大規模言語モデルを使用して合成訓練データを生成し、回答が短く、事実に基づき、単一のパッセージから導出されていることを確認してください。
- モデルが無駄な冗長性を学習しないよう、肯定的な訓練例から「テキストには記載がない」などのヘッジングフレーズを取り除いてください。
- 訓練中の検証損失指標だけに頼るのではなく、特定のテストセットでチェックポイントの性能を手動で監視してください。
- アプリケーションが「ブログ」ではなく「ドキュメント」を参照する場合、コンテキスト整合性を向上させるためにカスタムシステムプロンプトでモデルを再訓練することを検討してください。



