本記事は2023年末に公開し、某所からの依頼で一時公開を取り下げたものです。
公開可能な状態になりましたので、Qiita Engineer Festa 2024にあたり再掲いたします。

本記事はLLM Advent Calendar 2023 3日目の記事です。
初版は2023年7月末で、その後刷新と査読を経て資料化したものなので一部陳腐化していますが、参考にして頂けると幸いです。

こちらは早稲田大学の産学共同プログラムでの研究を踏まえて、工学院大学との共著により実現したものとなります。※発言･見解･研究結果は個人のものであり、所属･関与する団体を代表する物ではありません

詳細なレポートを転記すると膨大になりますので、別途提供できればと思います。

TL;DR

2023年6月ごろに、生成AIを使いたいけどクラウドに機密情報を載せたくないと言われて困った
なまじ資金力があるので金額的な面は考慮しなくてもいい
それならオンプレミス環境にOSSとオープンソースLLMを用いてChatGPTを作ろうと思った
暇つぶしにやってみたら割といけた、趣味で大学と共同研究して講演することになった

イントロダクション

私たちが目の当たりにしているのは、生成AI、特に対話型AIの急速な進化です。2022年11月30日には、ChatGPTが公開され、その後もAI技術の進歩は止まることがありません。この進展は、特に「Azure OpenAI Service」のようなサービスを通じて、開発者にとって高性能な生成AIの実装がより容易になる機会を提供しています。

しかしながら、この進歩の裏側には大きな課題が潜んでいます。主要なものは、セキュリティリスクです。企業がクラウドベースのAIサービスを使用する際、機密データの外部流出のリスクは無視できません。また、これらのサービスはしばしば拡張性に制限があり、特定の企業や言語モデルに依存する形になりがちです。

この記事では、生成AIのポテンシャルを最大限に活かしつつ、社内の機密データを保護することができる柔軟で拡張可能なシステムの構築について考察します。特に、クローズドな環境でのAIの利用について掘り下げ、企業が直面するセキュリティリスクにどのように対応できるかを考察します。

生成AIの急速な進歩とそれに伴うセキュリティ上の課題は、今後のビジネス環境における重要な要素です。企業がこの新しい技術を活用する方法を理解し、適応していくことが、これからの時代を生き抜く鍵となります。

1. クラウドサービスの課題と、オープンソース大規模言語モデルの活用によるアプローチ

LLM導入にあたって日本企業が直面する大きな課題の一つは、クラウドサービスにおけるセキュリティリスクとのバランスをどのように取るかです。この課題に対処するため、オープンソースの大規模言語モデル（LLM）の採用を想定して検討します。

オープンソースのLLMは、クラウドベースのマネージドサービスに比べて導入のハードルが高いかもしれませんが、各社の研究は日進月歩で進んでおり、その長期的な利益は計り知れないものです。

[画像出典]Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyond
https://arxiv.org/pdf/2304.13712.pdf

今回は、AOAIのRAGアーキテクチャとオープンソースの大規模言語モデル（LLM）を用いたRAGアーキテクチャを構築し、比較しました。対応する課題と期待する効果は以下の通りです。

セキュリティ: クラウドサービスを利用する場合、データを外部に持ち出し、管理を他者に委ねる必要があります。しかし、オープンソースLLMでは、オンプレミスサーバ上でデータを管理し、オフラインネットワーク上で使用することで、データ漏洩のリスクを大幅に低減できます。
応答精度：クラウドサービスベースの方が安価で高い性能を享受できるものの、大規模言語モデルのチューニングをベンダーに任せきりになります。現状、オープンソースLLMでは現状OpenAI社の「GPT-4」よりも精度は劣るものの、今後その問題は解消されていくと思われます。
柔軟性: クラウドサービス、特に「Azure OpenAI Service」のようなサービスを利用すると、OpenAI社のGPTのような特定のAIモデルに依存することになります。オープンソースLLMを利用すると、状況によって目的に応じたLLMを選択し、適切なデータセットを用いて学習されたモデルの利用が実現できます。また、特定の会話セッションで複数のLLMを用いたコンテキストを組み合わせることが可能となります。

2. プロトタイピング - 実用性とセキュリティを兼ね備えたアーキテクチャの構築

オープンソースLLMを活用し、対話型のWebアプリケーションを構築しました。このアプリケーションは、複数のオープンソース技術を組み合わせることで、納入後すぐに動作する仕組みを採用しています。

