「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ステージ †
Loading †
テキストデータを読み込む
Indexing †
テキストデータからインデックスを作成する。
Storing †
テキストデータとインデックスを永続化する。
Querying †
インデックスを使用してテキストデータを検索する。
Evaluation †
検索のリクエストレスポンスを客観的に評価。
機能 †
データの取得 †
生のテキストデータだけでなく、
- ファイル (PDF、ePub、Word、PowerPoint?、Audioなど) や
- Webサービス (Notion、Slack、Wikipediaなど) を
データソースとして利用できる。
インデックスの作成 †
- テキストデータをチャンクに分割し、チャンクからインデックスを作成する。
- さまざまなインデックス化の方法がある（キーワード、ベクトル、グラフ）。
- インデックス化の結果、チャンクに対応して実際取得されるデータはノードと呼ばれる。
- クエリでインデックスを検索し、対応するノードを取得する。
データのストア †
Vector Store、Document Store、Index Storeなどのストアにデータを保存。
- Vector Store
- Document Store
- Index Store
データの検索 †
インデックスを使用してデータを検索
- キーワード検索：キーワードを使用し、文書ベクトルを検索し結果を得る。
- ベクトル検索：クエリもベクトルに変換し、文書ベクトルと 近似最近傍探索（ANN）
- グラフ検索：全文検索後、ノードとエッジから関連文書を検索し結果を得る。
プロバイダ †
1st Party †
各ステージを処理する基本的なライブラリ
3rd Party †
各ステージを処理するライブラリ
- データ取得：LlamaHub?に様々なデータコネクタが提供されている。
- ベクトル化、ストア
- NoSQLデータベース：MongoDBやElasticsearchなどのNoSQLデータベースを使用してデータを保存および検索できる。
- クラウドストレージ: AWS S3やCloudflare R2などのクラウドストレージサービスを利用してデータを保存できる。
- Vectorストア: DeepLake?やFAISSなどを使用して、効率的なベクトル化、ベクトル検索を実現する。
詳細 †
斯々然々で公式を読む事をオススメする。
主要機能 †
Loading †
- Reader
- SimpleDirectoryReader?と言う汎用的なライブラリを利用できる他、
- Readerを使用する代わりに、ドキュメントを直接使用することもできる。
- また、数百のデータ コネクタをLlamaHub?レジストリをダウンロードして使用できる。
- LlamaCloud?のコネクタは、LlamaIndex純正IaaSストレージということだろう。
- ストレージによっては、インデックス化処理がオフロードされているものもあり、その場合、Indexingのプロセスは不要になる。
- node_parser
- API的には、Indexingと同じタイミングで実行されるが、
- 概念的には、Loading、Readerの後に実行されるもの。
- SplitterでChunkに分割する（APIはNodeを返す）。
- Splitterのインスタンスがnode_parserらしい。
- node_parserの単独実行も可能で、show_progressと言ったオプションもある。
- パイプライン（IngestionPipeline?）に組み込んで、複雑なパースを実装することもできる。
- IngestionPipeline?()には、Splitter、Extractor、Embeddingなどを指定できる模様。
Indexing †
- 基本的には、キーワード、ベクトル、グラフなどの検索を使用する。
Storing †
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を設定する。
Querying †
Evaluation †
その他の機能 †
エージェントの構築 †
ワークフローの構築 †
構造化データ抽出 †
トレースとデバッグ †
Index †
VectorStoreIndex †
Semantic Searchで説明済み。
KnowledgeGraphIndex †
GraphRAGで説明した処理に近いが、
- Indexing
コチラはノードからナレッジグラフ（トリプレット）と言うGraphにする。
- Searching
Graph検索、＋オプショナルなVector検索を使用する。
- Graph検索：クエリからキーワードを抽出してナレッジグラフ（トリプレット）を検索
- Vector検索：ノードを直接検索しているもよう
- keyword: keywordで検索
- embedding: embeddingで検索
- hybrid: keywordとembeddingのハイブリッドで検索
- プロンプトとノード（トリプレット（＋オプショナルなチャンク））から回答を生成する。
- 特徴：
- 初手のキーワード抽出に依存してる。
- ナレッジグラフの主語をプロンプトに含めそれがキーワード抽出される必要がある。
- ナレッジグラフのノードとなるキーワードが良くないと上手く辿れない事がある。
PropertyGraphIndex †
概要はGraphRAGで説明済み。
KeywordTableIndex †
キーワード検索
- Indexing
- チャンクからキーワードを抽出してIndexを作成しておく。
- キーワード抽出に３つのオプションがある。
- default：LLMを使用
- simple：正規表現を使用
- rake：RAKEを使用
- Searching
- キーワードでフィルタしたノードをリストする。
- プロンプトとノードのリストから回答を生成する。
- 特徴：キーワード検索なので
- キーワードが含まれていれば漏れることはない。
- セマンティックさが薄れることが予想される。
- キーワード≒セマンティック（固有名詞の説明を求める）のようなシーンでは活用できる。
TreeIndex †
リーフ・ノード（チャンク）から木構造のサマリ・ノードを作成する。
- Indexing
- 親ノードは子ノードのテキストをLLMでサマリしたテキストを保持する。
- 親ノードは指定数の子ノードを持つ。
- 根ノードは複数になることがある。
- Searching
- 根から葉へコンテキストに対応する件が含まれるノードを辿り、
- 最期に葉ノ－ドを取得する（葉の数はパラメタで指定可能）
- プロンプトと葉ノ－ド（チャンク）から回答を生成する。
- 特長
- SummaryIndexよりも処理要求数が少なくて済むので、完了までのリソース消費を節約できる。
- ルートからリーフへ正しく辿れる必要があり、かつ、リーフを元に回答する。
- 根ノードは複数になる≒いくらかコンテキストを変えてインデックス化しているものと思われる。
- しかし、サマリを使う時点である程度のコンテキストが失われる。
SQLIndex †
概要はPandas Dataframe、TextToSQLで説明済み。
- Indexing
- 自然言語のテキストではなく、RDBの2次元表形式データの検索機能を活用
- 自然言語のテキストではないのでチャンクはない。ノードはレコードに対応する。
- NLSQLTableQueryEngine?
- NLSQLTableQueryEngine?はテーブルを指定しプロンプトで検索
- LLMがプロンプトの指示をSQLのクエリに変換して結果を得る。
- それを、LLMに入力して結果を説明させる。
- SQLTableRetrieverQueryEngine?
- DBのスキーマ情報を読ませ、プロンプトからテーブルを選択させる。
- 以上期以降の部分は、NLSQLTableQueryEngine?と同じ。
- NLSQLRetriever
- Retreiverのみを行う。
- RetrieverQueryEngine?でラップすれば、回答の生成が行える。
SummaryIndex †
チャンク自体がIndexで、検索ではQA、Refineテンプレートを繰り返しサマリをする。
- Indexing
事前にチャンクのリストを作成しておく。
- Searching
- 順番、キーワードでフィルタ、embeddingsを使ったtop-k近似検索などでノードをリストする。
- シーケンシャルなノードのリストにQA、Refineテンプレートを繰り返しサマリをする。
- 初回は、QAテンプレートを使用し、クエリとコンテキストでサマリを得る。
- 以降は、Refineテンプレートを使用し、前回の回答とクエリとコンテキストでサマリを改善する。
- 特徴
- ノードを話題によってシーケンシャルにサマリするので、
- 最初と最後では、最後のほうが重要になりそう。つまり、コンテキストの並び順にも影響されそう。
- 全チャンクを処理させると、LLMに対する処理要求数が大きくなり、完了までに多くのリソースを消費する。
DocumentSummaryIndex †
HyDEそのものではないが似ている。
- Indexing
- 先ずチャンクをサマリする。
- これらのサマリのEmbeddingを作成する。
- 「サマリのEmbedding」と「チャンクのノード」を紐付ける。
- サマリを検索して該当するノードを選択
- LLMベース：LLMが「チャンクのノード」を選択する。
- Embeddingベース：Embeddingの類似検索で紐付いたノードを選択する。
- プロンプトとノ－ド（チャンク）から回答を生成する。
参考 †
公式 †
LlamaIndex - LlamaIndex
https://docs.llamaindex.ai/en/stable/
Home †
https://docs.llamaindex.ai/en/stable/
- High-Level Concepts
- Installation and Setup
- How to read these docs
- Starter Examples
- Discover LlamaIndex Video Series
- Frequently Asked Questions (FAQ)
- Starter Tools
Learn †
https://docs.llamaindex.ai/en/stable/understanding/
- Structured Data Extraction
- Tracing and Debugging
Use Cases †
https://docs.llamaindex.ai/en/stable/use_cases/
- Prompting
- Question-Answering (RAG)
- Chatbots
- Structured Data Extraction
Examples †
https://docs.llamaindex.ai/en/stable/examples/
- Agents
- Chat Engines
- Cookbooks
- Customization
Component Guides †
https://docs.llamaindex.ai/en/stable/module_guides/
非公式 †
LlamaIndexのXについてやってみた(v0.10 対応)｜Aya* †
その他 †
Indexing †
Graph †
サンプル †
https://github.com/OpenTouryoProject/DxCommon/blob/master/Notebook/Jupyter/path/TableOfContents.ipynb
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
