Pinecone のエンジニアリング担当バイスプレジデントである Jörg Schad 氏は 11 月 4 日のウェビナーで、検索技術がキーワード検索から RAG へとどう進化してきたかをたどり、AI エージェントが検索結果を消費するようになった今、システムに何が足りないのかを説明した。この記事は Pinecone のブログで公開された内容を要約したものだ。
冒頭で示された例は象徴的だ。エージェントに第 4 四半期のモバイル事業の成長率を予測させると、SQL を生成して実行し、+16% という結果を返した。しかし 9 月 8 日には 1 日限りのパートナー向けプロモーションがあり、エージェントはその急増を実際の需要と誤認していた。プロモーションを予測から除外しつつ、報告済みの合計には残すという正しい扱いにすれば、同じトレンドから得られる結論は +6% になる。データはすべて揃っており、SQL も妥当だった。誤っていたのは判断の部分である。
Schad 氏はこの事例を使い、検索の各世代が前の世代の弱点を補ってきた一方で、それぞれに限界があると説明する。キーワード検索は転置インデックスに基づき、1972 年まで遡る IDF や 1994 年の BM25 といった関連性指標で順位付けする。大規模に正確な一致を実現できるが、「解約」と「サブスクリプションの終了」を結び付けることはできない。意味検索は word2vec（2013 年）、近似最近傍探索のための HNSW（2016 年）、BERT（2018 年）によって語彙の違いを越えて関連する意味を見つけられるようになったが、限界は「設計文書の問題」に変わった。似ていることは、権威があることを意味しない。
2020 年に Lewis らが提案した RAG は、モデルがクエリ時に知識ベースへ回答を根拠付ける手段を与え、以来ほぼすべてのチャットデモで使われてきた。しかし Schad 氏は、その根拠付けが検証されていないと指摘する。モデルは返ってきたものをそのまま受け取り、それが正しい結果かどうかを確認する工程も、モデルが実際に使ったかを確かめる工程もない。
検索品質は通常 Recall@K で測られる。Recall@10 は関連文書が上位 10 件に入った割合を表し、情報が存在するかどうかを測る指標としては優れている。だが、新しい版に置き換えられたポリシーを考えてみると、検索は新旧両方を返し、Recall はどちらも関連ありと数える。古い版に基づくもっともらしい回答は実質ゼロ点だが、Recall@K は良好に見える。権限の問題も同じだ。クエリには非常に関連するが、呼び出し側が閲覧を許されていない文書であっても、Recall は減点しない。
では、意味検索の精度をどう上げるのか。Schad 氏の答えは、多くの場合、検索自体はすでに役割を果たしており、欠けているのは検索の外にある情報だというものだ。合併の例が挙げられた。合併後、一方の会社の会計年度は 1 月から 12 月、もう一方は 2 月から翌年 1 月であり、同じ「四半期」が両社で異なる月に対応する。両社にまたがる質問では、意味検索は関連文書をすべて見つけられるが、それらをどう組み合わせるかは示せない。検索器を調整しても解決しない。2 つの会計カレンダーをどう対応させるかというルールは、どの類似度スコアにも載らないからだ。
ウェビナーでは対比表で問題が整理された。第 4 四半期の成長予測では、9 月 8 日の急増を含む完全なデータが返り、判断を決めるのは「あれは 1 日限りのプロモーションであり予測から除外すべき」というルールだった。ある機能の仕組みを尋ねると、3 年前の設計文書と今朝のコードスキャンが返り、どちらが現在動いているコードを記述しているかが答えを決める。合併後の全社数字には、1 月から 12 月と 2 月から 1 月をどう対応させるかというルールが要る。ポリシーが何を許すかは、新旧どちらの版が有効かで決まる。つまり検索は Recall@K で評価され、コンテキストはそれを使って下された判断で評価される。
人間が答えを読む場合、この欠落は補える。明らかに高すぎる予測や、下がるはずのない数値の低下を見れば、人は眉をひそめて確認し直す。しかし自律エージェントが読む場合、その確認なしに結果をそのまま出してしまう可能性があり、しかもエージェントは人間の検索とは比較にならない規模で検索を呼び出す。大量の呼び出しを処理するエージェントは、結果が不合理だったり古かったりすることに気付かないかもしれず、自ら根拠を探すとも限らない。不足しているのは、それを教えてくれるコンテキストなのだ。
では、すべての情報をモデルに渡して関連性を判断させてはどうか。Schad 氏は Chroma のコンテキスト劣化に関する報告を引用した。18 の大規模言語モデルを評価したところ、入力長が増えるほど性能は不安定になり、意図的に単純化したタスクでも同じ傾向が見られた。LongMemEval では、平均約 300 トークンの焦点を絞ったプロンプトが、平均約 113,000 トークンの完全なプロンプトを上回った。エージェントも同様で、タスクに無関係な情報を詰め込むほど結果は悪くなる。問題は「正しい文書が返ったか」から、「エージェントは何が有効で、信頼でき、許可され、このタスクに適しているかを知る必要がある」へと変わる。
アーキテクチャとして Pinecone が採るのは、検索を残したまま、その上に「意思決定の層」を重ねるやり方だ。検索側では、密ベクトル、疎ベクトル、BM25 ランキングによる全文検索を 1 つのインデックスに同居させ、いずれもデータベースの外部ではなく内部に組み込んでいる。Schad 氏によれば、タスクごとに必要な検索ツールは異なり、複数必要な場合も多い。正確な一致が重要な場面ではキーワード検索の価値は依然として失われない。
意思決定の層は、タスクごとに「タスクコンテキスト」を保持する。要約、エンティティ、ポリシー、ルールに加え、クエリが届く前にバックグラウンドで整備された知識アーティファクトが含まれる。コンテキストはどのアーティファクトがそのタスクに関連するかを判断し、必要に応じて語彙検索、ベクトル検索、ハイブリッド検索をインデックスに対して発行する。合併の例に戻れば、検索はすでにすべての文書を見つけている。欠けているのは、一方の会計カレンダーをもう一方にどう対応させるかという意味情報であり、それがポリシーやルールと並べてタスクコンテキストに置かれる。置き換えられたポリシーや、データボットが遭遇した 1 日限りのプロモーションも同じ扱いだ。インデックスがデータを供給し、コンテキスト内のルールがその扱いを決める。
これが、エージェント向け知識エンジンである Pinecone Nexus の位置付けでもある。Nexus のキュレーションは処理済みソースの台帳を内容ハッシュで追跡するため、実行時には変更されたものだけに触れる。回答には引用が付き、各主張の背後にあるファイル、ページ、原文の範囲を示す。優先順位も明文化される。コンテキストの既定の指示は、そのコンテキストへのすべてのクエリに対するシステムプロンプトとして機能し、矛盾するソースをどう扱うか、たとえばどちらのポリシー版が優先されるかをモデルに伝えられる。
Schad 氏は適用範囲の限界も率直に示した。Nexus はすべてのワークロードに適するわけではない。検索パターンが単純で、上位 10 件に答えがあると確信でき、どのソースが優先されるかを決める複雑なルールやポリシーがなく、根拠付けを自ら担う用意があるなら、RAG で十分だ。大規模なオンラインストアの個々の購入のように毎秒変化する運用データには、ライブで動的なビューが向いており、一日中その場で編集されるリアルタイムのフィードや記録も現時点では Nexus に適さない。Nexus が最も力を発揮するのは、契約書や研究資料のようにデータの変化が比較的ゆっくりした場面である。
最後に Schad 氏は、埋め込みやリランキングの調整にスプリントを費やす前に、検索がすでに文書を見つけているかどうかを確認するよう勧めた。見つかっているなら、直すべきは判断を担う上の層だ。完全なリプレイは YouTube で公開されており、この層を構築したい読者は Nexus のドキュメントかトライアルの申请から始められる。