より良いモデルではエージェントは救えない | Pinecone

現在、本番環境でエージェントを構築しているチームは、同じ壁に直面している。モデル自体が制限要因になることはほとんどなく、最先端のモデルはほとんどのジョブに必要な推論能力を備えている。問題は推論ステップの前のすべての部分にある。エージェントはタスクを受け取り、情報が必要だと判断し、検索、取得、結果の評価を行い、さらに情報が必要だと判断して再度検索、読み取り、部分的な情報をつなぎ合わせ、ループする。モデルが回答を生成できる状態になる頃には、ほとんどのトークンとレイテンシの予算はすでに使い果たされている。

これが現在のエージェントインフラストラクチャのギャップである。この問題を中心に出現した分野はコンテキストエンジニアリングである。データをモデルが使用できる知識に整形し、エージェントがクエリ時に生データから再組み立てするのを防ぐ。しかし、これらのコンテキストパイプラインを運用可能にすることがチームの課題であり、特に実際の企業では、各ドメイン（営業、法務、財務、サポート、研究開発、運用）で必要なコンテキストの形状が異なる。ドメインごとに手作業でコンテキスト層を構築するのは、最初の1つか2つを超えるとスケールしない。

Pineconeは過去1年間、この問題に取り組んできた。この記事では、その難しさ、構築したもの、そして次に来るものについて説明する。

具体例：市場インテリジェンスエージェント

投資会社の市場インテリジェンスエージェントがS&P 500の10-K報告書を分析する場合を考えてみよう。この質問はエージェントが答える必要がある数十の例である：「NVIDIA、Microsoft、Walmartの間で、各10-Kに開示された2022会計年度の自社株買い活動を比較せよ。各企業について、(a)会計年度中の買い戻し額と買い戻した株式数、(b)開示されている場合、元のプログラム承認額と承認日、(c)会計年度末時点の残存承認額を述べよ。」

このエージェントを本番稼働させるには、コンテキスト層は4つの要件を満たす必要がある。正確性、タスクレイテンシ（秒単位）、トークンコスト（1回の呼び出しコストが限定され、ワークフロー全体でエージェントの料金が複合しないこと）、ガバナンス（フィールドレベルの権限制御と根拠となる出典）。

しかし、これら4つすべてを同時に満たすのは難しい。チームがこのようなエージェントワークロードのコンテキスト層を構築する場合、通常、次の2つのパターンのいずれかにチームと数か月の反復を費やす。Agentic RAG（10-Kコーパスをチャンク化し、埋め込み、ハイブリッド検索を使用。エージェントがループ：クエリ実行、再ランク付け、上位チャンクを読み、満足するまでループ）またはサンドボックス内のコーディングエージェント（ファイル一覧、ページ読み取り、grep、全文読み取りツールへのアクセスを与え、エージェントにループさせる。各10-Kを開き、資本返還セクションに移動し、表を解析して回答を抽出）。

どちらのアプローチも最終的に正しい答えを得られるかもしれないが、多くの場合、遅すぎてコストがかかり、本番に導入できない。両方とも同じ根本的な課題を抱えている。つまり、エージェントにクエリ時に知識を組み立てさせる。Agentic RAGはエージェントにチャンクを渡し、回答を縫い合わせるよう要求する。サンドボックスエージェントはエージェントにファイルを渡し、検索、grep、解析を通じて答えにたどり着くよう要求する。これらのアプローチでは、作業の大部分が生データの取得と適切なコンテキストの組み立てに費やされ、推論にはほとんど使われない。

手動コンテキストからコンパイル済み知識へ

このような問題の解決策はよく知られている。消費者がクエリごとに構造を導出するようにするのではなく、データを消費者が気にする構造をすでにエンコードしたアーティファクトに事前に整形し、それを提供する。これは新しいことではない。知識グラフ、エンティティカタログ、セマンティックレイヤーは何十年も存在している。データインフラの各世代は、同じ直感のバージョンを出荷してきた。つまり、方向付け作業を一度行い、結果を保存し、下流の消費者が直接読み取れるようにする。コンテキストエンジニアリングはその直感の最新バージョンであり、現在はダッシュボードではなくエージェントに適用されている。

