VectifyAI/PageIndex

長い文書に質問して答えさせる仕組み（RAG）を、ベクトル検索を使わずに組む Python のライブラリだ。ふつうの RAG は文書を細かく切り分け、質問と「意味が似ている」断片を引いてくる。PageIndex はそれをやめ、文書ごとに章や節の木（目次のようなもの）を作り、LLM にその木をたどらせて答えのある箇所を探させる。README は「似ていることと、関係があることは違う」と書き、専門家が長い報告書の該当する節を開いて読む動きをまねたものだと説明している。

手順は2段ある。まず索引づくり。木の骨格は LLM を使わずに文書のレイアウトから取り出し、索引用のモデルはそれを要約して整えるだけなので、安いモデルで足りるという。次に検索。チャット用のモデルが木をたどり、たどり着いた節だけを読む。README はこちらには払える範囲で最も良いモデルを勧めている。答えは、読んだ箇所までさかのぼれる。

オープンソース版は自分のマシンで動き、LLM は自分の API キーで呼ぶ。扱えるのは文字の入った PDF で、スキャンした資料の文字起こし（OCR）や画像の読み取りは、PageIndex の API キーを使うクラウド版の機能だ。ライセンスは MIT。

数百ページの報告書やマニュアルに、質問で答えさせたいとき

README が向いている例に挙げるのは、決算書、法律文書、規制当局への届出、技術マニュアル、医学文献など。README の測定では、答えが同じだった文書で比べると、PDF を毎回丸ごと渡すほうが 52ページで2.1倍、420ページで16.6倍高くついた（チャット用モデルは gpt-5.6-sol、プロンプトのキャッシュは使わない条件）。805ページでは、そもそもモデルに入りきらなかった。

答えの根拠がどこか、あとで示す必要があるとき

答えは、LLM が木のどの節を読んだかまでさかのぼれる。頼めば根拠の場所も示せて、自分のマシンで動かす版ではページ単位になる（クラウド版はもっと細かい単位）。

スキャンした PDF は、手元で動かす版では扱えない。 図や画像の中身も読まない。文字起こしと画像の読み取りはクラウド版の機能。MCP サーバー、フォルダ分け、何百万件もの文書をまとめて扱う機能もクラウド側にある。

質問のたびに LLM の利用料がかかる。 検索のたびにモデルが木をたどるためだ。README は検索側に良いモデルを勧めており、モデルを1段上げるごとに費用が1桁上がるグラフを載せている。

性能の数字は開発元自身の測定。 比較の条件は README とベンチマーク用のリポジトリで確かめてから当てにする。