LlamaIndex のバックアップ(No.27)

ベクトル化、ストア
- NoSQLデータベース：MongoDBやElasticsearchなどのNoSQLデータベースを使用してデータを保存および検索できる。
- クラウドストレージ: AWS S3やCloudflare R2などのクラウドストレージサービスを利用してデータを保存できる。
- Vectorストア: DeepLake?やFAISSなどを使用して、効率的なベクトル化、ベクトル検索を実現する。

↑

詳細 †

斯々然々で公式を読む事をオススメする。

↑

主要機能 †

↑

Loading †

データの取得

生のテキストデータだけでなく、

ファイル (PDF、ePub、Word、PowerPoint?、Audioなど) や
Webサービス (Notion、Slack、Wikipediaなど) を

データソースとして利用できる。

Reader
- SimpleDirectoryReader?と言う汎用的なライブラリを利用できる他、
- Readerを使用する代わりに、ドキュメントを直接使用することもできる。
- また、数百のデータコネクタをLlamaHub?レジストリをダウンロードして使用できる。
- LlamaCloud?のコネクタは、LlamaIndex純正IaaSストレージということだろう。
- ストレージによっては、インデックス化処理がオフロードされているものもあり、その場合、Indexingのプロセスは不要になる。

↑

Indexing †

インデックスの作成

テキストデータをチャンクに分割し、チャンクからインデックスを作成する。
さまざまなインデックス化の方法がある（キーワード、ベクトル、グラフ）。
インデックス化の結果、チャンクに対応して実際取得されるデータはノードと呼ばれる。
クエリでインデックスを検索し、対応するノードを取得する。

node_parser
- API的には、Indexingと同じタイミングで実行されるが、
- 概念的には、Loading、Readerの後に実行されるもの。
- SplitterでChunkに分割する（APIはNodeを返す）。
- Splitterのインスタンスがnode_parserらしい。
- node_parserの単独実行も可能で、show_progressと言ったオプションもある。
- パイプライン（IngestionPipeline?）に組み込んで、複雑なパースを実装することもできる。
- IngestionPipeline?()には、Splitter、Extractor、Embeddingなどを指定できる模様。

基本的には、キーワード、ベクトル、グラフなどの検索を使用する。
- ベクトル：VectorStoreIndex

グラフ：Graph RAG
- KnowledgeGraphIndex：RDF、トリプレット
- PropertyGraphIndex：プロパティグラフ

その他の検索

その他
- SummaryIndex
- DocumentSummaryIndex

参考：https://docs.llamaindex.ai/en/stable/module_guides/indexing/index_guide/

↑

Storing †

データのストア

Vector Store、Document Store、Index Storeなどのストアにデータを保存。
- Vector Store
- Document Store
- Index Store

Document Store、Vector Store、Index Storeに、Storage Contextを設定する。
- Document Store：既出の、Loadingの所で、Document Storeから読み出している。
- Indexingで、Vector Store と Index Storeに書き出し（永続化し）ている。
- DBにストア機能とサーチ機能が実装されているような場合、
  - Vector Store、Index Storeには同じDBのStorage Contextを設定する。
  - 一部のIndex機能では、NoSQL的ストアを使用しないと使用できないSearchオプションがある。

区分	インデックス	特性	適合する NoSQL
ベクトル	VectorStoreIndex	ベクトルデータ管理	ANN Pinecone, Weaviate, Milvus, Qdrant, Redis
グラフ	KnowledgeGraphIndex、PropertyGraphIndex	グラフデータ（ノードとエッジ）管理	Neo4j, ArangoDB, Amazon Neptune, TigerGraph?, JanusGraph?

↑

Querying †

データの検索

インデックスを使用してデータを検索
- キーワード検索：キーワードを使用し、文書ベクトルを検索し結果を得る。
- ベクトル検索：クエリもベクトルに変換し、文書ベクトルと近似最近傍探索（ANN）
- グラフ検索：全文検索後、ノードとエッジから関連文書を検索し結果を得る。

↑

Evaluation †

人手に依らない、マシンによるインデックスの評価機能を持つ。

↑

Index †

↑

VectorStoreIndex †

Semantic Searchで説明済み。

↑

KnowledgeGraphIndex †

GraphRAGで説明した処理に近いが、

Indexing
コチラはノードからナレッジグラフ（トリプレット）と言うGraphにする。

Searching
Graph検索、＋オプショナルなVector検索を使用する。

Graph検索：クエリからキーワードを抽出してナレッジグラフ（トリプレット）を検索
Vector検索：ノードを直接検索しているもよう
- keyword: keywordで検索
- embedding: embeddingで検索
- hybrid: keywordとembeddingのハイブリッドで検索

プロンプトとノード（トリプレット（＋オプショナルなチャンク））から回答を生成する。

特徴
- 初手のキーワード抽出に依存してる。
- ナレッジグラフの主語をプロンプトに含めそれがキーワード抽出される必要がある。
- ナレッジグラフのノードとなるキーワードが良くないと上手く辿れない事がある。

↑

PropertyGraphIndex †