問題：ドメインごとの運用化

難しいのは概念ではなく、運用化である。1つのドメインに対して優れたアーティファクト層を構築するには、高度なチームと数か月の反復が必要であり、使用する特定のキュレーション戦略、検索設計、評価ハーネス、ガバナンスフックを決定する。実際の企業には1つのドメインしかないわけではない。数十のドメイン（営業、カスタマーサポート、法務、財務、研究開発）があり、それぞれ独自のデータ形状、スキーマ、用語、アクセスパターンを持つ。エージェントを必要とするすべてのドメインに対して数か月の反復を掛け合わせると、これらのパイプラインを構築するリソースはすぐに枯渇する。実際には、最も価値の高い1つか2つのドメインにのみ層が構築されるか、まったく構築されない。

新しい知識インフラのカテゴリ

この問題は、新しい知識インフラのカテゴリの必要性を示している。コンテキスト層がインフラとして動作し、ドメイン間で自動化され、手動で調整・構築されるのではない。層が存在し、それに対してプロビジョニングする。新しいユースケースのたびにゼロから再構築する必要はない。

Pineconeは過去1年間、そのようなものを構築してきた。その名はPinecone Nexus、エージェント専用のKnowledge Engineである。

Knowledge Engineの内部

Knowledge Engineは4つのプリミティブから構築される。

アーティファクト：特定のタスクまたは成果のために構築された、型付けされ、統治された情報。同じ10-Kデータから、財務指標を必要とする市場インテリジェンスエージェントは、リスク要因の開示を必要とするコンプライアンスエージェントとは異なるアーティファクトを取得する。各形状が、各エージェントのジョブに効率的で調整された基礎表現となる。

コンテキスト：特定の役割、チーム、またはワークフロー向けにキュレーションされたアーティファクトのセット。アナリストの財務指標アーティファクトを、エージェントが必要とするナラティブセクション（MD&A、セグメント報告）とバンドルし、そのバンドルがアナリストのコンテキストとなる。コンプライアンスチームは独自のものを持つ。

知識：会社全体のすべてのコンテキストの集合体であり、アナリスト、コンプライアンス、M&A、ポートフォリオ監視など、ビジネスがどのように運営されているかを表す。知識に対するクエリは必要な数のコンテキストにまたがることができ、エンジンがルーティングを処理する。

Knowledge Engine：上記のすべてを構築し提供するシステム。その中核はContext Compilerであり、各ドメインのキュレーションコードとクエリコードを自律的に作成・調整する。ビルドループが完了すると、生データからアーティファクトを構築し、コンテキストに合成し、各エージェントのKnowQLクエリに応答する。

Context Compiler

Context CompilerはKnowledge Engineの中核となる自律的なコーディングエージェントである。エージェンティックハーネスパターンを使用して、タスク最適化されたコンテキストを構築する。コーディングエージェントと、ドメインごとに定義する評価セット（既知の正解を持つ代表的なタスクと対応するデータソース）、事前検証済みのスキルライブラリ（文書処理、エンティティ抽出、チャンク化など、エージェントがソリューションに構成できるもの）、および各イテレーションを評価シグナルに対してスコアリングするフィードバックループを組み合わせる。

イテレーションごとに、コーディングエージェントは2つの関数（アーティファクト構築用のcurate()と知識検索用のquery()）を修正し、評価セットを実行し、失敗シグナルを使用してコードを洗練し、評価に合格するまで繰り返す。出力はそのドメインの動作可能で調整されたコンテキストである。

このアプローチにより、ドメインエキスパート（検索のバックグラウンドがなくても）がエージェント最適化されたコンテキストを生成できる。スキーマ、検索ロジック、アーティファクト形状を事前に指定する必要がない。Context Compilerは評価に基づいて適切なアーティファクト構造、粒度、構築戦略を自動的に発見する。ほとんどの新しいドメインは既存のスキルを新しい方法で組み合わせることで対応できる。本当に適合しないものがあれば、新しいスキルをライブラリに追加する。

