オンラインセミナー「【書籍出版記念】LangChainから学ぶLLMを使ったアプリケーションの工夫」を開催しました【ご質問への回答まとめ】
2023 年 10 月 5 日に、「【書籍出版記念】LangChain から学ぶ LLM を使ったアプリケーションの工夫」というタイトルでオンラインセミナーを開催しました。
350 名以上の方にお申し込みいただき大盛況でしたので、講座の概要と、アンケートや講座中にいただいたご質問への回答をまとめます。
https://studyco.connpass.com/event/295516/
講座概要
StudyCo の大嶋が、吉田真吾さん (https://twitter.com/yoshidashingo) と共著で『ChatGPT、LangChain によるチャットシステム構築［実践］入門』という書籍を出します。
出版記念として、LangChain に関する勉強会を開催しました。
なお、こちらの書籍はすでに Amazon で予約可能になっています。 ご興味ある方はぜひ予約注文をお願いします！
https://www.amazon.co.jp/dp/4297138395
なぜ LangChain？
ChatGPT の API が公開されたころから、多くの組織が大規模言語モデル（LLM）を使ったアプリケーション開発に取り組むようになりました。 LLM を使ったアプリケーション開発で、最も注目されているフレームワークが「LangChain」です。
LangChain は LLM を使ったアプリケーション開発の幅広い分野を扱っており、論文などで発表された新しい手法も次々実装しています。 そのため、LangChain を学ぶことは、LLM を使ったアプリケーション開発の様々な工夫を学ぶことになるのです。
この勉強会のテーマ
この勉強会では、LangChain から LLM を使ったアプリケーションの工夫の例を学んでいきます。
とくに RAG (Retrieval Augmented Generation) と呼ばれる手法の基本から、発展的な工夫の例まで紹介していきます。
一部書籍と重なる内容もありますが、書籍にはない話題を中心とした発表となります！
発表資料について
発表資料は SpeakerDeck で公開しています。
ソースコードは GitHub で公開しています。
https://github.com/os1ma/langchain-rag-enhancements
アーカイブ動画について
アーカイブ動画は YouTube で公開しています。
ご質問への回答
ここから、事前アンケート・講座中の Q&A・講座終了後のアンケートでいただいたご質問への回答をまとめます。
※ ご質問の意図を把握しきれなかったものについては省略させていただきました。ご了承ください
参加登録時のアンケートでいただいたご質問への回答
RAG について
どのような形でドメイン知識のデータを準備するか？一問一答か？そこそこ長い文章か？
できれば一問一答のほうが正確な回答になりやすいとは思います。 ただ、一問一答で用意できるのであれば、最終的な回答を LLM が生成する必要はないかもしれません。 検索結果をそのままユーザに見せた方が高速かつ低コストになります。
データの長さについては、LLM に与えるプロンプトが長い場合、中間部分の情報は重視されないという話もあります。 そのため、ある程度の長さでチャンク化したほうが適切に回答できるかもしれません。
参考: Lost in the Middle: How Language Models Use Long Contexts
ドメイン知識のデータの準備に関連して、用意した文章から LLM で一問一答を生成するという工夫もあります。 例えば LangChain には QAGenerateChain という機能があります。 （現在ドキュメントには記載がありませんが、API リファレンスやソースコードを見ると見つけられます）
llama index と langchain の利用シーンに違いはあるのか？／lamaIndex は今でも主流なものでしょうか。これを代替とするものもあるのでしょうか。数カ月前は話題になっていましたが、今は記事もあまり見当たらないため質問させていただきました。
LlamaIndex は LangChain よりも RAG などデータを使うアプリケーションに特化しています。
LlamaIndex 自体は今でもかなりアップデートされていて、GitHub の Star を見ても伸びています。 ただ、日本語の記事は、たしかに特に最近あまり見かけない気がします。 （アップデートが激しすぎるため、記事化するメリットが小さいといった理由もあるかもしれません）
また、独自の工夫を色々する場合、フレームワークを使わない方がいいという意見もあります。 （工夫の例を学ぶとしてフレームワークはとても参考になりますが、フレームワークを使うとカスタマイズは大変です） そのため、フレームワークを使わない実装を採用するケースも少なくないのではないかと思います。
LLM アプリ全般について
会話履歴が社外に漏れないような環境を作って ChatGPT を使う良い方法があれば知りたいです。
「漏れない」が何を指すか次第で違う対応になります。
「学習に使われない」という意味であれば、ChatGPT をそのように設定するだけになります。
参考: https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance
「社外に通信しない」という意味であれば ChatGPT（またはその API）では実現できません。 その場合はローカルで動作する LLM を使って、ChatGPT のようなアプリを実装してください。 また、Azure の閉域接続なら問題ないという場合は、Azure OpenAI の使用を検討してください。
評価をどうやっているのか
個人的な感覚としては、まだ人力で感覚で評価しているケースが多いように思います。 人力で感覚で評価する以外だと、LLM（または Embedding）を使って評価する例を耳にするようになってきています。
まずは以下のあたりを見てみるのがおすすめです。
- LangChain の Evaluation
- Patterns for Building LLM-based Systems & Products
- Azure Machine Learning Prompt flow 評価メトリクス解説
- ragas
python メインだと思いますが、nodejs での実装で気をつけることがあれば。
私は LangChain については Python の実装ばかり使っているので、JavaScript/TypeScript の実装は詳しくないです。 すみません。
強いて言えば、Web やモバイルのフロントから直接 OpenAI の API を呼ばないようご注意ください。 秘匿すべき API キーをフロントで使うと、API キーを公開していることになります。 アプリケーション開発者からすると当然のことですが、プログラミングのハードルが下がったことで、このような実装例が増えているようです。
生成 AI の社内での活用推進の方法（特に ML 開発者を対象に）
開発者であれば、ChatGPT や GitHub Copilot を使うのはとても有益だと思います。
活用推進の方法は企業の規模・文化によっても違うと思うので、近い規模・文化の企業での事例を参考にするといいかもしれません。
余談ですが、とくに個人利用について、最近は「ChatGPT Plus に入らなくても、Bing や OpenAI Playground で GPT-4 を使った方が無料だったり安上がり」というのも話題だと思います。 （ただ、今後のアップデートは ChatGPT Plus の方が早くさわれることもあるかもしれません）
Bedrock での LangChain 活用
すみません。まださわれていないです。 記事などをかなり見かけるので、そちらを参考にしてください。
プログラミングスキルを上げたいのだけどどこから手を付ければいいのかわかりません。差し支えなければ教えていただきたいです。
（完全に個人の意見ですが…）「自分なりに何か作ってみる」「本などで体系的に勉強する」のを今の自分のタイミングにあわせてやってみるのがいいのではないかと思います。 本で勉強したり写経するだけでは結局自分なりのプログラムが書けるようにはならないので、サンプルコードを少し書き換えるところからでも、自分なりにプログラムを書いてみるのは大事だと思います。 逆に、我流でプログラムを色々書いているだけでは身につきにくいこともあるので、本などで体系的に勉強するのも役立つと思います。
あとは、質問できる相手がいると勉強しやすいと思います。 GPT-4 に質問するのもおすすめです！
書籍について
本のオススメポイント／書籍の概要。購入するかどうか悩んでいます
LangChain を学ぶのは、LLM アプリの開発の基本から最新情報までおさえるのに一番だと思います。 LangChain はカスタマイズが大変なので、本番コードでどこまで使うかは要検討ですが、もし LangChain なしで LLM アプリを実装するとしても、LangChain が使っている手法や実装例は非常に参考になります。
書籍の内容としては、ChatGPT の API や LangChain の基本から、Web アプリ・Slack アプリでのチャットボットの具体的な実装例、本番システムのためのヒントまで扱っています。
この一冊読んでいただくと、LLM アプリの開発のトピックをかなりおさえられると思います。
LLM を用いたアプリのアーキテクチャの全体像について
LangChain を学んでみると、LLM アプリの構成の全体像も見えてきやすいと思います。
そのため、この勉強会で紹介した書籍もおすすめですし、もし出版前に勉強したいのであれば、過去に開催した LangChain 入門の勉強会の資料／アーカイブ動画や、Udemy 講座を見てみてください。 （もちろん過去の勉強会・Udemy 講座より、書籍はさらに手厚い内容になっています！）
- 勉強会「プロンプトエンジニアリングから始める LangChain 入門」
- Udemy 講座「LangChain による大規模言語モデル（LLM）アプリケーション開発入門」
- 割引クーポンなどのまとめページ: https://www.nextskill.co.jp/courses
他の情報源としては、Azure や AWS での LLM アプリの実装例を調べると参考になると思います。
当日の Q&A
OpenAI の文章生成 API について
元々 2021 年 9 月までの情報をもとにモデルを構築していましたが、最近 2022 年 1 月までの情報をもとに学習したモデルに更新されませんでしたか？間違っていたら申し訳ございません。
ChatGPT のモデルは、2022 年 1 月までの情報に更新されているという記事も見つかります。
参考: https://news.yahoo.co.jp/articles/5561ea597078d80703de07821bd4dc8e3ed0d39e
ただし、API で使用できるモデルは新しく公開されておらず、公式ドキュメントにも 2021 年 9 月までの情報で学習していると書かれています。
参考: https://platform.openai.com/docs/models/gpt-3-5
トークン上限についてお考え聞かせてください。gpt の API を使い、単純に過去履歴を重ねてチャットを実装するとトークン上限エラーになりやすいです。しかし本家 ChatGPT の UI ではなかなか上限エラーが出ません。紹介いただいたベクトル化や要約などの手法を使い、履歴を圧縮することで上限エラーになりにくくしているのでしょうか。
まず、ChatGPT がどのように実現しているかは、情報が公開されていないと思うので分かりません。
履歴でトークン数の上限を超えないようにする工夫としては、やはり LangChain は参考になります。 LangChain の Memory モジュールがそのような機能を色々提供しています。 例えば以下のような Memory があります。
- 単に履歴を全て積み重ねる ConversationBufferMemory
- 直近何個かだけ使う ConversationBufferWindowMemory
- 会話履歴を要約してプロンプトに収まるようにする ConversationSummaryMemory
- Vector store を検索する VectorStoreRetrieverMemory
参考: https://python.langchain.com/docs/modules/memory/types/
試しに 02_rag_basic/load_docs.py を実行したら、以下のエラーが出ました。今日、実行されたプログラムを実行する場合、OpenAI で必要になるプラン、設定など教えていただけますでしょうか。openai.error.RateLimitError: You exceeded your current quota, please check your plan and billing details.
この RateLimitError は、OpenAI の有料プランで使用可能な量を超えたか、無料トライアルが終わっているのに有料プランに登録していない場合の表示になります。
おそらく、無料トライアルが終わっているのに有料プランに登録していないという状況だと思うので、有料プランに登録すれば使えるはずです。 （ただしその場合料金が発生します）
無料トライアルは、初めてサインアップしてからしばらくだけ使えるため、気が付かないうちに終了しているということが少なくありません。
LangChain について
semantic kernel との違いは何ですか? azure openai をつかっている場合、そっちの方がいいですか?
Semantic Kernel と LangChain がカバーしている範囲はある程度似ているため、どちらかを選択することになると思います。 (私は Semantic Kernel には少ししかふれていないため、あまり詳しくありません)
「Azure OpenAI を使っているから Semantic Kernel のほうがいい」ということは特にないと思います。 Azure OpenAI で LangChain を使うことも多いです。
例えば Sematic Kernel は C#などをサポートしていますが、このように対応している言語であったり、フレームワークとしての使い勝手などでどちらを使うか決めることになります。
文書を読み込んで QA のように答えるだけの仕組みならどんなライブラリ機能を使うのがいいでしょうか
LangChain で文章を読み込んで QA のように答える処理を実装する場合、RetrievalQA を使うのが基本になります。
ドキュメントの以下のページに RetrievalQA を使うシンプルな例が掲載されています。
https://python.langchain.com/docs/use_cases/question_answering/how_to/vector_db_qa
llamaindex と rerativalqa の違いはなんですか?
LangChain の RetrievalQA は、「検索して LLM に回答させる」という処理の流れだけを提供しています。
一方で、LlamaIndex は他にも非常に多くの機能を提供しています。
RAG 全般について
RAG だと質問に対して回答が１：１となっているとみました。複数意味のある単語の意味を質問した際に複数の意味を回答させる方法はありますか？
「RAG だと質問に対して回答が１：１となっている」とのことですが、これはおそらく、複数の質問が混在するとベクトル化したときに複数の要素が考慮されたベクトルになってしまい、類似度検索がうまく動作しにくくなる、ということだと思います。 (RAG では必ず質問と回答が 1 対 1 ということではなく、質問と回答が 1 対 1 のほうがうまく動作するケースが多い、ということだと思います)
複数の内容について質問する場合は、例えば質問を LLM を使って複数の質問に整理させて、各質問について類似度検索するようにすれば、うまく動作するかもしれません。
RAG の代わりに例えば Google 検索結果の上位を入力するなど既存の検索エンジンを使えばいいようにも思いましたが、この手法ではなく RAG を使うメリットなどはありますでしょうか。
Google 検索との違いとしては、独自文書が使えることが挙げられます。
また、Google 検索の結果に基づいて LLM に回答させることも有用な場合もあります。
PDF ファイルをベクトル化して読み込ませる際、情報が表になっている場合、うまく検索できないんですが、文章と同じように検索するにはどうすべきなんでしょうか。
PDF ファイルについては、私もある程度試したりしましたが、結論としては難しいです。 PDF をテキストに変換するときに表などの構造崩れてしまうためです。
対策としては、事前にマークダウンなどのテキストにしてあげるとうまく動くかもしれません。 また、OCR や画像をテキストに変換するモデルを使用したり、最近話題のマルチモーダルなどであればうまくいくかもしれません。
社内のドキュメントをデータベースに入れ込んで、何とか考察や推論が出来てればと思って取り組んでいるのですが、なかなか専門的にクリティカルな要約もしくは提案までには行き着きません。開発部では精度を上げていけばまだ何とか？と思っているのですが、営業やフロント側は完璧を求めるのかイメージが先行しているのか、中々理解をしてくれません。この意識の壁を決め打ちした精度の高いデータを読み込み仕組み化して解決すべきかそれとも草の根で利用者を増やしイメージを改善させるのか、方法としてはどちらが良いでしょうか？
私の意見を聞きたいというご質問だと思うので、私の意見という前提で回答します。
まず、完璧求める方向は LLM と非常に相性が悪いです。 LLM を使う場合、完璧を求める方向はやめたほうがいいと思います。 （その他の機械学習の手法でも同様です）
完璧を求める場合、おっしゃる通り、決め打ちのデータであったり、機械学習を使わない通常のプログラムで対応することになると思います。
LLM を使ったアプリケーションを作っている例でも、
- 完璧ではないことを明示する
- 社内向けにしか使わせない
- 出力をそのまま顧客に見せず、専門家が確認する
といった工夫で対応していることが多いと思います。
社内情報を覚えさせ、社内ヘルプデスクの AI チャットアプリを作りたいのですが、最短でそこそこクオリティの高いものを作るためにはどのような技術構成で作るのがおすすめですか？
RAG のような処理を行うアプリケーションをそこそこのクオリティで短期間で作るということかと思います。 その場合、おそらく Azure Cognitive Search などを使うのが、そこそこのクオリティのものを短期で実現しやすいのではないかと思います。
チャンク化について
先ほど 1000 文字単位でトークン分割していましたが、分割の前後で意味は通じるのでしょうか？中途半端な場所で分割した際でも検索できるのか分からず質問させて頂きました。
まず結論として、中途半端な場所で分割した場合、検索自体もうまくいかない可能性がありますし、検索できた場合でも回答がうまくいかない可能性があります。
今回のサンプルコードで、チャンク化には、LangChain の CharacterTextSplitter という文字単位で分割するものを使用しました。 CharacterTextSplitter には chunk_overlap というオーバーラップの設定があり、前後である程度重ねてチャンク化するよう設定できます。
CharacterTextSplitter は文字単位での分割ですが、他にも Python などのプログラムを、クラスや関数と言った意味のある単位で分割するといった方法もあります。
データのチャンク分割について、より良い検索精度を得るためのベストプラクティスなどあれば教えていただきたいです。
ベストプラクティスとまでは言えないかもしれませんが… LangChain では Text splitters として、文書の分割の仕方が色々提供されており、ある程度ヒントになるかもしれません。
参考: https://python.langchain.com/docs/modules/data_connection/document_transformers/
現在オーバーラップ 0 で分割しているんですが、ユースケースで重複させるとうれしさがあるんでしょうか？
オーバーラップがないと、文書が意味的なまとまりの途中で切れた場合に、その前後が一緒に検索対象にならなくて困る、ということになります。
オーバーラップさせた方が、関係する内容が 1 個のチャンクに入る可能性が出てくるということになります。
ベクトル化
分散表現において、単語のベクトル化はイメージしやすいのですが、今回の例のように文章のベクトル化も考え方は同じでしょうか？
単語のベクトル化と文章のベクトル化は、ある程度近い考え方ですが、違いもあります。
文章をベクトル化する単純な方法としては、各単語のベクトルを合計 (平均) する方法があります。 ただしこの方法では、単語の順番などが考慮されないといった問題があります。 そのため文章をうまくベクトル化するときはさらに工夫が必要になります。
具体的には RNN や LSTM、Tansformer といったモデルについて調べてみてください。 例えば書籍『IT Text 自然言語処理の基礎』などで解説されています。
Embedding は Word2Vec のように、単語を投げるとベクトルが返ってくるものなのでしょうか。
はい。そのような動作になります。 OpenAI の Embeddings API は、単語ではなく文章が入力になりますが、文章をもとにベクトルが返ってきます。
ベクターストア
分かりやすいご説明ありがとうございます！ベクターストアで FAISS を選択された理由は何でしょうか？Qdrant や pinecone など、他との差分があれば是非ご教授いただきたいです！
まず、Pinecone はクラウドサービスであり、ローカルで動作しません。
今回はローカルで動作するものから適当に Faiss を選択しました。
Qdrant と Faiss の違いは私は答えられないです。すみません。
ベクトルデータベースでオススメはありますでしょうか？
ローカルで動かすなら、Qdrant や Faiss、Chroma など選択肢が限られると思います。
クラウドなら Pinecone などがあります。 ただ、色々な話を聞いたりした感覚として、（そもそもベクトルデータベースではないかもしれませんが）検索部分は Azure Cognitive Search などに任せたほうが、うまくいくことが多いかもしれません。
Vector ストアについて聞き逃してしまったので教えてください。Vector ストアは Llama-index のように既にあるものを使うイメージでしょうか。あるいは必要に応じてユーザー側が構築するイメージでしょうか。（後者の場合はコストがかかるようなデメリットがあり、前者の場合は最新のものに対応できないデメリットがあると思いました）
LlamaIndex は Vector Store ではなく、RAG などのデータを扱う LLM アプリを実装するためのフレームワークです。 LlamaIndex で RAG を実装する場合も、Vector Store の準備は必要です。
Vector Store のような検索先としては、OSS の Faiss や Chroma などを自力でサーバにセットアップする方法もあれば、Pinecone や Azure Cognitive Search のようなクラウドサービスを使う方法もあります。
クラウドサービスと OSS を自力で使うことの一般論的な比較になりますが… クラウドサービスを使ったほうが、構築・運用コストは低くなりやすいです。 一方で、OSS を使って自力で構築したほうが、カスタマイズ性が高くなりやすいです。
最新の手法などへの対応は、開発が活発な OSS のほうが早いかもしれません。 ただし、自社での検証やアップデートにはコストがかかります。 一方で、クラウドサービスは最新のアップデートが自動で反映される場合もあり、最新の手法を低コストで取り込むことができる可能性もあります。
HyDE
HyDE は API を 2 回たたくことになるのでしょうか。
今回実行したサンプルでは、LLM の API を 2 回叩いています。 また、Embedding の API も叩いています。
正確に言うと HyDE はベクトル化のあたりを指すので、そこで 1 回 LLM を呼び出します。 そして最後に回答生成するときも LLM を 1 回呼び出します。
このような工夫は LLM を呼び出す回数が増えることが多いです。
HyDE は自社文書の検索などには向いていないということでしょうか
LLM がある程度類似する回答を推測できそうなユースケースでは、自社文書の検索にも HyDE が役立つかもしれません。 例えば社内規定などは、会社によって違いがそれほど大きくない場合もあると思います。 そのようなケースでは HyDE が効果的かもしれません。
FLARE
FLARE が気になっています。「指定された確率以上」の確率というのはどういうパラメーター？で精度を判断しているのでしょうか。／FLARE での確率の値はどのように求めるのでしょうか。人間が使う以上は「この応答は不適切なので値は低いです」のように、人間が教えてあげる必要があると思います。
まず、「確率がいくつ以上になるまで」という閾値については、「0.2」などと指定します。 人間が決めたり、何らかの方法で決めることになります。
そして、LLM が出してくる確率についてですが… そもそも言語モデルというのは、確率に基づいて文章を生成します。 なので、言語モデルを使う以上、生成された文章には確率があり、その確率を使う、ということです。 （ただし、OpenAI の Chat Completions API は確率を返してくれないので、この用途に使うことはできません）
さらに応用的な手法として、LLM が返してくる確率を使うのではなく、LLM の生成結果に外部から何らかの方法で確率を与える方法も考えられると思います。
補足になりますが、言語モデルが出力する確率というのは、例えば「0.5 なら 2 回に 1 回程度正しい」という意味ではありません。 あくまで「確率の公理」を満たし数学上「確率」と呼べる性質を持っているため「確率」と呼んでいるだけで、現実世界の出来事の割合などを指すわけではありません。 そのため、「FLARE で確率を 0.5 に設定すれば 2 回に 1 回程度正しい内容になる」といったことはありません。
参考: https://ja.wikipedia.org/wiki/%E7%A2%BA%E7%8E%87%E3%81%AE%E5%85%AC%E7%90%86
Ensemble Retriever
Ensemble Retriever で与える重みは、それぞれの retrieve での距離を重みづけ和されるイメージでしょうか？
RRF という手法の重みのことのようです。 詳細は以下のソースコードやドキュメンテーションコメントを参照してください。
RAG とファインチューニング
LAG を使いこなすとファインチューンの出番はないでしょうか？／ケースバイケースかとは思いますが、回答の精度を上げたい場合は RAG よりファインチューニングの方が効果的でしょうか。両者のメリットデメリットがあればご教示いただけますと幸いです。
私自身、RAG とファインチューニングの比較を自分でがっつりやっていないため、その前提での回答になります。
まず、「ファインチューニングの出番がない」ということはないと思います。 例えばファインチューニングでモデルに独自知識を組み込めた場合、ユーザへの応答速度は RAG より高速になる可能性があります。 また、汎用的な Embedding では固有名詞や専門用語の類似度検索が苦手な可能性もあり、ドメイン特化するようファインチューニングした LLM や Embedding モデルが有用な場合もあると思います。
RAG とファインチューニングでどちらのほうが回答の精度が高そうかは、あまりしっかりした情報を見たことがないので分かりません。 RAG とファインチューニングのメリット・デメリットとして簡単に言える範囲だと… ファインチューニングは（最近は多少 API などがあるものの）基本的に機械学習の知識や GPU などの環境が必要だったりするため、初期コストや知識・環境面のハードルが高めだと思います。 一方、RAG は機械学習関係の前提知識や環境が整っていなくても手を付けやすいと思います。
補足になりますが、そもそもファインチューニング自体、非常に様々な手法があるため、RAG と安直に比較できないという側面もあると思います。 モデルのすべてのパラメータを更新する Full Fine-Tuning 以外にも、Prefix-Tuning や RoLA など様々な手法があります。 ファインチューニングの手法によっても、どこまで精度が上がりやすいかなどが変わると思います。
そして、OpenAI の API でのファインチューニングは、公式でユースケースに「知識の獲得」について書かれておらず、知識の獲得には適さないのではないかと言われることがあります。 ただ、仮にそうだとしても、それはあくまで OpenAI の API でのファインチューニングに限った話であり、LLM のファインチューニングの一般論ではないことには注意が必要です。
その他
Microsoft 365 copilot に、Microsoft graph というデータ保管庫があります。これを利用することで、Langchain で実装しなくても、ある程度ローカルな質問に答えられるようになるのかなと想像しています。Microsoft 365 copilot の Microsoft graph の利用と Langchain の利用の使い分けについて教えてください。
Microsoft 365 copilot はふれていないので分かりません。
基本的に、何らかのサービスが提供している機能よりさらにカスタマイズが必要な場合は、LangChain を使うなどして自前で実装することになります。 （自前で実装する際、LangChain を使わないことも考えられます）
Langchain の SQLDatabaseChain を使って、社内 DB に対して自然言語での問い合わせをしたいなと思っているんですが、生成 AI 側（OpenAI 等）にデータ自体は渡さないにしろ、テーブル構成等の情報を渡すことになるのかなと思っています。まず、この認識ってあってますでしょうか。また、その場合、Open AI API の場合、OpenAI 側にテーブル情報が送られるのは抵抗があるなと思うんですが、その場合は Azure OpenAI Service を使用したほうが安全性が高いと思ってよいのでしょうか
まず結論として、OpenAI の API で SQLDatabaseChain を使う場合、テーブル構成は OpenAI の API に渡されます。 さらにデフォルトの設定では、生成した SQL の実行結果（データベースから取得したデータ）も OpenAI の API に渡されます。
SQLDatabaseChain は、デフォルトで以下のような処理の流れになります。
- データベースのスキーマを自動で読み取り、それをプロンプトに入れて SQL を生成させる
- 生成された SQL を実行する
- SQL の実行結果をもとに LLM に最終的な回答を生成させる
そのため、デフォルトの動作では、テーブル構造に加えて、データベースから取得したデータも OpenAI の API に渡ります。
SQLDatabaseChain の return_direct というパラメータを True にすることで、SQL の実行結果がそのまま Chain の実行結果となり、LLM による最終的な回答の生成は抑制されるはずです。
セキュリティ面について、安全性という言い方は難しいですが… 社内のコンプライアンスを満たしやすいかという観点では、例えば閉域接続などが可能なため、Azure OpenAI のほうが有利な可能性があります。
企業独自の形式知を持っている人の知識をモデル化するという取り組みなどありますか？もしあれば実装方法まで知りたいです。
人が持っている知識を、あらかじめ言語化する以外でモデル化する取り組みについては、私は分かりません。
講座終了後のアンケートでいただいたご質問への回答
RAG について
わかりやすくて面白かったです。ベクター DB への質問は一問一答が良いとのことですが具体的にああしろ、こうするなという知見があれば知りたいです。
「ベクター DB への質問は一問一答が良い」というのは、おそらく、複数の質問が混在するとベクトル化したときに複数の要素が考慮されたベクトルになってしまい、類似度検索がうまく動作しにくくなる、ということだと思います。
このように、内部の仕組みを理解することで、検討している工夫が有効かどうか推測できることも少なくないと思います。
また、機械学習を使ったアプリケーションにおけるアンチパターン（例えば絶対に確実な動作を期待すること）など、機械学習の一般論を学ぶことも役立つと思います。
ベクトル化で各手法の精度差などあるのでしょうか？
ベクトル化の手法やモデルによって、精度差は非常に大きくなります。 基本的に意味が近いテキストがベクトルとしても距離が近くなるようにベクトル化するのですが、意味的な類似性とベクトルの距離の近さがどこまで対応するかは、ベクトル化の手法やモデル次第です。
クローズのデータでは、うまく使えるかどうか。
RAG は社内文書などクローズのデータを扱うことが多いです。 どこまでうまくいくかは工夫次第になります。
その他
load summarize chain などで顧客に要約機能を提供するとして、顧客がプロンプトを編集可能にするとした場合に、どの程度の範囲で編集可能にすべきか。また、注意点はある？
どこまでプロンプトを編集可能にするかは要件次第かと思うので、一般的な回答は難しそうです。 注意点も要件次第かと思いますが、あまりに想定外の使い方をされた場合にどうなるかは考えておいたほうがいいかもしれません。
想定外の使い方を技術的に完璧に防ぐのが難しい場合、顧客向けの利用規約や契約書などで制限することも重要だと思います。
トークン計算の予算提示をどうにかしたいです。
OpenAI の文章生成 API を使ったアプリケーションにおいて、請求金額をぴったり推測するのは困難です。 基本的には、リクエスト数やリクエストあたりのトークン数などがどの程度になりそうか想定して見積もることになります。
これは OpenAI の文章生成 API に限らず、Auto Scaling するクラウドサーバや AWS Lambda などを使う場合の見積もりでも同様です。 このようなクラウドインフラの見積もり方法が参考になると思います。
また、OpenAI の API にはレートリミットを設定することができます。 上限金額を超えないようにしたい場合は、レートリミットの設定を検討してください。
参考: https://platform.openai.com/docs/guides/rate-limits
おわりに
以上、ご質問への回答を中心に、記事にまとめさせていただきました。
回答内容へのご指摘や追加のご質問については、お問い合わせフォーム からお問い合わせいただくか、発表者の Twitter にご連絡お願いします。
また、StudyCo では、法人様・コミュニティ様向けの出張勉強会や、技術サポートなどもお受けしています。 お問い合わせフォーム から、お気軽にご相談ください。
次回予告
10 月 26 日 (木) 19:30 から、「【書籍出版記念 vol2】LangChain で AI アシスタントを動かすハンズオン【オフライン開催】」を開催予定です。 StudyCo 初のハンズオン勉強会です！
https://studyco.connpass.com/event/298456/
こちらはすでに満席となっていますが、今後も色々な勉強会を開催予定です！ 次回のハンズオン勉強会も、好評でしたら追加開催を検討するかもしれません！