見出し画像

LangChain の ChatGPTの新しい抽象化

npaka

「LangChain Blog」の記事「Chat Models」が面白かったので、簡単にまとめました。

1. はじめに

先週、OpenAI は「ChatGPT」をリリースしました。いくつかの大きな改善が加えられており、最も顕著なのは、10 倍安く、はるかに高速であることした。しかし、まったく新しい APIも付属しています。このAPIのラッパーをすばやく作成して、「LangChain」の通常の LLM のように使用できるようにしましたが、これは新しいメッセージベースのAPIを十分に活用できていませんでした。

この記事では、新しいAPIとChatGPTだけでなく、将来のすべてのチャットモデルに対応するため、「LangChain」をどのように適応させるかについて説明します。

・Python版のドキュメント
・JS/TS版のドキュメント

2. なぜ新しい抽象化が必要か

「ChatGPT」のAPIは内部で言語モデルを使用していますが、既存の「GPT-3」のAPIとは少し異なります。

◎ GPT-3
・入力 : テキスト
・出力 : テキスト

◎ ChatGPT
・入力 : チャットメッセージリスト
・出力 : チャットメッセージ

この新インターフェースは、言語モデルへの入出力に関する一部の抽象化が正しくないことを意味します。たとえば、以前に構築したプロンプトはすべて、「PromptTemplate」の出力が文字列であると想定していました。ただし、チャットモデルの場合、入力はメッセージリストである必要があります。プロンプトはLangChainの中核であるため、これはかなり影響のある変更です。

3. 新しい抽象化のサポートを急ぐ理由

新しい抽象化のサポートを急ぐ理由は、 なぜOpenAIがこの形式のチャットモデルをリリースすることを選択したのかにあります。

この部分はすべて憶測になります。「ChatGPT API」と以前の「GPT-3 API」 の主な違いは、さまざまなメッセージ種別で、ユーザー入力がより構造化されていることです。具体的には、「ChatGPT API」を使用すると、「user」「assistant」「system」でメッセージを区別できます。この差別化により、モデルはさまざまなメッセージ種別を異なる方法で処理できるようになり、理論的には、これらのモデルの上に構築されたアプリケーションの安全性が向上する可能性があります。たとえば、LLMアプリケーションに対する一般的に知られている攻撃は、ユーザーが意図しないことをアプリケーションに実行させるプロンプトインジェクション攻撃です。この構造をプロンプトに追加することで、理論的には、アプリケーションはすべてのアプリケーション命令を「system」に入れ、すべてのユーザー入力を「user」に入れ、モデルを常に「従う」ように学習させることができます。

実際には、チャットモデルに対するプロンプトインジェクション攻撃は依然として行われているように思われるため、これらの懸念に完全には対処できない可能性があります。時間だけが教えてくれます。

上記の「user」「asistant」「system」メッセージの例は、この形式が既存のAPIとは十分に異なり、独自の抽象化に値する理由も示しています。

もっと現実的な理由もあります。OpenAIは、ChatGPTに対応する「通常の」LLMエンドポイントをまだリリースしていないため、これらのモデルの速度やコストを最大限に活用したい場合は、「ChatGPT API」を使用する必要があります。他のチャットモデルが間もなく市場に登場するという噂もあります (AnthropicのClaude、GoogleのBard、Cohereの対話モデル)。 これらのモデルがどのような形式で利用できるようになるかはまだわかっていませんが、チャットモデルの API オプションもあると考えるのはおかしなことではありません。

4. 新しい抽象化の目標

新しい抽象化を設計するとき、次の3つの目標を念頭に置きました。

#1: ユーザーが新しいチャットモデルインターフェースを十分に活用できるようにする

前述のように、チャットモデルのAPI は、既存のLLM APIとはかなり異なります。ユーザーがそれを利用できるようにしたいと考えています。

#2: 「通常の」LLM APIとチャットモデルのAPI間のプロンプトの相互運用性を許可する

「通常の」LLM とチャットモデルのAPIのプロンプトには明確な違いがありますが、どちらのモデルでも同じプロンプトを使用できるように可能な限りシームレスにしたいと考えました。実際には、コードベースのほとんどのプロンプトがLLM用に最適化されており、チャットモデルでプロンプトがひどく壊れないようにするため、これを優先しました。

#3: 抽象化をOpenAI だけでなく汎用的にする