概要はGraphRAGで説明済み。
KnowledgeGraphIndexのトリプレットの表現力の課題を解決すると言われている。
- ノードと（ノード間の）関係性にラベルとプロパティを割り当てれない
- ノードをベクトル埋め込みとして表現できない。
- ベクトル検索と記号検索の両方を実行できない。

Indexing

グラフ抽出に３つのオプションがある。
- SimpleLLMPathExtractor?は、KnowledgeGraphIndex?的トリプレットのグラフを作成
- ImplicitPathExtractor?は、LlamaIndexのnode.relationshiopsを使って、グラフを作成
- SchemaLLMPathExtractor?は、指定したスキーマに従い、グラフを作成

Searching

複数のretrieverを組み合わせることができる。
retrieverの機能をフルに使おうと思うと、Neo4jやNeburaGraph?を使う必要がある。

LLMSynonymRetriever?：LLMを使って、クエリからキーワード・シノニムを生成して、ノードを検索
VectorContextRetriever?：ノードのベクトル類似度から、ノードを検索
TextToCypherRetriever?：PropertyGraphStore?が対応している場合のみ、LLMを使って、CypherというGraphDB用クエリ言語に変換して検索
CypherTemplateRetriever?：TextToCypherRetriever?と同じくCypherを使うが、Cypherの定義をテンプレートで渡す限定版的なもの

特徴
- なんとなく期待値が高すぎて使うとがっかりするらしい。
- KnowledgeGraphIndex?の課題を解決と言う程でもなさそうな感じ。
- 複雑な割に効果が薄い、なにか特定のユースケースで効果的なのか？

↑

KeywordTableIndex †

キーワード検索

Indexing
- チャンクからキーワードを抽出してIndexを作成しておく。
- キーワード抽出に３つのオプションがある。
  - default：LLMを使用
  - simple：正規表現を使用
  - rake：RAKEを使用

Searching
- キーワードでフィルタしたノードをリストする。
- プロンプトとノードのリストから回答を生成する。

特徴：キーワード検索なので
- キーワードが含まれていれば漏れることはない。
- セマンティックさが薄れることが予想される。
- キーワード≒セマンティック（固有名詞の説明を求める）のようなシーンでは活用できる。

↑

TreeIndex †

リーフ・ノード（チャンク）から木構造のサマリ・ノードを作成する。

Indexing
- 親ノードは子ノードのテキストをLLMでサマリしたテキストを保持する。
- 親ノードは指定数の子ノードを持つ。
- 根ノードは複数になることがある。

Searching
- 根から葉へコンテキストに対応する件が含まれるノードを辿り、
- 最期に葉ノ－ドを取得する（葉の数はパラメタで指定可能）
- プロンプトと葉ノ－ド（チャンク）から回答を生成する。

特長
- SummaryIndexよりも処理要求数が少なくて済むので、完了までのリソース消費を節約できる。
- ルートからリーフへ正しく辿れる必要があり、かつ、リーフを元に回答する。
- 根ノードは複数になる≒いくらかコンテキストを変えてインデックス化しているものと思われる。
- しかし、サマリを使う時点である程度のコンテキストが失われる。

↑

SQLIndex †

概要はPandas Dataframe、TextToSQLで説明済み。

Indexing
- 自然言語のテキストではなく、RDBの2次元表形式データの検索機能を活用
- 自然言語のテキストではないのでチャンクはない。ノードはレコードに対応する。

Searching
クエリは3つの方法がある。

NLSQLTableQueryEngine?
- NLSQLTableQueryEngine?はテーブルを指定しプロンプトで検索
- LLMがプロンプトの指示をSQLのクエリに変換して結果を得る。
- それを、LLMに入力して結果を説明させる。

SQLTableRetrieverQueryEngine?
- DBのスキーマ情報を読ませ、プロンプトからテーブルを選択させる。
- 以上期以降の部分は、NLSQLTableQueryEngine?と同じ。

NLSQLRetriever
- Retreiverのみを行う。
- RetrieverQueryEngine?でラップすれば、回答の生成が行える。

↑

SummaryIndex †

チャンク自体がIndexで、検索ではQA、Refineテンプレートを繰り返しサマリをする。

Indexing
事前にチャンクのリストを作成しておく。

Searching
- 順番、キーワードでフィルタ、embeddingsを使ったtop-k近似検索などでノードをリストする。
- シーケンシャルなノードのリストにQA、Refineテンプレートを繰り返しサマリをする。
  - 初回は、QAテンプレートを使用し、クエリとコンテキストでサマリを得る。
  - 以降は、Refineテンプレートを使用し、前回の回答とクエリとコンテキストでサマリを改善する。

特徴
- ノードを話題によってシーケンシャルにサマリするので、
  - 件が漏れることを回避できる可能性がある。
  - "Keyword"TableIndexと比べると、"Summary"Indexは、セマンティックさを保持できる。
- 最初と最後では、最後のほうが重要になりそう。つまり、コンテキストの並び順にも影響されそう。
- 全チャンクを処理させると、LLMに対する処理要求数が大きくなり、完了までに多くのリソースを消費する。

↑

DocumentSummaryIndex †

