データ駆動型AI開発の新常識：あなたのAIアプリケーションを飛躍させるための体系的アプローチ

AI技術が急速に進化する中、多くのAIエンジニアや開発者が直面する共通の課題があります。それは、「どうすれば自分のAIシステムが本当に良いのか？」「どうすればもっと改善できるのか？」という根本的な問いです。チャンキング戦略の選択、最適なエンベディングモデルの特定、リランカーの導入、適切なインデックス作成アプローチ、メタデータフィルターの活用…これらの技術的な選択肢は、日夜、私たちの頭を悩ませています。

しかし、これらの問いに対する答えは、意外なほどシンプルで強力な原則に集約されます。それは、マネジメントの父、ピーター・ドラッカーが提唱した「測定できるものだけが管理できる」という言葉です。AIアプリケーションの複雑性が増す現代において、この原則はかつてないほど重要性を増しています。

本記事では、「データを見て、測定し、改善する」というChromaの共同創設者兼CEOであるJeff Huber氏とJason Liu氏が提唱する体系的なアプローチに焦点を当てます。このアプローチは、AIアプリケーションのインプットとアウトプットの両方を深く分析し、データ駆動型の意思決定を通じて、あなたのAI製品を次のレベルへと引き上げるための具体的な機能、ビジネスへの影響、そして将来性について、詳細かつ分かりやすく解説します。

Part 1: インプットの測定 — リトリーバルシステムの最適化

AIアプリケーション、特に情報検索（RAG: Retrieval-Augmented Generation）システムを構築する際、最も基本的な疑問は「どのようにして最適な情報を取得できるか」です。インプットの質がアウトプットの質を決定するため、リトリーバルシステムが適切に機能しているかを測定することは、成功の鍵となります。

従来の評価方法の限界と「Fast Evals」の必要性

多くの開発者が、リトリーバルシステムの性能評価において、いくつかの非効率なアプローチに陥りがちです。

推測と運頼み (Guess & fingers crossed): 最も原始的で非効率な方法です。変更を加えて、「うまくいくことを願う」だけでは、体系的な改善は望めません。
LLMをジャッジとして利用 (LLM-as-judge): 最新のLLMフレームワークの中には、LLM自体を評価者として使用し、ファクトチェックや他のメトリクスを測定するものがあります。しかし、これらは多くの場合、非常に高コストで、評価の実行に何時間もかかることがあります。迅速なイテレーションが求められる開発現場には不向きです。
公開ベンチマークの使用: MTEBのような公開ベンチマークは、様々なエンベディングモデルの性能を比較するのに役立ちます。しかし、これらのベンチマークデータセットは、しばしば「過度にクリーン」であるという問題があります。たとえば、「庭でパーゴラは何に使われますか？」というクエリに対する期待される回答が、ドキュメントの冒頭に直接的に書かれているようなケースです。現実世界のユーザーは、これほど直接的なクエリを常に発するわけではありません。さらに、多くのLLMはすでにこれらの公開ベンチマークデータで学習しているため、あなたのアプリケーションの実際のパフォーマンスを正確に反映しない可能性があります。

これらの限界を乗り越え、より効率的かつ実践的な評価を可能にするのが、Chromaが提唱する「Fast Evals（高速評価）」です。

Fast Evalsとは何か？

Fast Evalsは、非常にシンプルでありながら強力な評価手法です。これは、特定の「クエリ」が入力されたときに、「このドキュメント」が返されるべきである、というクエリとドキュメントのペアのセットを指します。このペアの集合体は「ゴールデンデータセット」と呼ばれます。

Fast Evalsの評価プロセスは以下の通りです。

ペアの作成: まず、「このクエリが入ったら、このドキュメントが出るべき」という形式の有効なクエリ-ドキュメントペアを定義します。
ゴールデンデータセットの構築: これらのペアを多数集め、独自のゴールデンデータセットを作成します。
システムの評価: 定義した全てのクエリをシステムに入力し、期待されるドキュメントが実際に返されるかを確認します。リトリーバル結果の上位N件（例えば5件、10件、20件など）に期待されるドキュメントが含まれているかを確認することで、システムのリコール率を測定します。

Fast Evalsの利点は、その「高速性」と「低コスト」にあります。これにより、開発者は大量の実験を迅速かつ安価に実行できます。数時間を要する評価プロセスが、数秒または数分で完了するようになることで、イテレーションサイクルが劇的に短縮され、よりアジャイルなAI開発が可能になります。

合成クエリの生成とリアリティへのアラインメント

独自のドキュメントは持っているものの、それに対応するクエリが不足している場合もあるでしょう。このような時、LLMを使ってクエリを生成することが可能です。しかし、単純にLLMに「このドキュメントに対する質問を生成して」と指示するだけでは、公開ベンチマークのように過度にクリーンで非現実的なクエリが生成されがちです。

