背景や目的

・先日ローカルLLMの基本環境を構築したので、今回はそれでRAGができるか試してみます。
（関連記事：「→性能の良さそうなローカルLLM３つを動作確認しました」）
・実用レベルにすることを念頭に置き、本番に近いデータで試してみます。

先日のおさらい(2024年9月の実験)

・LLMの確認環境としてOpen WebUIを採用し、ローカルでセットアップしました。
・モデル自体は、ELYZA-JP、gemma、Phiをそれぞれ試し、ELYZA-JPが良かったです。
・RAGはOpen WebUIの機能そのままでも使えそうでしたが、詳細確認はしていません。
・以下は、その時にぼんやり考えていた事です。
　- VectorStoreは別の何かで作った方が良い？
　- そうなるとOpen WebUIのカスタマイズになるのか？

Open WebUIの再確認：標準RAG機能

・さて、今回はOpen WebUIを開き、まずRAGの標準機能を入念にチェックしてみます。
・ちなみに、利用した環境は以下の通りです。

・セットアップ手順は、こちらにありますので、必要な方はご参照下さい。
（関連記事：「→性能の良さそうなローカルLLM３つを動作確認しました」）

・RAGの機能面をチェックした結果は以下の通りでした。

・以下は、操作時の画面です。

Open WebUIの再確認：DB直接操作

・さらに、データは別途投入出来た方が良いのかも・・と思い、直接操作できるか試しました。
・操作するためにインストール済ファイルをgrep等で調べ、わかった事は以下の通りです。

・上記のpathとcollection名を使ってpythonコードを作成し、登録したファイルから作成されたと思われるデータを見る事が出来ました。確認した値は、以下の通りです。
　- 収容データの数(idsの数)：１ファイルの内容が勝手に(?)分割されて格納されていました。
　- id別の、中身(documents)、ベクター値(embeddings)、付帯情報(metadatas)
・実行時のコードです。ご参考までに。（pathやnameは実際の値をセットして下さい。）

import chromadb

chroma_client = chromadb.PersistentClient(path="~/venv/lib/python3.11/site-packages/data/vector_db")
collection = chroma_client.get_collection(name="16b6a・・・7ff38")

print('Total documents in collection:',collection.count()) #収容件数を表示

documents = collection.get()
i=1
for id_num in documents['ids']: #データ内容、付属情報を出力(10行-14行)
  print('No.',i,'ids:',id_num)
  doc = collection.get(id_num)
  print(f"ids: {doc['ids']}\ndocuments: {doc['documents']}\nmetadatas: {doc['metadatas']}\n-----------------")
  i+=1
for id_num in documents['ids']: #ベクター値を出力させたい場合はこちら(15行-19行)
  print('No.',i,'ids:',id_num)
  doc = collection.get(id_num,include=['embeddings'])
  print(f"embeddings: {doc['embeddings']}\n-----------------")
  i+=1

Open WebUIの再確認：DOCSスキャン

・画面内に”DOCS_DIR (/data/docs) からドキュメントをスキャン”というボタンがあり、これも調べてみました。
・先程と同様にインストール済ファイルをみたり、動作させて分かった事は以下の通りです。

・別システムとの連携処理用の仕組みなのか・・、これ以上は未確認です。

Open WebUIの再確認：会話履歴

・画面内に表示されている会話の保存先（会話履歴）が気になり、これも少し調べました。
　わかった事は以下の通りです。

・いずれにせよ、前の会話が考慮されていて機能的な問題は無さそうです。

・色々調べてみましたが、結論として標準機能で構築する事にしました。本番に近いデータを使う事で課題がみえてくるはずと考えつつ、インストールに進みます。

インストール：環境やソフトウェア

・RAGを試すためのインストールを始めます。とにかくOpen WebUIが必要です。下表の環境でセットアップした例を、関連記事にて紹介しています。まだの方はそちらをご参照下さい。
　関連記事：「→性能の良さそうなローカルLLM３つを動作確認しました」

インストール：データファイル作成

・ベクターストアの元データとして、提供中システムのサポート対応記録を利用してみます。
・利用する元データの概要です。

・以下はデータの中身の抜粋です。シリアル番号「問合せID」で識別可能なQAの情報です。

・元データがCSVなので、AI処理(テキスト生成)で参照され易い形にしておきます。

・それら（個々のQA）を６６１件結合して、テキストファイルとして保存したら完了です。

・作成したファイルは以下のような内容です（一部抜粋、システム名は伏字）。

インストール：ファイルの登録(=DB作成)

・作成したデータファイルを登録します。
・Open WebUIを開き、画面左部ワークスペース、上段ドキュメント、の順にクリックします。

・ドキュメントの画面で、＋をクリックし、先ほどのファイルを指定します。

・ファイルを指定後、保存を押せば完了です。内部でDB作成がされています。（約５秒）

・pythonコードでChromaDB内を直接確認しました。とりあえず全部入っています。

