#抽象化
-
RAG は上位を選び、attention は全部を混ぜる — 同じ検索の、硬い版と柔らかい版
RAG はベクトル DB に内積のクエリをかけて一致度の高い情報を拾う技術だと聞いて、attention の仕組みを 思い出した——という思いつきをぶつけた対話。 返ってきたのは「なんとなく似ている、というレベルではなく、両者の骨格が本当に同じところを突いている」 だった。共通の骨格には名前がある。content-based addressing（内容によるアドレス指定）。 普通のメモリが「番地」でアクセスするのに対し、「中身の近さ」でアクセスする、という同じパラダイム。 RAG のクエリ埋め込みが attention の Query、文書の埋め込みが Key、文書の本文が Value にあたる。 ただし決定的な違いがあった。attention は soft retrieval（softmax で全 Key に重みを配り、 Value の加重和をとる。連続的で微分可能だから、端から端まで勾配が流れて学習できる）。 RAG は hard retrieval（top-k を離散的に選ぶ。選ぶ／選ばないの二値で、その選択は微分不可能。 だから RAG のエンドツーエンド学習は難しい）。 そして一番きれいな見方は、この二つは競合ではなく積み重なっているというものだった。 RAG が「硬い事前フィルタ」で数百万文書から数個に絞り、そこで拾った文書をコンテキストに載せると、 今度は LLM 内部の attention が「柔らかい統合」でそのトークン群を加重参照する。 hard retrieval → soft retrieval の二段構え。粒度の違う同じ操作が、階層的にスタックされている。 最後に系譜の話が出てきて、この直感が歴史的にも正しい筋だと分かった。もともと Neural Turing Machine や Memory Networks が「attention ＝微分可能な外部メモリのアドレッシング」として定式化していて、 attention は最初から retrieval として生まれていた。RAG はそこで一度手放した明示的な外部メモリへの 回帰だった。つまり「RAG を見て attention を思い出す」のは、開発史を逆再生していることになる。
-
曲面は元の空間に既にある — 多様体仮説と、非線形変換が果たす役割
生成 AI の文脈で言われる多様体仮説について、精密に理解したかった。データが「高次元空間の中の特定の 平面上にある」という単純な話ではないはずだ。では、高次元空間を適切に変換して初めて得られる、 別の基底での多様体を指しているのか——という問いから始めた。 返ってきた最初の修正は、「別基底」という言い方への指摘だった。射影や基底変換という語は、通常 線形写像を指す。しかし線形写像は、回転・スケール・せん断はできても、曲がったものを平らに 伸ばすことはできない。もし線形変換だけで多様体を平らにできるなら、その時点でデータは線形部分空間上に あったことになり、最初に棄却した「平面」のケースに戻ってしまう。多様体仮説の本質は、線形変換では 平らにできない曲率を持つという点にあり、必要な座標変換は非線形だ。 そこで問いを立て直した。曲面は元の高次元空間の中に既に存在しているのか、それとも非線形変換・ 次元削減して初めて曲面が見えるようになるのか。どちらなのか。 答えは前者だった。多様体は元の空間の中に、曲面として既に存在している。地球の表面が3次元空間に 物理的に存在しているのと同じで、メルカトル図法は球面を読めるようにする操作であって、投影が球面を 作り出すわけではない。 ただし「初めて見えるようになる」という言い方も、別の水準では正しかった。切り分けるとこうなる—— 存在論としては元の空間に在る。可読性としては、変換して初めて低次元性を扱えるようになる。 そして局所的には、曲面は接平面（小さなパッチ）に見えるので、近傍内ではすでに低次元性が露出している。 非線形写像が要るのは、そのパッチをどう貼り合わせるかという大域的な展開のほうだった。
-
機械が積み上げてきた抽象化の層が、ついに人間社会の層に届いた
NAND から始まった機械のスタックが、加算器・CPU・高級言語と積み上がり、LLM が乗ったことで、 ついに人間の層の底面にまで到達した。人間の側もかつて個人の活動から組織・マネジメントへと積み上げてきたが、 その最下層は機械から見ればはるか上にあり、間のギャップは人間が翻訳して埋めるしかなかった。 そのギャップが埋まった。結果、人間社会のノウハウが機械側で次々と再発見されている （プロンプトエンジニアリング＝部下への指示、ハーネス設計＝仕事術、マルチエージェント＝チーム編成）。 返ってきたのは「その再発見はほぼトートロジーだ」という応答だった——LLM はマネジメントされた人間の 出力の圧縮物なのだから、人間の技法が効くのは当たり前だ、と。そして継ぎ目は綺麗な関節ではない。
-
同じ「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 とインタプリタは排他ではなかった。