動機¶

このライブラリのアイデアは、いくつかのLLM関連OSSのコードを読んだり利用する中で抱いた課題意識 が発端となっています。

この課題意識を共有し、コミュニティに対して問題提起することで、より良い解決策を模索できればと思います。

現状のLLM関連ライブラリ（コミュニティ）の課題¶

最近は OpenAI の GPT-3.5-turbo や gpt-4 だけでなく、多くのLLMが利用可能になっています。

具体的には、2023/08/27現在で、 LangChainがサポートするLLMの数は、 52個に及んでいます(langchain/llms)。

時代の流れ的に、利用可能なLLMの数は加速度的に増えていくことになると思います。

基本的に、LLM関連ライブラリは新規に公開されたLLMを実装に追加することで進化しています。多くのライブラリでLLMに依存しないように抽象クラスを作成しており、このアプローチは正しいと感じられます。しかしながら、各ライブラリが独自の抽象化を行っているため、その抽象クラスに依存した開発がライブラリ固有となってしまいます 。加えて、コードの品質にばらつきがあり、メンテナンスが難しいコードも見受けられます。

この状況が続けば、新たなLLM関連ライブラリが増えるたびに不要な実装が繰り返され、ライブラリ間の連携が困難になる恐れがあります。

現状のライブラリの方向性は、それぞれが独立して機能するための利便性を持っています。しかしその結果、ライブラリ間の機能の統合が難しくなり、拡張性やカスタマイズ性が犠牲になる可能性が高まります。これは非効率であり、コミュニティ全体のリソースが無駄に消費される ことを意味します。

「LLMの進化にPythonライブラリが追いつけなくなるかもしれない」 という懸念から、LLMの進化に対応し、ライブラリやライブラリ間の連携がスムーズに行える方向性を考えるようになりました。

どんなライブラリがあれば良いか？¶

上記の課題に応えるための新しいライブラリを考えました。その方針として以下の３点を設定しました。

方針1: LLM関連ライブラリが安心して依存できるシンプルなインターフェイスを提供する¶

LLMを抽象化すれば、つまるところ、入力を受け取りテキストを生成するものとして表現できます。マルチモーダルではないテキストを入力するLLMであれば、テキスト入力を受け取り、テキストを生成するだけのインターフェイスがあれば十分です。LLMごとの細かい設定はあるものの、これは実装の詳細として隠蔽すべきです。

方針2: 限定的な機能を持つシンプルなライブラリにする¶

シンプルな構造は、使い勝手を良くし、直感的な操作を可能にします。

方針3: 依存先ライブラリを極力少なくする¶

FastAPI は、依存先が少ないライブラリの良い例です。そのアプローチを参考にしたいと考えました。依存先ライブラリが少ないということは、他のライブラリの破壊的な変更に対して堅牢であるというメリットがあります。

ここまでのまとめ¶

PromptoGen は、上記の方針に基づいて作成されたライブラリです。

LLMを利用したいライブラリが、このライブラリのインターフェイスに依存すれば、基本的に各LLMをサポートするようになる世界観を目指しています。

このライブラリのインターフェイスに依存しているライブラリ同士はお互いに連携しやすく、エコシステムが構築され、「車輪の再発明」が行われにくくなり、無駄な開発リソースを減らすことができるようになります。

もちろん、このライブラリが唯一の解ではないので、コミュニティに対する一つの問題提起 になれると嬉しいです。