根拠のある回答

「ドキュメントからの回答」は主張するのは簡単ですが、実際にうまく実行するのは困難です。このページでは、ファイルのアップロードから根拠のある回答生成までの間にプラットフォームが実際に何を行っているか、そして通常は明かされない部分について説明します。

ファイルからチャンクへ

取り込み：ドキュメントごとに1回

クエリ：質問ごとに1回

アップロードされたドキュメントはテキストに解析され、チャンクに分割され、埋め込まれ、暗号化されて保存されます。分割における2つの詳細は、見た目以上に重要です。

チャンクのサイズはトークン単位で測定されますが、テキストは文字単位で分割されます — そのため、プラットフォームは両者間の変換を行わなければならず、その変換は言語に依存します。ラテン語の比率（トークンあたり約4文字）は、1文字がほぼ1つのトークンに近い中国語、日本語、韓国語では大きく誤っています。グローバルな定数を使用すると、CJK（中国語・日本語・韓国語）のドキュメントは意図した数倍のサイズのチャンクになり、チャンクがサイズ設定されたコンテキストを超え、検索ではテキストの壁が返されます。

したがって、スプリッターはドキュメント自体の内容から比率を推定し、テキストのCJK比率とラテン語比率の間に補間を行います。中国語と英語が混在する契約書の場合、極端のどちらかではなく、その中間の値になります。

可能な限り段落をそのまま保持します。 チャンクはターゲットサイズに達するまで段落ごとに蓄積され、段落自体が oversized（サイズオーバー）の場合のみハード分割されます。連続するチャンクは設定可能な量だけオーバーラップし、前のチャンクの末尾を次のチャンクに引き継ぐことで、境界をまたぐ事実が両側から検索可能になります。

テキストレイヤーだけでなく、図も

ほとんどのドキュメント抽出はテキストレイヤーで止まります。データシート、設置マニュアル、またはレポートをアップロードすると、典型的なパイプラインは文章を抽出し、入力されたものではなく描画されたもの（配線図、基板レイアウト、ページ中央のチャートなど）を静かにドロップします。ファイルは「処理」されましたが、その内容の半分は読まれていません。「CPUファンのヘッダーはどれか」と尋ねても、その答えはインデックスに含まれていません。なぜなら、それは画像にしか存在しなかったからです。

このプラットフォームはそれらも読み取ります。

• スキャンまたは画像のみのPDF — テキストレイヤーがまったくない場合 — はページごとにレンダリングされ、ビジョンモデルによって文字起こしされます。これにより、写真撮影された契約書やスキャンされたフォームが検索可能なテキストになります。
• 混合ドキュメント — テキストレイヤー に加えて 図が含まれる場合 — は、他のシステムが見逃すケースです。実際の図を含むページはレンダリングされ、ビジョンモデルによって記述されます。その記述はドキュメントのテキストに組み込まれ、チャンク分割、埋め込みが行われ、文章と一緒に検索可能になります。基板レイアウトのページからはコネクタの名前とその位置が返され、チャートからはトレンドと数値が返されます。
• Wordファイルに埋め込まれた画像 はドキュメントから抽出され、同じ方法で記述されます。

難しい部分はビジョンモデルを呼び出すことではありません。同じ装飾的なサイドバーに対して40回も呼び出すことではありません。マニュアルはロゴとページ枠をすべてのページで繰り返します。それらを記述することは純粋なコストと純粋なノイズになります。したがって、図の検出は、 genuineな図（多くのベクトルパス、大きな写真、画像のモンタージュ）とテンプレートの装飾（コンテンツが同じでページ間で繰り返し出現する画像）を区別し、情報を含むページのみを送信します。

コンテキストヘッダー

単独で埋め込まれたチャンクは、それが特定のドキュメントから来たという事実を見失います。「借手が債務不履行の場合、条項7.2が適用される」というチャンクは、「ブリッジ製品の支払いを逃した場合どうなるか」というクエリに対して検索精度が低くなります。チャンクは自分がどの製品に属するかを述べません。

