反復的なプロセスを採用してデータ エージェントを改善する

データ エージェントのチューニングは、1 回限り設定されるのではなく、実験、観察、絞り込みを含む継続的な反復的なプロセスです。

この記事では、データ エージェントの改善を開始するのに役立つベスト プラクティスについて説明しますが、すべてのデータ環境とユース ケースが一意であることを認識することが重要です。 特定の種類の命令、例、または書式設定が特定のデータセットに適しているか、エージェントがユーザーの質問をより正確に解釈するのに役立つ追加のコンテキストが必要な場合があります。 応答を評価するときは、エージェントの指示の修正、ベンチマーク セットの拡張、または混乱を解決したり精度を向上させるためにクエリの例を調整したりするなど、試行とエラーのサイクルを経る必要があります。 時間の経過とともに、このプロセスは、すぐには明らかではない可能性があるロジック、スキーマの配置、またはクエリフレージングのギャップを明らかにするのに役立ちます。 重要なのは、データ エージェントを、静的な構成セットではなく、定期的なテスト、フィードバック、反復によって改善される進化するシステムとして扱うことです。

手順 1: ベンチマーク セットから始める

エージェントの構成をガイドし、パフォーマンスを評価するためのサンプルの最初のベンチマークから始めます。 次の形式を使用します。

エージェントの評価の詳細については、データ エージェントの評価方法に関する記事を参照してください。

時間の経過と同時にベンチマーク セットを拡張し続けて、エージェントが処理する必要があるユーザーの質問の種類の範囲を広げることができます。

手順 2: 正しくない応答を診断する

データ エージェントから正しくない結果または最適でない結果が返された場合は、原因の分析に時間がかかります。 適切な障害点を特定すると、指示、例、またはクエリ ロジックをターゲットに改善するのに役立ちます。

レビューの一環として、次の質問をします。

• 必要な説明や指示がありませんか?
• 指示があいまいすぎるか、不明瞭か、誤解を招くか。
• クエリ例は不正確か、それともユーザーの質問を代表していませんか?
• スキーマの構造または名前付けについて、ユーザーの質問はあいまいですか?
• 値の形式が一貫性がない ( "ca" と "CA" 、 "Ca"など)、エージェントがフィルターを正しく適用しにくくなるか。

これらの各問題は、意図を解釈して正確なクエリを生成するエージェントの能力に影響を与える可能性があります。 それらを早期に特定することは、後の手順でより効果的な改良を導くのに役立ちます。

ステップ 3: より明確なエージェントの指示でより適切な推論を導く

エージェントが一貫して間違ったデータ ソースを選択したり、ユーザーの意図を誤って解釈したり、不適切な形式の回答を返したりする場合は、 エージェント レベルの命令 で絞り込みを必要とする兆候です。 次の手順を使用して、エージェントの理由に関する質問、データ ソースの選択、応答の書式設定を行う方法について説明します。

エージェントの指示を反復処理する場合:

• データ ソースの使用状況を明確にする: 特定の種類の質問に使用するデータ ソースと優先順位を指定します。 特定のソースを特定のコンテキストでのみ使用する必要がある場合は、そのことを明確にします。
• 想定される応答動作を定義します。 トーン、構造、詳細レベルに対する期待値を設定します。 応答を簡潔な概要にするか、表形式の出力を含めるか、行レベルの詳細を指定するかを指定します。
• エージェントの推論手順をガイドします 。質問を解釈するときにエージェントが従う必要がある論理フレームワークを提供します。たとえば、質問の言い換え、関連する用語の識別、トピックに基づくツールの選択などです。
• 用語について説明します。 あいまいな用語、ビジネス固有の用語、または一般的に誤解される用語の定義またはマッピングを含めて、エージェントがユーザーの質問をより正確に解釈できるようにします。

これらの手順を時間の経過と共に改善することで、エージェントは質問の解釈からクエリの実行、最終的な応答の書式設定まで、すべてのステップでより良い意思決定を行うことができます。

手順 4: データ ソースの指示を改善してスキーマの理解を向上させる

障害分析の分析情報を使用して、 データ ソースの指示を継続的に改善します。 複数の不適切な応答のパターンを探して、エージェントが意図を誤って解釈している可能性がある場所、スキーマの理解に苦労している、または正しいクエリ ロジックを適用できない可能性がある場所を特定します。

