#計算機
-
ファインチューニングから RAG、そして memory へ — 適応をどこに置くかが移ってきた
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 とインタプリタは排他ではなかった。