GPTのAPIや、プロンプトエンジニアリング周りについてメモる

public.icon

次は、どうやったら精度が上がるかのフェーズtkgshn.icon

genemiはかなりのコンテキストを投げられる

これは、制度の概要と、過去に生成したデータ（"OpenFisca化"したデータ）のペアを大量にコンテキストに含めている例

なるべくGPTで完結させた方がシンプルだと思っているのだが、他のもっといいLLMがあったりするのかな？

それか、Local LLMも結構1つの候補には上がっている

ここら辺は本番環境でLLMを組み込んだソフトウェアを作る経験がある人に一旦聞いてみるのがいいかも？@blu3mo.icon, k3ntar0.iconあたり？

深い理由がなければとりあえずOpenAI APIを使えばいいと思うblu3mo.iconnishio.icon

日本語の情報扱うなら他にGeminiかClaudeも候補に上がると思うが、一旦OpenAIでいいかと

なるほどねtkgshn.icon*3

context lengthとか速度とかコスパで困ってきたら他の候補も考えればいいblu3mo.icon

それはそうだわtkgshn.icon

2024/10/22現在、GPT-4oが一番バランスがいい？

Omni（o1）というのが一番新しいやつっぽい、でも高い？

問題は、エンジニアリングにおいてGPTを使うとバージョンアップデートしたときに同じ返信が返ってこないこと

しばらくは日付指定で古いバージョンを使い続けることができるはず。永続保証はないけど。blu3mo.icon

gpt-4o-2024-08-06、gpt-4o-2024-05-13とか

そもそもバージョンが変わらなくても再現性ないのではnishio.icon

温度0だったら同じ結果が返るんだろうか？本質的に再現性を期待するべきでないシステムと認識していた

確かにtkgshn.icon

メモ

現在はプロトタイピングなので制度の数は多くないが、将来的にはこれが社会保障制度の数の分だけ増えていくことになる

"OpenFisca化"したデータをプロンプトに持っておくのは結構しんどくなるはず

コンテキストとして大量に持っておきたいなら、ベクトルデータ化して渡すというのもあると思う（TTTCの特定のクラスタの意見と対話する機能はそうやっていた）

これをRAGとよぶ?→YEStkgshn.icon

ただ、ベクトルデータだとちょっと抽象的すぎる？内容を覚えさせておきたいときはベクトルデータでもいいかもしれないが、今回のような「自然言語の概要→DSL」はもうちょっと詳細が必要なデータだという認識

RAG=検索によって増強した生成　なので「ベクトルだと抽象的」ってのはおかしいnishio.icon

ベクトルは検索に使うだけで、検索結果は普通に文章としてコンテキストに積むので…