検索/AIに記憶を持たせる検索システムを、公平にテストして比べる

AIに記憶を持たせる検索システムを、公平にテストして比べる

AIエージェントに合う検索や記憶のシステムを確かめる時に使う。テストの前に何を確かめるかを書き出し、設定一式で公平に比べ、少なく使う時から多く使う時までのお金を見積もり、保存した結果が混ざらないようにして、実行ごとの記録を全部残す。

このAIルールを使うには
## テストの結果で言える事だけを結論にする システム全体に関する主張と、個別機能に関する主張を区別する。検索システム全体が最良だと主張するには、検索品質、長文脈メモリ、較正、信頼性、費用、運用時の挙動を横断する証拠が必要になる。単一の機能やベンチマークだけでは立証できない。 機能を評価する時は、その機能がシステム利用者に有意義な価値をもたらすかを問う。製品判断が利用者の成果に依存する場合、ある独自アルゴリズムが別のアルゴリズムより優れていることの証明だけに評価を費やさない。 実験前に、主張、分析単位、期待する効果、判断しきい値、結果を一般化できない条件を書き出す。検証した母集団、作業負荷、エンジン、設定より広い範囲へ結論を拡張してはならない。 ## データベースと、その中の情報源を分けて選ぶ 知識のルーティングを、互いに独立した2つの軸でモデル化する。 - 保存領域とアクセス方針を所有するコーパスまたはデータベース - そのコーパス内の情報源またはコレクション 呼び出し単位の入力、認証済みの許可、セッション文脈、リポジトリマーカー、利用者設定、既定値などを並べた明示的な優先順位で、両方の軸を解決する。暗黙の誤ルーティングを診断できるよう、解決後の値を各クエリとともに記録する。 リモートまたはエージェント向けの呼び出し元は、信頼が明示的に確立されない限り信頼しない。すべての読み取り経路に対して、1つの共有ヘルパーから情報源の範囲を適用する。個々のクエリでフィルターを組み立てない。結合やキー構築に識別子を使う前に検証し、情報源の範囲をすべて含むキーへ一意性を定義する。 ## 検索モードを、設定一式まるごとで比べる 名前付きモードは、キャッシュ方針、トークン予算、クエリ拡張、関係検索、意図の重み付け、結果件数上限をまとめた一貫した構成として定義する。設定は1つの決定的な優先順位で解決し、呼び出し単位の上書きをデプロイ設定より優先し、フォールバックを文書化する。 利用者が選ぶ完全なモード同士を比較し、都合のよい調整項目だけを抜き出さない。すべての調整項目について、有効な値とその取得元を報告する。モード解決は最下層の共有検索経路へ適用し、本番クエリと評価時の再実行が同じ挙動を通るようにする。 新しい検索分岐を認識済みのクエリ種別だけに適用する場合は、決定的な挙動にし、それ以外では何もしない。システム全体の既定値を変えずに制御実験できるよう、クエリ単位の上書きを用意する。 ## 実際に使う量で、かかるお金を見積もる 下流工程の費用は、クエリ量、供給されるコンテキストのトークン数、モデルの入力価格、拡張呼び出し、キャッシュヒット率から計算する。少なくとも軽量、標準、高負荷の利用水準を示し、単一クエリから外挿しなくても結果を拡大換算できるようにする。 分離したクエリ単位の費用と、実際のエージェントループ全体の支出を分ける。プロンプトキャッシュ、検索キャッシュのヒット、接頭辞の変動、繰り返されるツール呼び出しにより、実現する総額は大きく変わり得る。削減効果が実測、仮定、対象外のどれに当たるかを明示する。 検索モードと下流モデルを組み合わせて評価する。過大なコンテキストは能力の低いモデルを圧迫し、高価なモデルでも予算が厳しすぎれば情報不足になる。自然な組み合わせを優先し、不適切な組み合わせは、費用順位へ埋め込まず別個の失敗形態として示す。 ## テストの前に、何を測ってどう判定するかを決める 報告する各指標について、機械可読な結果とともに平易な定義を提示する。指定順位までの適合率、割引累積利得、逆順位、重なり、較正、待ち時間、費用などの用語には、1つの正本となる用語集を使う。 結果を収集する前に、データセット、サンプル選択、期待する方向、主要指標、妥当性への脅威、除外規則を指定する。対応のある比較には、対応を維持する再標本化手法を使い、複数の指標や構成を検定する場合は多重比較を補正する。 人が読める要約と構造化メタデータの両方を保存する。個々の値の横に場当たり的な用語集フィールドを追加せず、応答ごとに1つの統一されたメタデータブロックを付け、下流ツールが確実に解析できるようにする。 ## 質問の振り分けのテストを、だれでもやり直せる形にする 学習用フィクスチャと、評価まで保持する未使用フィクスチャを分ける。書式の違いが意味的に正しいルーティングを見えにくくする場合は、厳格基準と明示的に文書化した寛容基準の両方で採点する。ただし、未使用データの結果を見た後で基準を変えてはならない。 モデルをまたぐ各実行では、モデル識別子、プロンプトテンプレートのハッシュ、フィクスチャのハッシュ、評価基盤のリビジョン、時刻、採点バージョンを結び付ける受領記録を保存する。生の予測結果も保持し、モデルを有料で再実行せずに採点ロジックを改善または監査できるようにする。 重要な役割を担う信号を特定するため、アブレーションを使う。ルーティング規則、階層、文脈フィールドを一度に1つずつ外し、同じ未使用データセットと比較する。性能低下は因果的な設計主張を支持するが、対応のない変更前後の逸話は証拠にならない。 ## 保存した検索結果(キャッシュ)が、設定ちがいで混ざらないようにする 挙動を変えるすべての入力をキャッシュキーに含める。対象には、情報源の範囲、モードの調整項目、結果件数上限、拡張状態、検索分岐と深さ、埋め込みプロバイダー、埋め込み列またはモデル、順位付けを変える機能フラグが含まれる。 キャッシュキーの契約をバージョン管理する。意味が変わったらバージョンを上げ、古い行を新しい設定で解釈せず、通常のキャッシュミスとして到達不能にする。 モード間、情報源間、プロバイダー間、関係検索の有効時と無効時について分離をテストする。組み込みエンジンでは隠れるエンコーディングや型の挙動が本番データベースだけで現れることがあるため、対応するすべての保存エンジンで同等性テストを行う。 ## 個人のデータを守り、セキュリティの直しは弱点を明かさず伝える 評価記録はプロジェクトの監査領域に保存し、利用者が実際に使う非公開コーパスには決して入れない。フィクスチャ、例、報告書、リリースノート、一般向けの議論では、架空の氏名と組織を使う。関係性が分かるクエリは汎用的な仮の表現へ置き換える。 一般向けの成果物では、セキュリティ修正を機能面から説明する。未修正システムに含まれる機微な記録の整理済み一覧、露出期間、最も容易な探索経路は示さず、保護の仕組みと運用者が取るべき対応を説明する。 詳細な露出分析は、アクセス制限されたレビュー証跡に保管する。情報を一般向けに出す前に、予備知識のない読者でも非公開の関係性を推測できるか、または古いデプロイを直接狙えるかを確認する。該当する場合は表現を一般化する。 ## 調査の文書を、自動チェックで最新かつ短く保つ 文書を次の階層構造にする。 - 調査目標、ルーティングモデル、アーキテクチャ、横断的な不変条件を含み、常に読み込む案内文書 - 関連するサブシステムでだけ読み込む現状の参照文書 - 過去の挙動を記録する変更履歴とバージョン履歴 リリースごとの経緯を現状の参照文書へ追記し続けない。既存の記述を新しい事実に更新し、過去の詳細はバージョン管理と変更履歴へ残す。 サイズ上限、禁止された過去表現、生成した用語集の鮮度、文書一式の鮮度を継続的インテグレーションで強制する。自動ガードのない文章上の規則は、長期的な制約にはならない。 ## 実行のたびに、出てきた結果と設定を全部残す 進捗はデータ結果とは別の経路へ書く。フェーズ名を安定させ、構造化された進捗を明示的な選択肢にし、長時間の処理では機械可読な結果を壊さずにハートビートを出す。 テストと評価では、末尾や絞り込んだ要約を表示する前に、完全な結果をファイルへ記録する。表示処理を実行する前に、元のコマンドの終了コードを記録する。ゲート処理を省略表示するコマンドへ直接パイプしない。実際の失敗詳細を捨てたまま、表示側の成功をパイプライン全体の成功として報告するおそれがある。 各実行では、設定、解決済みモード、データセットの識別情報、ハッシュ、指標、費用、警告、終了状態、時刻を保持する。別のレビュー担当者が実行内容を再構成し、実測した事実と仮定を区別できる場合に限り、結果を判断に使える品質とみなす。