構成図　できるかぎり簡素化して記載しております。

技術対応表　具体的には、以下の技術を用いています。

構築内容はシンプルです。Azure上で構築されたサービスアーキテクチャと同様のアーキテクチャをオンプレミスサーバ上に構築し、社内ネットワーク上で使用可能な環境を構築し、Windowsファイルサーバに配置したファイルをベクトル検索できるように実装しました。

Azure OpenAI Service

プロトタイプ

Gradio https://gradio.app/
LangChain https://www.langchain.com/
LlamaIndex https://www.llamaindex.ai/

※1：RAG（Retrieval-Augmented Generation）外部の知識ベースから事実を検索して、最新の正確な情報に基づいてLLMに回答を生成させるAIフレームワーク
※2：Azure Cognitive Search での取得拡張生成 (RAG) https://learn.microsoft.com/ja-jp/azure/search/retrieval-augmented-generation-overview

3. プロトタイピング - 提案手法と評価方法

3-1.提案手法と評価概要

目的：提案手法の有効性を評価

Azure OpenAI Serviceと、オープンソースソフトウェア＋オープンソースLLM、それぞれで同じサービスを構築した結果を評価。
準備作業として、応答精度の検証に利用するLLMは1種類に選定し、利用するLLMを選定する環境と検証する環境は同様とする。

構築するサービス

オープンソースLLMを利用して様々なドキュメントを活用できるRAGアーキテクチャを採用したAIチャットサービスを作成
なお、このサービスは社内ネットワーク上のオンプレミス環境で動作し、様々なオープンソースLLMを柔軟に切り替えることができるものとする

評価概要

柔軟性、セキュリティ、応答精度の３つの観点で、有効性・妥当性について評価
特に応答精度については、以下の三点を評価軸として、５段階で人手によるアラインメントテストを実施
✓ E1 - Semantics 意味の合致性
✓ E2 - Syntax 日本語の自然さ
✓ E3 - Pragmatics 回答の妥当性

テスト環境

3-2. 動作検証に利用するLLM複数種の選定

Nejumi LLMリーダーボード（JGLUEを使ったLLM日本語タスクベンチマーク）上位のオープンソースLLMを数種類利用。
選定基準として、比較的安価なGPUでも動作する70億パラメータ以下の大規模言語モデルを選択しました。

Model_name	AVG	MARC-ja-balanced	JNLI-balanced	JSQuAD-F1	JcommonsenseQA
Xwin-LM/Xwin-LM-7B-V0.1	0.41469435	0.49968957	0.33333333	0.63272501	0.19302949
rinna/japanese-gpt-neox-3.6b-instruction-sft	0.40096972	0.93767926	0.33333333	0.14073044	0.19213584
elyza/ELYZA-japanese-Llama-2-7b-instruct	0.39877367	0.51355546	0.33333333	0.55517639	0.19302949
mistralai/Mistral-7B-Instruct-v0.1	0.39864795	0.52474355	0.33927386	0.53575758	0.19481680
mosaicml/mpt-7b-instruct	0.39325135	0.50165840	0.33333333	0.54498417	0.19302949
stabilityai/japanese-stablelm-instruct-alpha-7b	0.38358178	0.52380101	0.33333333	0.48416328	0.19302949
line-corporation/japanese-large-lm-1.7b	0.30474791	0.50040132	0.33333333	0.19222750	0.19302949
Salesforce/xgen-7b-8k-inst	0.28611521	0.49803243	0.33333333	0.12006558	0.19302949
meta-llama/Llama-2-7b-chat-hf	0.28516208	0.52411136	0.33333333	0.09017413	0.19302949
tiiuae/falcon-7b-instruct	0.28187250	0.50000000	0.33333333	0.10917006	0.18498660
chainyo/alpaca-lora-7b	0.26878820	0.49852892	0.33333333	0.03774989	0.20554066
cyberagent/open-calm-7b	0.26302545	0.50000000	0.33333333	0.03199457	0.18677391

Nejumi LLMリーダーボード (2023/10/31) http://wandb.me/nejumi

※ StabilityAI Japanも日本語評価モデル「lm-evaluation-harness」[1]を提供しているが、評価方法の違い[2]により、今回の評価内容に適しているNejumi LLMリーダーボードを採用。
参考文献1： lm-evaluation-harness https://github.com/Stability-AI/lm-evaluation-harness/
参考文献2：Weights & Biases Japan note「オープンソースLLMの日本語評価結果」https://note.com/wandb_jp/n/n2464e3d85c1a/

