Launch HN: Laminar (YC S24) – サイレントエージェント障害を検出するモデルをトレーニングしました
要約
Laminarは、AIエージェントのトレースからサイレントな障害を検出するために、強化学習（RL）でトレーニングされたモデル「flow-1」をリリースしました。このモデルは、既存のモデルと同等の検出品質を持ちながら、コストを23倍削減できるため、サンプリングなしで全てのプロダクションエージェントトレースを分析することが可能になります。Laminarは、エージェントの挙動を理解し、エラーを特定・修正するループを容易にすることを目指しています。
全文翻訳
HNの皆さん、RobertとDinです。Laminar (https://laminar.sh) を開発しています。2024年からAIエージェント向けのオープンソース観測可能性（observability）を構築してきました。最近、エージェントのトレース内のエラーを見つけるためにRLでトレーニングされたモデル、flow-1をリリースしました。私たちのベンチマーク (https://laminar.sh/blog/flow-1) では、GPT-6-solと同等の検出品質を持ちながら、23倍安価です。これにより、サンプリングなしで、すべてのプロダクションエージェントトレースを分析することが手頃な価格で可能になります。
1分間のウォークスルーはこちらです: https://youtu.be/KJa3h6ZJNLQ
flow-1と他のモデルからのサンプルトレースと分析を含む投稿もまとめました: https://laminar.sh/blog/flow-1-in-action
エージェントの観測可能性の分野は混雑していますが、LaminarがXとどう違うかの箇条書きリストの代わりに、第一原理からエージェントの観測可能性をどのように解決しているかを説明します。
エージェントは現在、多くのステップを実行し、暗黙的に失敗します。エージェントは、すべての呼び出しが正常に完了する一方で、間違ったボタンをクリックしたり、間違ったドキュメントを引用したりする可能性があります。これらのエラーは、検出して理解する上で最も役立つものです。それらを見つけるには、エージェントが何をしようとしていたかを理解し、LLMの呼び出しとツールの結果を検査する必要があります。最終的なエージェントの出力を見るだけでは不十分です。
トレースを収集するだけでは、この問題は解決しません。多くのエージェント観測可能性プラットフォームは、依然としてデータコレクターが中心です。誰も読む時間がない、または価値を抽出できないトレースを保存するためにお金を払うことになるかもしれません。
トレースを検査するために別のLLMを使用することは、THEな解決策ですが、能力のあるモデルは大規模になると高価になり、安価なモデルはエラーを見逃したり、無関係なものをフラグ付けしたりすることがよくあります。
そこで、私たちはこの問題を正確に解決するためにモデルを構築しました。小さなOSSモデルをファインチューニングし、その後、ソフトウェア、法律、カスタマーサポートなどの現実的なエージェントワークフローの数千の合成調査でRLを使用してポストトレーニングしました。エージェントトレース分析に優れており、実行コストが非常に安いモデルを手に入れました。
flow-1は、Signalsと呼ばれるハーネス内で実行されます。これはコーディングエージェントとして機能し、エージェントトレースをリポジトリのように扱い、各スパン（LLM呼び出し、ツール呼び出しなど）をファイルとして扱います。これは、完全なエージェントトレースの圧縮された文字列表現とユーザープロンプトから開始し、スパン全体をgrepし、関連するものをフルで読み取ります。
Signalsの優れた点は、一般的なプロンプトに応答できることです。ユーザーの不満を特定するように依頼したり、ブラウザエージェントがチェックアウトを完了したかどうかを確認したりできます。これは生の検出エラーに限定されません。ユーザーが自由に定義できるスキーマとして、結果をJSONで返します。これらをシグナルイベントと呼びます。
すべてのトレースを分析すると、個々のイベントが多すぎて読めなくなります。そのため、類似のシグナルイベントを自動的にクラスターにグループ化します。繰り返し発生する問題とその発生頻度を確認し、個々のイベントとその背後にあるトレースをドリルダウンできます。
クラスターのトレースを使用して、そのタイプの失敗のための評価データセットを構築できます。その後、お気に入りのコーディングエージェントを使用して、これらの評価でヒルクライムを行い、本番環境にデプロイする前に、これらのケース全体で修正が機能することを確認できます。
トレース → 分析 → エラー検出とクラスター形成 → 修正 → リリース。このループを容易にすることが、Laminarを構築した理由です。
Laminarの他の部分にも同じ考え方を適用しました。私たちのブログ (https://laminar.sh/blog) では、エージェントが実際にどのように機能するかを詳しく見ることが、20倍のトレース圧縮、カスタムSQLクエリエンジン、自動タスク抽出の構築につながった経緯を説明しています。
LaminarはApache 2.0ライセンスで、セルフホスト可能です (https://github.com/lmnr-ai/lmnr)。私たちはマネージドクラウドから収益を得ています。
現在、エージェントのパフォーマンスをどのように追跡しているか、ぜひお聞かせください。ユーザーフィードバックと独自の監視から、それぞれどれだけ学んでいますか？そして、何かを修正したとき、それが別の失敗を引き起こしていないことをどのように確認していますか？