３年程前に、初めてLLMのファインチューニングをやってみた。
当時は「知識をモデルに埋め込む」という発想だったが、実際にやると、
- データ集めをする
- データの整形をする
- 学習をする
- 大きなGPUが必要
- 電気代もかかる
- モデルが変わるたびにやり直す
という世界だから、
資本力と人数の勝負だな
という感覚だった。
塾の建設、金策、設備の調達などで忙しくてしばらく放置していたが、1年ほど経って、ベクターデータベースを動かして、RAGをやってみた。
RAGは、「学習させずに検索すればいい」という発想だった。
ところがベクトル検索だけだと、
- 似ているけど違う話
- キーワードだけ近い話
- 一部だけ一致した話
- 無駄な情報がたくさん
が大量に返ってくる。
その頃から、多くの自治体や企業で、AIコンサルタントみたいな業者が組織の文書を読ませるRAGシステムの構築を試みてほとんどが失敗したようだ。
失敗するだろうなと思っていた。
LLMの勉強を始めた頃、Transformerが話題になったので少し調べてみた。自分で小さなLLMを作ってみた。
「真実を知っているわけではなく、次に来そうなトークンを選んでいるだけ」。
今でもその性質は変わらない。
Transformerの仕組み、ファインチューニングの問題、RAGの問題が身にしみて、少なくとも小さな設備で動かすなら、LLM中心の考えは捨てるべきだと思った。
ScaffoldとHarness
最近は、ScaffoldやHarnessという言葉を見る機会が増えた。
Scaffoldは、モデルが仕事を進めるために与えられる足場のこと。
- システムプロンプト
- 作業手順
- リポジトリ構造
- AGENTS.mdや設計資料
- 使用可能なツール
- 出力形式
- 検証や再試行のパターン
- 役割分担された複数エージェント
などの仕事の組み立て方。
Harnessは、モデルを動かす外側の実行機構のこと。
- モデル呼び出し
- エージェントループ
- Tool callの実行
- ファイルやシェルへのアクセス
- サンドボックス
- コンテクストの選択と圧縮
- 状態や記憶の保持
- 権限管理
- タイムアウト、再試行、中断
- 検証、評価、監査ログ
など。
OpenAIもCodexのharnessを、エージェントを動かすループとロジックとして説明しているし、Anthropicも、長時間の開発作業ではモデル性能だけでなくharness設計が重要だとしている。
ただし、実際の会話では両者が混同されていることが多い。
ScaffoldやHarnessの話が出てくると、
「まあ、そうなるだろうな」
と思う。
ZIKUUの現在地
ScaffoldやHarnessという言葉を見るようになる前から、ZIKUUで作ってきたものは、Scaffold/Harness側に向かっていた。
- CPS：原文と文脈束を作る
- Pivot：意味やFactを構造化する
- Repository Explorer：コードと設計の所在を調べる
- Nerve：出来事と処理をつなぐ
- Inference Broker：モデルや計算資源を抽象化する
- Inference Runtime Agent: 計算資源を管理する
- PRE：情報空間を観測する
- ZIKUU Vocabulary：判断の基準や共同体の概念を与える
- AI塾長：それらを使って応答する主体になる
個々はAIモデルではない。しかし、まとめて見ると、AI塾長を動かすための100万行を超える巨大なHarnessになっている。
さらにZDL（内部資料集）やリポジトリの構造、API-first、テスト、設計文書、作業規則などはScaffoldに相当する。
「まあ、そうなるだろうな」と思っていたから「当然、こうなった」。
モデル中心から環境中心へ
最近、ScaffoldやHarnessという言葉が増えた理由は単純で、モデル単体の比較だけでは、実際の仕事の性能を説明できなくなったから。
モデルの性能は一つの指標であるけれど、それだけでは性能を説明できない。
優秀な職人を連れてきても、
- 図面がない
- 道具がない
- 材料の場所が分からない
- 測定器がない
- 前工程の記録がない
- 完成条件が不明
なら、まともな仕事はできない。
逆に、仕事場、治具、工程、測定、記録が整っていれば、職人の能力をかなり安定して引き出せる。
Harness Engineeringは、AI版の工程設計、治具設計、工場設計に近い。
モデルを賢くするというよりは、賢さを仕事として成立させる周辺構造を作る話になっている。
本質的にはモデルを中心に考える時代から、システム全体を中心に考える時代へ移ったということだろうと思う。
ZIKUUでは、これらの言葉が出てくるようになる前から、その方向で設計していた。
例えば、ここまで開発してきたものを見ても、
- Nerveはイベントを運ぶ。
- CPSは文脈を作る。
- Pivotは意味を構造化する。
- Brokerは推論資源を抽象化する。
- Repository Explorerはコードや設計への入口になる。
これらは全部、「LLMを賢くする」のではなく、「LLMが仕事をできる環境を作る」ための部品だ。
だから最近の論文やフレームワークが「Harnessが重要です」と言い始めても、
「まあ、そうなるよね。」
という反応になる。
その一歩先
ZIKUUの設計思想はもう一歩先まで踏み込んでいる。
一般的なHarnessは、「エージェントを効率よく動かす」ことが目的だが、ZIKUUではそれだけではなく、
- 原文を残す
- 文脈束を残す
- Factを残す
- イベントを残す
- 推論の材料を残す
という、「思考の材料そのものを育てる基盤」になっている。
つまり、Harnessが一回限りの実行環境ではなく、知識が循環して成長するインフラになっている。
私は流行に飛びつかない性格だから、モデルの性能競争やScaffoldやHarnessという言葉にも飛びつかない。原理原則から離れずに、淡々と「こうあるべき」「こっちの方がいい」と思うことをやり続けている。
その先
膨大な費用が必要なモデル開発。
これはこれで今後も進むだろうと思う。
恩恵は確実にある。
でも、AI利用者が増えてくると様相が変わる。
推論専用チップが登場する、推論だけを考えてシステムを組む。
そういうことが増えるだろう。
これまで取り組んできたような「モデルに知性を押し込む」のではなく、「周辺構造に知性を配置する」という設計思想が生きてくると思っている。
LLMは置き換え可能な部品でしかない。
すでにZIKUUのシステムはそうなっている。
ZIKUUは、モデル依存のロジックをできるだけ外へ追い出している。
例えば、
- Collectorがデータを集める。
- CPSが文脈束を作る。
- Pivotが意味を整理する。
- Nerveがイベントを流す。
- Inference Brokerがモデルを抽象化する。
ここまでで、「AIに考えさせる前の仕事」のかなりの部分が終わっている。
するとLLMは、
- 文脈を読む
- 推論する
- 文章を生成する
という、本来得意な部分だけを担当する。
LLMが変わってもシステムへの影響は軽微だし、LLMの性能が向上すれば、それを置き換えるだけで、素直にシステムの性能は向上するはずだと思っている。
法隆寺宮大工だった故西岡常一氏は、「木を組むとは、人を組むことだ」と言った。
木にも人にも個性がある。
それをうまく組み合わせるのが棟梁の仕事だという。
ソフトウェアの世界で言えば、棟梁はアーキテクトだ。
私なんぞは、西岡氏の足元にも及ばない未熟者だが、考え方は参考にしたいと考えている。
これが私流の伝承。
これからも精進を続けていこうと思う。
「ScaffoldとかHarnessとか、話題になっているけど「まあ、そうなるだろうな」と思っていた」への1件のフィードバック