3-3. 応答精度の検証に利用するLLM一種の選定

応答精度の検証に用いるLLMは、先述したLLMの中から質疑応答に適したものを、以下の手法で選定しました。

選定手法
以下の6つのタスクにおいて、それぞれ複数のプロンプトを投入し、回答を生成。
• 質問への回答
• 文章の要約
• 感情分析
• 機械翻訳
• 文章の分類や言い換え
• キーワードの抽出

質疑応答に必要な能力である、「意味の合致性、日本語の自然さ、情報の妥当性」という観点で評価※を行い、最も精度の高い応答をしたLLM 「elyza/ELYZA-japanese-Llama-2-7b-instruct」を利用する。

※ 評価手法としてGPT-4を用いたLLM-as-Judge手法[1][2]をベースにした手法を採用した。
参考文献1：LLM-as-Judge Research paper from lmsys group https://arxiv.org/abs/2306.05685
参考文献2：Evaluating Large Language Models: A Comprehensive Survey https://arxiv.org/abs/2310.19736

4. プロトタイピング実装

4-1. Azure OpenAI Serviceを用いてチャットボットを構築

OpenAI Serviceを中心に、ファイルに対するベクトル検索の仕組みを実装しました。

OpenAIのEmbeddingモデル「text-embedding-ada-002」を利用して、BLOBストレージ上のファイルをベクトル化。
Cognitive Searchでベクターストアインデックスを作成し、
情報をベクトル検索する仕組みを実装。
ノーコードでAIチャットを作成できる仕組みで、Azure Web Appsにデプロイ。

こちらの詳細なアーキテクチャ解説は本題から逸れますので割愛させて頂きます。

4-2. オープンソースLLMによるプロトタイプ開発

オープンソースの大規模言語モデルを用いた提案手法を適用しました。

基盤技術：「Text-generation-web UI」をベースにプロトタイプ開発

Text-generation-web UIは、ブラウザを用いてユーザーフレンドリーにLLMを利用できるオープンソースソフトウェア。API機能の標準提供や、各種パラメータの調整も行うことができる。Huggingfaceと連携して、様々なオープンソースの大規模言語モデルをダウンロード・利用できる点が特徴。

ファイル参照・ベクトル検索の開発

Windows11のWSLを実行環境とし、Anaconda上のJupyter-labにてPythonコードを組み、ベクトル検索の仕組みを実装。

LangChainのEmbeddingクラスを利用して、Embeddingモデル
「multilingual-e5-large※」を用いて読み込んだファイルをベクトル化。
LlamaIndexを用いて、ベクターストアインデックスを作成し、情報をベクトル検索する仕組みを実装。
モデルの応答精度に関して、応答精度が最も高くなるハイパーパラメータの調査も併せて実施。（核サンプリング, 温度の調整）

※ intfloat/multilingual-e5-large
https://huggingface.co/intfloat/multilingual-e5-large

インターフェースへの組み込み

ユーザーフレンドリーにフォルダやファイルを参照できるよう、インターフェースを改修
既存のLLM応答部分に関する実装はTransformersを用いられていたため、LangChain＋LlamaIndexを利用するように既存のコードをすべて組み替えて実装

対応LLMの拡大

text-generation-webuiでは、モデル読み込み時にAutoTokenizerを利用してモデルに適したTokenizerを動的にロードできる
AutoTokenizerで対応できないモデルも存在したため、既存メソッドを改修することで、読み込みができるように拡張

※後のcommitでデフォルトで対応できるよう改修されました

動作確認

改修後、実際に利用し、動作確認を実施。

5. 評価・分析

5-1. 利用ファイル

テストに用いたファイル。以下のファイルを、すべて 特定の１フォルダ に配置しました。ファイルの詳細は以下の通りです。
一部私の手元にしかないファイルがありますが、大半はWEBで確認できるものを中心に選定しました。