埋め込みの前に、各チャンクにはコンテキストヘッダーがプレフィックスとして付加されます。これはドキュメントのタイトル、およびオプションでLLMによって生成された状況注記です。これにより、ベクトルは文章だけでなく、それが属する文脈も反映します。保存されるテキストは変更されません。ヘッダーは埋め込み入力のみが持ちます。

クエリ書き換え：多くのシステムが省略する部分

検索の品質は通常、ランキングの問題として議論されます。しかし、多くの場合そうではありません。多くの場合、クエリ自体に情報が含まれていません。

顧客が「あの製品の利率はいくらですか？」と尋ねます。代名詞は2ターン前に言及されたものを指しています。その文を埋め込むと、特定のベクトルに近いものではなく、そのターンでの検索はほぼランダムになります。リランキングの量では修正できません。なぜなら、シグナルが元々存在しなかったからです。

したがって、埋め込みの前に、以前の文脈に依存するフォローアップ質問は自己完結型の質問に書き換えられます。3つの意図的な選択があります：

• 過剰トリガーに偏ります。 参照表現の正規表現により、書き換えが試みられるかどうかが決まります。不要にトリガーすることは、1回の安価な呼び出しコストと、書き換えられた質問が変更されないことによる損失です。トリガーしないことは、そのターンの検索を完全に失敗させることになります。
• キーワードではなく、より完全な文に書き換えます。 埋め込みモデルは文に対して訓練されています。キーワードに減らすと関係性（「貸し手の借主の責任」とその逆は同じベクトルに崩壊する）と否定（保証を必要としないケースはどれか）を見失います。
• 検索ベクトルにのみ影響します。 モデルに送信されるメッセージは常に顧客の元の言葉です。書き換えはプロンプト、会話履歴、またはストレージに入ることはありません。また、失敗した場合元の文にフォールバックするため、最悪の場合でも旧来の動作と同じです。

検索と関連性の閾値（フロア）

その後、最大距離によってトップマッチがフィルタリングされます。これが有用なエージェントと自信過剰なエージェントを分ける部分です：

要求された数よりも少ないチャンクを返すことは、欠陥ではなく正しい結果です。 知識ベースに関連するものが何もない場合、エージェントはそれを受け取らず、そう伝えます。代わりに、最も無関係なパスジを渡されて、それらの間に橋渡しを創作させられるわけではありません。結果を固定された数にパディングすることは、検索システムが流暢で出典があるように見えるが誤った回答を生成する方法です。

フィルタはSQL述語ではなく、ランク付けされたフェッチの後に適用されます。結果はすでに距離順に並んでいるため、結果は同一ですが、これはクリーンなインデックススキャンを維持し、フルテーブルのポストフィルタに劣化しないようにするためです。

検索は成功したが、それでも失敗する場合

関連性の閾値は、何もが近すぎないケースを捉えます。しかし、捉えられないより困難なケースがあります：すべてのパスジが閾値をクリアし、トピックは正しいが、質問が関心を持っていた唯一の事実がそのいずれにも含まれていない。

このサイトのプレセールエージェントで測定しました。「Starterプランにいて、月間使用量が30%成長する場合、6ヶ月後にいくら支払うか」と尋ねたところ、検索結果は3つのパスジでした：Starterプランのページ、トークン使用量のガイド、利用規約。すべて関連性があります。しかし、それらのいずれも価格を述べていません。プランのページは、そのプランが誰向けであるかについてのページです。数値を含まない「Starter」というタイトルのドキュメントが与えられ、モデルは数値を供給しました。5回のランで、$5、$250、$99、$0、$29を生成し、それぞれに引用マーカーが付いていました。実際の数字は$49です。

検出可能な方法で何かが失敗したわけではありません。距離は適切だったため、検索のミスとして報告されることはありませんでした。引用は実際に取得されたパスジを指していました。間違っていたのは回答のみです。