Chromaの研究では、LLMに「現実世界のユーザーがどのようなクエリを発するか」を教え込むことで、合成クエリの特異性を実際のクエリに意味的にアラインメントさせる手法が開発されました。これにより、合成データセットを使った評価が、より実世界に近い形でシステムの性能を反映するようになります。過度に特異なクエリでシステムがうまく機能していると誤解するリスクを回避し、真の改善点を見つけることができます。

エンベディングモデルの選択とW&Bチャットボットの事例

新しいエンベディングモデルが次々と発表される今日、どれが自分のアプリケーションに最適かを見極めるのは困難です。公開ベンチマークで高スコアを叩き出している「セクシーな」最新モデルが、必ずしもあなたの特定のデータセットで最良のパフォーマンスを発揮するとは限りません。

W&B（Weights & Biases）チャットボットでの事例は、この点を明確に示しています。4つの異なるエンベディングモデルをFast Evalsで評価した結果、以下のような興味深い発見がありました。

初期の選択の誤り: このアプリケーションで当初採用されていた「text-embedding-3-small」は、評価したモデルの中で最もパフォーマンスが悪いことが判明しました。
ベンチマークと現実の乖離: 公開ベンチマークで非常に高い評価を受けていた「jina-embeddings-v3」も、このW&Bのユースケースでは期待したほどの結果を出しませんでした。
経験的データの勝利: 実際に最もパフォーマンスが良かったのは「Voyage-3-large」モデルでした。

この結果は、自分のデータに対してFast Evalsを実行することで初めて得られる洞察であり、公開ベンチマークや一般的な認識に惑わされずに、データに基づいた合理的な意思決定を行うことの重要性を強く示唆しています。新しいモデルへの切り替えは、再エンベディングのコスト、APIの速度、信頼性など、多くのエンジニアリング上の考慮事項を伴います。だからこそ、その変更が実際に自分のシステムに利益をもたらすかどうかを、経験的に検証することが不可欠なのです。

Fast Evalsは、あなたのAIシステムの改善をより体系的かつ決定論的にし、推測や運に頼るのではなく、データに基づいた確かな進歩を可能にします。

Part 2: アウトプットの測定 — 会話データから製品の洞察を得る

インプットの質を測定する一方で、AIアプリケーションがユーザーに提供する「アウトプット」を深く分析することも、製品改善のもう一つの重要な側面です。特に、LLMベースのチャットボットやエージェントシステムでは、ユーザーとの会話履歴そのものが、製品開発のための宝の山となります。

手動レビューの限界と「隠れたシグナル」の発見

製品が初期段階にある場合やユーザー数が少ない場合（例えば、28件未満のクエリや188件未満の会話）、個々の会話を丹念に手動でレビューすることは有効です。各インタラクションを注意深く読み込み、AIの応答が適切であったか、ユーザーの意図を正確に捉えられたか、といった定性的な評価を行うことができます。

しかし、製品が成長し、ユーザー数が増加すると、この手動レビューはすぐに限界を迎えます。数千のクエリや数万の会話は、人間が手作業で分析できる範囲をはるかに超えます。会話は複雑で詳細に富み、何を見るべきかの専門家も常にいるわけではありません。また、大量の会話データの中から特定のパターンや問題点をスキャンするのも困難です。

こうした状況下でも、会話データには製品改善のための貴重な「隠れたシグナル」が埋もれています。

ユーザーの不満とリトライパターン: あなたはLLMに「もう一度試して」「もっと良くして」「直して」と何回言ったことがあるでしょうか？ユーザーの会話には、システムに対する生の不満や、期待通りの結果が得られなかった際のリトライパターンが「フィルタリングされていない形」で残されています。これらは、フィードバックウィジェットや「サムズアップ/ダウン」のボタンでは捉えきれない、より詳細で具体的なペインポイントを示唆します。
自然言語のデータ: 最も重要なのは、これらのデータがすでに自然言語として存在している点です。私たちはこの「カオス」の中から、意味のある「構造」を抽出する必要があります。

単純なメトリクスを超えた洞察の獲得

単一のメトリクスやKPI（例: ファクトスコア0.6）だけでは、製品の全体像や改善すべき具体的なポイントを把握するのは困難です。これが「良い」のか「悪い」のか、何を意味するのかが分かりにくいからです。

これを理解するために、マーケティングの例を考えてみましょう。

