現職では、RAG(Retrieval-Augmented Generation)を使ったアプリケーションを構築しています。

RAGを実装するにあたっての有用なライブラリとしてLlamaIndexというものがあります。

https://docs.llamaindex.ai/en/stable/index.html

このドキュメントを読んでみて、今まで自分になかった気づきを軽くまとめておきます。ただの走り書きなのでめちゃ読みにくいです。

気づきたち

  • エンジンは、データへの自然言語アクセスを提供します。例えば： クエリ エンジンは、知識を強化した出力のための強力な検索インターフェイスです。 チャット エンジンは、データとのマルチメッセージの「往復」対話のための会話型インターフェイスです。

「エンジン」という単位がある。

https://docs.llamaindex.ai/en/stable/getting_started/concepts.html#stages-within-rag

  • 読み込み: これは、データが保存されている場所 (テキスト ファイル、PDF、別の Web サイト、データベース、API など) からパイプラインにデータを取得することを指します。 LlamaHub では、数百ものコネクタから選択できます。

RAGのためにデータを読み込むコネクタがLlamaHubに数百ほど公開されている。

https://docs.llamaindex.ai/en/stable/getting_started/concepts.html#querying-stage

  • ルーター: ルーターは、ナレッジ ベースから関連するコンテキストを取得するためにどの取得者を使用するかを決定します。より具体的には、 RouterRetriever クラスは、クエリを実行する 1 つまたは複数の候補取得者を選択する役割を果たします。セレクターを使用して、各候補者のメタデータとクエリに基づいて最適なオプションを選択します。
  • ノード ポストプロセッサ: ノード ポストプロセッサは、取得したノードのセットを受け取り、それらに変換、フィルタリング、または再ランキング ロジックを適用します。
  • レスポンス シンセサイザー: 応答シンセサイザーは、ユーザー クエリと取得されたテキスト チャンクの指定されたセットを使用して、LLM からの応答を生成します。

RAGのクエリする段階においては、ただクエリする以外にもルーティングする、受け取ったノードを加工する、ノードを使ってレスポンスを生成する、という概念が実装されている。

https://docs.llamaindex.ai/en/stable/getting_started/concepts.html#putting-it-all-together

  • クエリ エンジン: クエリ エンジンは、データに対して質問できるようにするエンドツーエンドのパイプラインです。自然言語クエリを受け取り、取得して LLM に渡した参照コンテキストとともに応答を返します。
  • チャット エンジン: チャット エンジンは、データと会話するためのエンドツーエンドのパイプラインです (1 回の質疑応答ではなく、複数回のやり取り)。
  • エージェント: エージェントは、一連のツールを介して世界と対話する、LLM を利用した自動化された意思決定者です。エージェントは、所定のタスクを完了するために任意の数のステップを実行し、事前に決められたステップに従うのではなく、最適な行動方針を動的に決定できます。これにより、より複雑なタスクに取り組むための柔軟性がさらに高まります

RAGアプリケーションは大きくこの3つに別れる。

https://docs.llamaindex.ai/en/stable/use_cases/extraction.html

  • LLM は、大量の非構造化データを取り込んで構造化形式で返すことができ、LlamaIndex はこれを簡単にするように設定されています。 LlamaIndex を使用すると、LLM に自然言語を読み取り、名前、日付、住所、数値などの意味的に重要な詳細を識別させ、ソース形式に関係なく、それらを一貫した構造化形式で返すことができます。 これは、チャット ログや会話トランスクリプトなどの非構造化ソース資料がある場合に特に便利です。 構造化データを取得したら、それをデータベースに送信したり、コードで構造化出力を解析してワークフローを自動化したりできます。

非構造化データにおける名前、日付、住所、数値などの意味的に重要な詳細を構造化形式で抽出するユースケースも紹介されている。

https://docs.llamaindex.ai/en/stable/use_cases/multimodal.html

  • マルチモーダル RAG (検索拡張生成) 検索拡張画像キャプション
  • 画像推論のための LLaVa-13、Fuyu-8B、MiniGPT-4
  • マルチモーダル LLM モデルの比較
  • マルチモーダル LLM の構造化出力を生成するための Pydantic プログラム
  • GPT4-V を求める思考連鎖 (COT) マルチモーダル RAG の簡単な評価
  • 単一ベクトル ストアによるマルチモーダル検索に Chroma を使用する
  • Microsoft を使用した表を含む PDF 上のマルチモーダル RAG Table Transformer

マルチモーダルRAGに関していろんなユースケースがある。

https://docs.llamaindex.ai/en/stable/understanding/loading/llamahub.html

  • Browse LlamaHub directly to see the hundreds of connectors available, including:
    • Notion (NotionPageReader)
    • Google Docs (GoogleDocsReader)
    • Slack (SlackReader)
    • Discord (DiscordReader)
    • Apify Actors (ApifyActor). Can crawl the web, scrape webpages, extract text content, download files including .pdf, .jpg, .png, .docx, etc.

あらゆる形式のデータのコネクタを実装するのは大変なので、一旦LlamaHubのローダーを使うのはアリかも。

https://docs.llamaindex.ai/en/stable/module_guides/loading/documents_and_nodes/root.html

  • ドキュメント は、PDF、API 出力、データベースから取得したデータなど、あらゆるデータ ソースの汎用コンテナです。 。これらは手動で構築することも、データ ローダーを介して自動的に作成することもできます。デフォルトでは、ドキュメントには他の属性とともにテキストが保存されます。その一部を以下に示します。
    • metadataテキストに追加できる注釈の辞書。
    • relationships他のドキュメント/ノードとの関係を含む辞書。