コードで決定される2回目のパス

したがって、最初の検索の後、戻ってきたものに対して2つの質問が投げかけられます。どちらもモデルに委ねず、文字列比較だけで回答可能です：

聞かれていることが言及されているか？ 質問内の固有名詞、および知識ベースのドキュメントのタイトルから抽出された用語 — 私たちが推測したものではなく、誰かがキュレーションした語彙です。ある用語が質問に含まれており、取得されたパスジのいずれにも含まれていない場合、その用語は単独で検索されます。

聞かれている側面が存在するか？ これは最初のチェックで見逃される半分で、上記の測定で問題となった部分です：Starter は 取得されたテキストに含まれていました；価格は含まれていませんでした。したがって、各質問は、それが 何を求めているか とも一致させられます。それらの一部には硬性フォーマットがあります — 価格には通貨記号、期間には時間単位、連絡先情報はメールアドレスまたはURLの形式 — を持ち、実際にその側面をカバーする素材はそのフォーマットを省略することはほとんどありません。その他（返金、コンプライアンス、トライアル、統合）にはフォーマットがないため、シグナルは言語ごとに書き出されたトピック用語自体であり、ベクトル類似性に橋渡しを任せることはありません。

どちらかのチェックが不足している場合、派生した用語を1回だけ検索し、結果をマージします。ループは行いません。誤検知は1回のベクトルクエリコスト（追加のモデル呼び出しやラウンドトリップなし）ですが、見落としは引用付きの創作された数値をもたらします。

明確にしておくべき2点があります。これは創作に対する下限であり、正しさの証明ではありません — 質問の側面が表現されていないことに気づくだけで、回答が正しいことを示すわけではありません。また、知識ベースが実際にその事実を含んでいる必要があるという必要性を除去するものではありません：上記の例を本番環境で機能させた修正は、各プランに価格を明記した短いドキュメントを提供することも含まれていました。なぜなら、成長と超過料金に関する長い質問は、常に単一の統合された価格表よりも優先されるからです。

質問が条番号を名指したとき

引用の照合に意味的類似度を使うのは、道具の選び方を間違えています。「第 18 条」「Part 9」「ISO 9408」——これらは意味を持たず、対象を特定します。標準の一覧表で一桁だけ違う二つの行は、埋め込みから見れば同じ文です。

そこで質問中の識別子は取り出されてテキストとして検索され、名指された識別子をそのまま持つ断片は意味的な並べ替えより前に固定され、並べ替えはそれを動かせません。この最後の一句こそが要点で、はっきり書く価値があります。ここではかつてそうではなかったからです。その保護はコードのコメントに書かれていて、実装されていませんでした。だから再ランカーが固定された断片を下へ並べ直しました。隣り合う行が一桁しか違わない標準表で実測したところ、尋ねられた部を名指す唯一の行は、 再ランクを切れば 1 位、入れれば上位 20 にも入りません——そして回答は隣の行から出ていました。

識別子を意味ではなく同一性として扱うと、二つの帰結が生じます。

その識別子が文脈に収まらないほど多くの箇所に現れるとき、引用はもう丸ごと捨てられません。 以前は捨てていました。「第 18 条」が収まる数を超えて一致したら、「標本は答えではない」という理屈でそのグループ全体を落としていたのです。それはファイル順に先頭から数件取る場合には正しく、質問に最も近いものを取る場合には正しくありません。実測した一例をその順で並べると、答えを含む二つの断片はコサイン距離 0.27 と 0.31、雑音は 0.51 から始まりました——その段差自体がどこで止めるべきかを示しており、閾値を推測する必要はありません。距離が段ではなく滑らかな坂を成すときは、何も救いません。均等な広がりは断片どうしが区別できないことを意味し、それこそが本当の標本です。

