10万以上のラベルに対応する文書分類のスケーリング

Databricksでは、何千ものお客様が、自由形式のテキストを10万以上のラベルからなる正規化されたタクソノミにマッピングする本番ワークロードを構築しています。代表的なユースケースには、以下のようなものがあります。

• 生体医学エンティティのリンク。臨床ノートや研究論文に記載されている疾患、医薬品、処置を、何千もの生体医学概念識別子を持つ語彙集であるUnified Medical Language Systemの概念と一致させる必要があります。
• ベンダーの正規化。支出パターンを分析するために、金融機関は「SBUX #4471 SEATTLE WA」のような未加工の取引文字列を、10万以上の加盟店セットに対して正規化します。
• 企業の正規化。企業は、会社の説明を10万以上の企業セットと照合することで、異なる社内システム間で顧客レコードの重複を排除します。

これらのユースケースはいずれも、*タクソノミ*とも呼ばれる大規模なラベルセットを定義しており、すべての入力はそれらのラベルの1つ以上にマッピングされる必要があります。お客様は通常、以下の基準に基づいて本番ソリューションを評価します。

1. 品質：下流の意思決定を促進するのに十分な精度で分類を行います。
2. コスト：特に大規模な環境において、ドキュメントあたりの分類コストを低く抑えます。
3. スループット：多くの場合、数十万件規模のドキュメントに及ぶ大規模なワークロードを、妥当な時間内に処理します。

これら3つの要件をすべて満たすことは、本番環境における大規模なタクソノミ分類を困難にします。Databricksでは、これらの課題に対するソリューションの研究と構築を優先的に進めています。

既存のアプローチが不十分な理由

これまで、多くの組織はカスタムの正規表現（regex）ルール、キーワードマッチング、および教師あり機械学習分類器に依存して大規模なタクソノミ分類に取り組んできました。しかし、これらのアプローチにはいくつかの側面で不十分な点があります。

脆弱なパターンマッチング。正規表現やキーワードルールは完全一致に依存しているため、実際のデータにおける予測不可能なフォーマットの乱れに対応できません。YipitDataのような企業は、エッジケースやタクソノミの変更に対応するために正規表現パターンを継続的に更新する必要がありましたが、これは何千ものラベル規模で維持するのは困難です。

まばらで偏りのあるグラウンドトゥルース（正解データ）。実際のラベル分布はロングテールです。一握りのラベルがほとんどのドキュメントをカバーする一方で、何千ものラベルはめったに現れません。ほとんどのお客様は、タクソノミ内のすべてのラベルに対するグラウンドトゥルースドキュメントを持っていないため、教師あり分類器のトレーニングが困難になります。分類器はトレーニングデータに含まれていないラベルの分類を学習できず、クラスの不均衡によって、分類器は頻出するラベルを過剰に予測し、稀なラベルを過少に予測してしまいます。

タクソノミのドリフト。新しいビジネスユースケースへの対応や分類品質の向上のために、ラベルとその説明は常に追加、廃止、書き換えが行われます。タクソノミのバージョンが新しくなるたびに、正規表現パターンを更新し、分類器を再トレーニングしてデプロイする必要があります。

最近では、分類に大規模言語モデル（LLM）を使用するお客様が増えています。 LLMを使用すれば、モデルをトレーニングしたり、脆弱な正規表現パターンを維持したりする必要がなくなります。しかし、数十万ものラベル規模になると、LLMはコンテキストウィンドウ内にタクソノミを収めて推論することに苦労します。1つのプロンプトに何千もの候補が含まれると、モデルはハルシネーション（幻覚）を起こし始め、タクソノミにまったく存在しないラベルを返すようになります。また、プロンプトキャッシュを利用したとしても、数十万件のドキュメントに対してタクソノミ全体をフロンティアモデルに渡すことは、大規模環境ではコストがかさみます。

大規模ラベル分類へのアプローチ方法

