すべてを収集せずに LLM 生産ドリフトを監視する

研究と文書の内容

2026 年 8 月のプレプリントである ProxyDrift では、インタラクションの構造化された要約を使用して、ライブ トラフィックとテスト セットを比較する方法を研究しています。これらの概要は、生のインタラクションへの直接アクセスの代わりになります。 LangSmith のドキュメントでは、ライブ実行のスコアリングとオフライン テスト セットへの例の追加について説明しています。これらは異なるアプローチです。どちらも、監視設定がプライバシーを保護したり、あらゆる種類のユーザー要求をカバーしたりすることを証明するものではありません。

証拠: プロキシ表現を介した大規模 LLM アプリケーションのプライバシー保護データ ドリフトの検出と回復 [1]ラングスミスの評価 [2]

3種類の変化を見る

入力ドリフトは、リクエストが変更されたことを意味します。ユーザーはさまざまなタスクを依頼したり、新しい言語を使用したり、より長い文書を送信したりすることがあります。結果のドリフトとは、エラーが増えたり、回答が遅くなったりするなど、結果が変化したことを意味します。測定値のドリフトは、採点プロセスが変更されたことを意味します。新しい審査員、採点ガイド、サンプリング ルールによって数値が変動する可能性があります。これらの変更を個別に記録します。

失敗率が高いということは、受信するタスクがより困難であることを意味する可能性があります。必ずしもモデルが弱いというわけではありません。簡単なリクエストと難しいリクエストのバランスがとれている場合、平均が変わらないことで問題が隠れる可能性もあります。言語やタスクの種類など、製品にとって重要なグループを比較します。各スコアの背後にある例の数を表示します。

集中的な監視記録を維持する

Rubrex では、各アラートがサポートする必要がある決定から始めることをお勧めします。ツールのタイムアウトを調査するには、ツール名、時間、エラーの種類、およびソフトウェアのバージョンが必要になる場合があります。ユーザーメッセージ全体が必要ない場合もあります。答えが正しいかどうかを確認するには、ソース文書が必要になる場合があります。誰がそのデータにアクセスできるのか、いつ削除する必要があるのか​​について合意します。

ラベルや埋め込みなどの数値ベースの表現には、依然として機密情報が含まれている可能性があります。個人情報を明らかにしているかどうか、または個人と関連付けられる可能性があるかどうかを確認してください。ライブ ユーザー データを公開サンプルに含めないでください。失敗を説明するときは、架空の例を使用するか、機密性の高い詳細を削除してください。変換されたデータは、自動的に安全に共有できるわけではありません。

例: スキャンされた文書により新たな障害が発生する

新しい統合が開始された後、購買アシスタントがスキャンされたドキュメントの受信を開始するとします。モデルは変更されていませんが、システムはテキストを抽出するのに苦労するようになりました。古いテスト セットではクリーンなデジタル テキストが使用されています。実際のユーザーにはさらに多くの失敗が見られますが、それでも問題は解決されません。

まず、確認が許可されている例を使用して、抽出が失敗する場所を確認します。参照テキストをチェックして、スキャンしたドキュメントを別のテスト グループに追加します。次に、抽出ステップと最終的な答えをテストします。すぐに変更しても、欠落しているソーステキストは修正されない可能性があります。新しいテストを警告信号として信頼する前に、新しいテストが実際の問題を捉えているかどうかを確認してください。

すべてのアラートに次のステップを与える

各アラートの所有者に名前を付けます。しきい値が重要な理由と、所有者が最初に何を確認する必要があるかを説明します。誤ったアラームと、アラートが見逃したインシデントを確認します。実際の障害がテスト ケースになったら、その障害がどこから発生したのか、何が起こるべきか、どのテスト セットのバージョンにその障害が含まれているかを記録します。新旧の結果を比較するときは、トラフィックとスコアリング ルールの変更に注意してください。

• アプリケーション、テストセット、ジャッジ、およびサンプリングのバージョンを記録します。
• 各タスク グループ内および全体の品質を比較します。
• アラートをトリガーするケースとともに広範なサンプルを確認します。
• 生データおよび派生ラベルのアクセスおよび削除ルールを確認してください。

インシデント時にダッシュボードを役立つようにする

モニタリングでは、選択した信号が時間の経過とともにどのように変化するかを示します。可観測性は、信号を要求、システム設定、または依存関係まで追跡するのに役立ちます。評価では、結果がユーザーのニーズを満たしているかどうかを確認します。 Rubrex では、これらのレコードを実行 ID に接続することをお勧めします。製品の同意されたデータ ルールに従って、調査に必要なデータのみを保持します。

1 つのアラートに最初から最後まで従ってみてください。チームは影響を受けるケースとソフトウェアのバージョンを見つけることができますか?誰かがその失敗を、別のエンジニアが再実行できるテストに変えることができるでしょうか?各傾向の横にサンプル数、欠落した結果、重大な失敗、スコアの定義を表示します。修正後、テストを再実行し、結果が改善されたかどうかを確認します。ダッシュボードは、誰かが次に何をすべきかを決定するのに役立ちます。

よくある質問