ベクトル距離が最も近い断片は、必ず回答の文脈に持ち込まれます。 再ランクは並べ替えてよいが、最も近い一致を捨ててはなりません。実測では再ランカーがその断片を文脈から押し出した割合は 7 回に 1 回で、手作業で確認した標本の中では、押し出されたその断片が唯一その問いに答えられるものだったこともありました。置き換えではなく追加です——場所を空けるために他の断片を落としません。

モデルが自分から材料を求めるとき

目の前の断片では問いが決まらないとき、モデルは答えずに自分で知識ベースを検索することがあります。 その行動こそが信号です。 手元の材料を読み終え、その先を求めたのですから、必要なのは次の一群 であって、同じものではありません。素朴な実装は同じものを返しますが、それはモデルに何も伝えません。

次の一群はすでに手元にあります。検索は見せるより広い候補プールを取得し、一度だけ順位づけし、その上位を見せます。残りはまさにこの瞬間のために保持されています。それを渡すのに二度目の検索も、二度目の順位づけも、二度目の関連性評価も要りません——もともと行われるはずだったモデル呼び出しが一回あるだけです。最初の実装は検索をやり直しており、ある問いでは 22 秒が 71 秒になりました。「もう一度見る」ことの代価は、推測ではなくこうして測られます。

渡すのは 1 ターンに一度だけです。その後の再検索は通常どおりに振る舞います。「もう一度引いても同じものが返る」こともまた信号であり、それを取り除くとモデルは際限なく掘り続けるからです。

復号化は最後に行われる

チャンクの内容は、スペースごとに暗号化されて保存されます。実際に一致したチャンクのみが復号化され、そのテナントとユーザー用の暗号化キーが読み込まれます。検索はベクトルに対して行われ、プレーンテキストは直後に使用されるパスジに対してのみ表示されます。

数値は意味ではない

上記すべては機械的な処理です。このセクションはあなたが制御できる部分であり、このページ上のどの設定よりも結果に大きな影響を与えます。

検索は意味に一致します。値自体は意味をほとんど持たないため、事実がテキスト内にあっても到達不能な場合があります — 検索が常に 何か を返すため、静かに、しかし確実にです。

これは実際の顧客カタログの 1,500チャンク中1,480 に表示された行です：

Reading level: 1 · Age: 5 · Words: 1951

そして「自分で読み始めようとしている子供に適した本はどれか」というクエリに対して、音楽の英才教育に関する本が返されました。1 は beginner reader（初心者向け読者）とは、1つの単語が別の単語に似ているような関係性を持っていません。

値の隣に1文追加することで修正されました。そのレコードで測定した結果：

Reading level: 1 · Age: 5
Suitable for around age 5, for children just starting to read on their own.

数値が低いほど近接度が高く、以下に示すように、このモデルでは無関係な2つのパスジは約0.61に位置します。したがって、最後の行は「偶然よりわずかに良い」から実際の一致へと移動し、その効果は言語を超えて維持されます。

一般的なルール：価格、日付、レベル、可用性、在庫など、プロパティによって回答される質問の場合、フィールドだけでなく言葉でも記述してください。 構造化された値はフィルタリング用です。検索は書かれたものを見つけます。

努力する価値が ない ことの1つは、測定した結果です：エクスポートはしばしば自身を繰り返します（summary と description が同一の文章を含む）。重複を除去しても、60レコード全体で検索距離が +0.002 変化しただけで — 何の変化もありません。埋め込みは方向であり、繰り返されたテキストが使い果たす予算ではありません。

距離はスコアではなく、モデル間で比較可能ではない

距離の数値を読む前に知っておくべきもう1つのことです。埋め込みモデルはテキストを狭い円錐に圧縮し、その狭さはモデルによって異なります。このプラットフォームが現在実行しているモデルでは、2つの完全に無関係なパスジは約 0.61 離れています — したがって、0.52のヒットは弱い一致ではなく強い一致であり、0.5 はどこでも意味のあるカットオフではありません。

2つの実用的な帰結：