大規模なタクソノミにおいてコストと品質の最適なバランスを見つけるために、3つの異なる方法を評価します。

方法1：ベクトル検索

テストする最初の方法は、ベクトル検索を使用して、入力に対して最適なラベルを取得することです。すべてのラベル（説明がある場合は説明を含む）と入力ドキュメントを、2026年7月時点で上位にランクインしているオープンウェイトの埋め込みモデルであるQwen3-Embedding-8Bモデルを使用して埋め込みます。次に、意味的類似性と語彙的類似性の両方を考慮したハイブリッドスコアを使用して、ドキュメントに対する各ラベルの関連性をスコアリングします。

意味的スコアは、ドキュメントとラベルの埋め込み間のコサイン類似度を計算することによって決定されます。コサイン類似度が高いほど、テキストが完全に一致していなくても、ラベルの意味がドキュメントと密接に一致していることを意味します。語彙的スコアはBM25アルゴリズムで計算されます。このアルゴリズムは、共有される各用語をラベルセット全体の逆文書頻度で重み付けするため、何千ものラベルに出現する「use」のような一般的な動詞の重みは低くなり、「ETL」のような珍しいトークンの重みは高くなります。

各検索方法は、それぞれランク付けされたラベルのリストを返します。各リストにおける各ラベルの位置に基づいてスコアリングを行う相互ランク融合（Reciprocal Rank Fusion）を使用して、2つのリストをマージします。上位k個を取得し、kを1、5、10、20、50、100、200と変化させて最適な平均精度を持つ値を見つけ、最上位のラベルを予測値として使用します。

数十万ものラベル規模では、タクソノミを一度埋め込んでインメモリインデックスを構築する方が、ホストされたベクトル検索インデックスを作成するよりもコスト効率が高くなります。Qwen3-8Bの4096次元float32埋め込みを想定すると、10万個のラベルの埋め込みに使用するストレージは約1.6 GBであり、Databricks AI Query関数を使用した埋め込みには約1〜3分かかります。その後、ワークロードの開始時にメモリ内にベクトル検索インスタンスを作成し、永続化された埋め込みを取り込んで、ワークロードの実行期間中すべてのドキュメントに対してそのインデックスを使用します。ベクトル検索の実装例のコードは、こちらのチュートリアルノートブックで確認できます。

方法2：ベクトル検索 ＋ AI Classify

テストする2番目の方法は、ベクトル検索アプローチとDatabricksのAI Classify関数を組み合わせた2ステップのワークロードです。AI Classifyは、ドキュメントと、ラベルから説明へのマップを受け取り、最もよく一致するラベルまたはラベルのセットを返すDatabricksのAI関数です。AI Classify関数は、分類品質を維持しながら大規模なドキュメントやタクソノミを管理するために、さまざまな手法を組み合わせて使用しています。

AI Classify関数は、以下のようにSQLで実行できます。

方法1で説明したのと同じベクトル検索による取得を使用して、ドキュメントごとに最も類似したk個のラベルを絞り込み、その絞り込みリストのみをAI Classifyに渡すことで、2ステップのワークロードを作成します。精度が向上しなくなる最小の値にkを調整し、AI Classifyの結果を予測値として採用します。

方法3：フロンティアモデルの直接呼び出し

テストする最後の方法は、入力ドキュメントと（説明がある場合は説明を含む）ラベルのリストを使用してフロンティアLLMを直接呼び出し、正しいラベルを返すようモデルにプロンプトで指示することです。テストしたモデルは、GPT-5.6 Luna、GPT-5.4 mini、Gemini 3.5 Flash、Claude Sonnet 5であり、これらはお客様の一般的な本番環境の分類予算の範囲内にある最新モデルです。Claude Opus 4.8、Claude Fable 5、GPT-5.6 Solなどのフラッグシップモデルは、トークンあたりのコストが3〜10倍高く、1日に何千ものドキュメントを処理する分類ワークロードを実行するお客様にとっては、通常予算オーバーとなります。