・実際には分割されていて、186個に分けらていました。画面内の設定値「チャンクサイズ(デフォルト1500)」で制御されていそうです。

・これでRAGのインストールは完了しました。試験に進みます。

試験仕様

・以前にGPT-4 Turboを使用しクラウドベースでRAGを構築した事があり、それと比較できるように、その時の試験内容を抜粋して、試す事にしました。
（以前の実験：→本番データでのRAGシステム構築例紹介）
・実際の試験項目です。
　- 試験１．～ ４．検索と回答生成が適切（情報が存在するケース１～４）
　- 試験５．６． 前提情報不足を考慮できるか（ケース１、２）
　- 試験７．８．情報が存在しない事を適切に回答（ケース１、２）
　- 試験９．１０．別のローカルLLMで挙動確認（変更LLM１、２）
・各試験の共通手順は以下のとおりです。
　- 対象DBは作成済のものをそのまま使用。画面内で#を入力し、そのファイルを選択。
　- モデルは「ELYZA-JP-8B」を選択。
　- 画面内入力欄に各試験の「入力文」を入力し、「↑」マークを押す。

試験１（情報が存在するケース１）

・結果は以下の通りです。（*****は伏字です。実際には名称が記載されています。）

試験１追試（引用文に含ませるための深掘り）

・検索周りに問題がありそうです。それに関わりそうなパラメータを調整してみます。

・結果は以下の通りです。

試験２（情報が存在するケース２）

・結果は以下の通りです。

試験２追試（引用文内の期待箇所を参照）

・生成時参照量に問題がありそうです。引用文内の期待箇所が参照されるように、関連設定値を増やしてみます。

・結果は以下の通りです。

試験３（情報が存在するケース３）

・結果は以下の通りです。

試験４（情報が存在するケース４）

・結果は以下の通りです。

試験５（前提情報不足のケース１）

・結果は以下の通りです。

試験６（前提情報不足のケース２）

・結果は以下の通りです。

試験７（情報が存在しないケース１：単純）

・結果は以下の通りです。

試験８（情報が存在しないケース２：難しい）

・結果は以下の通りです。

試験９（変更LLM１：Gemma2 9B）

・最後にLLMを別のものに変えて少し試しました。

・結果は以下の通りです。

試験１０（変更LLM２：Phi-3 14B）

・もう一つ変えて試しました。

・結果は以下の通りです。

試験結果サマリー　クラウドvsローカル

・ローカルLLM環境(今回)の方は「トップKとコンテキストの長さ」がデフォルトの時です。
・括弧書きした追試の〇は「トップK」や「コンテキストの長さ」を増やして調整した結果で、反応時間が1分～５分位と遅く、問題があります。
・結果として、クラウドベースのRAGの圧勝となりました。ローカルLLM環境は検索精度が課題です。

まとめ

ローカルLLMでRAGを構築してみました。その過程でわかった事を最後にまとめます。

１．検索機能について
・回答文の下に表示される「引用文」が検索結果でした。
・回答生成で使われるコンテキストはその引用文全てでは無く、設定値：コンテキストの長さ(デフォルト2048)で指定した分がその対象になるようです。ただ、その範囲は引用文の末尾から参照されていて、少し不思議でした（類似度低い順？）。
・検索結果を引用文へどれだけ出力するかについては、クエリパラメータ トップK(デフォルト10)で設定可能です。チャンク分割されChromadbへ登録されたデータ(キー情報はids)を、類似度の高い順にいくつ含めるか設定する事になります。
・検索精度自体(ベクター値同士の類似度比較処理)はあまり良くないです。原因がチャンク数によるものか、モデルの質によるものかは断定できませんが、ベクター値の類似度で差を出やすくするために、チャンクサイズを小さくする方向で調整する事は有効かもしれません。

２．プロンプト（コンテキスト含む）について
・RAG用プロンプトは英文のデフォルト値をそのまま使い、特に気になりませんでした。
・検索結果の参照用に、設定値「コンテキストの長さ」が使われています（前述の通り）。

３．ローカルLLM(Elyza)の要約性能について
・良かったです。参照した時、はずれた時、いずれも違和感の無い回答文でした。
・前提条件（システム名）の不明点を再確認する等、細やかな面ではGPT4oが勝りそうです。

４．試験結果全体から
・全体を通じて、検索精度の向上が一番の課題だと思いました。
・処理時間が５秒以上かかる事も課題。コンテキストの長さを増やすとすごく遅くなります。
　以下が検討テーマ。
　- 速度だけを考慮したらコンテキストの長さは2048が良い。→検索精度の向上が鍵。
　- ローカルPCの性能に起因する事も考慮する。→クラウドにあるLLMを使う事も視野に。
・テキスト生成能力（要約能力）は、Elyzaで大丈夫そう。ただ、GPT-4oの方が性能は良い。

生成AIを利用したツール開発は、今後も注目してゆきたいと思います。
何かお気づきの点があれば、下の「ご連絡フォーム」からご指摘頂くととても助かります。
お読み頂き、ありがとうございました。