初期のデザインパートナーとの作業では、コンパイラは新しいドメインのコンテキストを数か月ではなく数日で提供した。まだより多くのドメインとエッジケースを測定中だが、初期のシグナルは有望であり、このハーネスベースのエージェンティックアプローチが知識インフラの未来の基盤であると信じている。

KnowQL

コンテキストが作成されたら、次のステップはエージェントがそれを効果的に使用できるようにすることである。エージェントが段落レベルの自然言語クエリを発行し、テキストのブロックを解析する必要がある場合、エージェントが呼び出しごとに時間とトークンを再方向付けに費やすため、以前の失敗が戻ってくる。そこで、エージェントが必要なものを宣言し、正確で型付けされ、引用付きの応答を受け取るインターフェース、KnowQL（Knowledge Query Language）を設計した。

「宣言的」部分が中核の設計原則である。SQLでは、何を望むか（結合、フィルター、射影など）を記述し、エンジンが実行計画を選択する。KnowQLは同じ考えをエージェントの知識検索に適用したものである。エージェントは必要な回答、形状、制約を指定する。Knowledge Engineが検索するコンテキスト、読み取るアーティファクト、それらを構成する方法を決定する。

KnowQLクエリは4つのカテゴリで構成される。

意図：質問、応答形状、スコープ内のコンテキスト。複数のコンテキストにまたがって構成可能。

フィルター：決定論的述語とアクセス制御ポリシーを表面で強制。エージェントは呼び出し元が許可されたものだけを見る。

出典：フィールドレベルの引用を構築時に返し、後から再構築しない。すべての値にソースが付随。

制御：予算のエンベロープ（深さとレイテンシ目標）。コストをトークンではなく成果で宣言。

前述のS&P 10-Kの質問に対するKnowQLクエリは次のようになる。

{ "ask": "NVIDIA、Microsoft、Walmartの間で、2022年度の自社株買いを比較：買い戻し額、元のプログラム規模、残存承認額", "ground": true, "shape": { "type": "object", "properties": { "companies": { "type": "array", "items": { "type": "object", "properties": { "company_name": { "type": "string" }, "repurchased_usd_millions": { "type": "number" }, "program_size_usd_millions": { "type": "number" }, "remaining_usd_millions": { "type": "number" } } } } } } }

エンジンは1つの型付き応答を返し、エージェントの唯一の推論ステップはその応答オブジェクトを比較することである。すべての方向付け作業はビルド時に行われているからだ。

知識検索の影響の測定

Nexusの価値を証明するために、知識検索がエージェントのパフォーマンスに与える影響を定量化する必要があった。既存の検索ベンチマークのほとんどは分離された状態での再現率のみを測定し、異なる検索戦略がエンドツーエンドのマルチステップエージェントループに与える影響を比較しない。

そこで、KRAFTBench（Knowledge Retrieval Assessment Framework for Text）を作成した。このハーネスは、一貫したコンポーザーモデルからの応答の精度、レイテンシ、トークンコストを、異なる検索メカニズム間で測定する。これにより、品質、レイテンシ、トークンコストの違いは検索に起因するものとなる。テストされた3つの検索メカニズムは以下の通り。

コーディングエージェント：小さな読み取り専用ファイルシステムツールキットを提供。インデックスなし。

Agentic RAG：ファイルをチャンク化して埋め込み、Pineconeベクトルデータベースに保存。

Pinecone Nexus：Context Compilerで構築されたコンテキストを使用し、KnowQLクエリを発行。

結果は、Nexusが精度、レイテンシ、コストのすべての面で他の方法を大幅に上回った。特に、複雑な質問に対しては、Nexusは数秒で正確な回答を提供し、他の方法は数十秒から数分かかり、はるかに多くのトークンを消費した。

Pinecone Nexusは、コンテキストエンジニアリングを手動のカスタマイズから自動化されたインフラストラクチャへと変える、エージェントインフラの新しいカテゴリを代表するものである。