機械学習（ML）プロジェクトの成否を左右するのは 「最初にどれだけ完璧に作れるか」 ではなく、「どれだけ速く改善ループを回せるか」 だと思っています。特に専門性が高い領域では、アノテーションの外注コストやドメイン知識の壁から、“作る ↔ 直す” を高頻度で繰り返さないかぎり精度が頭打ちになりがちです。
Human-In-The-Loop は ”運用しながら育てる仕組み” であり、小さく作って改善を回していくことが最短ルートだと考えています。estieでの事例を元にご紹介します。
Step1: 初期モデル・ルールの構築
HITLの最初のステップは、完璧ではないが「それなりに使える」初期システムを作ることです。このモデルを用いてStep2での評価データセット構築を楽にしていきます。
ルールベースや汎用的な学習済みモデルが非常に有用です。特にLLMは非常に簡単に扱える上に強力です。
この段階ではまだモデルの評価を行うことが出来ないので、あまり作り込みすぎずに早めにStep2へ移行することが重要です。
Step2: 評価データセットの作成
作ったモデルを評価するためにデータセットを作成します。精度評価と精度改善の二つが主な目的です。
特にLLMを使ったプロジェクトの場合は、（自分が何もしなくても）新モデルがどんどん発表されていきます。評価データセットを持っておくことで、コストや精度を元に定量的に議論を行うことができます。
また、間違った事例を分析することでプロンプト改善につなげていくことが出来ます。
データセットの作成は大抵自分がやることになると思います。Step1で作ったモデルを初期入力として、それを修正する方が0から打ち込むよりも楽です。
Step3: 精度改善
評価結果をもとに、以下の 3 アプローチ を適宜組み合わせます。
アプローチ1: プロンプト改善
コンテキスト量が許すなら、まず Few-shot を試すべきです。一般的に精度向上に大きく寄与するためです。
また、修正が多発するパターンを分析し、プロンプトに追加していきます。
# 改良後プロンプト（抜粋） PDF から物件情報を抽出し、次の JSON スキーマに従って出力してください。 ## 注意点 - "1R" と "1K" は厳密に区別されます - 年号でなく西暦を用います - 面積は 坪と m2 の二種類の表記がありえます
アプローチ2: 後処理
よくある間違いパターンをルール化して後処理で修正していきます。
プロンプトを工夫しても100%にはならなかったりするので、後処理を入れた方が簡単だったりします。
全角半角の調整やスキーマのバリデーションなどが典型的な例です。
アプローチ3: ファインチューニング
十分なデータが貯まった段階での選択肢です。
データさえあれば結構簡単に導入することもできますが、精度・コスパは必ずしも上がるわけではないです。estieでも抽出タスクで一度作成したことがありますが、結局ファインチューニングしたモデルより最新の基盤モデルの方が精度が高かったという事例があります。
Step4: フィードバックループの設計
精度の怪しい部分は最終的に人間が入ってチェックしています。estieのデータも大抵人手のチェックが入っています。ここで得た修正データは非常に重要で、運用しながら間違い事例がどんどん貯まっていくことになります。この間違い事例を元にまたStep2,3へ還元していくことで改善ループを回していっています。
すべてのデータを人間がチェックするとコストが高すぎるため、「間違っていそうな箇所」を自動で特定する仕組みが重要です。LLMのAPIを使っていながら確信度を得るのは難しいので、同じタスクを複数のLLM（GPT-4、Claude、Geminiなど）に実行させ、出力が一致しない項目を擬似的に確信度が低いと認定してチェックする等の工夫を行っています。小さいモデルに検算させるのも同様に有効です。（GPT-4oの回答をGPT-4o-miniも再現させられれば、確信度が高いとする考え）
まとめ
HITL を “回しながら作る” 最大のメリットは、「人の知見」がシステムに高速で循環する 点です。小さく始め、ループを壊さず運用すれば、ドメイン特化タスクでも短期間で実用レベルに到達できます。ぜひ、次のプロジェクトで試してみてください。
