#計算機
-
AI の「調教」の歴史は、適応をどこに格納するかの移動だった — θ か、x か
AI を自分好みの出力に近づける操作——ここでは「調教」と呼ぶ——の手法が、時代とともに変わってきた。 昔はファインチューニング一択だった。一時期はベクトル DB や RAG の話が出ていた。最近はベクトル DB すら 使わず、memory のような仕組みが登場している。**この変遷の歴史を整理してほしい**、という対話。 返ってきた定式化が、この対話の核心だった。**モデル f_θ(x) に対して、できることは 「θ（重み）をいじるか、x（入力＝文脈）をいじるか」の二択しかない**。だから歴史の変遷は、 **適応をどこに格納するかの重心が、θ 側から x 側へ移動してきた過程**として読める。 ファインチューニング期（θ を直接書き換える。永続的だがコストが高く、忘却のリスクもある）。 LoRA などの PEFT（「適応に必要な重み更新は低ランク部分空間に収まる」という経験則）。 そこからプロンプト／few-shot（θ を一切触らず、forward pass の中で一時的に適応させる）。 RAG／ベクトル DB（**知識を θ から剥がして外部ストアに置く**）。 そして memory 期——**なぜベクトル DB すら消えたのか**。 答えは規模だった。個人のパーソナライズで扱う「記憶」は、文書数百万件のコーパスではなく、 せいぜい数百件のファクト。**この規模では近似最近傍探索のうまみがない**。コンテキストが広いので、 関連する記憶を丸ごと文脈に入れてしまえる。memory の新しさは技術というより、 **抽出→格納→再注入のループを自動化した**点にあった。 そして最後に、きれいな比喩に着地する。**θ ＝ ディスク（永続・グローバル・書き換え高コスト）、 コンテキストウィンドウ ＝ RAM（揮発・ローカル・即時）、RAG／memory ＝ その間のキャッシュ層**。 歴史の変遷は、**能力が上がるにつれて「ディスクに焼く」必要が減り、上位の速い層で調教が完結する ようになっていった流れ**として読める。
-
同じ「VM」という名前の、別の概念 — 抽象化の階層はどこに挟まるのか
Java のバイトコードを動かす「VM」と、ハイパーバイザーの上に乗る「VM（仮想マシン）」は、 同じ概念なのか、それとも名前が似ているだけの別物なのか——という素朴な問いから始めた対話。 答えは「名前が似ているだけの別物。ただし、どちらも『抽象化レイヤー』という共通の思想から来ている」 だった。そこから、Java・C・Python の変換経路を一つずつ対比していくことになる。 Java は「Write Once, Run Anywhere」のために、自由に書ける高級言語と、CPU ごとに違うアセンブリの間に、 「高級言語ほど高級ではないが、CPU の仕様まで踏み込む必要がない」中間の層を挟んだ。それがバイトコード。 C は中間層を持たず、コンパイル時に機械語まで落とす。つまり**アーキテクチャの差を、Java は実行時に JVM が吸収し、C はコンパイル時に gcc が吸収する**。 この対比から、いくつかの理解が芋づる式に繋がった。Java が C より逆コンパイルしやすいのは、 バイトコードが元のソースの構造を保っているから。gcc は「動くマシン」と「生成する機械語のターゲット」を 分離できる（クロスコンパイル）。そして最後に、思い込みが一つ壊れた—— **Java は最初から JIT で全部コンパイルするわけではなく、まずインタプリタで実行し、 よく使われる部分だけを JIT でコンパイルする**。JIT とインタプリタは排他ではなかった。