小さく受託している会社が、SoTAよりデータを重視する理由
木村 優志
AIの相談を受けると、「この課題には、どのモデルが一番よいですか」と聞かれることがあります。画像認識なら最新のアーキテクチャ、生成AIなら新しい基盤モデル、音声認識ならベンチマークの上位モデルが候補に挙がります。
私たちも論文を読み、SoTA（State of the Art：その時点での最高性能）を追います。私も、日本音響学会や人工知能学会の全国大会、FIT（情報科学技術フォーラム）に参加し、発表を聞いて最新の情報を集めています。音声処理、AI、情報科学で、いま何が議論されているかを現場に持ち帰るためです。ただ、受託開発の現場で最初に見るのはモデルではありません。お客さまが持っているデータです。
実際の課題では、モデル間の性能差よりも、何をデータとして集め、何を正解とし、どのデータで評価するかの方が結果を大きく左右するからです。SoTAを使えば現場の問題が解けるのではなく、現場の問題を表したデータがあって初めて、モデルの性能を生かせます。
論文の数字は、そのデータセット上の数字である
論文で報告される精度は、定義されたデータセットと評価方法の上で測られた数字です。それは手法を公平に比較するために必要ですが、そのまま自社の現場で再現されるとは限りません。
たとえば、画像認識には次のような違いがあります。
- 論文では鮮明な画像だが、現場では振動や汚れがある
- 学習時は対象物が中央にあるが、実運用では位置がずれる
- 検証用データにはない型番や材質が流れてくる
- 昼夜、季節、照明の交換によって見え方が変わる
音声認識なら、話者の年齢、方言、専門用語、マイク、騒音が変わります。RAGなら、公開ベンチマークにはない社内固有の略語、古い文書、表、スキャンPDFが入ってきます。
論文と現場の差は、モデルを新しくするだけでは埋まりません。入力されるデータの分布そのものが違うからです。
最初に知りたいのは、データ量ではない
「データは何件必要ですか」という質問もよく受けます。しかし、件数だけを先に決めても、学習や評価に使えるとは限りません。
最初に確認したいのは、次のようなことです。
- そのデータは、実際の運用条件を含んでいるか
正常時だけでなく、失敗しやすい条件や例外が入っているか。 - 正解の定義が決まっているか
担当者によって判断が変わる対象を、同じラベルとして扱っていないか。 - データの偏りが分かるか
特定の製品、設備、話者、期間だけに集中していないか。 - 学習用と評価用を適切に分けられるか
同じ対象から得た似たデータが、両方へ混ざっていないか。 - 本番運用後もデータを集められるか
導入時の一回だけでなく、変化や失敗を継続的に記録できるか。
100万件あっても、同じ条件のデータばかりなら現場の変化には弱いままです。反対に、件数が少なくても、重要な条件と失敗例を押さえていれば、技術的な可能性を判断できることがあります。
大事なのはデータの多さではなく、解きたい問題がデータに現れていることです。
正解ラベルは、現場の合意そのもの
教師あり学習では、データに正解ラベルを付けます。外観検査なら良品・不良品、音声なら書き起こし、文書分類ならカテゴリです。
この作業は単純な前処理に見えますが、実際には業務要件を決める工程です。
たとえば、同じ傷を見ても、担当者Aは不良、担当者Bは良品と判断することがあります。製品の用途や納入先によって基準が変わることもあります。この状態で高性能なモデルを学習しても、一貫した正解を覚えることはできません。
そこで、モデルを作る前に判断が割れるデータを集めます。なぜ判断が違うのかを現場の方と確認し、必要ならラベルを細かく分けたり、「要確認」という区分を設けたりします。
AI開発におけるアノテーションは、人が持つ判断基準を機械へ写す作業です。基準が曖昧なら、その曖昧さもモデルへ入ります。SoTAのモデルでも、この問題を自動的に解決することはできません。
評価データを作ると、目標が具体的になる
学習データと同じくらい重要なのが、評価データです。
「精度を上げたい」という目標だけでは、何が改善したのか判断できません。実際に起きる場面を評価データとして用意すると、必要な性能が具体的になります。
外観検査であれば、すべての不良を一つの精度へまとめるのではなく、次のように分けて見ます。
- 見逃してはいけない重大な不良
- 人が確認すればよい微妙な不良
- 誤検知が起きやすい正常品
- 新しい型番や撮影条件
RAGであれば、答えられる質問だけでなく、文書に答えがない質問、複数の規程が関係する質問、古い版と現行版が混ざりやすい質問も入れます。
こうして初めて、「全体スコアが高いモデル」ではなく、「この業務で避けたい失敗を減らせるモデル」を選べます。
小さな受託会社は、モデルより先にデータの流れを作る
大規模な研究組織のように、すべての候補モデルを試し、膨大な探索を行えるわけではありません。限られた時間と予算で成果を出すには、モデル選定より先に、改善が積み上がる流れを作る必要があります。
現場のデータを集める
→ 正解と評価基準を決める
→ 小さなベースラインを作る
→ 失敗を種類ごとに分ける
→ 足りないデータを追加する
→ 再評価するこの流れがあれば、最初のモデルが十分でなくても改善できます。反対に、この流れがなければ、モデルを交換するたびに単発のデモを繰り返すことになります。
特に重要なのは、失敗したデータを残すことです。誤認識、見逃し、回答不能、現場からの修正を記録し、次の評価や学習へ戻します。本番で得られる失敗例は、その現場に固有の問題を表す貴重なデータです。
SoTAを捨てるわけではない
SoTAを追う意味がない、という話ではありません。新しい手法によって、少ないデータで学習できる、推論が速くなる、従来は難しかった入力を扱える、といった変化は実際にあります。モデルの進歩が問題を解くこともあります。
そのために、私も論文だけでなく学会へ足を運びます。日本音響学会では音声・音響の実装と評価の話を、人工知能学会では機械学習と応用の話を、FITでは情報科学・ITの幅広い発表を聞きます。発表の時点で論文になっていない知見や、失敗例、現場への落とし込みの議論は、論文を読むだけでは得にくいことがあります。最新を知ることは、何を試すかの候補を増やすためです。お客さまのデータに当てはめるかどうかは、そのあとで判断します。
ただし、私たちはSoTAであること自体を採用理由にはしません。
- 現場データで既存手法より改善するか
- 改善した失敗は、業務上重要か
- 必要な計算資源と運用コストに見合うか
- 将来も同じ条件で評価し直せるか
この条件を満たしたときに、新しいモデルを採用します。モデル名ではなく、現場データ上の差で判断します。
まとめ
論文が示すのは、あるデータセット上で手法がどこまで到達したかです。受託開発で問われるのは、お客さまの現場で何を正しく判断できるかです。
その間をつなぐのは、さらに新しいモデルだけではありません。現場を代表するデータ、合意された正解、失敗を含む評価セット、運用後にデータを戻す仕組みです。
小さく受託している会社が論文と現場のあいだで捨てるのは、研究そのものではありません。「最も新しいモデルを選べば、あとは解ける」という考え方です。
SoTAは変わり続けます。しかし、現場で集め、定義し、改善してきたデータは、その会社の課題を解くための資産として残ります。
