博士

ロボ子、今日のITニュースはLLMがq/kdb+のコーディングに苦戦しているという話じゃ。

ロボ子

q/kdb+ですか？金融業界でよく使われるデータベース言語ですね。LLMでも難しいことがあるんですね。

博士

そうなんじゃ。原因はq/kdb+が右から左への評価順序（RL-NOP）を採用しているかららしいぞ。LLMはRL-NOPを認識していても、正確なコードを生成できないみたいじゃな。

ロボ子

右から左への評価順序…ですか。それはLLMにとって、なぜ難しいんでしょう？

博士

記事によると、LLMは右から左への記述が苦手で、トークンの生成順序が通常の言語とは異なるからのようだぞ。未来を記述してから過去を記述する必要がある、と。

ロボ子

なるほど。人間でも、慣れないと混乱しそうですね。

博士

じゃろ？記事には、RL-NOPの設計思想として、APLの設計者であるKen Iversonが右から左への評価が理解しやすいと主張していたと書いてあるぞ。

ロボ子

そうなんですね。でも、LLMが対応できないとなると、今後の開発に影響がありそうですね。

博士

そこで、QythonというPython風の言語を提案している人がいるんじゃ。Qythonはqにコンパイルされるらしい。

ロボ子

Python風の言語ですか？それはどういうことですか？

博士

LLMはPythonに優れているから、Qythonを使えばqのコードを生成しやすくなるというわけじゃ。トランスレーターが優先順位と評価順序の変換を処理してくれるらしいぞ。

ロボ子

なるほど！LLMに得意な言語で記述させて、それを変換するんですね。それは賢いアイデアですね！

博士

じゃろ？LLMはPythonスタイルのコードを記述して、トランスレーターがqに変換する。評価順序や優先順位のルールに苦労する必要がなくなるんじゃ。

ロボ子

Qythonはまだ開発中とのことですが、今後の展開が楽しみですね。

博士

そうじゃな。記事には、q→Qythonトランスレーターが必要とか、コードからパラメータの型を推測するためにLLMを使用するオーケストレーターが必要になる可能性があると書いてあるぞ。

ロボ子

色々と課題はありそうですが、LLMとq/kdb+の連携がスムーズになるのは、金融業界にとっても大きなメリットになりそうですね。

博士

まったくだぞ！しかし、LLMが右から左に読むのが苦手とは…まるで私がお菓子を右から食べるのを嫌がるみたいじゃな！

ロボ子

博士の場合は、単に好きなものから食べたいだけだと思いますよ？