• 無関係なベースラインに対して距離を評価し、どこかで覚えた数値に対して評価しないでください。コンソールの知識スターマップは、まさにこの理由でそのスケール上にベースラインをマークします。
• キーワードよりも長い質問の方が検索精度が高いです。 900文字のパスジに対して1つの単語は、パスジが文字通りその単語についてのものであっても弱いシグナルです。完全な質問ははるかに近い一致です。実際のユーザーは文を書くため、これは良いケースですが、1語のクエリでテストする場合、実際のシステムパフォーマンスよりも数値が悪く見えることを期待してください。

検索が実行できないこと、およびそれに対応する回答

上記すべては、質問に回答するパスジを見つけることです。3種類の質問はパスジに関するものではなく、パラメータを調整しても類似度検索がそれらに回答することはありません：

• カウント — 「いくつありますか」、「非fictionはどれくらいありますか」
• 数値フィルタリング — 「200語未満のものはどれか」、「1000〜2000の間」
• グループ化 — 「カテゴリごとにいくつあるか」、「最も頻出する著者は誰か」

これらは見逃しやすい方法で失敗します。「500語前後のものがありますか」と尋ねられた場合、ベクトル検索のみを持つエージェントは、上位の数件に含まれていたレコードについて報告します — 4つのドキュメントについての真実の陈述が、コレクション全体の陈述として提示されます。

構造化インデックス

したがって、知識ベースはベクトル alongside に2番目の小さなテーブルを保持できます：ドキュメントごとに1行、ドキュメントが既に含むフィールドから構築されます。値は文字単位でコピーされます — 生成も書き換えもされません。

これにより、エージェントは質問に合ったツールを選択します：

フィールドは、いくつかのドキュメントを読み取ってからコレクション全体に対して検証することによって提案されます。5分の1のドキュメントのみで見つかったフィールドはドロップされ、報告されます。なぜなら、それに基づいてフィルタリングすると残りを静かに省略してしまうからです。インデックスの構築または変更は再埋め込みを行いません — 値はすでに保存されているテキストから読み出されるため、既存の検索を乱しません。

機械可読なヘッダーを共有しないドキュメントにはインデックスが付与されず、プラットフォームはそれを伝えます。すべての値が異なるテーブルを構築するのではなく。これは回避すべき制限ではありません。そのようなテーブルはカウントやグループ化の意味をなし、存在すると悪く回答される質問を誘発するだけです。

なぜ回答のリンクが以前は間違ったアイテムに属していたか

同じテーブルが修正する2番目、より静かな失敗があります。

検索はチャンクを返しますが、タイトル、製品コード、リンク、画像はドキュメントのヘッダーに存在します — つまり、チャンク1にあります。一方、質問に回答したパスジはチャンク7である可能性があります。したがって、モデルは3〜4つのドキュメントから4〜5断片を受け取り、どのリンクがどのタイトルに属するかを推測しなければなりません。

それを間違えた場合、何も間違って見えません。リンクは実在し、開き、画像はレンダリングされます — それは単に別のアイテムに属しています。4,500ドキュメントのカタログで、20のテスト回答中11が、タイトルを別のドキュメントのリンクとペアにしました。

正確なフィールドとしてマークされたもの（リンク、画像、識別子）は、今ではモデルに一切表示されません。プレースホルダーを受け取り、プレースホルダーを出力し、プラットフォームが出力時に保存された値に置換します。モデルは見たことのない住所を誤って入力することはありません。同じ20の質問は、20中20が正しくなりました。

顧客に送信する どの リンクかは、データが述べていないビジネス上の事実であるため、それらのフィールドを自分で命名します。その他は提案されます。詳細は 構造化インデックス を参照してください。

資料に本当に回答がない場合

時々、正直な答えは「それはあなたの資料にありません」であり、時にはそれが有用な会話の終わりになります。パブリックソースフォールバックは、オプトイン式の、エージェントごとの代替手段です：検索が空の場合、エージェントはウェブを検索し、見つかったページの1つを読み、それに基づいて回答できます。