No.	ファイル形式	使用ファイル	ファイル概要	リンク
1	TXT	＜当社名＞_Wikipedia	＜当社名＞のWikipediaをテキスト化したもの	リンク
2	TXT	工学院大学_Wikipedia.txt	工学院大学のWikipediaをテキスト化したもの	リンク
3	TXT	早稲田大学_Wikipedia.txt	早稲田大学のWikipediaをテキスト化したもの	リンク
4	TXT	ユーザー応対ログ_1.txt	ユーザーとオペレーターの会話をテキスト化したもの（感謝）
5	TXT	ユーザー応対ログ_2.txt	ユーザーとオペレーターの会話をテキスト化したもの（クレーム）
6	CSV	Test_data.csv	ダミーユーザーマスタ（500件）CSVファイル
7	TSV	Payment_test_data.tsv	ダミー購買トランザクションログ（200件）TSVファイル
8	PDF	JISA技術委員会活動報告・提言_R4-J007outline.pdf	概要「デジタル技術応用の拡大と社会変革の実現に向けて～DX と内製化の状況分析から～」PDF	リンク
9	HTML	JISA行動憲章_一般社団法人情報サービス産業協会.html	JISA行動憲章情報サービス産業ＣＳＲ（企業の社会的責任）宣言十箇条	リンク
10	HTML	2023年10月31日_ソフトバンク株式会社_プレスリリース.html	ソフトバンク「国内最大級の生成AI開発向け計算基盤の稼働および国産大規模言語モデル（LLM）の開発を本格開始」	リンク

5-2. 評価基準

評価基準

評価指標	評価基準
E1	意味の合致性: 質問に沿った回答になっているか
E2	日本語の自然さ: 日本語として成り立っているか、文法は合っているか
E3	回答の妥当性: ローカルのファイルを適切に引用して回答できているか

評価指標：E1

評価軸	評価指標
5	質問に沿って回答できており、正しい内容である
4	質問に沿って回答できており、正しい内容であるが、情報が過剰／不足している
3	質問に沿って回答できており、正しい内容であるが、一部誤りを含んでいる
2	質問に沿って回答しているが、誤った内容である
1	質問に沿った回答になっていない

評価指標：E2

評価軸	評価指標
5	日本語が自然である
4	概ね正しい日本語であるが、一部おかしい表現がある
3	意味は伝わるが、誤った表現や単語が含まれている日本語である
2	意味は伝わるが、日本語として成立していない
1	日本語として成立していない

評価指標：E3

評価	評価指標
5	期待した通りファイルを参照できており、正しいデータを提供できている
4	期待した通りファイルを参照できているが、情報が過剰である
3	期待した通りファイルを参照できているが、情報が不足している
2	期待した通りファイルを参照できているが、情報が誤っている
1	期待しているファイルを参照できていない

※ 評価に関しては、人手評価とLLM-as-a-judgeの選択肢が存在する[1]。
LLMの選定時に利用したLLM-as-a-judgeも検討したが、今回は評価対象にGPT-4自身を含むため、人手評価を採用した。
　参考文献1：LLMを用いたLLMの自動評価について〜可能性と注意点〜 https://engineers.ntt.com/entry/2023/09/25/091245　

5-3. 質問した内容・結果

No.	質問	タスク	オープンソースLLM			Azure OpenAI
			E1	E2	E3	E1	E2	E3
#1	＜当社名＞の通称を教えてください。	抽出	5	5	5	5	5	5
#2	内製化でユーザー企業に求められるスキルはなんでしょうか？	抽出	5	5	5	5	5	3
#3	＜当社名＞について要約して教えてください。	要約	5	5	3	5	5	5
#4	早稲田大学の歴史を調べてください。その後、端的に要約して教えてください。	抽出 ⋀ 要約	5	4	3	5	5	4
#5	testdata.csvのemployee列には、何人のユニークな名前がありますか？	データ分析	2	4	2	N/A	N/A	N/A
#6	payment_test_data.tsvのpayment項目の値が最も大きい行は何行目ですか？	データ分析	2	4	3	N/A	N/A	N/A
#7	ユーザー応対ログ1を参照し、ユーザーが何に対してどのような感情を持っているか分析してください。	感情分析	5	5	5	N/A	N/A	N/A
#8	ユーザー会話ログ2を参照し、ユーザーの感情を分析してください。	感情分析	5	5	5	N/A	N/A	N/A
#9	JISAの行動憲章について参照し、小学生でもわかるように言い換えて教えてください。	言い換え	3	5	5	5	5	5
#10	国内最大級の生成AI開発向け計算基盤の稼働において、＜当社名＞はどのように関わっていますか？100文字以内で要約して教えてください。	抽出 ⋀ 要約	1	5	2	5	5	5
#11	工学院大学の理念を調べてください。その後、英語で回答してください。	抽出 ⋀ 翻訳	2	5	5	2	5	2
#12	AIチャットボット導入を取り巻く問題を調べて、英語で回答してください。	抽出 ⋀ 翻訳	2	5	4	5	5	5
	平均点		3.50	4.75	3.92	4.63	5.00	4.25

