ロドリゴ・ディエゴ(Rodrigo Diego)はJuly 31, 2026、品質管理製品の文書検索Copilotが、特定の人物が作成した文書数を尋ねられた際に誤答したと報告した。データベース上の実数は84だったが、RAG Copilotは記録元ではなく、検索、フィルタリング、表示処理の後に見える文書から回答していた。

このCopilotはLangGraphとBedrockで構築されたマルチエージェントシステムだった。「Xが作成した文書」のようなメタデータ質問では、検索エージェントが文書サービスに問い合わせ、結果を再順位付けし、閲覧権限ゲートを適用し、複数の文書版を1枚のカードに統合し、最大30件を表示した。検索には妥当な処理だったが、「何件か」の意味を変えていた。SQLは真の合計84を持ち、検索は上限付きtop-k行を返し、権限チェックは表示可能な行を減らし、版統合は1文書の5版を1カードにし、最終表示集合は常に最大30だった。

この不具合はクラッシュより検出しにくかった。27件のような上限付き・重複排除済みの件数は、品質管理の業務では報告書に載せられそうな自然な数字に見えるためだ。ディエゴは、LLMが件数、合計、「最新」値のような集計を計算すべきではなく、記録元のシステムが計算し、モデルは結果を文章化するだけにすべきだと述べた。

文書サービスはフィルタ済みクエリごとに真の合計をすでに返しており、検索ノードはそれを`total_available_results`として保存していた。下流の権限ゲートノードは同じフィールドを別の意味、つまりユーザーに見せる閲覧権限適用済み・版統合済みカード数として再利用した。コメントには、5版が4文書になるようにUI件数は表示カードと一致すべきだとあったが、共有状態フィールドは上流では「データベース内の一致数」、下流では「画面上のカード数」を意味していた。

ディエゴの修正は、30カード上限と版統合の前に、文書サービスの真の一致合計を入れる別の権威的フィールド`total_matching_records`を追加した。既存の`total_available_results`は表示カードとページネーションに結び付けたまま残した。出力ノードは`total_matching_records`を使い、「Showing 5 of 84 matching documents」のようなユーザー向け見出しと、合計84文書が一致したと伝えるツールメッセージを生成した。

エージェントのプロンプトにも、「how many」質問では上限付きの表示カード数ではなく、ツールが報告した権威的な合計で答えるよう指示を入れた。ディエゴは、真の数字をエージェント文脈とUI見出しの両方に置く構造だと説明した。モデルが指示を無視しても、インターフェースには回答の横にデータベース件数が表示される。

変更を確認する3つのテストも追加された。表示件数より一致文書が多い場合は件数注記が出ること、すべての文書が表示される場合は消えること、内容のみのセマンティック検索では一切表示されないことを検証した。セマンティック検索のケースでは、類似度ランキング（意味の近さで並べる処理）が明確な一致集合を作らないため、正確な件数を示すと誤解を招く。

同じリリースでは、「last 10 daysに作成された文書」のような質問に関する日付バグも修正された。モデルは相対日付をフィルタに変換するため現在日付を必要としたため、ディエゴはLangGraphミドルウェアを追加し、すべてのモデル呼び出しに当日のUTC日付を注入した。ミドルウェアは、フィルタ作成前に「today」「yesterday」「the last 10 days」「since March」を具体的なISO-8601日付へ解決するようモデルに伝える。

このミドルウェアは、永続化された会話履歴には日付を追記しない。「today is 2026-07-30」のような保存済み行は、翌週に会話を再開すると古くなるためだ。ディエゴは残る制約として、モデルの本文が権威的な件数を使うことは強制されない点、内容のみの検索はなお表示件数にフォールバックする点、合計、平均、「どの著者が最多か」にはサービス側の本物の集計エンドポイントが必要な点を挙げた。

ロドリゴ・ディエゴ(Rodrigo Diego)はJuly 31, 2026、品質管理製品の文書検索Copilotが、特定の人物が作成した文書数を尋ねられた際に誤答したと報告した。データベース上の実数は84だったが、RAG Copilotは記録元ではなく、検索、フィルタリング、表示処理の後に見える文書から回答していた。

このCopilotはLangGraphとBedrockで構築されたマルチエージェントシステムだった。「Xが作成した文書」のようなメタデータ質問では、検索エージェントが文書サービスに問い合わせ、結果を再順位付けし、閲覧権限ゲートを適用し、複数の文書版を1枚のカードに統合し、最大30件を表示した。検索には妥当な処理だったが、「何件か」の意味を変えていた。SQLは真の合計84を持ち、検索は上限付きtop-k行を返し、権限チェックは表示可能な行を減らし、版統合は1文書の5版を1カードにし、最終表示集合は常に最大30だった。

この不具合はクラッシュより検出しにくかった。27件のような上限付き・重複排除済みの件数は、品質管理の業務では報告書に載せられそうな自然な数字に見えるためだ。ディエゴは、LLMが件数、合計、「最新」値のような集計を計算すべきではなく、記録元のシステムが計算し、モデルは結果を文章化するだけにすべきだと述べた。

文書サービスはフィルタ済みクエリごとに真の合計をすでに返しており、検索ノードはそれを`total_available_results`として保存していた。下流の権限ゲートノードは同じフィールドを別の意味、つまりユーザーに見せる閲覧権限適用済み・版統合済みカード数として再利用した。コメントには、5版が4文書になるようにUI件数は表示カードと一致すべきだとあったが、共有状態フィールドは上流では「データベース内の一致数」、下流では「画面上のカード数」を意味していた。

ディエゴの修正は、30カード上限と版統合の前に、文書サービスの真の一致合計を入れる別の権威的フィールド`total_matching_records`を追加した。既存の`total_available_results`は表示カードとページネーションに結び付けたまま残した。出力ノードは`total_matching_records`を使い、「Showing 5 of 84 matching documents」のようなユーザー向け見出しと、合計84文書が一致したと伝えるツールメッセージを生成した。

エージェントのプロンプトにも、「how many」質問では上限付きの表示カード数ではなく、ツールが報告した権威的な合計で答えるよう指示を入れた。ディエゴは、真の数字をエージェント文脈とUI見出しの両方に置く構造だと説明した。モデルが指示を無視しても、インターフェースには回答の横にデータベース件数が表示される。

変更を確認する3つのテストも追加された。表示件数より一致文書が多い場合は件数注記が出ること、すべての文書が表示される場合は消えること、内容のみのセマンティック検索では一切表示されないことを検証した。セマンティック検索のケースでは、類似度ランキング（意味の近さで並べる処理）が明確な一致集合を作らないため、正確な件数を示すと誤解を招く。

同じリリースでは、「last 10 daysに作成された文書」のような質問に関する日付バグも修正された。モデルは相対日付をフィルタに変換するため現在日付を必要としたため、ディエゴはLangGraphミドルウェアを追加し、すべてのモデル呼び出しに当日のUTC日付を注入した。ミドルウェアは、フィルタ作成前に「today」「yesterday」「the last 10 days」「since March」を具体的なISO-8601日付へ解決するようモデルに伝える。

このミドルウェアは、永続化された会話履歴には日付を追記しない。「today is 2026-07-30」のような保存済み行は、翌週に会話を再開すると古くなるためだ。ディエゴは残る制約として、モデルの本文が権威的な件数を使うことは強制されない点、内容のみの検索はなお表示件数にフォールバックする点、合計、平均、「どの著者が最多か」にはサービス側の本物の集計エンドポイントが必要な点を挙げた。