メインコンテンツへスキップ

9.6.4 LlamaIndex

この節の位置づけ

LangGraph が「状態の流れとワークフローのオーケストレーションのフレームワーク」に近いとしたら、LlamaIndex はもっと次のようなものに近いです：

知識と文書の整理を中心にしたフレームワーク。

特に得意なのは「マルチロールの協調」そのものではなく、次のような処理です。

  • 文書が入ってきたあと、どう整理するか
  • どう分割するか
  • どうインデックス化するか
  • どう検索するか
  • どう質問の入口にするか

学習目標​

  • LlamaIndex の中心的な抽象概念を理解する
  • なぜ知識・文書シーンに特に向いているのかを理解する
  • Document -> Node -> Index -> Retriever -> Query Engine の流れを読み取れるようになる
  • どんなときに LlamaIndex を優先して考えるべきか判断できるようになる

なぜ多くの LLM プロジェクトは、実はまず「知識システム」なのか？​

すべてのシステムが対話問題を解くわけではない​

実際の LLM アプリケーションの中心は、チャットではなく次のようなものです。

  • 企業ナレッジベースの QA
  • 文書検索
  • 研究資料の統合
  • レポート作成の補助

これらのタスクに共通しているのは：

知識そのものの整理方法が、システム品質を直接左右する。

ここが LlamaIndex の一番価値があるところ​

LlamaIndex は単に「どうモデルを調整するか」を考えるのではなく、次のことを考えます。

  • 文書をどうシステムに取り込むか
  • 情報をどう分割するか
  • 検索構造をどう作るか
  • クエリをどう組み立てるか

なので、すごく実用的に言うと：

LlamaIndex は、純粋なワークフローフレームワークというより、知識システムのフレームワークに近い。

まず最重要の概念を整理しよう​

Document​

もっとも元になる知識単位です。
たとえば：

  • 1 本の記事
  • 1 つの PDF
  • 1 つの Web ページの内容

Node​

Document を分割した、より小さな単位です。
多くの知識システムでは、実際に検索に使うのは文書全体ではなく、もっと細かい粒度の node です。

Index​

これらの node を、検索できる形に整理する方法です。

Retriever​

ユーザーの質問に応じて、関連する node を探し出す役割です。

Query Engine​

「クエリ -> 検索 -> 結果の整理」を、より完成された 1 層としてまとめます。

まずは一言で覚えましょう。

文書は素材、ノードは切り分けた素材、インデックスは倉庫の構造、retriever は商品を探す係、Query Engine はそれをユーザーに渡す窓口です。

まずは純粋な Python でこの流れを見てみよう​

文書 -> ノード​

documents = [
    {"id": "doc1", "text": "コース購入後 7 日以内かつ学習進捗が 20% 未満の場合は返金可能です。"},
    {"id": "doc2", "text": "すべてのプロジェクトを完了し、テストに合格すると修了証が取得できます。"}
]

nodes = []
for doc in documents:
    nodes.append({
        "doc_id": doc["id"],
        "text": doc["text"]
    })

print(nodes)

想定出力：

[{'doc_id': 'doc1', 'text': 'コース購入後 7 日以内かつ学習進捗が 20% 未満の場合は返金可能です。'}, {'doc_id': 'doc2', 'text': 'すべてのプロジェクトを完了し、テストに合格すると修了証が取得できます。'}]

この例はとてもシンプルですが、すでに大事な考え方を表しています。

元の文書は、そのまま質問応答に使うのではなく、インデックス化や検索に向いた知識単位へ先に変換することが多い。

なぜ「文書の取り込み」が知識システムの第一歩なのか？​

元の文書はたいてい汚れている​

実際の文書には、次のようなものが含まれがちです。

  • ヘッダーやフッター
  • 重複した段落
  • 表のノイズ
  • とても長い段落

最初にうまく処理しないと、その後の検索結果も悪くなりやすいです。

だから知識システムの最初の一歩は、たいてい「モデル調整」ではない​

むしろ次のような作業です。

  • 文書を読む
  • クリーニングする
  • 分割する
  • メタデータを付ける

だからこそ、LlamaIndex のようなフレームワークは ingest を特に重視します。

なぜインデックスと検索が中心になるのか？​

知識アプリで一番怖いのは「文書はあるのに、システムが見つけられない」こと​

もし次のような状況なら：

  • 文書が多い
  • ノードが多い
  • 質問の表現がとても柔軟

