このシリーズの最初の 3 つの記事に対する驚くべき反響を見て、私は第 4 部を発表せざるを得ませんでした。
前回の 3 つの記事では、会話 AI エージェントのパフォーマンス メトリックの定義、インストルメンテーション、スケーラビリティについて説明しました。前回の記事をまだご覧になっていない方は、次のリンクをご覧ください。
この記事では、これらのメトリックをより実用的なものにして(最新の LLM の進歩を利用して)、継続的にパフォーマンスを向上させる方法について説明します。目的は、この分野で働くすべての人にとって、議論をシンプルかつかなり高度なものにすることです。
ユーザーが認識したメトリクスとユーザーが報告したメトリクスは、ここで説明した 2 つの高レベルなメトリクス クラスです。従来、前者はシステム レベルのメトリクスと考えられており、これらのメトリクスはログから直接測定されます。その結果、ユーザーが認識したメトリクスは本質的に実行可能であり、したがって運用可能です。
運用メトリックは、運用ログから定期的に追跡され、チーム全体の OKR に関する目標設定に使用できます。
ただし、ユーザー認識指標は簡単に運用できますが、これらは「認識された」ユーザー指標であり、「実際の」ユーザー指標ではないことに注意する必要があります。その結果、これらの指標を徹底的に調査しても、会話型 AI エージェントに対するユーザー認識が大幅に改善されるとは限りません。これらのプロジェクトが複数の四半期にまたがる場合、リソース管理が非効率的になる可能性があります。
すべてのパフォーマンス改善の予想される影響を、ユーザーが報告した指標と直接比較して測定する方法が必要です。これは「北極星」の影響として扱われるべきです。では、問題は何でしょうか?
直接のユーザーからのフィードバックは構造化されていないことが予想され、実行可能ではなく、運用化も異なります。
詳細なユーザー報告フィードバックは、本質的に構造化されていない必要があります。ユーザー報告フィードバックを構造化すると、社内チームがすでに認識している領域に焦点が当てられる可能性があります。これらに加えて、ユーザー報告メトリックは、季節性や企業の認識などの要因によっても影響を受けます。
ユーザーが認識した指標への影響はより正確に推定できますが、ユーザーが報告した指標には制御できない要因が多数あります。
構造化されていないユーザー報告フィードバックは、実用的な構造化形式に変換する必要があります。構造化されていないフィードバックを既存のシステムレベルのメトリックに変換することを目的として、特定の ML モデルをトレーニングすることもできます。
これらのメトリックの固有の偏りを防ぐために、ユーザー報告メトリックの主な目標を「最近の」ユーザー メトリック回帰に使用する方が実用的である可能性があることに注意してください。より水平的な長期プロジェクトでは、これらのメトリックを使用して、システム レベルのメトリックとともにユーザーの認識への影響を測定する必要があります。
ここで疑問が残ります。私たちが求めている特定のメトリクスに合わせて ML モデルをトレーニングするには、どの程度の労力が必要でしょうか。最近、LLM の人気が高まり、利用できるようになったため、すぐに使用できる API を使用して、構造化されていないフィードバックを、システムレベルのメトリクスと同様に追跡および測定できるものに変換できる可能性があります。
LLM が処理できるトークンの数が増えると、多くの製品固有の情報が「プロンプト」自体の一部として提供される可能性があることに注意することが重要です。その結果、既製の LLM API といくつかのプロンプト エンジニアリングを組み合わせることで、実用的なユーザー レポート メトリックを提供できるようになります。
これにより、システムレベルのメトリック改善プロジェクトがユーザーの認識に与える影響を非常に迅速に評価できるようになり、パフォーマンス改善プロジェクトの優先順位付けに役立ちます。
構造化されたユーザー報告メトリックスのこのアプローチでも、予期しない変更が発生する余地はあります。ただし、特定のプロジェクト (システム レベルのメトリックスの改善を目的としたプロジェクト) が報告メトリックスにプラスの影響を与える場合、そのプロジェクトは実際にユーザーの認識を改善している可能性が高いと、ある程度の確信を持って推測できます。
ただし、実際に「良い」変更がすべて、ユーザー報告指標を常に効果的に改善するという保証はありません。そのため、パフォーマンス改善プロジェクトの優先順位付けと評価には、両方を組み合わせて使用することが重要です。