Microsoft Research の Semantic Telemetry プロジェクトは、毎週数億件規模の Bing Chat 対話ログをサンプリングし匿名化して、LLM を活用してユーザー専門性、主トピック、満足度といったメトリクスを自動分類し、リアルタイムかつ高スループットに分析するパイプラインを構築しました。Microsoft が実践する数億件規模のデータ処理手法から得られるインサイトが、皆さんの取り組みの一助となれば幸いです。

具体的な分析内容

分類モデルの構築

LLM に対話内容を要約させ、それをもとに分類ラベルのタクソノミー（分類体系）を生成し、反復的に改良を重ねている。

主な分類項目
- トピック（Topics）：チャット全体の主要トピックを一つラベル付け
- タスクの複雑さ（Task Complexity）：例「情報検索」vs「複数のアイデアを評価する」など。低複雑度と高複雑度の2つのカテゴリに分類
- ユーザーの専門知識レベル：Novice～Expert の5段階
- AI の専門知識レベル：上記と同様の分類
- ユーザー満足度：LLM による 20 項目の評価をまとめたスコア

得られた知見

職業的・専門的な複雑タスクほど、ユーザーの継続利用傾向が高い
初心者ユーザーも高難度タスクへ急速に適応している（2024年1月の36% → 8月には67%へ）
専門家ユーザーは、AI が同等レベルの知識を持つ場合にのみ満足度が高い。一方、初心者の満足度は AI の専門知識に関わらず低い傾向

1. 課題

分類パイプライン設計には、以下のような技術的課題が存在した。

大規模処理の必要性：毎週数億件のチャットログを処理するための分散処理基盤が不可欠
高信頼性と汎用性：LLM エンドポイントの遅延や不安定性に耐える堅牢なオーケストレーションが求められる
プロンプトとトークンの最適化：コスト、レイテンシ、精度を両立させるためのバッチ戦略やトークン削減が重要
モデル切り替え対応：将来的なモデル更新にも柔軟に対応するプロンプト設計が必要

2. 解決策（概要）

ハイブリッド処理エンジン（PySpark + Polars）により、大規模ジョブと軽量ジョブの切り替えを同一コードベースで実現。
LLM 分類レイヤーがモジュール化され、専門性・トピック・満足度など複数分類を柔軟に追加可能な構造を提供。
パイプラインの安定性を確保するために、バッチ／非同期処理、スループット制御、プロンプトクレンジングなど多重対策を導入。

アーキテクチャ

3. 技術ブレークダウン

3.1 ハイブリッド処理基盤：PySpark ＋ Polars

PySpark による並列・分散処理で大量データを高速処理。
Polars による軽量ジョブを小規模環境で高速実行可能。
両者を同一 API 層で切り替える設計。Spark環境／非Spark環境の両方に対応可能。

3.2 LLM 中心の変換レイヤー

モデル非依存（model‑agnostic）なインターフェースを中心に設計。
Prompty 言語仕様でプロンプトテンプレートを統一管理し、柔軟性を確保。
出力の整形・クリーニング処理も組み込み、誤分類やフォーマット不整合に対応。

3.3 LLM エンドポイントのレイテンシと変動性

リモートでホストされている LLM エンドポイント（例：Azure OpenAI）では、モデルの負荷、プロンプトの複雑さ、ネットワーク状況の変動により、レイテンシが予測不能になることがある。その結果、パイプライン全体で安定したスループットを維持することが難しいという課題があった。

解決策

複数エンドポイントのローテーション運用
Azure OpenAI の複数エンドポイントを循環的に利用してワークロードを分散し、スループット向上と負荷均等化を図った。
出力の定期保存による耐障害設計
ネットワークエラーが発生した場合でも、出力データを一定間隔で非同期保存し、状況に応じて安全に処理を継続可能。
高スループットモデルの選定
gpt-4o-mini のように、1 分間に処理可能なトークン数（TPM）が高いモデルを使用した。たとえば、GPT-4（80K TPM）と比較して gpt-4o-mini（2M TPM）は25倍のスループット増となる。
指数バックオフによるタイムアウト・再試行機構
タイムアウト発生時には指数的に待機時間を延ばすバックオフ処理を取り入れ、再試行の安定性を向上させた。

＋α 検討項目

3.4 進化する LLM モデルと迅速な調整

Phi、Mistral、DeepSeek、GPT-4o／GPT-4.1／GPT-5 など、新たな LLM モデルが登場するたびに、分類の精度や出力形式、プロンプト解釈に微妙な変化が生じる。そのため、モデル更新のたびにベースラインとの整合性を保ち、一貫した結果を提供することが継続課題であった。

解決策

少量サンプルによる新モデルの初期テスト
新モデルを使って代表的なサンプルを処理し、出力の分布が既存ベースとどう一致するかを確認した。
分布の一致／不一致に応じたスケール調整
出力分布が十分に一致していれば規模を拡大。それ以外の場合はプロンプトを調整し、再テストを実施した。
柔軟な解釈の導入
出力分布の変化は必ずしも後退ではなく、モデル自体が改良された結果、より精緻でニュアンス豊かな分類が可能になる場合もあると認識し柔軟な評価を実施した。

