Telemetry は、エージェントの動作を計測し、実際の結果を調べ、次の改善につなげる仕組みを提供します。判断の根拠となる SQL は、人が確認できます。
実際の結果 · 確認できる SQL · 人が検証できる判断
telemetry.shで計測し、デプロイして改善点を見つけ、修正の効果まで検証してください。
意思決定ループ
エージェントは最適化の前に計測を組み込みます。デプロイ後に成果を照会し、改善点を見つけて修正し、再デプロイして効果を確かめます。
エージェントに目標とガードレールを与えます。待ち時間やエラーを増加させることなく、チェックアウトの完了を改善します。
動作を変更する前に、結果を計測し、配信をテストし、イベント コントラクトをデプロイします。
結果をクエリし、機会を見つけて修正を配布し、再デプロイ後に結果が改善されたことを確認します。
意思決定の根拠
このループでは、エージェントがチェックアウトのリリースを比較し、遅い処理を修正して、p95の低下と完了率の改善を確認します。同じ流れを成長、信頼性、AI品質、コストにも使えます。
より良い意思決定
受け入れ率が下がるなら、高速化だけでは改善とは言えません。人への引き継ぎが増えるなら、安価なモデルにも意味がありません。Telemetryなら、成果とそのコストを一緒に判断できます。
SQL で OpenAI コストを追跡するリリース、プロンプト バージョン、モデル、ルート、ワークフローを、ユーザーが実際に受け取った結果と比較します。
同じクエリ内で品質、成功、レイテンシ、コストを維持できるため、最適化によってその欠点が隠れることはありません。
イベント コントラクト、SQL、結果、および警告は、決定を担当する人間に表示されたままになります。
測定する価値のある意思決定
推測の代償が大きい場所から始めましょう。ワークフローを、保守対象のダッシュボードではなく、再現できる検証ループに変えます。
このリリースでは、ハンドオフやコストを増加させることなく、成功した実行が改善されましたか?
1 ドル当たり最も受け入れられる結果を生み出すモデルはどれですか?
新しいリリースでは、テール レイテンシーを増加させることなくエラーが減少しましたか?
どのワークロードが停止していますか? 再試行が増加する前に何が変更されましたか?
どのオンボーディング変更によってアクティベーションが変更され、使用量が維持されたのはどれですか?
人間によるレビューに値するほど変化したアクセス パターンはどれですか?
成果、リリース、所要時間、ワークフローを安定したフィールドで記録し、変更前後を比較できるようにします。秘密情報や生のペイロードを除外し、安全で読みやすい根拠を残します。
telemetry.log("checkout_attempt_completed", {
attempt_id,
status: "completed",
duration_ms,
step,
release,
});人が参加するループ
“Telemetry を使用すると、ビジネスで何が起こっているかを追跡、分析、視覚化することが非常に簡単になります。”
“データの投入から実際にデータを理解するまでの最も簡単な方法の 1 つ。”
“それは簡単で、SQL ワークベンチは高速であり、事前にスキーマについて心配する必要はありません。”
検証ループを教える