大嶋氏の自己紹介
大嶋勇樹氏：では「LangChainソースコードリーディング／テーマ：OpenAI Chat APIを『ちゃんと』使う」ということで、1時間ほど勉強会をします。
（スライドを示して）最初に私の自己紹介ですが、名前は大嶋勇樹と申します。キャリアとしては、新卒で都内のIT企業に入って、その後フリーランスエンジニアを経て、会社を設立して、いろいろやっています。現在は実務に就き始めたエンジニアのスキルアップのサポートということで、研修や勉強会の開催、「Udemy」講座の作成などといった活動をしています。
今日（のセッションの内容）は実務に就き始めとかはあまり関係ないですが、今日と関連する分野で「LangChainの入門」や「LlamaIndexでこういうことをやってみた」みたいな発表などを過去にやってきています。
ということで、「LangChainソースコードリーディング」の勉強会に入っていこうと思います。
本勉強会実施の背景
まず背景として、最近は大規模言語モデル、LLMを使ったアプリケーション開発のフレームワークとして、LangChainが注目を集めています。LangChainは毎日のように新バージョンがリリースされており、とてもアップデートの激しいオープンソースとなっています。
LangChainのようにアップデートが激しいオープンソースを使う場合、例えば公式ドキュメントであっても情報が不足していたり、公式ドキュメントすら実装とずれてしまっていることは少なくありません。また、自分がやりたいことを実現したりエラーを解決したりするには、そのOSS自体のソースコードを読むしかないことも多いです。
なのでこの勉強会では、そんなLangChainのソースコードリーディングに少し取り組んでみようと思います。
オープンソースのソースコードを読む時は目的を持つ
そしてこれは私の意見になるんですが、オープンソースのソースコードを読む時は、なにか目的を持ったほうがいいかなと思っています。
例えば遭遇したエラーの根本原因を調べたいとか、ある機能がどんなふうに実現されているのか知りたいとか、ドキュメントには書かれていない設定や関数がないか調べたいなど、いろいろ目的はあると思うんですが、こういった目的があったほうが、ソースコードを端から端まで読むよりも理解しやすいことが多いんじゃないかなと思っています。
ということでどんな目的を持つかですが、GPTを使ったアプリケーションの開発では、OpenAIのAPIの中でもChat Completions API……。今日は略して「Chat API」と呼ばせてもらおうと思いますが、これを使うのが定番です。
実はLangChainでこのOpenAIのChat APIをちゃんと使うには、LangChainのソースコードを読むことが、私の経験的にちょっと役立ったかなと思っています。そこで今日は、LangChainでのOpenAIのChat APIの「ちゃんと」した使い方をテーマとして、ソースコードリーディングを実施してみようと思います。
このあたりまで（の話）はconnpassにも載せました。
前提知識
ということで、「LangChainソースコードリーディング／テーマ：OpenAI Chat APIを『ちゃんと』使う」ということでやっていきます。
参加者の方が大勢いるので一応前提知識なども共有すると、前提としてはPythonのライブラリのドキュメントを読める程度の基礎知識があることと、LangChainについては基礎知識があることを前提とします。
一応connpassページにも書きましたが、過去にLangChainの入門の勉強会をやっているので、そちらの資料かアーカイブ動画を見たぐらいの基礎知識があることをある程度前提とします。発表の中でも簡単には補足しますが、そんな発表になります。
（スライドを示して）プラス、今日のソースコードリーディングについては、やり方はあくまで私のやり方の例です。オープンソースのソースコードリーディングといっても人によっていろいろなやり方があると思いますが、あくまで私のやり方になります。
それと、ソースコードリーディングにあまり慣れていない方もけっこういるんじゃないかと思うので、そういった方を想定して、比較的簡単な内容をテーマとしています。そのあたりはご了承ください。
セッションのアジェンダ
ということでアジェンダです。まずOpenAIの文書生成APIの基本を簡単に復習して、LangChainでのOpenAI Chat APIの使い方の基本、そしてそのOpenAI Chat APIをLangChainで「ちゃんと」使うには、という話をしていこうと思います。
最後にLangChainの過去のバージョンのドキュメントを見る方法も、時間があれば補足的に話せればと思っています。
OpenAIの文書生成APIの基本
前置きが長くなりましたが、ここから本題に入っていきます。まずは少し前提知識の復習として、OpenAIの文書生成APIの基本から見ていきます。
みなさん（の中に）はChatGPTを使っている方が多いと思いますが、ChatGPTはPlusプランに入ると、GPT-3.5とGPT-4……。（スライドを示して）これは画面キャプチャーが少し古い画面ですが、GPT-3.5とGPT-4というモデルを選ぶことができます。
そもそもOpenAIのモデルにはいろいろ種類があります。例えばGPT-4は自然言語やコードを生成するモデルです。ほかに自然言語やコードを生成するモデルとして、GPTの3.5やGPTの3があります。
また、Whisperという音声をテキストに変換するモデルもあれば、Embeddingsというテキストを数値のベクトルに変換するモデルもあります。ほかにもいろいろありますが、ざっくりOpenAIにはこんなモデルがあります。
そして、最近特に注目されているGPT-3.5やGPT-4を使ったアプリケーションを開発する時は、こういったモデルをOpenAIのAPI経由で使うことになります。
今GPT-4やGPT-3.5、GPT-3と言ってきましたが、このGPT-4とかGPT-3.5、GPT-3というのは、実際はモデルの集まりのことを指しています。実際にAPIを使う時はこのモデルの集まりのことではなく、その中に含まれる細かいモデルの名前を指定することになります。
例えばGPT-4というモデルファミリーの中には、小文字の「gpt-4」や「gpt-4-32k」といったモデルがあったり、GPT-3.5といっても「gpt-3.5-turbo」や「text-davinci-003」というモデルがあったりになっています。そして実際にAPIを使う時は、こちらの小文字で書いてあるモデルの名前を使うことになります。
この中でもいろいろ以前から存在するものや新しいものがあるんですが、2023年3月にgpt-3.5-turboが公開されて、それまであったモデルよりも10分の1の安さで（使えることになり）、すごく衝撃を与えました。gpt-4という、非常に高性能なモデルが出てすごく衝撃を与えたというのが、最近の話題になっているところです。
OpenAIの文書生成APIにはChatとCompletionsの2種類がある
（スライドを示して）そしてOpenAIのAPIを使う時の1つのポイントとして、OpenAIの文書生成APIにはChatとCompletionsの2つがあります。Chatのほうは“Chat Completions”と呼んだり（そのように）ドキュメントに書かれていることもありますが、ChatとCompletionsの2種類があります。
古めのモデルについてはCompletionsというAPIを使うんですが、新しめのgpt-3.5-turboやgpt-4といったモデルについてはChatのほうを使うことになります。料金や性能の観点から、現在はこのChat、またはChat Completionsと呼ぶこともありますが、とにかくこのChatのAPIを使うのが基本となっています。
このChatのAPIの使い方に少し特徴があって。実はLangChainでこのChatのほうのAPIを使う時も少し工夫が必要だったりするので、今日はそういったところがテーマになってきます。
Completions APIとChat APIの違い
さて、一応このCompletions APIとChat APIはどう違うのかまで復習しておこうと思います。
Completions APIという以前からある文書生成APIは、例えば1ヶ所にプロンプトとしてなにかテキストを与えると、これに対応する応答が返ってくるだけというシンプルなものでした。
最近使うべきとなっているChat APIのほうは、messagesという配列を与えます。その配列の各要素には「"role": "user"」、または「"role": "assistant"」や「"role": "system"」、最近は「"role": "function"」というものもあります。とにかくrole、そしてuserやassistantと、プラスcontentとして、発言の内容みたいなものを含めます。
どういうことかというと、このChatのAPIのほうを使う時は、各roleのメッセージをリストとして与えます。もうちょっと丁寧に言うと、例えばAIと何度か会話したつもりで続きを返してほしい時には、「"role": "user"」と「"role": "assistant"」「"role": "user"」のやり取りを配列の中に3つとか含めたりしてリクエストを送って、その続きをAIに回答してもらうとか。そんな使い方になります。
これがちょっと癖があるものなんですが、今はこちらを使うべきで、これをLangChainで使う時にどんな注意が必要かが今日のテーマですね。
（次回につづく）
