有機分子記述法開発 02
理想は面白いと感じてはいるものの、もう少し詳しく計画を考えるべきでしょう。
そのために、既存の方法と比較しつつ、何が必要なのかを考えました。
大前提 Webサイトで動く
我々が普段使っているWebベースのAIチャット(Copilotなんかもそうですね)は、いわゆるWebサイトなわけですから、 Webサイトで動かないと、インタラクティブな会話はできません。つまり、そもそもC言語でいかに軽いアプリケーションを作ったところで、 チャット画面で実行することができないわけです。
この時点で、既存の多くのアプローチは使えないことが分かります。RdkitはPythonライブラリですから、これを活用するのは現実的ではないでしょう。 仮に、ChemDrawなどを無理やり活用できるとしても、そもそも元のソフトが動かせないわけです。
また、知名度は皆無に等しいですが、軽量なSketchEIなどのフリーソフトは存在します。しかし、これはjavaランタイム上で動くソフトであって、サイト上では 動かせません。
調べてみたところ、意外と、JavaScriptで分子を書けるサイトというのはあるようです。有名なのがJSMEやChemDoodleなどのようですね。
ただし、これらのサイトは、分子をマウスで書くような操作をやるためのサイトであって、コードによって生成するというタイプではないため、LLMがいじるのは大変でしょう。
というわけで、JavaScriptで完全に自作することにしました。とりあえず言語はこれで行きます。
ソースコードが短く済む
最新モデルは数学がここまで解けるように、といった記事は数多くありますが、実のところ、普通の人が触るようなAIは、そんなことはやってくれません。
なぜなら、そういった試験は、APIを直接叩くという普通の人はやらない手段で行われているからです。普段私たちがアプリケーションやブラウザで動かす、想像するようなAIは、そんなに優秀ではないです。
これは、モデルが賢くないという意味ではありません。むしろ、トークン量、キャッシュ量の厳しい制限によって、「考える頭自体はあるが、使っていい領域が非常に狭い」 という認識のほうが近いでしょう。AIと会話を続けていると、急激に重くなったり、話してた内容を忘れてしまったりするのは、これが原因ということになります。
このため、図の出力にかかるトークンが多いと、そっちに思考のリソースが持っていかれてしまい、議論ができなくなります。また、キャッシュも食うため、すぐ話を忘れてしまうでしょう。
よって、ソースコードが短く済むのは必須の仕様といえるでしょう。
まだいろいろありますが、数回に分けて記事にしていこうと思います。