タクソノミがモデルのコンテキスト長を超える場合は、コンテキストウィンドウに収まるようにラベルリストを切り詰めます。プロンプトキャッシュを利用するために、各ドキュメントの呼び出し間で一貫してタクソノミを渡します。

評価方法

上記で説明した最も一般的なお客様のユースケースをカバーする3つのデータセットで、各方法のベンチマークを行います。特に断りのない限り、ラベルは説明とともに埋め込まれます。

• 取引（10万ラベル、評価ドキュメント200件）：Crunchbaseの10万件の上位企業名に基づいて合成生成された取引文字列。
• 企業（10万ラベル、評価ドキュメント200件）：「取引」と同じCrunchbaseの企業名カタログにマッピングされた会社説明。ラベルは名称のみ。
• MedMentions（35kラベル、200件の評価文書）：MedMentionsコーパスから、Unified Medical Language Systemの概念識別子へのバイオメディカルなメンションのリンク。

各データセットは、予測されたラベルが正解ラベル（ground truth）と一致する文書の割合である「正解率（accuracy）」でスコア化されます。すべての直接的なフロンティアモデルの呼び出しにおいて、モデルプロバイダーのプロンプトキャッシュオプションを有効にしています。

結果

アプローチごとに、3つのデータセットの平均値として、文書あたりのコストに対する正解率をプロットしています。コストには、プロバイダーのプロンプトキャッシュ割引を適用した文書の埋め込み（embedding）とLLMトークンが含まれます。ワークロードの規模に応じてスケールしない一回限りのコストであるタクソノミーの埋め込みは除外しています（ベクトル検索構成のストレージ見積もりについては、「大規模なラベル分類へのアプローチ方法」を参照してください）。

すべてのデータセットにおいて、AI Classifyワークフローはすべての直接的なフロンティアモデルを上回るスコアを記録しました。文書あたりのコストが100分の1でありながら、次点であるGemini 3.5 Flashの平均正解率0.76に対して、0.81を達成しています。AI Classifyワークフローの品質は、平均して、ベクトル検索から上位20個のラベルを絞り込んでAI Classify関数に渡す場合に最も高くなります。

ベクトル検索のみの場合は、文書の埋め込みのみが必要で、ランキングのCPUコストは無視できるため、AI Classifyワークフローよりも100倍近く安価になります。しかし、kを調整した後でも、AI Classifyワークフローを20ポイント以上下回るスコアにとどまります。

最大のタクソノミーでは、直接的なフロンティア呼び出しではモデルのコンテキストウィンドウにすべてのラベルセットを収めることができません。MedMentionsでは、1Mトークンのコンテキスト内にタクソノミー全体を保持できたのはGPT-5.6 Lunaのみでした。トークン化後、他のどのモデルも制限内にラベルセットを収めることができませんでした。この段階で、開発チームはコンテキストを管理するために、バッチ、マルチステップ、およびエージェント戦略の評価を選択できます。これらの機能は、私たちのチームが構築し、AI Classify関数で継続的に改善しているものです。

結論

35,000から100,000のラベルに及ぶ3つのベンチマークにおいて、ベクトル検索とDatabricksのAI Classify関数を組み合わせたAI Classifyワークフローが、コストと品質の最良のバランスを示しました。最も強力な直接的フロンティアモデルであるGemini 3.5 Flashを5ポイント上回り、文書あたりのコストは約100分の1に抑えられています。タクソノミーが変更された場合でも、再トレーニングや再デプロイを行うことなく、不要になったラベルを削除し、新しいラベルを埋め込んでワークフローの開始時に取り込むことができます。

この規模の分類に直面しているチームにとって、AI Classifyとベクトル検索を使用したワークフローの作成は、最適なスタート地点となります。このステップバイステップのチュートリアルでは、ラベルセットの埋め込みからKの選択まで、Databricks上での完全なワークフローを順を追って説明します。

AI Classifyワークフローを試す

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事