ローカルRAGは、通常のチャンク分割によって文章の文脈が保たれる一方、スプレッドシートのセルに意味を与える関係構造が崩れるため、物語形式の文書に対してより適切な回答を返すことがよくあります。
ポリシーに関する段落では、主題や修飾語が近接する文に含まれています。一方、ワークブック内の「42」は、行ラベル、列の日付、単位、数式、シート名に依存している可能性があります。ホームサーバーが両方をプレーンテキストのチャンクに変換すると、グリッドとセル間に隠れた関係が失われる一方で、物語形式の文章は、根拠に基づく回答の生成において、その変換をより忠実に保ちます。
物語形式のチャンクは独自の意味的近傍を持つ
文章では、隣接する文の中でエンティティ、動詞、因果関係が繰り返されます。固定サイズのチャンクでも、通常は埋め込みがトピックを表現し、生成モデルが根拠を解釈するのに十分な言語情報が保たれます。オーバーラップを設定すれば、境界をまたぐ文も保持できます。
テーブルファーストRAGアプローチでは、従来のRAGは物語形式のテキストでは有効に機能する一方、重要な情報が表や構造の中にある場合には機能しにくいと指摘されています。この不一致は生成前、つまり表現と検索の段階から始まります。
ただし、物語形式の文章の品質には注意が必要です。流暢な段落は、誤ったチャンクが検索された場合でも、流暢な回答を促します。比較上の優位性は構造の保持にあり、文章形式の回答が事実として正しいことを保証するものではありません。
スプレッドシートの意味は座標と操作に宿る
セルの意味は、軸をまたぐ関係から生まれます。行ごとに平坦化すると、見出し、結合されたラベル、数式、非表示のシート、単位などが切り離される可能性があります。その結果、埋め込みは、たとえば特定の四半期を抽出してカテゴリーを合計するといった、質問が求める操作ではなく、孤立した文字列同士を比較するようになります。
表のトポロジーに関する研究では、ハイブリッド文書には通常の線形チャンクでは失われる接続が含まれるため、テキストと表のトポロジーを明示的にモデル化しています。隣接関係と階層構造を保持することで、復元できる根拠が変わります。
検索が完全でも、スプレッドシートに関する質問を最後まで処理できるとは限りません。生成モデルはセルを選択し、データ型を尊重し、算術演算を実行し、座標を引用する必要があります。段落の要約が得意な言語モデルでも、列を入れ替えたり、書式設定された表示テキストを使って計算したりする可能性があります。
物語形式のRAGが優位性を失う場面
文書に密な相互参照、長い付録、定義から離れた事実が含まれている場合、物語形式の優位性は失われます。逆に、見出しが明確で、行が整然としており、意味検索レイヤーを備えたスプレッドシートは、曖昧な文章よりも回答しやすい場合があります。
表形式RAGの評価に関するガイドでは、一般的なテキスト指標ではなく、表を根拠とする質問に対して評価することの重要性が強調されています。回答は、正確なセルと操作に照らして確認する必要があります。
物語形式とスプレッドシートのパイプラインで異なるOCR、埋め込みモデル、権限が使われている場合も、この仕組みは機能しません。その場合、形式とツールの影響が混同されています。「見栄えがよい」ことは、根拠に基づいていることと同義ではありません。どちらの形式でも、回答レベルでの検証が必要です。
検索と計算を別々の段階として評価する
1つの物語形式のレポートと1つの整然としたワークブックから、対応する質問を作成します。質問には、検索、比較、集計、例外に関するものを含めます。必要な文章の箇所またはセル座標を記録し、両方を同じモデルと検索予算で処理します。検索、計算、引用、最終回答をそれぞれ個別に評価します。
ローカルベクトルデータベースを使い、ベクトルとソースファイルをローカルに保持しながら、表に対応したシリアライズ方法を単純な行テキストと比較して検証します。モデルの温度とプロンプトは固定してください。
スプレッドシートの根拠は検索できているのに算術処理に失敗する場合は、構造化された実行ステップを追加します。検索前に見出しが消えている場合は、抽出とシリアライズを修正します。物語形式の回答が単に優れているように聞こえるだけで、誤った箇所を引用している場合は、文章パイプラインが優れていると結論づけるのではなく、評価方法を調整します。
テック&AIハブ
もっと読む

ローカルRAGの検索品質を測定し、再現率・適合率・引用カバレッジを解釈する方法
ローカルRAGのテストセットを構築し、主要な検索指標を算出し、それらのトレードオフを解釈し、回答の主張が引用された根拠によって裏付けられているかを監査する。

サンプリングレートが同じ場合、センサー数の増加に伴ってスマートホームの機能計算がより重要になるのはなぜですか?
デバイス数の増加に伴うセンサーごとおよびセンサー間の計算処理を追跡し、非線形な融合コストを特定して、自動化処理に遅延が生じる前に特徴量パイプラインのベンチマークを実施します。

同じクエリ量でも、ドキュメントライブラリが拡大するとRAG評価コストが重要になるのはなぜか?
ユーザークエリを増やさずにコーパスの拡大がRAG評価の工数を増加させる理由と、層別テストによってコストをリスクに応じて抑えられる仕組みを理解する。