ドキュメントとドキュメントがrelationshipを持つこともある。

https://docs.llamaindex.ai/en/stable/module_guides/loading/documents_and_nodes/usage_documents.html

  • 通常、ドキュメントには多くのメタデータ キーが含まれますが、応答合成中にそれらのすべてを LLM に表示したくない場合があります。上記の例では、LLM にドキュメントの file_name を読み取らせたくない場合があります。ただし、 file_name には、より適切な埋め込みを生成するのに役立つ情報が含まれる場合があります。これを行う主な利点は、LLM が最終的に読み取る内容を変更せずに、取得用の埋め込みにバイアスをかけることができることです。

ドキュメントとメタデータを常に一緒に取り回せるようになっていて、ベクトル埋め込み生成時やレスポンス合成時にLLMに食わせるかどうかをドキュメントごとに切り替えられるようになっている。

  • ご存知のとおり、メタデータは、LLM または埋め込みモデルに送信されるときに、各ドキュメント/ノードの実際のテキストに挿入されます。デフォルトでは、このメタデータの形式は次の 3 つの属性によって制御されます。
    1. Document.metadata_seperator>デフォルト ="\\n"
    メタデータのすべてのキー/値フィールドを連結する場合、このフィールドは各キー/値ペア間の区切り文字を制御します。
    1. Document.metadata_template>デフォルト ="{key}: {value}"
    この属性は、メタデータ内の各キーと値のペアの形式を制御します。 2 つの変数 key と value 文字列キーが必要です。
    1. Document.text_template>デフォルト ={metadata_str}\\n\\n{content}
    metadata_seperator と metadata_template を使用してメタデータが文字列に変換されると、このテンプレートは、メタデータがテキスト コンテンツと結合されたときにどのように表示されるかを制御します。ドキュメント/ノード。 metadata および content 文字列キーは必須です。

ベクトル埋め込み生成時は、必ずメタデータとコンテンツを1つに文字列にして生成することが前提になっている。

https://docs.llamaindex.ai/en/stable/module_guides/loading/documents_and_nodes/usage_metadata_extractor.html

  • 当社のメタデータ抽出モジュールには、次の「特徴抽出モジュール」が含まれています。
    • SummaryExtractor一連のノードの概要を自動的に抽出します
    • QuestionsAnsweredExtractor各ノードが回答できる一連の質問を抽出します
    • TitleExtractor各ノードのコンテキストに基づいてタイトルを抽出します
    • EntityExtractor各ノードのコンテンツ内で言及されているエンティティ (つまり、場所、人、物の名前) を抽出します

ノードに対してメタデータを抽出する方法としてこのような手段が用意されている。EntityExtractorとか内部がどうなってるのか気になる。

https://docs.llamaindex.ai/en/stable/examples/metadata_extraction/MetadataExtractionSEC.html

QuestionsAnsweredExtractorと TitleExtractorを使ってメタデータを付与してからインデクシングを行うと、UberとLyftのドキュメントを混同せずに回答してくれるという例。サブクエリエンジンも使われておりUberとLyftの情報を分けて取得しに行っているにもかかわらず、メタデータなしだとUberとLyftのデータを混同している。

https://docs.llamaindex.ai/en/stable/examples/metadata_extraction/MetadataExtraction_LLMSurvey.html

QuestionAnsweredExtractor と SummaryExtractor を使うことで、より詳細の情報が提供されるという例。こんなメタデータが付与される。

[Excerpt from document]
prev_section_summary: The section discusses the F_{BERT} formula used in BERTScore and highlights the advantages of BERTScore over simpler metrics like BLEU and ROUGE. It also introduces MoverScore, another metric that uses contextualized embeddings but allows for many-to-one matching. The key topics are BERTScore, MoverScore, and the differences between them.
next_section_summary: The section discusses the comparison between BERTScore and MoverScore, two metrics used to evaluate the quality of text generation models. MoverScore is described as a metric that measures the effort required to transform one text sequence into another by mapping semantically related words. The section also highlights the limitations of conventional benchmarks and metrics, such as poor correlation with human judgments and low correlation with tasks requiring creativity.
section_summary: The key topics of this section are BERTScore and MoverScore, which are methods used to compute the similarity between generated output and reference in tasks like image captioning and machine translation. BERTScore uses one-to-one matching of tokens, while MoverScore allows for many-to-one matching. MoverScore solves an optimization problem to measure the distance that words would have to move to convert one sequence to another.
questions_this_excerpt_can_answer: 1. What is the main difference between BERTScore and MoverScore?
2. How does MoverScore allow for many-to-one matching of tokens?
3. What problem does MoverScore solve to measure the distance between two sequences?
Excerpt:
-----
to have better correlation for tasks
such as image captioning and machine translation.

**[MoverScore](https://arxiv.org/abs/1909.02622)** also uses contextualized
embeddings to compute the distance between tokens in the generated output and
reference. But unlike BERTScore, which is based on one-to-one matching (or
“hard alignment”) of tokens, MoverScore allows for many-to-one matching (or
“soft alignment”).

![BERTScore \(left\) vs. MoverScore \(right\)](/assets/mover-score.jpg)

BERTScore (left) vs. MoverScore (right;
[source](https://arxiv.org/abs/1909.02622))

MoverScore enables the mapping of semantically related words in one sequence
to their counterparts in another sequence. It does this by solving a
constrained optimization problem that finds the minimum effort to transform
one text into another. The idea is to measure the distance that words would
have to move to convert one sequence to another.

However, there
-----

まとめ

今日はここまで。。。