3.5 LLM 呼び出しの動的同時実行スケーリング

LLM エンドポイントは、高負荷時にレート制限にかかったり応答時間が不安定になったりする。また、デフォルトの同時実行設定が最適でない状況も多く、最適な並列度の判断が困難な状況が続いていた。

解決策

外部システムの並列タスク数を参照に初期設定
Spark のエグゼキューターや非同期ワーカーなど、パイプライン全体で走っているタスク数を参考に、同時実行数の初期値を決定した。
成功率／失敗率に基づく動的調整
LLM 呼び出しの成功率・失敗率を継続監視し、失敗が増えれば一時的に並列度を下げ、成功が安定すれば徐々に上げる制御を採用した。
レイテンシを用いたフィードバック制御
レート制限エラーを待つのではなく、応答時間そのものを測定。レイテンシが上昇したときは並列度を落とし、レイテンシが改善し成功率が高ければ慎重にスケールアップした。

4. 最適化実験

スループットと効率性を向上させるため、複数の最適化戦略を比較・実験した。各アプローチにはトレードオフが伴うため、慎重に評価した。

4.1 Azure OpenAI Batch API

バッチエンドポイントでは、LLM プロンプトをまとめて処理し、レスポンスをファイルに書き出すことで、高い費用対効果と中〜高スループットを実現。

メリット
- 非バッチエンドポイントと比べ、約50%のコスト削減
- トークン制限を考慮した専用処理により、最適化された処理が可能
デメリット
- 処理完了までに最低 24 時間を要し、即時性には不向き
- 全体スループットは非バッチよりも低め

4.2 プロンプト内での会話バッチ処理

複数会話を 1 つのプロンプトで分類することで、スループット向上とトークン使用量の削減を実現。

メリット
- 扱うトークン数とリクエスト回数の両方を削減可能
デメリット
- 精度劣化のリスクあり（例：10件を同時分類した場合、ドメイン分類が平均15〜20%変動）
- 精度維持のために「採点用プロンプト＝Grader LLM」による誤分類検出と再分類を併用することで改善可能

4.3 分類器を単一プロンプトに統合

複数分類器を 1 つのプロンプトにまとめて一度に処理することで、スループットと効率化を目指す。

メリット
- 呼び出し回数削減によるスループット向上
- 会話テキストの送信回数減少によるトークン使用削減
デメリット
- 精度低下の可能性があるため、結果のモニタリングが重要

4.4 テキスト埋め込みを用いた分類

会話の埋め込み（例：text-embedding-3-large）を取得し、複数の分類器用に再利用するニューラルモデル（MLPなど）をトレーニングするアプローチ。scikit-learn でロジスティック回帰と MLPClassifier の両方を比較する等。

メリット
- LLM への複数リクエストが不要になり、スループットとコストを大幅削減
- 埋め込みは会話ごとに 1 回取得すれば分類器間で共有可能
デメリット
- GPU などの追加インフラが必要になる可能性あり
- プロンプトベースの分類と同等の精度が得られない可能性

4.5 プロンプトの高速圧縮（Prompt Compression）

不要トークンを除去したり、LLMLingua のようなツールを用いてプロンプトの長さを自動圧縮し、効率化を図る。SAMMO を用いてプロンプトを単なるテキストではなく、構造化されたメタプロンプト（metaprompt）として扱い、構成要素の削除・置換・圧縮などを行いながら最適化することもできる。

メリット
- トークン数削減によるスループット向上とコスト削減
デメリット
- 圧縮により分類精度が損なわれる可能性
- 圧縮処理のオーバーヘッドがある場合、逆にスループットが低下するリスク

4.5.1 プロンプト最適化：SAMMO の活用

SAMMO（Structure‑Aware Multi‑objective Metaprompt Optimization）は、プロンプトを構造化された「メタプロンプト」とみなし、コンパイル時に構造最適化を行うフレームワーク
プロンプトを関数グラフとして扱い、冗長要素の削除やパラメータ調整などを自動実行。また、精度と効率（トークン長等）を同時に最適化できる マルチオブジェクティブ設計

SAMMO により、複数のモデルとプロンプトのバリエーション間で出力を比較できるようになった。プロンプトの変更やモデルのアップグレードの影響を定量化し、新しいモデルを導入するタイミングや分類スキーマを調整するタイミングについて、情報に基づいた意思決定が可能になった。

あとで SAMMO を使った実践的なプロンプト最適化を試してみる予定。

4.6 テキストの切り捨て（トランケーション）

プロンプトに含まれる会話を一定長に切り詰めることで、送信トークン数を制限。

メリット
- TPM 制限前により多くのリクエストが送信可能
- コスト削減と効率向上を両立可能
デメリット
- 最適な切り詰め長は分類器や会話内容に依存するため、精度への影響を事前評価する必要あり
- 会話の重要な部分が切り落とされ、分類精度が落ちる可能性もある

各アプローチは、スループットとコスト効率を向上させる可能性を持つ一方で、分類精度の低下や処理遅延などのリスクも伴う。運用シナリオに応じて、トレードオフを意識しながら適切な戦略を選び、モニタリングと調整を行うことが重要。

次回

今回示された様々なアプローチをコードレベルで実証してみる。

参考