構造化インデックス：AI エージェントが「何個か」について文書に回答する方法
構造化インデックスとは、エージェントが文書にすでに含まれているフィールド（タイトル、価格、レベル、リンク、画像）から構築する小さなテーブルと、意味を検索するために使用されるベクトル検索を組み合わせたものです。ベクトル検索は質問のように読める段落を見つけますが、カウントしたり、数値でフィルタリングしたり、グループ化したりすることはできません。構造化インデックスはそれらの問いに答え、エージェントが断片から再構築するのではなく、リンクや識別子を正確に引用できるようにします。
「いくつありますか？」と尋ねると、エージェントは偶然取得した4つのパッセージから回答します。リンクを求めると、実在するリンクを渡すことがあります。ただし、それは異なるアイテムに属するリンクです。リンクは開き、画像はレンダリングされ、エラーは発生しません。それがどのように起こり、それをどう止めるかをご紹介します。
各ドキュメントには色がついています。左側では、今日の検索動作において、回答のタイトルは1つのドキュメントから、リンクは別のドキュメントから取得され、色の不一致が瞬時に判明します。右側では、取得された各フラグメントは独自のドキュメントの事実を伴って到着し、リンクはリンクではありません。それは、モデルがアドレスを直接見ずにコピーするプレースホルダーです。実際の値は出力時に置換されるため、混同する要素はありません。
検索はパッセージを見つけますが、コレクション全体は見えません
ベクトル検索は類似性に基づいて動作します。あなたの質問は空間内の方向に変換され、それに最も近いパッセージが返されます。これは「Xについて何が書かれているか」には正確に合致しますが、「いくつあるか」「200語未満のものはどれか」「カテゴリごとにいくつあるか」といった質問には構造的に無意味です。これらはコレクション全体に関する質問であり、検索は常に最も近い数個のパッセージしか見ません。
どんなチューニングをしてもこれは修正できません。類似性検索が合計値を返すようにする閾値は存在しません。合計値はパッセージではないからです。
2つ目の、静かなる失敗：チャンクはドキュメントではありません
長いドキュメントは、検索が適切な段落を見つけられるようにチャンクに分割されます。しかし、あなたのタイトル、製品コード、リンク、画像はヘッダーに存在します。つまり、チャンク1に存在するということです。一方、実際に質問に答えたパッセージはチャンク7である可能性があります。
そのため、モデルは3つまたは4つの異なるドキュメントからの4つまたは5つのフラグメントを保持し、どのリンクがどのタイトルに属するかを判別しなければなりません。モデルは推測します。そして、その推測が外れた場合、回答は間違って見えません。リンクは実在し、開き、画像はレンダリングされます。ただ、それは別のアイテムに属しているだけです。エラーは発生しません。誰も気づきません。
4,500件のドキュメントからなるカタログでは、テスト回答20件中11件が、タイトルを別のドキュメントのリンクとペアリングしていました。上記のプレースホルダーメカニズムを使用した場合、同じ20件はすべて正しく返されました。
構造化インデックスとは
それは小さなテーブルです。1行が1つのドキュメントに対応し、ドキュメントが既に持っているフィールドから構築されます。何も発明されず、何も書き換えられません。値は1文字ずつコピーされます。
これが設置されると、エージェントには1つの方法ではなく2つの回答方法が用意されます。
| 質問 | 回答元 |
|---|---|
| 「恐竜に関するものはありますか？」 | ベクトル検索 |
| 「いくつありますか？」 | テーブル |
| 「恐竜に関するもので、5歳の子供に適したもの」 | テーブルでのフィルタリング、ベクトル検索によるランク付け |
| 「リンクとカバー画像は何ですか？」 | テーブル（正確な引用） |
フィールドの定義はしませんが、最終決定権はあります
プラットフォームは数件のドキュメントを読み取り、フィールドを提案します。その後、コレクション全体に対して各フィールドを検証してから、それを保持します。ドキュメントの5分の1にしか現れないフィールドは、それを使用してフィルタリングすると残りの大部分が黙って除外されてしまうため、ドロップされ、報告されます。
あなたが提供できる入力は2種類です。
正確でなければならないフィールド。 顧客に送信すべきリンクはどれか、3つのコードのうち、顧客があなたに引用するものはどれか。あなたのデータはこの情報を示しておらず、推論することもできません。事前に名前を指定すれば、それらは文字通り正確に抽出され、文字通り正確に引用されます。
自然言語による修正。 「著者も追跡してほしい。そうすれば、彼の本を他の本も見つけられるようになる。」「イラストレーターでフィルタリングできるようにしたい。」「カバーリンクを除外したい。」変更は既存のテーブルへのパッチとして提案され、書き換えではありません。そのため、1つのフィールドに関するリクエストが他のフィールドに影響を与えることはありません。ドキュメントに含まれていないものを依頼した場合（エクスポートに出版年が含まれていなかった場合など）、空の列を追加するのではなく、そう伝えます。
あなたのデータに関する他の洞察
すべてのフィールドは受け入れられる前にコレクション全体で測定されるため、レポートは誰も知らなかったことを定期的に浮上させます。数千タイトルからなる実際のカタログでは、その10分の1のタイトルがページ数0を持っていたことがわかりました。それは短い本ではなく、ゼロとして記録された欠損値であり、これがすべての平均値を低下させ、「最短」で大きな同点を引き起こすところでした。
そのチェックはどこかで発生する必要があります。今日では、通常、顧客が間違った回答に気づいた時点で発生します。
適用されない場合
あなたのドキュメントがプロース（記事、トランスクリプト、書簡など）である場合、テーブル化するものはなく、プラットフォームはすべて異なる値からなるインデックスを生成するよりも、インデックスの構築を辞退します。そのようなテーブルは意味のある方法でカウントしたりグループ化したりすることはできず、それを保持することは、不適切な回答を引き起こす質問を誘発するだけです。
そのような資料に対しては、ベクトル検索が適切かつ唯一のツールです。
よくある質問
- なぜ私のエージェントは、私が持っている製品の数を顧客に伝えられないのですか？
- ベクトル検索は、質問のように読める限られた数の段落を返すため、それらの段落をカウントすることはできないからです。これはチューニングの問題ではなく、検索結果に合計数を返すような設定は存在しません。構造化インデックスは、文書にすでに含まれているフィールドから構築された小さなテーブルを照会することで、カウント、範囲指定、グループ化に関する問いに答え、ベクトル検索は意味に関する問いの処理を引き続き担当します。
- エージェントはリンクや製品コードをでっち上げますか？
- フィールドが正確な値としてマークされている場合、エージェントはでっち上げません。これらの値はモデルには一切表示されません。モデルにはプレースホルダーが渡され、プラットフォームが出力時に保存された値に置き換えます。モデルは、自分が見たことのない URL を誤って入力することはありません。これは一見すると大したことではないように思えますが、実際には、でっち上げられたリンクではなく、異なるアイテムに属する実際のリンクが表示され、それが正常に開いて正しく見えるという失敗の方が一般的です。
- これはどのような文書から構築できますか？
- 機械可読なヘッダーを共有する文書です。メタデータテーブル、YAML フロントマター、または「フィールド: 値」の行などです。製品の出力、カタログ、医薬品添付文書、政策スケジュール、コース一覧などは通常該当します。プレーンな文章は該当せず、プラットフォームは無意味なテーブルを構築するのではなく、その旨を伝えます。すべての値が異なるテーブルでは、カウントやグループ化を意味のある形で行うことはできません。
- フィールドを自分で定義する必要がありますか？
- いいえ。プラットフォームはあなたの文書のいくつかを読み取り、フィールドを提案します。その後、コレクション全体に対してすべてのフィールドを検証し、保持します。その後、自然言語でフィールドの追加、名前の変更、削除を行うことができます。また、タイトル、リンク、画像、コードなど、正確に抽出する必要があるフィールドを事前に指定できます。顧客に送信すべきリンクは、データ自体には記載されていないビジネス上の事実だからです。
- これを追加すると、ナレッジベースの再処理が行われますか？
- いいえ。埋め込みは再計算されません。フィールドは、文書にすでに含まれているテキストから直接読み取られるため、インデックスの構築や変更には再インデックスのコストがかからず、すでに動作しているベクトル検索を妨げることはありません。
- 文書を追加または削除したときに、どのように最新の状態が保たれますか？
- 新しい文書は、すでに確立されたルールを使用してインポート時に読み取られるため、モデルを待たせることはありません。インデックス自体は、それが必要となる次の質問の前にオンデマンドで再構築されます。1000 件の文書を追加しても、1000 回の再構築がトリガーされるわけではありません。
エージェントが知るべきことのほとんどは、すでにどこかに書かれている——あなたのウェブサイトに、そしてチームがすでに顧客に送っている PDF に。URL からのインポートが公開されている半分を、アップロードが残りをカバーする。
ストーリーラインは、エージェントが各エンドユーザーとともにたどる有向グラフである——どのノードも一つのステップ（それ自身のタスク、知識、ツール）で、出口には条件が付き、各人の進捗、プロフィール、メモがセッションやチャネルをまたいで保存・再開される。これはエージェントを、点在するタスクをこなすアシスタントから、複数ステップのサービスを自ら届けられるものへと変える。
Dynamic Planner は会話を見張り、ユーザーがエージェントの領域内で本当に複数ステップを要するタスクに取り組んでいて、どう進めればよいか明らかに分からずにいるとき、そのタスクを一時的なストーリーライン——チェックリスト駆動の、段階的な計画——へ展開することを提案する。エージェントはその計画を、一度に一つのステップへ集中して実行し、進捗はユーザーからも見える。計画づくりは検証つきで一度だけ起こり、実行は決定的である。
長文執筆は、エージェントがアウトラインの計画をまず行い、開始前に必要なものをすべて要求し、各セクションをあなたの資料や公開ソースに対して調査し、再起動しても継続可能なジョブとしてセクションごとに執筆することで、完全な多セクションのドキュメント（提出書類、市場参入レポート、デューデリジェンスメモなど）を生成するものです。チャットの横にあるキャンバスで編集し、選択した段落を書き換えることができ、すべてのバージョンが保持されます。