次の領域に注目して、構成を更新します。

• フィルターの使用状況を明確にする: 手順内でフィルターを適用するタイミングと方法を明示的に記述します。 たとえば、フィルターで完全一致、範囲、またはパターン マッチングを使用するかどうかを指定します。
• 一般的な値の例を追加します。 サンプル値と期待される形式 (たとえば、 "CA"、 "MA"、州の省略形の "NY" 、会計四半期の "Q1 FY25" など) を指定して、エージェントが正しくフィルター処理する方法を理解できるようにします。
• 一貫性を強化する: 用語、書式設定、言い回しが命令と例にまたがって一貫して適用されていることを確認します。 同じ概念において、省略形、大文字と小文字の使い方、または代替ラベルを混ぜないように注意してください。
• 進化するスキーマまたはビジネス ルールに基づいて更新します。 データ ソースに新しいテーブル、列、またはロジックが導入された場合は、それらの変更を反映するように手順と例を調整します。

これらの詳細を反復処理することで、エージェントは進化するデータとビジネス コンテキストに合わせて調整され、時間の経過と共により正確で信頼性の高い応答が得られます。

手順 5: 対象となる例を使用して正確なクエリ生成をガイドする

クエリの例は、エージェントが一般化し、正確な応答を生成する上で重要な役割を果たします。特に、結合、フィルター処理、複雑なロジックに関する質問に対しては役立ちます。 データ エージェントから正しくないクエリが返された場合は、例を見直して改良し、予想される構造とロジックをよりよく説明します。

次の機能強化に焦点を当てます。

• 結合ロジックを明確にする: エージェントが正しくない結合を生成している場合は、関連するテーブルの結合方法を明示的に示すクエリの例 (結合キー、結合の種類など) を含めます。
• 正しいフィルター パターン: 書式設定の詳細 ( LIKE '%keyword%'、日付範囲、大文字と小文字の区別の要件など) を含め、特定の列にフィルターを適用する方法を示します。
• 予想される出力を指定します。 さまざまな種類の質問に対してエージェントが返す必要がある列を明確にします。 これは、生成されたクエリの構造とフォーカスの両方をガイドするのに役立ちます。
• あいまいまたはオーバーロードされた例を絞り込みます。 一般的な例または過度に広範な例を、特定のユーザー意図を反映するより対象を絞ったクエリに分割します。
• 現在の命令とスキーマとの整合性を確認します。 スキーマ、ビジネス ルール、または命令形式に対する最近の変更を使用して、例を最新の状態に保ちます。

観察された問題に基づいてサンプル クエリを改善および拡張することで、エージェントにより強力な参照ポイントを与え、正確でコンテキストに対応した応答を生成できます。

手順 6: 参加の問題に対処する

結合ロジックは、クエリ生成の失敗の一般的な原因です。 結合エラーが原因でデータ エージェントが正しくないか不完全な結果を返す場合は、エージェントがデータの関連を理解するのに役立つ、より明確な構造ガイダンスと例を提供する必要があります。

結合の精度を向上させるには:

• ドキュメント結合のリレーションシップを明確に示します。 関連するテーブル、結合に使用するキー ( EmployeeID、 ProductKeyなど)、リレーションシップの方向 (一対多など) を指定します。 関連するデータ ソースの手順にこのガイダンスを含めます。
• クエリに結合の例を含めます。 最も一般的または複雑なリレーションシップの正しい結合動作を明示的に示すクエリ例を追加します。
• 結合テーブル間で必要な列を明確にします。 特に複数のソースに類似した列名が存在する場合に、どのフィールドからどのテーブルから取得するかを指定します。
• 必要に応じて簡略化します。 必要な結合が複雑すぎる場合やエラーが発生しやすい場合は、構造を単一の非正規化テーブルにフラット化してあいまいさを軽減し、信頼性を向上することを検討してください。

手順と例の両方で結合ロジックを適切に定義することで、エージェントはデータ構造をナビゲートし、完全で正確な回答を返す方法を理解するのに役立ちます。

次のステップ

• データ エージェントの概念
• データ エージェントのシナリオ
• データ エージェント構成の概要