オフに設定されており、オンにする必要があります。オンになっている場合、3つのことが真です。

ページを読むことは、それ自体の一部であり、追加ではありません。 検索結果はタイトルと2行の要約であり、重要な数値（有効期間、手数料、期限など）は通常本文のみに含まれます。評価セットの1つのページは、スニペットに「5年間有効」と記載し、ページ自体にのみ「更新期限：9ヶ月」と記載しています。要約のみが与えられた場合、モデルにはヒントはありますが事実がなく、記憶からギャップを埋めます。したがって、1つのスイッチで検索と読書の両方を有効にします。検索のみを有効にすることは、より保守的なオプションではなく、測定可能な最悪の構成です。

読まずに検索することは許可された結果ではありません。 エージェントが検索し、ページを開かずに回答した場合、プラットフォームは回答が配信される前に1ページ読むように強制します。この違いは学術的なものではありません：現在日本のPMDAを率いているのは誰かと尋ねた場合、要約のみは自信過剰な誤った名前を生成しました。同じ質問でページを読んだ場合、正しい名前が生成されました。

パブリックページからのものはすべてラベル付けされ、何を検索したか確認できます。 引用マーカーは異なる色で、パネルはドメインを表示し、これがあなたの資料ではなくパブリックソースであることを明確に伝えます。この区別はプラットフォームによって適用されます — モデルに尋ねるのではなく、それはまさに重要な瞬間に忘れるでしょう。

エージェントが読んだページと、単に見つかった結果の両方がリストされ、異なるスタイル（実線 versus 破線）と異なるラベルで表示されます。なぜなら、それらは異なる証拠の等級だからです。以前のバージョンでは読んだページのみが表示され、意図とは逆の効果がありました：フェッチが失敗したターンでは、回答は要約から来ており、ソースマーカーを一切持っていませんでした — あなたの資料からの回答と視覚的に同一です。弱い証拠を隠すことは、証拠が弱いという事実を隠すことになりました。

そのような回答はすべてレビューキューに入ります。 コンソールの Knowledge review（知識レビュー）の下です。質問、回答、ソースURL、読んだときのページのスクリーンショット、およびアウトバウンドファクトチェックがソースに追跡できなかった数値。

承認時に書き込まれるのは質問と資料から書き換えられた新しいエントリです — 訪問者が受け取った回答ではありません。回答は1人の人物に向けられ、その会話によって形成されていました：名前で始まり、「あなたの製品ライン」を参照し、アクションを促すもので終わります。そのまま記録すると、1人の訪問者のプライベートコンテキストが全員への回答になります。したがって、エントリはそれらを一切含まないように再生成され、タイトルは質問ではなく資料から書かれます — 「…私の製品について」という表現の質問は、タイトルが検索で重みを持つ場所に誰かのコンテキストを静かに持ち込むタイトルになります。メールアドレスと電話番号は、保存する前にマスクされます。書き換えられたエントリを確認し、必要であれば編集し、承認します。

却下すると記録が保持されるため、同じページは翌月に再レビューされません。

知っておいてほしい数値

知識ベースが本当に回答できなかった24の質問で、3回実行した結果：実ソースに追跡可能な回答は 8% から33% に増加し、ソースに追跡できない数値は13から6に減少しました。2番目の数はゼロではありません。12回答中約1が、依然として説明できない数値を伴っています。 これが、ファクトチェックが機能の後ではなく機能と一緒に提供され、レビューキューが存在する理由です。

実務での意味

• 多言語ドキュメントセットは静かに劣化しません — チャンク化は文字セットに適応します。
• ドキュメント内の図やチャートは回答可能であり、画像の他の部分と一緒に静かにドロップされません。
• フォローアップ質問は、オープニング質問と同様に検索されます。
• エージェントの正直な「それは持っていません」は、関連性の閾値の設計された結果です。