Soichiro Inatani

## #チーム情報 アドバイザー1名／実装担当1名（**自分**）／利用者3名程度。**設計・実装は自分が担当。** ## #開発・実装内容A: VLMによるモデル評価の自動化 **【概要】** 人手で行っていたモデル精度の評価を、VLM（Vision-Language Model）で自動化するシステム。 **【どのような機能の開発・実装か】** 評価対象の出力をVLMに判定させ、人手の確認作業を置き換えるパイプライン。**設計・実装ともに自分が担当。** **【課題・問題点】** - モデル改善の効果判定が**担当者の経験（職人技）に依存**しており、再現性がなかった - モデルを大きく変更した際の正解確認に、**1回あたり10時間以上の人手作業**を要していた - 評価が属人的なため、改善の良し悪しをチームで客観的に議論できなかった **【打ち手・使用した技術】** - **全部を自動化しようとしなかった。** VLMが確実に判定できる領域とそうでない領域を切り分け、**できる範囲に限って完全自動化**した - **自動評価が人の判断と一致するかを検証**し、評価方法そのものの妥当性を担保してから運用に載せた - 生成AIは万能ではないため、**どこまで任せてどこから任せないかを線引きする**ことが業務に載せる際の肝だと考えている。線引きせずに全面自動化すると、信頼できない評価結果が量産されて誰も使わなくなる - **技術**: Python / VLM / GPT系マルチモーダルモデル ## #開発・実装内容B: 自動評価機能とカバレッジ評価の仕組み **【概要】** LLM/AIシステム向けの自動評価機能と、基盤モデルのカバレッジ評価。 **【どのような機能の開発・実装か】** 評価項目を定義して自動実行する仕組みと、基盤モデルが対応できる範囲を体系的に測るカバレッジ評価。**自分が実装。** **【課題・問題点】** モデルの性能を「良くなった / 悪くなった」の感覚ではなく、**どの領域が改善しどの領域が劣化したか**の粒度で把握する必要があった。 **【打ち手・使用した技術】** - 評価項目を定義し、モデル開発担当者が日常的に回せる形に整備 - **技術**: Python / TypeScript / React / C# / Three.js - **評価項目** F1をメインとし、Precision, Recallもみた ## #成果 - **1回10時間以上**を要していた正解確認を、VLMが有効な判定領域で**完全自動化** - 属人的だった精度判断を、**再現可能な自動評価**に置き換え - モデル開発担当者3名が日常的に利用する評価基盤として定着・運用中