HyDEそのものではないが似ている。

Indexing
- 先ずチャンクをサマリする。
- これらのサマリのEmbeddingを作成する。
- 「サマリのEmbedding」と「チャンクのノード」を紐付ける。

Searching

サマリを検索して該当するノードを選択
- LLMベース：LLMが「チャンクのノード」を選択する。
- Embeddingベース：Embeddingの類似検索で紐付いたノードを選択する。

プロンプトとノ－ド（チャンク）から回答を生成する。

↑

その他の機能 †

↑

パイプライン †

Loading、Indexing、Storing、Querying、Evaluationプロセスの設計・実装をカスタマイズする。

様々なpipeline

Ingestion Pipeline、Data Transformation Pipeline
- データの加工や変換に特化したパイプライン。
- データ取得、データ正規化、トークン化、保存

Index Pipeline
- データをインデックス化するための処理パイプライン。
- データソースからデータ取得、前処理、インデックス構築

Query Pipeline
- クエリ処理を複数のステージで行うパイプライン。
- クエリ解析、インデックス検索、フィルタリング、応答生成

RAG Pipeline
- 外部データを活用して生成的な応答を行うパイプライン。
- 情報検索（Retrieval）、文脈強化（Context Augmentation）、応答生成

Multi-Index Query Pipeline
- 複数のインデックスを統合してクエリ処理を行うパイプライン。
- クエリ分割、個別検索、結果統合、最終応答生成

Custom Workflow Pipelines
- ユーザーが独自の処理フローを設計可能なカスタムパイプライン。
- 特定業界向けの独自ソリューション、複雑なビジネスプロセスに対応するカスタムシステム。

↑

ワークフローの構築 †

Pipeline は、データ処理やインデックス構築のためのシンプルかつ直線的なフローを構築するのに適しているが、
Workflow は、より、複雑なタスクや動的な処理を管理し、条件に応じた柔軟な操作を実現するのに適している。

LangFlowとかAzure のプロンプトフローとかソレ系統の機能。
ただし、RAGに特化した仕様で、非構造化データや外部データベースを利用した情報取得とプロンプト設計に強みがある。
かつ、LangFlowや Azure のプロンプトフローにあるGUIのデザイナ機能は提供されていない。

↑

エージェントの構築 †

最近では、システムによる自動化されたプロンプトエンジニアリング、プロンプトフローを
ReAct的プロンプトエンジニアリングを用い更にファジー化した、エージェント・システムが注目されている。

↑

構造化データ抽出 †

↑

トレースとデバッグ †

LLMツールは、高度に抽象化されていることから内部でどのような処理がされているか通常は見えないことが多い。

↑

インデックス評価 †

特徴	VectorStoreIndex	PropertyGraphIndex
データ構造	ベクトル	プロパティグラフ
検索方法	ベクトル検索	グラフクエリ言語（例：Cypher）
ノードの管理	ドキュメントをノードに分割しベクトル化	ノード（エンティティ）とエッジ（関係）
クエリの複雑さ	シンプルな意味的類似性検索	複雑なCypherクエリをサポート
ハイブリッド検索	なし	ベクトル検索とグラフを用いた検索をサポート
用途	意味的な類似性に基づく検索	データの関係性を重視した検索

↑

VectorStoreIndex †

「シンプルな意味的類似性検索」だが強力といえば強力
主要な用途にRAGが含まれる。
初回のEmbeddingさえ終われば、以降、Indexing、Searchingに大きなコストがかからない。

↑

PropertyGraphIndex †

ベクトル検索に比べて強力と言う触れ込みがあったが、実はそれほどではない。
主要な用途は、KB構築で、RAGが含まれない。RAGに応用されたイメージ。
Indexingのグラフ作成に多くのコスト（LLMへの要求）が発生し、大規模データには向かない。

ベクトル検索とグラフ検索（シンボリック検索）を併用
- グラフ検索：ノード間のパスを探索し、関連するデータを検索します。
- シンボリック検索：データのシンボル（名前、属性、関係など）を使用して検索を行います。

LLMにはチャンクと、チャンクから抽出したグラフ情報が追加されて渡される。

↑

SummaryIndex †

ランク上位のチャンクしか抜かないVectorStoreIndex、PropertyGraphIndexと異なり全体要約が可能。
全体要約するので、Indexingは、ただのチャンクで、Searchingは、全チャンクの要約になる。
Searchingの全チャンク要約に多くのコスト（LLMへの要求）が発生し、大規模データには向かない。

QA、Refineテンプレートを繰り返しの中で、誤りや、欠落が発生すると全体が破綻する（評価中に実際に発生）。

↑

独自プロンプトフロー †

SummaryIndexの仕組みなどを確認すれば、全体要約は、一種のプロンプトフローに過ぎない事が解る。

そのため、以下のような独自のプロンプトフローで実装が可能と考えられる。
- VectorStoreIndexを使用しTOPではなく、類似度スコアの閾値を超えるチャンクを収集して、要約する。
- QA、Refineのような直列の要約ではなく並列で要約し、プロンプトに適合した要約が含まれる場合、コレを次の入力に統合する。