  |
はてなキーワード:中間言語とは
人類の言語そのものを目的関数としてそれに対して最適化するのがLLMなのだから、人類の認知で到底不可能なことはやりようがないだろう。
一文で本質を突いている。AIの能力限界を構造的に説明している。
今よりもAIが進歩した未来では「自然言語で与えられた仕様から機械語を出力するように訓練されたAI」が出てくるかもしれないけど、そいつの内部をよく観察したら結局今日の高級言語みたいなもので思考していた、みたいなオチになるんじゃないんですかね
結論と完全に一致。内部に抽象化レイヤーが生まれるという洞察。
マシン語でエラーを吐き出されても、元となるプログラミング言語での設計がすっ飛ばされていたら、どこの何が問題なのかが照合困難で修正が困難なのが根幹な気がします。
検証・修正サイクルに意味の単位が必要という話を、実務的な観点から der表現。
計算機科学について何一つ知らなかったとしても、ニーモニックを無作為に並べるよりソースからコンパイルした結果の方が解空間が圧倒的に小さいのだから、機械語の生成はAI 以前に単なる探索として悪手だ、というのが自然な発想だと思うんだけど。
探索空間という観点からの指摘。高級言語は制約を与えて解空間を狭める役割がある。
抽象化した方が簡潔に記述できるのはAIにとっても同じことで、そっちの方がAIも理解しやすいし、生成しやすい。現在の機械語、アセンブリ、高級言語の階層構造が崩れるとは思えない。
「AIにとっても同じ」という視点が正しい。人間向けとAI向けが乖離しないことを理解している。
「AIが直接機械語書けばプログラミング言語は要らないのでは？」的な話はみんな最初に頭を過るだろうけど、コードを出力するのがLarge "Language"Modelである以上は意味論から組み立てる高級言語の方がそりゃ相性いいでしょうね。
AIを何かgodlikeな超知性だと思っている人間が多いけど、人間にとって「機械語よりも高級言語の方が当然書きやすい」のと同様、AIにとっても「機械語よりも高級言語の方が当然書きやすい」よなぁという話
「AI向け言語は人間にも使いやすいはず」という結論と同じ方向。
CPUへの命令にまで細かく分解された機械語なんて、それが何をするための処理なのかはAI（LLM）でも大変だと思いますよ。そのCPUへの命令群で何をやろうとしているのかなんていう情報はほぼ捨て去っているわけなので。
機械語には意味がエンコードされていない、という議論の核心部分。
機械語派は抽象化の力を舐めすぎ。型なし言語はトークン削減量に対して失われる確定情報量が多すぎ。LLMが内部で型を推論したら本当にトークンが削減できるか怪しい。全能AIを仮定するなら、「人が作ったハード上で機械語を直接書く」なんて中途半端で「ハードごと最適化」くらいの夢を語ってほしい。
AIが機械語を直接書くようになるとか言っている人は、機械語にこそ真の価値があると思ってるんですかね？いかなる音声も元にせず、指示に従ってレコードに直接溝を刻んで音を鳴らす技術が広まれば、音楽がさらに発展するとでも思っているんでしょうか？
AI専用言語にせよ機械語を直接出力にせよ、人の持つ高レベルの意図や仕様、アルゴリズムを正しく反映したデータセット、意味構造が保存された対応データが存在しないから難しいというか現実的に無理よなぁ
学習データの観点から。意味構造が保存されたデータがないと学習できない。
「AI がマシン語を吐いたらプログラミング言語はいらない」系の話が出てくるのは「AIは人間の言葉より、機械の言葉の方が本当は理解しやすいはずだ」という思い込みから来ているのじゃないかと思っていて
誤解の根源を正確に特定している。
まず機械語を直接記述するメリットがない。現代コンパイラ、インタープリタは超優秀(OSや組み込みの一部だけ)。人類のプログラム資産は高級言語がほとんど。AIの学習先もそれ、よってAIは高級言語で出力するほうが成績が良い
AIが直接機械語を出力すべきか？という話題が流行っている。直感的には、動作中のAIの中身を調べると、結局はコンパイラやプログラミング言語に相当する構造が即席で構成されてそう。つまり同じことを高いコストでやる感じになり
内部に抽象化レイヤーが生まれるという洞察。mod_poppoさんと同じ結論。
意味推論がLLMの得意技なので、意味を削ぎ落とした本質の塊である機械語は理解できず、意味の羅列である高級言語こそがむしろ生成AIに最適化されている。
コンパイラって優秀だから、AIといえども生で機械語を読み書きするよりもコンパイラ介した方がいいと思うんだよな。そのくらいLLMって機械寄りじゃなくて人間寄りなんだと思う。元がニューロンの模倣だし。
高レベルになるとコンパイラの出力を疑って生成されたコードを読まないといけない状況は普通にあるので、高水準なAI生成のコードが何をやってるか理解するスキルは当面は必須だと思う
もし仮にAIが機械語を吐き出せるとしても、高速に、決定論的に、段階的に、最適に動作するコンパイラを使わず、低速で、確率論的で、逐次的で、最適な動作ができないAIを利用する意義はほぼないと思う
コンパイラとの比較で、AIに機械語を吐かせるメリットのなさを指摘。
機械語は冗長で複雑かつ非常に正確な出力が必要なので、高級言語を使って既存のコンパイラやビルドパイプラインに乗せる方がAIにとっても効率が圧倒的に良いと聞いて確かになぁと思いました。
自然言語を処理するのがLLMなので、不自然な機械語は難しいだろうね。1命令ごとに「それは何を目的とした操作か」とか文脈でわかりにくいしねぇ。
AI時代の人間の仕事は、信頼性確約（＝こういう理屈で大丈夫、と説明できること）が大きな領分を占めるだろうと推測されるので、機械語だけで良いとか言ってるやつは責任を取る気皆無なゴミ野郎です。
LLMに機械語を出力させようとするやつは「AIは機械なんだから機械語は簡単に扱える」という意味不明な思考をしてるだけなのでまともに取り扱うような相手ではない。名字が山口な人は長州方言が話せるんですよねとか言ってるくらい支離滅裂
人間がソフトウェアに「こう動いてほしい」という意図と「ソースコードがどのように変更されたか」の対応はGitHubとかに大量のデータがあるのでそれを学習すればコーディングするAIは作れる気がするけど、人間の意図と機械語の対応は学習データが全然ないからAI作れないように思う
「よく使うロジックを共通部品化する」とか「とはいえ局所最適な命令も欲しい」とかを考えると、中間言語を用意して最終的な機械語へコンパイルする、という流れは必要と思う。つまり、「AI用に最適化されたプログラミング言語」があるべき。
AIは人とのコミュニケーションをいかにスマートにするかにとんでもなく時間を掛けてきたわけで、人が直接読み書きできない機械語を出力しても意味がないよね。
AI機械語コーディング、やろうと思えばできるが普通はやらないような可読性の低いコーディング方法が多すぎて、AIﾁｬﾝに本気出されるとバグったときに修復不能になりそうな気がする
これだけAIが発展したならAIに直接機械語作らせればいいじゃんみたいな言説をたまに見るけど、それどうやって今のLLMと同じ水準まで学習するの？といつも思ってる
ロジックに従っているわけだから、ソースで想定外の挙動をした被疑箇所前後にロガーやらブレークポイントを仕込むという原始的だが確実なデバッグが、いきなり機械語を吐かれると出来ないんよ。
デバッグ実務の観点から。意味の単位がないとデバッグできない。
AIにしか読めない言語より、人類が発見的に設計したんじゃない人類にもAIにも優しいプログラミング言語・中間表現・機械語をデータドリブンに統計的に正しくAIが作るって方向に行かないですかね
AIが直接機械語吐くのは遠回りしてるだけだから無いとして、完全に人間がプログラムを読まなくなったらプログラミング言語はどう進化するのかは気になる
「無い」と断じた上で、次の問いを立てている。建設的。
プログラミング言語は人間の認知負荷、記憶量の限界、ミステイク、スパゲティコード理解できないためにあるので、AIだったら直接機械語吐くだろ。常考。
反論： 完全に逆。プログラミング言語は「人間の限界を補うため」ではなく「意味を構造として保持するため」にある。AIも意味を扱う以上、意味を表現する層が必要。「常考」と言いながら何も考えてない。
シンギュラリティ前夜 アダム（AI）が、人間には理解できないどころか、読むことすらできないコードを出力し始めた。後に判明することだが、それは機械語だった。
反論：SFポエム。「人間に読めない＝機械語」という発想が、まさに今回の議論で否定されてる誤解そのもの。AIが人間を超えるとしたら、ローレベルに降りるんじゃなくてハイレベルに登る方向。
なんかLLM界隈？では「AIがやがて機械語をだす（ので実用的にはコンピュータ言語は不要になる）」と言うと、無知だとか実情知らないとかブロックしてやるとか言われる見たいだけど。数年は無理だけど、いずれそうなると予想してる。
反論： 「数年は無理だけど、いずれそうなる」の根拠がゼロ。なぜそうなるのか、意味と機械語のギャップをどう埋めるのか、何も説明してない。批判されてる理由を理解してない。
プログラム言語って人間が扱うために自由度を削り取った結果の産物やから、AIに機械語で作ってもらって最適解であれば、現代の言語の宗教感ってほぼほぼ否定されるのです
反論： 「人間が扱うために」という前提が間違い。自由度を削ってるのは「意味を保持するため」。AIも意味を扱う以上、同じ制約を受ける。「宗教感」とか言って茶化してるけど、構造を理解してない。
「まだ」人間が安心する為では無いのですか？コンパイル後の機械語を読む人が殆ど居ない事は受け入れてるのに、将来的にAIが機械語出力する事に忌避感を感じるのは論理的とは言えません
反論：コンパイラの出力を読まないのは「コンパイラが検証済みだから」。AIの出力は検証が必要。この二つを同列に扱うのがおかしい。「論理的とは言えません」と言いながら、論理が破綻してる。
AIが機械語はけば、は数ヶ月前にメンバーと話になった。結論は、いまはあかんやろけど数年後に、もう人間が見る必要全然ないわ、となったらありうるな、となった。
反論： 「人間が見る必要がなくなったら」という仮定自体が検討されてない。人間が見なくていいとして、AIはどうやって検証・修正するの？意味の単位がない機械語で？その議論が抜けてる。
機械語って逆にトークン消費するの？お〜…じゃあLIFE3.0時代のAIは機械語ではなくAI用に最適化された人間には読めない言語で思考する、という方向性なのかな。
反論： 「人間には読めない言語」がなぜ生まれると思うのか。AIは人間の認知を模倣してるので、AIにとって扱いやすい言語は人間にも扱いやすい方向に収束する。逆方向には行かない。
中間言語不要派の言い分：AIが直接機械語を出力可能で、効率最適化が進む。人間の都合で言語が存在するが、AIなら移植性や抽象化不要で中間層をスキップできる。
反論： Grok自身が「中間言語不要派の言い分」として紹介してるけど、これ全部間違い。「人間の都合で言語が存在する」が誤り。意味を扱うために言語が存在する。AIも意味を扱う。
反論： 「うまくやってくれるかもしれん」で済む話じゃない。なぜうまくいくのか、検証・修正はどうするのか、何も考えてない。
反論： これは自虐なので反論というより…正直でよろしい。専門外だと自覚してるなら、なぜそう思ったのか掘り下げて、専門家の意見を聞く姿勢があれば良いと思う。
筋の悪い言説に共通するのは：
1. 「高級言語＝人間のため」という誤解 -意味を扱うための構造だと理解してない
2. 「AIは機械だから機械語が得意」という誤解 -AIは人間の認知を模倣してると理解してない
3.検証・修正の問題を無視 - 一発で完璧に動く前提になってる
HTMLコンパイラとは、一般的な「コンパイラ」の概念とは少し異なり、HTML文書や要素に対して新しい文法や振る舞いをブラウザに伝え、拡張するための仕組みを指すことが多いです。例えば、AngularJSのHTMLコンパイラは、開発者が定義したカスタム要素や属性（ディレクティブ）を解釈して、動作を紐づける役割を持ちます。これにより、標準のHTMLにはない独自の文法や機能をブラウザ上で実現できます。
一方、一般的な「コンパイラ」は、人間が書いたプログラムコードをコンピュータが理解可能な機械語や中間言語に翻訳するソフトウェアや処理のことです。この処理を「コンパイル」といい、プログラミング言語で書かれたソースコードを一括で変換し、実行可能な形式にします。コンパイラと対比されるのが「インタプリタ」で、こちらはソースコードを逐次読み解いて実行する方式です。
まとめると、「HTMLコンパイラ」はHTMLの静的な宣言文法を拡張し、新たな振る舞いを実現するものであり、主にフロントエンドフレームワーク（例：AngularJS）で用いられます。一方、「コンパイラ」はプログラムコード全般を実行可能な形式に変換する処理・ソフトウェアです。
https://ja.taiwebs.com/windows/download-html-compiler-2548.html
フロントエンドフレームワークで、新しいHTML要素や属性を作成するために用いる。
そのフレームワークがHTML文書の解析時にカスタムディレクティブやテンプレートを解釈し、動的な振る舞いを紐付ける。
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。
ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。
そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。
前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。
しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。
つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。
コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。
データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。
早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。
上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。
一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。
digraph graphname {
A -> B;
}
DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？
DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。
ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。
生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する"
];
A -> B;
}
プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。
このDOT言語をGoogle Gemini 2.5Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPEhtml>
<html lang="ja">
<head>
<meta charset="UTF-8">
<metaname="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<divid="output"></div>
<script>
//Webページが表示されたら（DOMが完全に読み込まれたら）実行される
document.addEventListener('DOMContentLoaded', function() {
// "Webページを表示する"ステップは、このHTMLファイル自体が表示されることで達成されます。
// "Webページを表示したらHello, worldとテキストを表示する"ステップ
const outputDiv = document.getElementById('output');
outputDiv.textContent = 'Hello, world';
});
</script>
</body>
</html>
フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。
また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。
より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
A -> B;
}
labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。
DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
最初の処理 -> 次の処理;
}
ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。
ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。
更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。
digraph増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機",
font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
];
最初の処理 -> 次の処理;
}
生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。
つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。
より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。
プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。
以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。
色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。
今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。
Permalink |記事への反応(36) | 19:36
絵師という言葉は最近できた言葉ではなく律令制にもある外来語が入ってくるまで使われた伝統的な言葉が1990年代から再度使われ始めただけ
そんな事より絵をかくことと音楽を作る事を同列に考えた場合、作曲家が考えた音楽は楽譜をとおして一般の演奏家が演奏するというのは紀元前より行われていた
しかし描かれた絵を再現する方法というのは生成AIが出てくるまでなかったのだ
音楽では作曲家と演奏家が別の能力であり演奏できるからといって作曲できる訳ではなく、多くの人が作曲家が作った曲を楽譜をよんで演奏しているだけである
絵は絵師が描いた絵を模倣するための中間言語が存在せず演奏家にあたる人がいなかったのだが生成AIが中間言語の役目を果たしプロンプトエンジニアが演奏家の役目となったのだ
開発したのがOpenAI Inc.なので勘違いしているのだろう。
ChatGPTは文字通りGenerative Pre-trained Transformerでしかない。
OpenAI社は人工知能の完成を目指している会社ではあるのだが、ChatGPTは副産物というか、素材というか。
神経細胞、シナプスの挙動を貧弱なコンピューターでどう再現するか。
こういうアプローチだった。
これと袂を分けて、入出力が人間っぽかったら良くね？
商業的な利用もそっちのほうがよくね？
先々人工知能エンジンの脳再現精度が上がったとしても入出力は自然言語で行わなければならない。
そのためには言語モデルを先に構築しておくのは無駄にはならない。
コアの人工知能エンジンは中間言語で入出力を行うが、外側HMIの部分をChatGPTに担わすようなイメージではなかろうか。
人の指示→ChatoGPTで中間言語にコンパイル→コアAI→中間言語でChatGPT→人が認知できる出力
このようなモデルならばコアAIは本質的人工知能の開発に注力できる、分離できる。
従来のAI研究はここ一緒くたにやとうとしてたのも停滞の原因と見抜いたのだろう。
営利企業である以上は稼げるプロダクトでなければ資金調達はできない、利益にならない
言語モデルの段階でも中間処理がそこそこできてればそれっぽいプロダクトにはなる。
商業的な使い道もある。
今後AIエンジンの開発は続くだろうが、現時点では知能とは程遠い完成度でしかない。
入出力がそれっぽいので知能っぽく見えるが、古典的な人工知能の定義から言えばおおよそ別物。
俺も気に入って使ってる、プログラム食わせたらあっさりバグも見つけやがった。すげぇと思う。
が、これは知能ではない。
なんか世間では、すげぇ物ができちゃった、世界が変わる、大革新、みたいな熱狂と不安と禁忌があるけどさ。
いやいや、そんな大層なものではありませんｗ
まぁこの辺のOpenAI社のマーケティング、演出は秀逸ではある。
ChatGPTの指示かな？ｗｗｗ
https://www.publickey1.jp/blog/22/net_7.html
中間言語なおかげで、コメントや変数名は残らないが普通に読めるレベルでC#コードに戻せるのがよかったのに、ネイティブだとそういうのも難しくなりそう
そのおかげで助かったこともあったし、ソースコードが見づらくなるネイティブ化はあんまりしてほしくないなーってところ
クライアントからこのソフトと連携してとexeを渡されたものの、仕様通りに動いてなくエラーログも出ない
もうサポートしてないバージョンらしく、ベンダーに聞いたりサポートしてもらうのも無理そう
C#で作られたものだったので、とりあえずソースコードを見たら原因がわかってどうにか対処できた
たとえばC#など.NET系のリファレンスはMSDNで読むことができる。
RubyだってHaskellだってScalaだって、公式サイトにガイドぐらい置いてある。
Oracle、DB2、MySQL、PostgreSQL、SQLite、AccessなどSQLが実装されたDBMSは様々にあるが、どれを取っても仕様が違う。
皆が標準SQLに従っていてその上で適当に増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。
根幹的に必要な機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。
これと上記１とのせいで、何かググった時に特定のDBMSでしか解決法にならないものが大量に出てくる。
最近のプログラミング言語は大抵、雑に書いたってコンパイラが適当に最適化してくれる。
同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。
SQLもオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。
そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、
より速い中間言語が生成されるようSQLをチューニングし直さなければならない。
これでは何をやっているのかわからない。
有名なサイトでは、初心者が必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、
なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。
しかもその文法、ググってもろくな解説が無かったり、特定のDBMSに依存してたりと使えないオチ。
上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。
エディタが単なるメモ帳でしかないようなDBMSも多いから、インデントの文字数さえ個々人に任される。
インデントは2文字か4文字か。SELECTで改行するかしないか。カンマは列の後ろか、前か。
いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。
つまり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。
何かの解決法をググるたびに違うスタイルだからどう書いていいのかわからない。
結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。
まずは【お前自身が機械翻訳に駆逐されろ】"iwatani"の翻訳した記事が上がっていた。
＜GoogleのAI翻訳ツールは独自の内部的言語を発明したようだ、そうとしか言えない不思議な現象が＞
Zero-Shot Learningは分岐のない翻訳などではない。これは正しくOne-shot Learningの延長線上にあり、
ワンショット学習すらしないで（この場合対応ペアでの事前学習をおこなわず）、新規ペアでの処理を行うっていうことだ。
この語は翻訳に限った話でもない。だからほとんどの訳がおかしい。むしろ機械翻訳の方がマシ（背景を理解していない翻訳者より機械翻訳の方がマシという皮肉な状況）。
（ちなみに実際に脳内でもOne-Shot Learningは繰り返し学習とは別パスなのではという示唆もある）
＜グーグルの翻訳AIが「独自の言語」を生み出したといえる根拠＞
http://wired.jp/2016/11/24/google-ai-language-create/
http://b.hatena.ne.jp/entry/wired.jp/2016/11/24/google-ai-language-create/
これらは古くから考えられてきた「基底となる」文法等を完備した「中間言語」などではない。
論文で触れられている「『Interlingua』な表現形式」は『semantic representations』とされていて、まさに多言語間で共通する「『意味表現』の表現空間」であり、
ツリー状に開かれてもいない。人が想像する構造化された言語などではない。
ただしその空間を共有していて、つまり共通の意味表現を持っていることは論文(arXiv:1611.04558)で実験的に証拠を提示されている。
今までも多対多の翻訳でネットワークを共有することでBLEUを向上できるという論文は出ていたが、今回のは、翻訳に関して言えば、十分普遍化した意味空間を内部的にもったネットワークに新規ペアをぶち込んでも能動的な転移学習すらせずにそれなりの結果が得られる、結果の向上だけでなく未知ペアを処理できるって事である。
そしてその効果は汎用性↑↑、そして最大のメリットはサンプルが少ない言語ペアもやりやすくなるぞ、マイナー言語にも早く適用できるかもって所だ。
One-shot Learning系（小サンプル）とDeep Learning系（巨大サンプル）によるネットワークについて、意味という（我々にも見えない）上位構造の下に配置された構造である「言語」を扱う特別な例では、両方を一つで達成できる可能性が垣間見えた論文なのでもある。
いわゆる頭の中が多動というやつで思考がいつもしっちゃかめっちゃかなのと、
力を抜くと思考がそのままダダ漏れになりそうになったり、早く喋りたくて口が開きかける衝動を必死で抑え込んで、
日本語として成立していない、自分のフィーリングと語感だけで構築された脳内の中間言語を最低限通じる日本語に直しつつ、
状況を見て出したりひっこめたりしながら喋らなければいけないので、日本語で会話するだけでかなり疲れる。
かなり疲れるのだけれど、医者からするとテンポはやや遅いが普通に会話ができているので、ADHDの診断はつくものの、会社員もできてるしイケるイケるって感じらしい。
診断を受ける15年ぐらい前に、中学の社会の授業中に不意に当てられて慌てて立ち上がりながら「アパラチア山脈」と言おうとして、
「アパッチのArmadilloはさんざっぱら白濁したAsparagusの茹で汁で脈絡なくRockYou」(英語部分はネイティブ風)とスラスラ答えて大恥をかいたことを契機に、
自分の異常性に気付いて自分なりに訓練し続けてきたおかげか、人前ではある程度抑え込めるだけマシな部類ではあるのだろうけれど、
表面上抑え込めたからといって普通の人に混じって生きるのが楽なわけでは決してなくてぐぬぬとなる。
歳を重ね、語彙が増えるほどに増している気がする中間言語の奔放さで脳内翻訳家の疲労は年々高まるばかりで、
心身の調子が良い日の方が、逆に思考の回転や衝動性が絶好調で、普通に会話するためのコントロールに苦心するという有様。
普通に喋るための抑圧感があまりに強かったので、先日居酒屋で友人に頼んで試しに中間言語をそのまま垂れ流した会話を少しさせてもらった際に、
どうせ私のクソ雑魚ナメクジなワーキングメモリでは覚えてなどいられないのでスマホで録音してみたが、あとから書きおこしてみたら思っていた以上に意味不明だった。
友人「おうおう、じゃあこっからってことで、はい乾杯おつかれー」
増田「ウィーンプラハ甲冑ぐるぐる モンティパラミッチャーげタンドリーナン(getout turn dreaming now かも) onceon the way」
友人「いやー、トランプさん勝っちゃったねー」
増田「Database バンシャディフォルモントゥ 放射ニカラグア絡まって左から北川 総研証券ドンタコスったらドンタコス」
増田「タンデムマンダム オーデュロイキャベツPrismProxyショートショートでガッテントゥルットゥ」
友人「そういや今度ポケモン出るやんか？」
増田「あんれまあビール さんさんさんさわやかスリザリン 僕らの肩にフリーズドライ 座布団どんぶりムートンブーツでムーンウォーク BoomBoomナチョス Ah」
友人「お前買う？」
増田「金平ごぼうで滅びた信玄Likeカーティス、マヌカハニーは無理筋かなメルシー？」
友人「前のもクリアしてないし俺は今のところ見送りかなあ、でもそのうち買ってしまいそうやけど」
付き合ってくれた友人からは、ところどころなんとなくわからなくもないが友好的な宇宙人って感じで怖い。とのお言葉をいただいた。
自分でも支離滅裂な言葉をスラスラと喋ってるのを聞くとコイツァヤベェやって思う。でも喋るのはとても楽だった。今から年をとってボケるのが怖い。
いちいち随分グニャグニャと喋ってるけど、声に出しているのは頭の中を流れて行ってる思考の中から関連の強そうなものを一応言語としてすくい上げたものだったり、
口を動かしてる間に飛んでいかなかった強い言葉の成分なので、実際の頭の中はもうちょっといろんなイメージが駆け回っている感じ。
普段はここから普通の日本語に変換して喋っているわけだけれど、多分こういったことを言おうとしていただろうという翻訳後はこんな感じになる。
友人「おうおう、じゃあこっからってことで、はい乾杯おつかれー」
増田「ウィーンプラハ甲冑ぐるぐる モンティパラミッチャーげタンドリーナン onceon the way」(うぇーい、どーもどーも、おつかれーい)
友人「いやー、トランプさん勝っちゃったねー」
増田「Database バンシャディフォルモントゥ 放射ニカラグア絡まって左から北川 総研証券ドンタコスったらドンタコス」(マジでなー、ヒラリーはホンマやらかしたな、えらいこっちゃで)
増田「タンデムマンダム オーデュロイキャベツPrismProxyショートショートでガッテントゥルットゥ」(そうなりそうやな、まあ俺にはどっちがいいのかわからないけど)
友人「そういや今度ポケモン出るやんか？」
増田「あんれまあビール さんさんさんさわやかスリザリン 僕らの肩にフリーズドライ 座布団どんぶりムートンブーツでムーンウォーク BoomBoomナチョス Ah」(あーあれ、サンとムーン？)
友人「お前買う？」
増田「金平ごぼうで滅びた信玄Likeカーティス、マヌカハニーは無理筋かなメルシー？」(今んとこビミョー、まあ買うとしたらムーンかな、お前は？)
友人「前のもクリアしてないし俺は今のところ見送りかなあ、でもそのうち買ってしまいそうやけど」
増田「晩酌よりかはキルフェボン、串刺し墓場酒場タタラ場板場ンティス？」(そういや前のもやってたな、ちなみに買うならどっちバージョンよ？)
軽度とされる人の中にはこんな感じの頭の中を抱えながら一般人のふりして暮らしているのもいるよということで。
世の中には同じようなことになっている人がきっといると思うので、そういう人に似た様なのがいるぞと届けばいいなと思う。
---
追記
友人がすごいという件についてちょっとだけ補足。
友人とは取り決めとして、恐らく会話にならないのでしばらく一方的に会話を投げかけてもらうということにしていた。
ただ、ポケモンのくだりあたりはこれまでの付き合いから、こちらの反応や返事の仕方をなんとなく予想ができたみたいで、見返すと割とちゃんとした会話めいたやり取りになってた感じ。
とはいえ「はうあーゆー」と言えば「うんたらかんたら えんでゅー？」とくるから、うんたらかんたらが聞き取れてなくても返すとか、そういう感じのやり取りであって明確に理解ができてるわけではない。
そもそも合間合間で友人は「わっかんねー」としこたま笑い転げていたし、合衆国大統領は時事ネタとしてとりあえず投げてみたけど思った以上に無理そうだったから諦めたとも言っていた。
なんとなくわかる部分については、話し方のトーンとかアクセントとかに加えて、普段から私の傾向として、何かが思い出せない時にかわりに出てくる言葉がかなり音に引っ張られたりするので、
付き合いが長いとその辺りからぼんやりと「なんかマ行多めに言ってるから多分ムーンなんやろなあ」「バって一杯言ってたし疑問形だし、バージョンかなあ」とかそういう感じに想像していたらしい。
今回の件とは関係ないけれど「ヤバイ」の派生だけで10分会話してみようという遊びをして割と不自由なく意思疎通できてしまったり、
「次にお前は○○と言うゲーム(予想がついたらハモる遊び)」で正解を連発してお互いに気持ち悪がったりしたこともあるので、理解度が割と高いのだと思う。
どちらにせよしょうもない実験にも付き合ってくれるし、双方が相手に干渉しすぎないのが分かっていて気楽にいられるので、大変貴重な友人であることには変わりない。
IntelコンパイラにしろVSにしろ有償のものは使いやすいけどね。会社に買わせるか経費で買うものだとは思う。
ただ、使ったことがない人は使うといいと思う。
Intelコンパイラ(VTuneなど含む) Visual Studio Perforceの３つは少なくともお金を出して使いたい。
モチベーションが高いといっても、お金を稼ぐことに対するモチベーションか、プログラムに対するモチベーションかで大きく変わると思う。
大抵は、お金か、名誉だろうから、それならWebプログラミングをやればいいと思う。
これからは、９割のプログラマーは何がしかの中間言語 JavascriptやPHPなどをやることになるだろ。それならツール群はいらん。
