LLMトレースをクラスタリングするのにLLMは必要ない

OpenAI互換ゲートウェイを十分な時間実行すると、見た目は異なるが同じプログラムであるトレースに溢れかえることになる。同じJSONスキーマ、同じ「回答スパンを返す」、同じ「この発行体名を正規化する」——異なる企業、金額、文だが、契約は同一である。これがSeldonの根底にある仮定だ：それらのプログラムを見つけ出し、繰り返しをより安価な決定論的パイプラインにコンパイルする。この投稿は、そのループの前半部分——Trace Audit——と、それを大規模にストレステストした際に学んだことについて述べる。

コンパイルは、まず正確な質問に答えられる場合にのみ機能する：どのトレースが同じ置き換え可能なプログラムなのか（単に同じトピックではない）？私たちはTrace Audit v0でその答えを構築し、12,517のトレースで測定し、モデルよりも多くのことを教えてくれた間違いを保持した。Auditは物語の半分に過ぎない：クラスタが存在すれば、Seldonはそれらを制限された形式のプログラム合成の仕様として扱う。以下でそのコンパイルステップを概説する；詳細なフォローアップ投稿で合成器について深く掘り下げる予定。

TL;DR。最初にハードコントラクトブロック、次に短い決定論的特徴文字列（embedding_text）に対するブロックローカルDBSCAN。ペア精度/再現率/純度で1.000/0.9999/1.000を達成し、モデルコストはほぼゼロ。ライブ要約器（GPT-4.1、GPT-5.6-luna、Phi-4）はクラスタリングに役立たず、純度を損なった。LLMはクラスタリングの信号としてではなく、クラスタリング後のラベルと報告書に使用すべき。

LLM製品を出荷するチームにとってこれが重要な理由：多くのチームは、プロトタイプの抽出、分類、正規化の最速の方法としてフロンティアモデルから始める。その後、ボリュームが現れ、呼び出しの大部分が同じ形状を何度も繰り返すようになる：ドキュメント/チケット/レコード→同じプロンプトテンプレート→同じresponse_format/出力形状→異なるペイロード。あなたはプロンプトをまとったETLに推論価格を支払っている——多くの場合、血統がなく、どのワークフローが支出を支配しているかのランク付けビューもなく、モデルから安全に脱却する道もない。

Seldonのループは意図的に退屈だ：見る（ゲートウェイトラフィック→契約互換クラスタ→節約額でランク付けされたワークフローマップ）、コンパイルする（より安価なパイプラインを再生産するクラスタを検索するための型付き演算子ライブラリを探索）、信頼する（トレースに対するシャドウ検証、自動LLMフォールバック、品質低下時の格下げ）。Trace Auditはステップ1である。バケットを間違えると、下流のすべてが架空のものになる。

間違った直感（そしてそれがどこにでもある理由）：「自分のLLMトラフィックを理解する」ための流行のパイプラインは、埋め込みとLLM要約を使用するものだ。コンパイラにとって、これは間違った目的関数である。「これらのトレースは請求書について話している」ではなく、「これらのトレースは同じコンパイル可能な抽出プログラムである」を求めている。プログラムの同一性≠文書の類似性。

Trace Audit v0の仕組み：合成の前に、Auditはトラフィックを契約互換クラスタに分割する必要がある。誤った統合は合成を毒する——混合仕様に対して検索することになる。誤った分割は節約を隠す——ボリュームに気づくことはない。

パイプライン：最初にコントラクトブロックを定義する（ワークスペース、ロールシーケンス、応答モード、スキーマ、ツールシグネチャ、出力形状、JSONキー、IOコントラクトバケットをハッシュ）。生のプロンプト長はブロックキーに意図的に入れない。長さはペイロード属性であり、置換可能性の制約ではない。次に、embedding_text（タスクシグネチャ| roles=... | mode=... | shape=... | keys=... | hints=...、変数エンティティは意図的に折りたたまれる）に対してブロックローカルDBSCANを実行する。これがプログラムをクラスタリングしているのであり、ドキュメントではない。

私たちはリアルなOpenAI形式のスイートを構築し、各公開学習分割の約10％と小さなキュレートファミリーを追加した：Banking77（意図）1,000、SQuAD（スパン抽出）8,759、CoNLL-2003（エンティティ→ID）1,404、STS-B（ペア類似度）574、GSM8K（数値回答）747、キュレート請求書/発行体/散文各10、敵対的「ブリッジ」トレース3。合計12,517トレース。小さすぎる/全散文ブロックをスキップした後、12,504トレースが対象となった。

同じブロック、対象ガード、コサインカットオフ（約0.82/eps=0.18）の下で比較した：embedding_text + ブロックローカルDBSCAN、決定論的要約 + DBSCAN、GPT-4.1要約 + DBSCAN、GPT-5.6-luna要約 + DBSCAN、Phi-4要約 + DBSCAN。結果：embedding_text + DBSCANが1.000/0.9999/1.000で勝利。LLM要約は純度を低下させた（GPT-4.1 0.920、Luna 0.920、Phi-4は1.000だが再現率0.771）。

モデルよりも重要だった2つのバグ：入力長バケット（短/中/長）が同一のワークフローをプロンプト長で分割していたため削除。数値がスパンとして抽出されるタイピングが過剰に積極的だったため、プロンプトが抽出を示し、数値が入力内で完全なトークンとして現れる場合のみ再分類するよう修正。修正後、再現率は精度損失なく約0.999に上昇した。

同じ類似度カットオフで密度クラスタリングと相互kNN連結成分を比較した。DBSCANはより多くの再現率を回復。相互kNNは、語彙/テンプレートエッジを追加しない限り、密なブロックで接続不足になり、それが誤った統合を生み出し純度を損なった。コントラクトブロック内の密度が正しい帰納的バイアスである。

Seldonが誠実である方法：コンパイルできないものを拒否し、コンパイルできるものを検証し、品質が低下したらフォールバックする。次は、クラスタダッシュボード→ファミリーラベルA–G/非コンパイル可能→ランク付け節約マップ→合成への引き渡し。LLMはそのダッシュボード/提案ステップに属し、分割には属さない。

開発者が気にするべき理由：LLMゲートウェイ/ルーター、評価または可観測性スタック、またはトレースからの内部「自動ETL」プロトタイプを構築している場合、デフォルトのML直感（プロンプト/要約の埋め込み）は間違った類似性に対して最適化している。コントラクトファーストのTrace Auditは、Seldonがゲートウェイトラフィックをコンパイル可能な節約のランク付けマップに変換する方法である。

注意点：ラベルはコントラクトファミリーと整合したワークフローIDであり、部分的に自己充足的。キュレート行はテンプレート循環。Phi-4はAIコスト制御のために打ち切られた。