良いインデックス層と検索層がなければ、その後ろのモデルがどれだけ強くても引っ張られてしまいます。

最小の検索例​

このコードをローカルで実行するなら、先に scikit-learn をインストールしてください。

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity

node_texts = [node["text"] for node in nodes]
vectorizer = TfidfVectorizer(token_pattern=r"(?u)\b\w+\b")
index_matrix = vectorizer.fit_transform(node_texts)

def retrieve(query):
    query_vec = vectorizer.transform([query])
    scores = cosine_similarity(query_vec, index_matrix)[0]
    best_idx = scores.argmax()
    return nodes[best_idx]

print(retrieve("返金ポリシーは何ですか"))

想定出力：

{'doc_id': 'doc1', 'text': 'コース購入後 7 日以内かつ学習進捗が 20% 未満の場合は返金可能です。'}

このコードは、実際には何の抽象概念に対応しているのか？​

実はすでに次のものに対応しています。

  • node
  • index
  • retriever

つまり、LlamaIndex の価値の多くは、この知識の流れをより体系的に整理するところにあります。

なぜ Query Engine を別に取り出す価値があるのか？​

質問応答は「一番似ている段落を返す」だけではないから​

実際のシステムでは、たいてい次のことも考える必要があります。

  • 何件返すか
  • 要約するかどうか
  • 出典を付けるか
  • さらにモデルを呼び出すか

このとき「Query Engine」は、「単体の retriever」よりもシステム層の抽象概念に近くなります。

超ミニマルな Query Engine の例​

def query_engine(query):
    node = retrieve(query)
    return {
        "answer": node["text"],
        "source": node["doc_id"]
    }

print(query_engine("返金ポリシーは何ですか"))

想定出力：

{'answer': 'コース購入後 7 日以内かつ学習進捗が 20% 未満の場合は返金可能です。', 'source': 'doc1'}

この例が教えてくれるのは：

検索は途中段階にすぎず、最終的には結果をユーザー向けの問い合わせ口としてまとめる層が必要だということです。

LlamaIndex と LangGraph の違いを一言で言うと？​

かなり大ざっぱにまとめるなら、こう覚えられます。

  • LangGraph は「タスクの状態をどう流すか」に寄る
  • LlamaIndex は「知識をどう整理するか」に寄る

もちろん実際には組み合わせることもできますが、最初に注目しているポイントは確かに違います。

なので、あなたのプロジェクトの本質が次のようなものなら：

  • 文書 QA
  • ナレッジベースアシスタント
  • RAG の本流

LlamaIndex のような抽象化のほうが、たいてい扱いやすいです。

どんなときは LlamaIndex が主役ではないのか？​

もしシステムがより次のような方向なら：

  • マルチ Agent 協調
  • 複雑なループ
  • 明示的なステートマシン

その場合、LlamaIndex は「メインフレームワーク」ではなく、知識層のコンポーネントに近いかもしれません。

なので、「万能の Agent フレームワーク」と考えるのではなく、次のように捉えるのがよいです。

知識と検索の問題にとても強いフレームワーク。

初学者がよくやるミス​

モデルだけ見て、文書の取り込みを見ない​

知識システムの問題は、入口の文書処理に原因があることが多いです。

インデックスを作れば、もう QA システムは完成だと思ってしまう​

インデックスは中間層であって、プロダクトのゴールではありません。

ワークフロー型フレームワークとの境界がわからない​

その結果、本来あまり得意ではない問題まで解決してくれると期待しがちです。

まとめ​

この節で一番大事なのは、LlamaIndex の API を覚えることではなく、次を理解することです。

LlamaIndex の価値は、文書知識を元のテキストから、検索可能で、引用可能で、問い合わせ可能な構造へと整理していくことにある。

LlamaIndex を「万能フレームワーク」ではなく「知識整理フレームワーク」として見ると、多くの判断がかなりわかりやすくなります。

練習​

  1. Document、Node、Index、Retriever、Query Engine がそれぞれ何に似ているか、自分の言葉で説明してみましょう。
  2. なぜ文書の取り込み品質が、その後の検索結果に直接影響すると言えるのか考えてみましょう。
  3. 自分の知識ベースデータから 3 つノードを作り直して、検索例をもう一度実行してみましょう。
  4. システムの主軸が知識検索ではなくマルチ Agent 協調の場合、なぜ LlamaIndex を「総合フレームワーク」にすべきとは限らないのか説明してください。