あなたの広告キャンペーンの総合スコアが0.5だったとします。この数字だけでは、次に何をすべきかは不明確です。
しかし、もし追加の分析によって、ユーザーの80%が35歳未満、20%が35歳以上であることが分かったとします。そして、35歳未満のユーザーには広告が非常にうまく機能している一方で、35歳以上のユーザーには全く機能していないことが判明したらどうでしょう？
この洞察によって、あなたは明確な意思決定を下すことができます。例えば、「若い層へのマーケティングをさらに強化する」か、あるいは「なぜ35歳以上の層に響かないのかを徹底的に分析し、広告戦略を調整する」といった具体的なアクションプランが立てられるようになります。

このように、データをセグメント化し、特定のユーザー層やユースケースにおけるパフォーマンスを理解することで、単なる数字の羅列が「実行可能な洞察」へと変わります。

カオスから構造を抽出する「Kura」ライブラリ

大規模な会話データからこのような洞察を抽出するために、Chromaは「Kura」というオープンソースライブラリを開発しました。Kuraは、LLMを活用して、混沌とした会話データから構造化された情報を自動で抽出し、分析を容易にするための強力なツールです。

Kuraの主要なパイプラインステップは以下の通りです。

会話の要約と構造化: LLMに会話全体を分析させ、以下のような構造化された情報を抽出します。
- 何が起こったかの要約（会話のメインテーマ）
- 会話中に使用されたツールの特定
- ユーザーのエラーパターンと不満レベル
- 顧客満足度スコア（推測または明示的なフィードバックから）
- 会話の長さや複雑性などこれには、Pythonのinstructorやpydanticのようなライブラリを用いて、LLMの出力を厳密なデータモデルに適合させる技術が活用されます。
類似する会話のクラスタリング: 抽出された構造化データ（またはエンベディング）に基づいて、類似するテーマや問題意識を持つ会話を自動的にグループ化（クラスタリング）します。これにより、手動では見つけられないような隠れたパターンや共通の課題が浮き彫りになります。例えば、「データ可視化に関するヘルプ」「SEOコンテンツのリクエスト」「認証問題」といった具体的なクラスターが形成されます。
メタクラスターの階層構築: さらに、これらのベースクラスターを統合し、より上位のテーマに基づいた「メタクラスター」の階層を構築します。これにより、例えば「テクニカルサポート」という大きなメタクラスターの下に、「データベースの問題」と「認証問題」といった具体的なクラスターがぶら下がるような、ツリー構造の洞察が得られます。
クラスター間のKPI比較: 各クラスター（またはメタクラスター）において、不満レベル、エラー率、顧客満足度などのKPIを比較分析します。これにより、「どのユースケースでAIがうまく機能しているか」「どの領域に重大な問題が潜んでいるか」をデータに基づいて明確に特定できます。

Kuraによる実践での成果として、以下のような具体的な洞察が得られました。

存在しないフィルターへの需要: ユーザーが、現在のシステムには存在しない特定のフィルタリング機能を求めているクラスターが発見されました。これは新機能開発の明確なヒントとなります。
アクセスできないデータソースへの質問: システムがアクセスできないデータソースに関する質問が集中しているクラスターが見つかり、データ連携の改善の必要性が示唆されました。
満足度の低いパフォーマンスの低いセグメント: 特定のユースケースにおいてユーザーの満足度が著しく低いクラスターが特定され、その原因究明と改善の優先順位付けが可能になりました。

このようにKuraは、大量の非構造化データから意味のある構造を抽出し、AIアプリケーションの利用状況に関する深い洞察を得ることを可能にします。

分析からアクションへ — データ駆動型改善のロードマップ

Jeff Huber氏とJason Liu氏が強調するのは、データ測定の究極の目標は、単に数値を出すことではなく、「次に何をすべきかを理解すること」にあるという点です。Fast EvalsとKuraのようなツールが提供する洞察は、あなたのAIアプリケーションの改善に向けた具体的なアクションへと繋がります。

データ駆動型意思決定のプロセス

この体系的なアプローチは、以下のステップを通じて、AIアプリケーションの継続的な改善を可能にします。

成功メトリクス（KPIとEvals）の定義: まず、アプリケーションの成功を測るための明確な指標を設定します。これは、ビジネス目標に直結するKPIと、Fast Evalsによって測定可能な技術的パフォーマンスの両方を含みます。
会話を意味のあるセグメントにクラスタリング: Kuraを活用し、ユーザーの会話履歴をテーマ、意図、問題点などに基づいて意味のあるグループ（クラスター）に分類します。
パターンを見つけるためにクラスターごとのKPIを比較: 各クラスターにおけるKPIのパフォーマンスを比較し、どのセセグメントがうまく機能しているか、またはボトルネックとなっているかを特定します。
各セグメントについて構築、修正、または無視を決定: データ分析で得られたパターンとパフォーマンスの比較に基づき、各セグメントに対して具体的なアクションを決定します。
- 構築: 新しい機能やツールが必要な場合。
- 修正: 既存の機能やプロンプトに問題がある場合。
- 無視: 現状で許容できるか、優先度が低い場合。
リアルタイム監視のために分類器を訓練: 特定された問題やユースケースのクラスターをリアルタイムで監視できるよう、分類器を訓練します。これにより、新たな問題発生を早期に検知できます。
ダッシュボードとアラートを作成: 監視結果を可視化するためのダッシュボードを構築し、特定の閾値を超えた場合にアラートを発するシステムを設定します。
データ駆動型のロードマップ意思決定: これらのデータと洞察に基づいて、製品開発のロードマップや優先順位を決定します。

