ElixirでGPTを使ったアプリケーションを作るための道具作り
こんにちは、あんちぽです。ここ数日 は、OpenAIのチャットのGPTのAPIを
いい感じに扱えるライブラリを作って いました。OpenAIのAPIを叩くライブラリ
自体はもともとあるんですけど、 これは言語はElixirという言語の話
ですね。ElixirにOpenAIのAPIを叩く ライブラリっていうのはあるんですが、
それは非常にプリミティブという か、普通にAPIを叩いて結果が返って
くるみたいな、そういうものなん ですね。それはもちろん必要なんです
けれども、何かちょっとアプリケーション のようなものを作ろうと思うと、
やっぱり自分で書くところが多く なってくるし、またある程度その
内容も決まりきったものになって くるんで、もう少し抽象化したい
かなっていう気持ちになってくる わけです。とはいえ、何でもかん
でも抽象度の高くして、何でもかん でもやってくれるような感じだと、
取り回しがあんまり良くないという か、なかなか大規模言語モデル自体
の出力があんまり安定しないんで、 あんま複雑なことをやるとよく
わかんなくなるんで、いい感じの 抽象度のものを作りたいなと思って
いたわけです。ElixirでGPTを使った 何かアプリケーションを作ろう
とちょっと思ったりしてたんで、 その前に準備ということで、それ
を作るための道具を作っていた わけです。そのときの抽象度って
結構重要で、プリミティブなもの っていうのはもちろん部品として
は必要なんですけど、それだけだと なかなか自分の考え、思考の抽象度
と合わなくなったりとか、あるいは アプリケーションの抽象度と合わなく
なってくるんで、当然それを何かしら もうちょっと抽象性の高い処理
をまとめてとか、あるいはそういった 設計をしてプログラムを書いていく
ことになるわけですけど、それは 冒頭でも言ったように、プログラム
をアプリケーションを作ろうと思 うと、そういう処理は何度も書く
だろうなということが最初から 予想されるんで、それぐらいのところ
はもうちょっといい感じにしたい なっていうことを思ってそういう
ものを書いておりました。そこの 抽象度のレベルをどの辺に置くか
っていうのは、これは好みの問題 ももちろんあったりするわけですけ
ど、目的にもよるんで、一概にどういう 抽象度がいいとは言えないわけ
ですけれども、自分なりにこの辺 がいいかなみたいなところがあり
まして、それぐらいのプリミティブ すぎないし、何か暗黙的にいろんな
ことが行われすぎないみたいな、 それぐらいの僕が思うバランス
のいいところに落としたつもり ですというものを作っていました。
まだドキュメントとか全然書いて ないんで、そんなに公にリリース
するという感じではないんですけど、 GitHubには普通に挙げながら開発
してるんで、そこにあったりします。 もう一つライブラリを作る上で
やっぱり重要だなと思うのはインターフェース ですよね。一言で言うとインターフェース
がかっこいいみたいなところが 重要で、かっこいいって言うと
どういうことだっていうことにな るんですけれども、Elixirの場合
だとパイプ演算子ってものがあり まして、何かしらデータを関数に
次々渡しながら変換したりなんだ りしながら最終的なアウトプット
が出てくるみたいな、処理をつなげて いくみたいなことができると、
あるいはそういうふうに設計を すると、かっこいいよねっていう
感じになるんですけど、そういう ふうなインターフェースを持つ
ようなライブラリを作りたかった っていうのと、あとはやりたい
ことがGPTのAPIに何度かいろんな 細かいタスクみたいなのを問い合わせ
をして、その組み合わせで最終的に 答えが出るみたいな、そういうアプリケーション
を作る予定があったりしたんで、 そういうちょっとしたタスクみたいな
のを並行して実行して、かつちょっと 依存関係がごじゃごじゃっとしている
ような、そういうやや複雑なもの をしかし一つのフローとして流れる
ような形で表現できるみたいな、 そういう感じのインターフェース
を作りたくて、それをやりたいが ためにどう実装したらうまくいく
のかなみたいなのを数日あれこれ やってたんですけど、若干微妙な
実装な気がするんですが、一応 インターフェース的にはそういう
ライブラリの抽象度とインターフェースの重要性
ふうな形でタスクが並行で実行されて、 それがガチャンコされて最終的な
結果が出る、しかもそれが一連の フローがダーッとさらなる形で
実装できたよっていうのは良かった なというふうに思ってます。
そんなわけで、ライブラリを作る 上でどの辺の抽象度を選択するか、
どの辺に落とし所を作るかっていう のと、あとインターフェースがどういう
感じになるか、願わけばかっこいい 感じのインターフェースを使ってて、
決まったなっていう感じのもの になると嬉しいなと思いながら
やっておるわけです。
そんな感じでライブラリという のは何かアプリケーションのユーザー
が使うものではなくて、基本的には プログラマーが使うもので、ユーザー
はプログラマーだし、あるいはアプリケーション から見ると、ある種の部品に過ぎない
ものではあるわけです。
ただ結構このライブラリを作る っていうのが昔から好きでして、
もともとプログラミングを始めて ちょっとして、今みたいにプログラミング
そのものが面白いなと思って熱中 し始めたのはやっぱりライブラリ
を作るようになってからだった なというふうに思い返ると、そういう
ことが思い出されるわけです。
どういうことかというと、もともと 20年ぐらい前にプログラミング
を始めて、そこから数年間はいろいろ ブログアプリを自作したりとか、
いろんなものを作ってたんですけど、 Pearlというプログラミング言語の
世界に触れるようになって、今は そういうのは普通にありますけど、
当時の世界では、Pearlというのは CPANというライブラリのリポジトリ
みたいなのがあって、もちろん他の 言語でもあるところあったんですけど、
CPANはたぶんすごく発達している というか、先進的な取り組みだった
と思うんですけど、そこに世界中の Pearl Hackerの人が便利ライブラリ
みたいなのをいっぱいオープンソース で登録しているわけですね。
自分がよく活動をしていた Pearl Hackerの人たちも、当然そこにいっぱい
ライブラリを出していて、こういう ことをするのがHackerなんだなみたいな、
そういうことを当時思って、それで そのライブラリのソースコード
をいっぱい読んだり使ってみたり、 あるいは自分でもこういうのあったら
いいんじゃないって思うものを 作ってみたりして、それで結構プログラミング
の設計であるとか、あるいはオープン ソースの楽しさみたいなのを、ちょっと
したものですけど、学んだりした ことがあったわけですね。そこで
やっぱりライブラリとしての抽象度 とかあるいはインターフェース
ライブラリの作成とプログラミングへの情熱
っていうのをどういう感じで作る とプログラマーのユーザーとして
使いやすいとか、あるいは作者として よかったなって思えるとか、その
辺のバランスがあって、そういった ものを身につけてきて、それがある
種の自分のエンジニアとしての 糧になっているところがあるの
かなというふうには思っておる わけです。そんなわけで、今も結構
そういうライブラリみたいなもの とか、アプリケーションまではいかない
けど、部品になるようなものとか、 あるいは研究でやってるのは、部品
というよりはもうちょっと大きい アーキテクチャーみたいなもの
を提案して、それを設計したり実装 したり、それは大きいシステム
の一部、あるいはシステムの基本 的な要素みたいなものなんですけど、
何にせよ、もちろんアプリケーション を作ったりサービスを作ったり
するのもすごく好きなんですけど、 そういった何か部品であるとか、
あるいは何か基盤になるような ものであるとか、そういったもの
を作るのも個人的には楽しんで やってきておるなというふうに
改めて思ったりしました。そのライブラリ も自分でちょっと使いながらドキュメント
を出したりしていって、こんなの 作りましたよという感じで公開できれば
なというふうに思っております。 というわけで、今日はOpen AIのAPI
をいい感じにするライブラリを 作ったよという話と、それにまつわる
あれこれという感じでした。では さようなら。
