AIの精度が上がらないとき、何から改善する？――データ・評価・ファインチューニングの実務
AIの精度を上げたいとき、すぐにファインチューニングを始めるのは得策とは限りません。
データの分け方が不適切、ラベル基準が揺れている、評価指標が業務目的と合っていない――この状態で学習を重ねても、数字の意味が分からず、改善を再現できません。
モデルを学習する前に、改善を測れる状態を作る。
これが、画像AIでもLLMでも共通する出発点です。本稿では「精度が出ない」という相談を、どの順番で診断し、どの技術を選ぶかを整理します。
「精度を上げたい」を測れる言葉へ変える
精度という言葉は、業務によって意味が変わります。
| 課題 | 重視する指標の例 | 見落としやすい条件 |
|---|---|---|
| 不良品を見逃したくない | Recall、見逃し件数 | 誤検出が増えても運用できるか |
| 誤警報を減らしたい | Precision、誤検出件数 | 見逃しの許容範囲 |
| 個体を正確に数えたい | 個数誤差、画像単位Recall | 重なり、画角、対象サイズ |
| 文書を正しく分類したい | F1、クラス別Recall | クラス不均衡、曖昧な正解 |
| LLMの回答を安定させたい | 正答率、形式遵守率、根拠一致率 | 評価者間の基準差 |
| 現場端末で動かしたい | レイテンシ、fps、メモリ、消費電力 | 精度とのトレードオフ |
まず「どの失敗を、どこまで減らせば業務で使えるか」を決めます。総合スコアが上がっても、重要な対象だけ見逃していれば改善とは言えません。
まず測る
学習に使っていない評価データと、業務上の合格条件を先に固定します。
原因を分ける
見逃し、誤検出、形式違反、速度不足など、直したい失敗を種類別に確認します。
改善は7つのレバーで考える
1. 評価データを固定する
学習に使っていない検証データを用意し、改善前のベースラインを保存します。撮影場所や時期が同じ画像だけをランダム分割すると、似た画像が学習側と評価側に入り、実運用より高い数字が出ることがあります。
現場、設備、撮影日、文書の作成部署など、実際に変化する単位で分割することが重要です。
2. 誤りを種類別に分ける
スコア一つでは、次に何を直すべきか分かりません。
- 小さい対象を見逃す
- 逆光や影で誤検出する
- 背景の似た模様を対象と判断する
- 特定クラスだけ学習例が少ない
- ラベルの境界や分類基準が担当者ごとに違う
- LLMが事実を知らないのか、出力形式を守れないのか
失敗例を20〜100件ほど並べて分類すると、モデル変更より先に直すべき課題が見えることがあります。
3. データとラベルを改善する
多くの場合、効果が大きいのはモデルの大型化よりデータの改善です。
- 重複データや誤ラベルを除く
- ラベル定義と判断例を文書化する
- 苦手条件のデータを追加する
- クラス数と分類境界を見直す
- 個人情報や機密情報を適切に処理する
- データの利用権と学習済みモデルの扱いを確認する
データ数だけでなく、実運用で起きる失敗を代表しているかを見ます。
4. 前処理・拡張・しきい値を調整する
画像AIでは、解像度、切り出し、明るさ補正、回転・ぼかし等のデータ拡張、NMS、信頼度しきい値で結果が大きく変わります。
LLMでは、入力の正規化、指示テンプレート、出力スキーマ、例示、長文の分割方法が該当します。学習をしなくても、入力と後処理の設計で改善できる場合があります。
5. 手法とモデルを選び直す
一つのモデルに固執せず、課題に合う構成を比較します。
- 古典画像処理と学習モデルのハイブリッド
- 物体検出、セグメンテーション、分類の使い分け
- 大きなモデルから小さなモデルへの蒸留
- LLMのプロンプト、RAG、ツール実行、ファインチューニングの使い分け
- クラウド推論とエッジ推論の役割分担
「最新だから」ではなく、評価指標、運用環境、保守性で選びます。
6. ファインチューニングする
既存モデルの知識や特徴を生かし、特定タスクへ追加学習します。
画像AIでは、独自画像で物体検出・分類・セグメンテーションモデルを学習します。LLMでは、SFT、LoRA、QLoRAなどを使い、応答の形式、用語、タスク手順を学習させます。
一方、頻繁に変わる社内情報を覚えさせたいだけなら、RAGやデータベース連携の方が更新しやすいことがあります。ファインチューニングは、正解例を安定して用意でき、繰り返し現れる振る舞いを変えたいときに向いています。
7. 配備環境に合わせて軽量化する
検証PCで高精度でも、現場端末で遅ければ使えません。
量子化、蒸留、入力解像度の調整、ONNXやTensorRTへの変換、バッチ・キャッシュ設計などを比較し、精度と速度の許容点を決めます。最終評価は、実際に使う端末と撮影・通信条件で行います。
モデルを変えず、パイプラインで改善できる場合もある
業務で感じる「AIの精度」は、モデル単体ではなく、入力から確認画面までを含むパイプライン全体で決まります。モデルの重みを変更しなくても、前処理、検索、外部ツール、ルール、出力検証を組み合わせることで改善する可能性があります。
画像AIなら、対象領域の切り出し、照明補正、古典画像処理との組み合わせ、複数フレームの集約が候補です。LLMなら、入力の正規化、RAG・データベース検索、ツール実行、JSONスキーマ検証、再試行、人による承認などを比較します。
- 1入力を整える切り出し・正規化・指示設計
- 2情報を補うRAG・DB・外部ツール
- 3モデルで推論既存モデル・追加学習モデル
- 4出力を検証ルール・スキーマ・再試行
- 5人が確認する訂正・承認・失敗例の蓄積
パイプラインで解消できない反復的な誤りや、用途固有の出力形式が残る場合に、ファインチューニングを組み合わせます。どの方法も、変更前後を同じ評価条件で測ることが前提です。
ファインチューニングが向くケース・向かないケース
向いている
- 対象や出力形式が明確
- 一貫した正解データを用意できる
- 同じ失敗パターンが繰り返される
- 既存モデルのベース性能が確認できる
- 評価指標と合格条件が決まっている
先に別の改善を検討する
- 業務要件や正解がまだ曖昧
- データが少ないだけでなく偏っている
- 最新情報を回答へ反映したい
- 誤りの原因をまだ分類していない
- 学習後の評価・更新担当が決まっていない
丸太材積計測AIで行った改善例
丸太材積計測AIのブラウザデモでは、古典画像処理、汎用の物体検出モデル、丸太専用に学習したYOLOを比較できるようにしています。
自主検証では、学習に使っていない69枚・丸太8,304本をconf=0.5で評価し、本数Recallが0.42から0.95、Precisionが0.77から0.84へ改善しました。ただし、この数字だけで「どの現場でも95%」とは言えません。公開データを用いた特定条件の結果で、材積誤差は未評価です。撮影角度、照明、重なり、背景が変われば結果も変わるため、デモには信頼度表示と手動補正を残しています。
Recall見逃しの少なさ
Precision誤検出の少なさ
この事例で重要なのは、特定モデルを使ったことよりも、次の改善サイクルを回したことです。
- 汎用モデルと古典手法でベースラインを作る
- 見逃し・誤検出を画像ごとに確認する
- 対象データとラベルを追加・修正する
- 再学習し、固定したデータで比較する
- ブラウザやエッジ端末で使える形へ変換する
- 自動判定だけに頼らず、補正できるUIを残す
学習条件と試行の詳細は、ローカルAI実測ラボのケーススタディで公開しています。
ローカルLLMに向き合う会での発表
Link Fieldの運営者は過去に、ローカルLLMの開発者コミュニティ「ローカルLLMに向き合う会」で、**ローカルLLM × GISによる「妖怪ハザードマップ」**をLT発表しました。QLoRAで用途に合わせた構造化出力を試し、そのJSONをGISへ渡して地図表示するパイプラインを構築しています。なお、この発表時のQLoRA学習には外部GPU環境を利用しており、現在の標準環境であるRTX A6000だけで行った実績としては扱っていません。
これとは別に、同コミュニティでは、複数のローカル・エッジデバイスを連携させた「AI Map Explorer」の展示も行いました。2つの発表・展示を通じて得た知見を、モデル学習だけで終わらず、データ取得、出力検証、GIS・データベース連携、端末配備まで含めて設計する支援に生かします。
RTX A6000 48GBで対応する範囲
Link Fieldでは、48GB ECCメモリを備えたNVIDIA RTX A6000をローカル検証基盤として使用します。画像AIの追加学習、複数条件の比較、パラメーター効率のよいLLM調整など、小〜中規模の改善PoCを繰り返す用途に向きます。
ただし「何Bモデルまで」と一律には決めません。必要メモリは、モデル、精度、入力長、バッチサイズ、学習方法によって変わるためです。最初に小規模ベンチマークを行い、次のどれで進めるか判断します。
- A6000内で条件を調整して反復する
- 複数ジョブを順番に実行する
- 案件の承認を得てクラウドGPUを一時利用する
- 継続需要がある場合に追加GPUや大容量メモリ機を導入する
計算資源を先に大きくするのではなく、案件の評価方法と再現可能な改善手順を先に作る方針です。
改善PoCで残すべき成果物
モデルの重みだけを納品しても、次回の改善で困ります。少なくとも次を残します。
- 業務目的、評価指標、合格条件
- データの範囲、分割方法、ラベル基準
- 改善前のベースラインと誤り分析
- 試した手法、設定、比較結果
- 採用モデルと不採用案の判断理由
- 再現手順、実行環境、依存ライブラリ
- モデル・データ・OSSのライセンス整理
- 既知の限界と、人が確認すべき条件
- 配備用モデル、推論コード、動作確認結果
- 次に集めるべきデータと改善バックログ
相談時に分かる範囲で用意するもの
- 解決したい業務と、現在困っている誤り
- 現在のモデル、コード、または手作業の流れ
- 利用できるデータの件数・形式・権利関係
- 正解ラベルの有無と作成できる担当者
- 目標指標、処理時間、利用端末
- クラウド利用可否と機密性の条件
全部そろっていなくても構いません。最初の診断で、学習を始める前に不足しているものを整理します。