LangChain RetrievalQAとChatGPTで QAツールを作る 2023/11/25 第29回勉強会

自己紹介 ● 名前: 西岡 賢一郎 ○ Twitter: @ken_nishi ○ note: 西岡賢一郎@研究者から経営者へ (https://note.com/kenichiro) ○ YouTube: 【経営xデータサイエンスx開発】西岡 賢一郎のチャンネル (https://www.youtube.com/channel/UCpiskjqLv1AJg64jFCQIyBg) ● 経歴 ○ 東京大学で位置予測アルゴリズムを研究し博士 (学術) を取得 ○ 東京大学の博士課程在学中にデータサイエンスをもとにしたサービスを提供する株式会社ト ライディアを設立 ○ トライディアを別のIT会社に売却し、CTOとして3年半務め、2021年10月末にCTOを退職 ○ CDPのスタートアップ (Sr. PdM)・株式会社データインフォームド (CEO)・株式会社ディース タッツ (CTO) ○ 自社および他社のプロダクト開発チーム・データサイエンスチームの立ち上げ経験

本日のお話 ● LLMの限界と解決策 ● RAG (Retrieval Augmented Generation) ● LangChainを使ったRAGの実装 ● デモ

LLMの限界と解決策

大規模言語モデル（LLM）の限界 ● 訓練データへの依存 ○ LLMは、訓練に使用されたテキストデータに基づいて学習する。 ○ 特定の情報や最新のデータが不足している場合、不正確な回答を生成する可能性がある。 ● 「ハルシネーション」の問題 ○ LLMは時に、実際には存在しない情報を生成することがある。 ○ これは、モデルが訓練データからのみ情報を引き出すために起こる。 ● ユーザー期待との不一致 ○ モデルがユーザーの期待に沿った応答をしないことがある。 ○ これは、モデルの訓練データがユーザーの特定のニーズや文脈を完全には反映していないた め。

ファインチューニング VS 外部リソース活用 LLMの欠点を克服するための2つのアプローチ ● ファインチューニング ○ 訓練済みモデルの一部もしくは全体を、別のデータセットを使って再トレーニング。 ○ 利点: 特定のタスクやドメインに特化させることが可能。 ○ 欠点 ■ 過度に最適化されて、モデルの汎用性がなくなることがある。 ■ 計算資源と時間を多く要する。 ● 外部リソースの活用 → RAG (Retrieval Augmented Generation) ○ データベースなど、LLM外部のリソースと連携させる ○ 利点: 最新のデータや企業独自データなどを組み込み、より正確な回答を生成できる。 ○ 欠点 ■ 性能がデータベースに大きく依存する ■ 検索結果が不完全・不正確な場合、生成される回答もそれらに影響を受ける。

RAG (Retrieval Augmented generation)

RAG（Retrieval Augmented generation）のアーキテクチャ ● 質問に関連した外部リソースをLLMに連携し、LLMの回答の精度を高める手法 ● 外部リソースのデータ検索のプロセス ○ RAGでは、入力されたプロンプトに基づいてデータを検索し、その結果をLLMに組み込んで回答を生 成 ○ 検索サーバの設置が必要。 ● 検索方式の多様性 ○ RAGでは、キーワード検索とセマンティック検索（ベクターサーチ）の両方が利用される。 ○ セマンティック検索では、入力されたプロンプトをベクトルに変換し、関連するデータを検索。今回 はこちらを利用。 ● 文章の分割とサマリ ○ LLMの入力制限に対応するため、データは適切に分割され、必要に応じてサマリされる。 ○ これにより、ベクトル内の情報が適切に反映されるように管理される。 ● Vector Databaseの役割 ○ RAGのセマンティック検索には、Vector Databaseが重要。これにより、プロンプトに関連するデー タを効率的に検索が可能になる。

Vector Databaseとは ● Vector Databaseは、ベクトル埋め込みを効率的に保存・管理する特殊なデータ ベース。 ● AIアプリケーション、特に大規模言語モデル（LLM）にとって、長期記憶や高速検 索・クエリ能力を提供。 ● ベクトル (テキスト) 埋め込み（Vector Embedding） ○ ベクトル埋め込みは、オブジェクトが数値のリストに変換され、非構造化データを検索可能にする。 ○ 機械学習アルゴリズムを使用して、複雑なデータを低次元のベクトル空間に表現。 ● 最近傍探索（Nearest Neighbour Search） ○ ベクトル間の距離は類似性を表し、最も類似したデータを探す「最近傍探索」が重要な概念。 ○ 最近傍を迅速に見つける能力が、Vector Databaseの価値となる。 ● Vector Databaseの必要性 ○ 伝統的なデータベースにベクター拡張を追加することも可能だが、、特化型Vector Databaseが必要 という議論もある。

RAGのアーキテクチャ: インデックス作成 ● RAGを実現するためには、手元にある文書をベクトル化して、Vector Databaseに保存する。 ● 「文書を読み込む」→ 「文書を分割する」→「分割された文書をベクトル 化」→「ベクトル化された文書と文書情報をVectore Storeに保存」

RAGのアーキテクチャ: LLMのプロンプト作成 ● ユーザの質問に関連した文書をプロンプトに埋め込み、LLMに答えさせられ るようにする。 ● 「ユーザの質問をベクトル化」→「Vectore Databaseで関連文書を抽出」→ 「抽出された文書をPromptに埋め込む」 ● インデックス作成も含めると、LLMとのやりとりなど、各システム間のやり 取りが多く発生し、それぞれのアウトプットの連携が複雑になりがち。

LangChainを使ったRAGの実装

RAGの実装をLangChainで簡単に実現する ● LangChainは、追加のデータソースを組み込むことで、大規模言語モデル （LLM）を拡張することができるライブラリ ● LLMと外部リソースの連携を簡単にし、LLM単体では不可能だったことを可 能とする。 ● 利点 ○ 訓練データに限定されない柔軟性。 ○ 新しい情報や特定のコンテキストに対応可能。 ● 応用例 ○ リアルタイムのニュースデータ、企業内のプライベートデータベース、特定の科学的研究な ど、多様なデータソースに適用可能。

LangChainを使用したQAツールの構築 LangChainを使用して、テキストデータソース上で簡単な質問応答アプリケーションを構築 ● アーキテクチャ ○ インデックス作成: DocumentLoaderを使ってデータを取り込み、Vectore Storeを使ってインデックスを作 成 ○ LLMのプロンプト作成: ユーザーの質問を受け取り、Vectore Storeを使って関連データを検索し、関連デー タからプロンプトを作成 ● 実装手順 ○ データのロード: DocumentLoadersを使用してデータをロード。 ○ テキストの分割: 大きなドキュメントを小さなチャンクに分割。 ○ ストレージとインデックス作成: 分割したテキストをストレージに保存し、インデックスを作成。 ○ 検索と生成: ユーザーの入力に基づいて関連するテキストを検索し、チャットモデル/LLMを使用して回答を生 成。ここで今回の発表タイトルにあるRetrievalQAを利用する。 ● 補足 ○ DocumentLoader: PDFやウェブページなど色々なデータソースからデータを取り込むもの。 ○ Vectore Store: Vectore Databaseを操作するためのラッパー。ベクトルの保存や検索を担う。

デモ ● デモの内容 ○ テキスト埋め込み (Embedding) の基本 ○ Vector Databaseの基本 ○ RetrievalQAを使った検索 ● ソースコード https://github.com/knishioka/machine-learning-workshop/blob/main/l angchain/RetrievalQA.ipynb