LlamaIndex は私有データを検索可能な文書エージェントへ組み立てる

OSS フレームワークと Parse を混同しない

LlamaIndex OSS の README は、エージェント型アプリケーションと検索アプリケーションを構築するオープンソースの Python フレームワークとしてプロジェクトを紹介しています。一方、LlamaParse は、文書エージェント、agentic OCR、解析、抽出、取り込みを扱う別のプラットフォームとして説明されています。リポジトリの説明にある文書エージェントと OCR という表現だけを見ると一つの製品に見えますが、README は OSS とクラウド側の Parse を分けています。採用時には、コードとして使う範囲とアカウントを要するサービスの範囲を先に分けて考える必要があります。

取り込みから検索結果までを分解する部品

README が示す役割は、データコネクター、構造化、検索とクエリー、外部アプリケーションとの統合です。コネクターは API、PDF、一般文書、SQL などのデータを取り込み、インデックスやグラフを使って LLM が参照できる形にします。クエリーインターフェースは入力されたプロンプトに対し、検索したコンテキストと知識で補った出力を返す構成です。LangChain、Flask、Docker、ChatGPT などとの連携も README に挙げられています。高レベル API は短いコードで開始でき、低レベル API ではコネクター、インデックス、retriever、query engine、再ランキングを選び直せる、と説明されています。

llama-index と core を選ぶ境界

Python での入口は二つあります。llama-index はコアと選択済み統合を含むスターターパッケージです。構成を絞る場合は llama-index-core を入れ、LlamaHub から必要な統合パッケージを追加します。README は LlamaHub に 300 以上の統合があり、LLM、埋め込み、ベクトルストアのプロバイダーと組み合わせられると述べています。インポート名にも境界があり、llama_index.core を含むものはコア、core を含まないものは統合側を意味します。例えば LLM は llama_index.core.llms、OpenAI の実装は llama_index.llms.openai から読み込む形です。

VectorStoreIndex の例が示す RAG の順序

README の例では、まず OPENAI_API_KEY を環境変数に設定し、VectorStoreIndex と SimpleDirectoryReader でディレクトリの文書を読み込みます。VectorStoreIndex.from_documents でインデックスを作り、index.as_query_engine() から質問を渡す query engine を用意します。OpenAI 以外の構成として、Ollama、HuggingFace の埋め込みモデル、transformers の tokenizer を Settings に割り当てる例もあります。index.storage_context.persist() で storage に保存し、StorageContext と load_index_from_storage で再読込する流れも示されています。実運用では、チャンク分割、埋め込みモデル、検索上位数、保存先と回答評価を自分の資料で測る必要があります。

配布キャッシュを検証するための道具

README には llama-index-core のパッケージに nltk と tiktoken のキャッシュを含む _static フォルダーが同梱されるという説明があります。ディスクアクセスが制限された環境での実行を想定した配布物です。その内容がリポジトリのファイルと一致することを確認するため、GitHub の attest-build-provenance action と gh attestation verify を使うスクリプトが記載されています。これはインストール済みファイルの来歴と一致性を確認する仕組みで、検索や生成の正確さを測るものではありません。配布物を信頼する判断と、アプリケーションの回答品質を評価する判断を切り分けることが大切です。

LlamaParse が分担する文書エージェント機能

LlamaParse 側には、130 以上の形式を扱う Parse、構造化抽出の Extract、取り込みと RAG パイプラインの Index、大きな文書を分割する Split、Workflows と Agent Builder で構築する Agents が挙げられています。README は LlamaIndex と一緒に使えるほか単独利用もできると案内しています。ここで示されている形式数はプロジェクトの説明であり、手元の帳票や表が同じ品質で変換される証拠ではありません。API キーの取得、料金、保存先、アクセス権限はリンク先の公式資料で確認すべき領域です。

MIT と README が残す確認事項

リポジトリのライセンスは MIT です。著作権表示と許諾表示を残す条件で、使用、複製、変更、結合、公開、配布、サブライセンス、販売を認め、ソフトウェアは現状のまま提供され保証を負わない、という条件が示されています。README の引用用 BibTeX には Zenodo DOI の欄がありますが、素材では正確な DOI を確認できず、プレースホルダーとして扱う必要があります。リポジトリの星や fork は利用規模の手掛かりにはなりますが、検索品質、費用、サポート時間の裏付けにはなりません。

文書検索の評価では、取り込めたかどうかだけを合格条件にしないことが大切です。元ファイルの形式、ページや表の境界、メタデータ、チャンクの位置を残し、検索で正しい資料が上位に出たかと、生成文が根拠の範囲を越えていないかを分けて測ります。README は 5 行程度で始められる高レベル API と、各部品を差し替える低レベル API の両方を説明しますが、どの埋め込みが最適か、どのベクトルストアが必要かは決めていません。LlamaHub の統合数や LlamaParse の 130 以上という形式数も、自分の帳票での再現性を代わりに証明しません。OSS のコア、選択した provider、LlamaParse のクラウドを分けてデータフローと費用を記録すれば、検索基盤の責任範囲を整理しやすくなります。

読み込みの構成を決めるときは、LlamaIndex のコネクターが返す文書単位と、後段の index が必要とするメタデータを確認します。表や見出しの境界が崩れれば、ベクトル検索が成功しても回答の根拠は弱くなります。OpenAI の例は API キーと Settings の設定を前提にし、Ollama と HuggingFace の例は別のモデル経路を示します。モデルを変えるなら、埋め込みの次元、保存済み index の互換性、再作成の時間、回答の引用範囲を同時に確認します。_static キャッシュの attestation はパッケージの来歴を確認する材料であり、データ処理の正確さや秘密情報の扱いを検査するものではありません。OSS と LlamaParse のどちらを使う場合も、入力資料がどのサービスへ出るかを記録してから実データを投入してください。

編集部の結論

LlamaIndex は、PDF、文書、API、SQL など自分のデータを LLM の検索と生成に接続したい Python 開発者に適しています。最初は llama-index のスターター構成か llama-index-core の最小構成を選び、埋め込み、LLM、ベクトルストア、保存形式を小さな資料集合で検証してください。README は対応数や用途を説明しますが、品質や運用費用を保証するものではありません。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes