LLMにおける翻訳レイヤーの導入
あけおめことよろ
AIの進化はとどまるところを知らず、モデルが現れては消え、動画生成AIに至っては計算資源を食いつぶす勢いだ。動画モデルの高コストの理由としてその作り方が挙げられる。画像をたくさん作っているからだ。そしてその画像は彫刻を掘り出すように作られる。具体的には、ノイズを元にしてそこから任意のプロンプトに沿った画像を取り出すという手法だ。これはLLMにおける文章作成が、確率的なトークンの羅列として作られる事と対照になる。
例えて言うなら、文章の生成がホワイトボードに黒ペンで絵を描くことだとするなら、画像の生成はホワイトボードを一度黒ペンで塗りつぶし、そこから不必要な黒ペン部分を消していくことになる。だから彫刻
このように現状の生成AIはコストが大きい
AIのプロンプトでは現状、マークダウン方式が取られる。プロンプトエンジニアリングというものだ。再現性高く意図をなるべく高確率で反映させるための技術だ。一方で我々一般人は、友人や家族と話すようにLLMに語りかける。それでもLLMはある程度納得のいく回答を作成してくれる。しかしもちろんブレは大きく（このブレはプロンプト自体にも原因があるが、どのバッチ処理にあてられるかも原因となるらしい）意図を取り違える場合もある
プロンプトエンジニアリングという言葉が出てきた当初、私は「そのうち絶滅するし、絶滅することこそがAIにおける勝利」だと思っていた。今は違う。プロンプトエンジニアリングは、自分の意図を最大漏らさず誇大表現せずそのまま相手に伝えるコミュニケーション手段として発展すると考えられる。対象はAIからAIを含めた全てのコミュニケーション対象になるだろう
このように、生成AIにはより良いコミュニケーション手段が必要だ
とあるネットニュースにおいて、LLMに対するプロンプトが偉そうだと不快感を覚える、という内容のものがあった。プロンプトなど意図が正しく伝われば良さそうなものだが、対外的にそれを見せるときには表現方法まで社会的な影響を考慮しなくてはいけないらしい
プロンプトを社会的に開示する必要がある場合、その表現方法は自分が何者かを自己紹介する一端となり得、それ故に、そのプロンプトは非効率なものになり得る
言語によってLLMの成果物に差が出ることが確認されている
例えば英語でのプロンプトは優秀な成果物が作成される事が多い。なぜなら英語はよく使われており、それに対する成果物もよく作成されており、故にフィードバックループがよく回るからだ。さらにトークン分割の効率化も見逃せない。英語の特徴として単語間にスペースが入る。助詞ではなく文章における配置場所によってSやOが決まる。LLMは英語で使うことの効用が大きい
それらの事例を見て私なりに考えた
画像や動画は複雑なので、まずはLLMでなにか工夫ができないか？
そこで至ったのが、翻訳レイヤーを導入するというものだ
利用フローは以下の通りだ
１ 人間がプロンプトを自然な会話として入力する
２ 翻訳レイヤーで意味の正規化が行われる。LLMが効率的に動くための翻訳だ。それは文章の入れ替えであるかもしれないし英語への翻訳かもしれない。情緒的な文章や論理破綻した質問、その言語に根ざした社会的な文化背景を前提とする文章は、翻訳できないのでしない。逆に数学や論理などはかなり良く適合する。プロンプトの意味をなるべく変えたくないが、実務上「変更はあったが意味が変わっていないことの証明」がものすごく難しいのでそこは妥協する。LLMの計算効率を上げるため少しだけ意味合いが変わるかもしれない。
そこで翻訳されたものをIRと名付けよう
３ IRは、もしくは翻訳が不可能であったためそのまま素通りされた素のプロンプトは、LLMに送られる。前者の場合、効率的な演算が行われより良い成果物が生まれる可能性がある。後者の場合は、今までと何も変わらない。あえて言うなら翻訳可能会中のチェックが入る分、ほんの少しコスト（演算リソースや時間）がかかるかもしれない（原文のプロンプトにもよるがが、無視できる程度だろう。）
４ IRで入力された成果物はIRのような無味乾燥な、または、色も素っ気もない文章が成果物として生成される。そこでLLMに渡すときに翻訳をしたように、今度はIRを人間側に翻訳する必要がある。人間側が質問した表現に合わせるのだ。IRをそのまま渡して問題ないようなプロンプトが原文であった場合はそのまま渡す。プロンプト原文が表現豊かな場合、身も蓋もない文章は回答として成果物にふさわしくない。なのでプロンプトに合わせる表現を付加する。この時、意味合いは変わらないが表現方法の点において限定されてハルシネーションが入り込む余地はある
仕様の一覧としては以下の通りだ
１ 入力コンパイラ
原文の意味・意図を100%保持したまま、LLMのトークン効率が最大化される構造（IR：中間表現）へ写像する
翻訳不可能な場合、エラーを返したりと、まるでプログラムにおけるコンパイラのようなことはしない。UXを優先し、今まで通り素通しする
２ 入力値バリデーション
日付の矛盾（例：13月34日）など、明らかなエラーをLLM送信前に検知する。それによりLLMに「その日付はありません」と回答させるような無駄なコスト（計算コストと時間）を事前にカットする
３ ローカルキャッシュ
翻訳機本体とキャッシュ、メタデータはすべてユーザーのローカルデバイスに置く。これにより、プライバシーの完全保護、およびクラウド同期に伴う遅延と通信コストをゼロにすることを狙う
例えば毎日「今日の天気は？」とスマホでLLMに質問するユーザーがいた場合、そのユーザーのスマホには「今日の天気は？」に対するLLMが最も効率的に動くことができるキャッシュが存在する確率が高い
なお、２の入力値バリデーションチェックに引っかかったものはキャッシュを作らないし作る判断をするロジックまでいれない。これにより、ローカルストレージを節約し、有用性の高いキャッシュが選別されて保存される
４ 嗜好設定のサーバー同期（Preference Sync）
翻訳キャッシュの実体はローカルだが、そこから抽出された「回答の嗜好（例：簡潔に、丁寧になど）」のみをサーバーのLLMパーソナライズ設定に反映する。これにより、回答の嗜好において、スマホと家のPCと会社のPCでの同期が取れる
５ 中間表現（IR：Intermediate Representation）
プロンプトを根拠に作成した、事実、数値、因果関係、固有名詞、制約条件などを抽出・固定したLLMの処理に最適化された無味乾燥なデータ構造。英語かもしれないしそうでないかもしれない。それは言語圏によって思考スタイルや概念のズレさえそんざいするからだ。砂漠で生まれた言語の伝統的思考と、北極で生まれた言語の伝統的思考が必ずしも自然言語として翻訳可能とは言えない。翻訳できないならプロンプトの言語そのままにしておくべき。効率や成果最大化を図るなら英語のほうが良いと思われる
６ 出力デコンパイラ
IRがLLMにわたり成果物としてIRのような回答が生成される。そのデータに基づき、プロンプトの情緒やユーザーの嗜好に合わせた「肉付け」を行う。比喩や語り口の調整を許容する。日本語のプロンプトで表現豊かな質問がプロンプトとして入力されたなら、その回答もまた、日本度で表現豊かな回答であるべきだ。途中のIRにおいて、無味乾燥な英語に翻訳できた場合、そのように翻訳しなければならない。
注意点として、ここで新情報が追加されることはない。ハルシネーションを抑えたいからだ。ハルシネーションが発生するとすれば、表現の揺れなどにとどまる。その為、ルールベースでの構造チェックは必要になるだろう
問題点
１ コンパイラ（人間→LLMの翻訳）における意味損失の具体性が低い
２ デコンパイラの意味検出におけるルールもまた抽象的
３ LLMのモデルが新しいものに（バージョンアップ）なった際、キャッシュもまた最適化されるのが筋（ただし古いLLMモデルが新しいLLMモデルと併存することは多いので、古いキャッシュも置いておく必要はある）。キャッシュのバージョンアップと、キャッシュ構造自体がバージョンアップした際（IRのバージョンアップ）の再作成に関して詰めきれていない
（ローカルストレージとの兼ね合い）
４ 「トークン密度が低い日本語やアラビア語は必ず英訳を試みる。比較的高い中国語は英訳をせず構造化のみを行う」という、コンパイラにおける多言語対応メタデータがあっても良いかもしれない
５ ユーザーが、当該翻訳レイヤーの価値を可視化できる「仕掛け」がない
演算コストが下がったのであれば、ユーザーがその恩恵を受けられても良いはず。現在のような定額制でなく従量課金制の場合明確になりやすい
しかしこれはLLMメーカーの決めること
６ 翻訳レイヤーやキャッシュの業界標準化
これによりユーザーは様々なLLMにスイッチングしやすくなる。もちろんLLMメーカー、特に現在だとOPENAIやGOOGLEがそこに旨味を見出さなければ実現されない
また、どのLLMモデルでも使える効率化は、どのLLMモデルでもそこそこ非効率だったりもする。ユーザーにとっての恩恵とメーカー間の綱引きになる
現実解としては、業界標準というよりデファクトスタンダードが市場を支配する流れになるだろう
７ コンパイル・デコンパイル双方において、医療や法律など業界の最新ドメイン情報をプラグインとして導入する方法が考えられる。現状LLMはその全てを一つの巨大な脳で処理しており、重い
８ ローカルに翻訳レイヤーを置くことで、特にスマホのバッテリー消費が気にされる
既存技術との比較
・既存のプロンプトキャッシュ(Anthropic等)
サーバー側で同一文字列のキャッシュ
プライバシー懸念あり
ユーザー個別の最適化なし
・本提案の翻訳レイヤー
ローカルで意味ベースのキャッシュ
プライバシー完全保護
個人の癖や嗜好を学習
以上、ではでは