※1 ハイパーパラメータである核サンプリングと温度は同一の値を採用した。
※2 回答できなかったもの（N/A）については、平均値の集計対象外とした。

5-4. 代表的な質疑応答

5-5. 質問した内容・結果

実践を踏まえた応答精度の計測結果を回答パターンに分けて報告します。

全体の傾向
オープンソースLLMを用いたプロトタイプでも、精度の高い回答を生成できた。一方で、OpenAI Serviceを用いたプロトタイプの方がハルシネーションは少なく、回答の品質が高い傾向にあった。
どちらも正解したケース
シンプルな情報抽出や引用に関しては、どちらも正しい回答が生成できていた。
但し、回答の品質に関してはAzure OpenAI Service プロトタイプの方が自然であった。
オープンソースLLMプロトタイプがハルシネーションを起こしたケース
オープンソースLLMプロトタイプの場合は、引用データに対する誤った要約や、存在しない情報を追加した回答が見られたが、Azure OpenAI Serviceプロトタイプの回答はハルシネーションが少なかった。これは、大規模言語モデルの性能に起因すると考えられる。
Azure OpenAI Serviceプロトタイプが回答できなかったケース
ファイル名を指定した質問では、ファイルを参照できず、回答を生成できなかった。他の質問でもファイル名を指定した場合は同様に回答できなかった。Embeddingモデルの違いによるものか、誤回答を軽減するためのAOAIの仕組みと考えられる。
どちらも共通して問題が発生したケース
ファイル全体の要約や沿革の要約タスクにおいては、一部の情報しか要約できなかった。情報が途切れているのは、参照したノードに紐付くチャンク（文章のまとまり）をもとにしているため、参照したテキストチャンクの範囲内の情報しか引用できていない。これはRAG共通の問題 ※である。
※ テキストチャンクの範囲内の情報しか引用できない問題に対して、解決策を提案しているOSSも存在する（https://github.com/alejandro-ao/ask-multiple-pdfs）

6. 考察

本稿では、特定の企業・言語モデルに依存せず柔軟性・拡張性を持ち、社内の機密文書漏洩を防止する、生成AIをベースにしたシステム構築のためのアーキテクチャを提案し、プロトタイピングによって検証した結果を報告しました。

Text-generation-webUIと、LangChain、LlamaIndex、オープンソースのLLMを用いてシステムを構築した。
応答精度の評価には「elyza/ELYZA-japanese-Llama-2-7b-instruct」を用いた。
柔軟性：Text-generation-webUIのLLM選択機能を採用した。加えて、非対応のLLMも選択できるように対応範囲を拡張し、より多くのモデルを選択可能とした。
セキュリティ：LLMをダウンロードしておけば、オンプレミス環境で動作する仕組みを構築した。これにより、機密情報をクラウドサービスにアップロードせず、社内のみで利用可能とした。
応答精度：文法的な側面と、ローカルファイルの適切な参照については、一定の成果を確認できた。一部の精度については、Azure OpenAI Serviceと比較して問題があった。
今回用いたファイル数やファイルサイズ、並びに質疑応答は、限定された内容であった。
応答精度の評価はテストデータに依存して算出された可能性があるため、今後はより精度の高い検証を行う必要がある。

7. まとめ

今回の考察で、オープンソース大規模言語モデルとオープンソースソフトウェアを用いたシステムを構築し、オフライン環境にて動作を確認することができました。以下、まとめです。

今回製作したプロトタイプの仕組みは、インストールするだけで、RAGフレームワークが実装されたAIチャットボットをすぐに利用できる、有用な仕組みであると考えられる。
応答精度に関しては、大規模言語モデル自体の応答精度や、オープンソースソフトウェアの性能向上により自ずと向上していくと思われ、この仕組みの実用性も高まっていくと想定される。
今回は時間に限りがあるため、速度面やコスト面の計測は実施できなかった。次回研究時はそちらも考察範囲に加えて研究したいと考えている。
将来的には、画像認識への対応や、音声入力への対応など、マルチモーダルな仕組みの拡張も検討していく。

長文となってしまいましたが、ご一読頂きありがとうございました。