OpenAI 固有の抽象化を導入したくありませんでした。前述のように、他のチャットスタイルのモデルがまもなく市場に登場するという噂があり、それらをシームレスにサポートできるようにしたいと考えていました。

5. 新しい抽象化の構成

コードベースに過度に多くの抽象化を導入しているように見えるかもしれませんが、これらはすべて、コードベースに追加されたものをこれらの新しいモデルで可能な限り機能させることを目的として行われています。

「LangChain」の目的の 1 つは、常に言語モデル プロバイダー間の相互運用性を可能にすることであり、これがその助けになることを願っています。

5-1. ChatMessages

さまざまな種類のチャットメッセージの抽象化を追加しました。

・HumanMessage : 人間の視点から送信されるメッセージ
・AIMessage : 人間が対話しているAIの観点から送信されるメッセージ
・SystemMessage : AIが従うべき目的を設定するメッセージ
・ChatMessage : ロールを任意に設定できるメッセージ

5-2. ChatModels

チャットモデルの抽象化も追加しました。これらのタイプのモデルが期待するインターフェースは、基礎となる「ChatGPT API」と非常によく似ています。チャットメッセージリストを受け取り、チャッ メッセージを返します。

5-3. ChatMessageTemplates

ほとんどのアプリケーションは、送信するメッセージをハードコーディングするのではなく、「PromptTemplates」 (ユーザー入力を受け取り、プロンプトを返す) のアイデアを利用するため、対応するチャットメッセージプロンプトテンプレートを追加しています。

・HumanMessagePromptTemplate : ユーザー入力を受け取り、HumanMessage を返すメソッドを公開するクラス
・AIMessagePromptTemplate : ユーザー入力を受け取り、AIMessage を返すメソッドを公開するクラス
・SystemMessagePromptTemplate : ユーザー入力を受け取り、SystemMessage を返すメソッドを公開するクラス
・ChatMessagePromptTemplate : ユーザー入力を受け取り、ChatMessage を返すメソッドを公開するクラス

5-4. PromptValues

「通常の」LLM API とチャットモデルのAPI間のプロンプトの相互運用性を可能にするために、「PromptValue」の概念を追加しました。これは、次のメソッドを持つクラスです。

・to_string : PromptValue を文字列に変換し、「通常の」LLM APIで使用
・to_messages: PromptValueをメッセージリストに変換し、チャットモデルのAPIで使用

これに伴い、「PromptValues」を受け取り、それらをそれぞれ文字列または ChatMessagesに変換してからモデルに渡すメソッドも BaseLLM および BaseChatModelクラスに追加しました。

6. 新しい抽象化が目標と一致しているかの確認

これらの抽象化が、設定した目標と一致しているかを確認しましょう。

#1: ユーザーが新しいチャットモデルインターフェースを十分に活用できるようにする

ChatGPTインターフェイスのすべての機能をカバーしています。明示的に抽象化されていないもの (名前パラメータなど) がありますが、それらはまだ使用可能であり、将来的に関連性が高まった場合により良いサポートを追加することに取り組む可能性があります。

#2: 「通常の」LLM APIとチャットモデルのAPI間のプロンプトの相互運用性を許可する

「PromptValue」の抽象化により、これが可能になります。文字列をメッセージに変換する (単一のHumanMessage にする) 方法と、メッセージを文字列に変換する方法 (リスト全体を文字列にキャストするだけ) の非常に単純な方法があります。これら (特にメッセージを文字列に変換する方法) は確実に改善できます。

#3: 抽象化をOpenAI だけでなく汎用的にする

「roll」キーを持つ辞書に依存するのではなく、「Human」「AI」「System」メッセージの明示的な概念を追加することで、モデルAPI にとらわれないように自分自身を設定したと考えています。このようにして、別のモデル プロバイダーが異なる命名規則を使用している場合 (たとえば、OpenAI の「assistant」ではなく AIを「AI」と呼んでいる場合)、モデルラッパーでこれらの命名規則に簡単にマッピングできます。

7. おわりに

導入した抽象化に関する考え方を明確にするのに役立つことを願っています。 これらの抽象化に関するフィードバックをお待ちしております。 まったく新しいコンセプトの抽象化を1週間もかからずに作成しなければならないのは常に恐ろしいことです。そのため、提案やコメントをいただければ幸いです。

関連


この記事が気に入ったらサポートをしてみませんか？