競合する古いドキュメントを使用して RAG システムをテストする

エンタープライズ検索は常にクリーンであるとは限りません

EnterpriseRAG には、検索ノイズとともに、事実の矛盾や知識のギャップが明示的に含まれています。その 2026 年のプレプリントは、個々の制約を満たすことで、それらを一緒に満たすことができないことを隠してしまう可能性があると報告しています。実際的な意味は、ベンチマークで報告された結果を独自の調査条件内に保ちながら、要件の組み合わせに対するテストを作成することです。

証拠: EnterpriseRAG: 非理想的なエンタープライズ検索下での LLM 命令の準拠性と堅牢性のベンチマーク [1]

最初にソース解決ポリシーを作成します

各タスクに対してどのソースが信頼できるか、およびバージョンがどのように解釈されるかを決定します。より新しいドラフトは、承認されたポリシーに優先することはできません。地域別の補遺は、特定のユーザーに対してのみ一般規則をオーバーライドする場合があります。モデルが文言から推測することを期待するのではなく、可能であればこれらの関係を取得可能なメタデータにエンコードします。

発行日、発効日、取得時刻を区別します。彼らはさまざまな質問に答えます。今日公開された文書には、次の四半期に発効するルールが記載されている可能性があります。評価参照には、ユーザーのリクエストに関連する日付を指定する必要があります。

制御された競合ケースを構築する

Rubrex では、サポートされている明確なケースから始めて、一度に 1 つの競合を導入することをお勧めします。古いバージョン、署名のないドラフト、地域固有の例外、または発効日のない文書を追加します。タスクが実際の検索に似ているように、妥当な形式を維持します。

システムを実行する前に、予想される動作を定義します。場合によっては、承認された現在のポリシーを選択する必要があります。場合によっては、どの日付または地域が適用されるかを尋ねる必要があります。場合によっては、意見の相違を表面化して延期する必要があります。常に決定的な答えが得られるテストでは、適切な不確実性が抑制されます。

実例: ドラフトの方が新しい

サポート アシスタントは、現在の返金ポリシーと、より寛大な条件を含む新しい草案を取得します。最新のタイムスタンプがあるため、ドラフトが選択されます。この障害は、単にデータが古いという問題だけではありません。それは、承認状態と最新性の区別が欠けていることです。

メタデータを認識した取得変更またはソース選択ルールをテストします。新しいドキュメントが実際に承認された代替ドキュメントであるコントロールを含めます。そうしないと、常に古いドキュメントを優先する修正が元の例を通過し、別のクラスのエラーが発生する可能性があります。

紛争の証拠を読み出しに保存する

ソースのバージョン、権限の仮定、予想される解決策、および実際の回答を記録します。サポートされていない解決策は、明示的な拒否や説明の要求とは別に追跡します。目標は、アシスタントが不確実性を適切に処理しているかどうかを理解することであり、中断することなく回答する質問の数を最大化することではありません。

よくある質問