キーインサイト：AI改善はインフラから

このプロセス全体を通して明らかになる重要な洞察があります。それは「AIモデル自体の性能向上だけが解決策ではない」ということです。多くの場合、解決策はAIの根幹をなすモデルを改善することではなく、むしろそのモデルを最大限に活かすための適切な「サポートインフラストラクチャ」を構築することにあります。

例えば、ユーザーの会話履歴から「タイムフィルターに関するクエリ」が頻繁に検出されたとします。もし、あなたのリトリーバルシステムにまだタイムフィルター機能が実装されていなければ、それを追加するだけでFast Evalsのスコアが大幅に改善される可能性があります。あるいは、OCR（光学文字認識）プロセスでわずかなステップを追加するだけで、契約書内の特定の情報を大規模にフィルタリングできるようになり、ユーザーのニーズに応えられるようになるかもしれません。

これらの改善は、LLMの基盤モデルをより大きくしたり、より複雑にしたりする話ではありません。それは、データソース、メタデータフィルタ、ルーティングロジック、あるいはユーザーへのツールの提示方法といった、AIアプリケーションを構成する「周辺要素」を強化することによって達成されます。

進捗 = 仮説の質 × 実験の速度

最終的に、AIアプリケーションにおける真の「進捗」は、以下の二つの要素によって決まります。

仮説の質 (Quality of Hypotheses): 明確なセグメンテーションとクラスター分析から生まれる、的確で質の高い仮説。
実験の速度 (Velocity of Experimentation): Fast Evalsとリアルタイム監視を通じて、これらの仮説を迅速にテストし、フィードバックを得る能力。

このデータ駆動型で体系的なアプローチは、より質の高い仮説、より迅速な実験、そしてリアルタイム分類による継続的なフィードバックを提供します。AIエンジニアが、このサイクルを回すことで、推測ではなくデータに基づいた意思決定を通じて、持続的に製品を改善し、真にユーザーに価値のあるAIアプリケーションを構築できるようになるのです。これは、AI製品だけでなく、あらゆる製品開発に適用できる普遍的な原則です。

まとめと今後の展望

現代のAIアプリケーション開発は、単に最先端のLLMモデルを導入するだけでなく、いかにデータを測定し、その洞察を製品改善に結びつけるかが成功の鍵を握ります。「測定できるものだけが管理できる」という原則は、AIの複雑な世界においても変わりません。

Jeff Huber氏とJason Liu氏が紹介したFast EvalsとKuraは、それぞれインプットとアウトプットの両側面からAIアプリケーションのデータを深く理解し、体系的な改善を促すための強力なツールとなります。

Fast Evalsは、公開ベンチマークの限界を乗り越え、あなたの独自のコーパスに対して高速かつ安価に、リトリーバルシステムの性能を評価することを可能にします。これにより、どのエンベディングモデルがあなたのデータに最適か、どのようなチャンキング戦略が効果的かを、データに基づき経験的に判断できます。
Kuraは、大量の会話データに隠されたユーザーの不満やニーズを、LLMの力で構造化された洞察へと変換します。これにより、手動では見つけられなかったパターンを発見し、製品の改善点や新機能開発の優先順位をデータ駆動型で決定できるようになります。

これらのツールと体系的なアプローチを組み合わせることで、AIエンジニアは「分析からアクションへ」とスムーズに移行し、単なるAIモデルの改善に留まらず、それを支える適切なインフラストラクチャを構築することの重要性を理解します。

Jason Liu氏の「スパイシーな見解」として、「エージェントビジネスは、使用されたトークンではなく、行われた作業、つまり成功と価値に基づいてサービスを価格設定しようとするだろう」という言葉は、このデータ駆動型の流れの先に、AIビジネスモデルの根本的な変革が待っていることを示唆しています。

AI技術はまだ若い分野であり、その開発プロセスも進化の途上にあります。しかし、データに基づき、体系的に測定し、学習し、改善するという原則は、今後もAIアプリケーションの持続的な成長と成功を支える盤石な基盤となるでしょう。あなたのAIアプリケーションを次のステージへと導くために、今日からデータの測定と体系的改善のアプローチを取り入れてみてはいかがでしょうか。