今日はハーネスエンジニアリングに関する長文を読みました。数万語に及ぶ、ほぼ間違いなくAIが書いたものです。最初の反応は「わあ、なんて強力なコンセプトなんだ」というものではありませんでした。「この人たちは古い言葉に新しい言葉を作る以外に何かアイデアを持っているのか?」というものでした。 私はAIの世界におけるこのパターン、つまり既存の概念が絶えず再発明されることにずっと苛立ってきました。プロンプトエンジニアリングからコンテキストエンジニアリング、そして今はハーネスエンジニアリングへと進みます。数ヶ月ごとに誰かが新しい用語を作り、1万語のエッセイを書き、大手企業のケーススタディをいくつか取り入れ、コミュニティ全体が盛り上がります。しかし実際に内容を見ると、毎回同じことがわかります。 モデルが動作する環境を設計しましょう — どんな情報を受け取り、どんなツールを使えるか、エラーの捕捉方法、セッション間でのメモリ管理の仕組みなど。これはChatGPTが立ち上げられた日から存在しています。誰かが何らかの理由で新しい名前を付けたからといって、新しい分野になるわけではありません。 とはいえ、不満はさておき、記事で引用されている研究やケーススタディには価値があります。特に、私がhow-to-sglangで構築してきた内容と大きく重なる点が大きいからです。だから、これを機会に私が実際に犯した間違いについて話したいと思います。 まずは背景を説明します。SGLangコミュニティで最もよく聞かれる質問は「ハウツークエスチョン」です。8GPUでDeepSeek-V3をどう展開するか、ゲートウェイがワーカーアドレスにアクセスできない場合の対応、GLM-5 INT4と公式FP8間のギャップが大きいかどうかなどです。これらの質問は非常に広範な技術層に及び、コミュニティがどんどん成長するにつれて、返信に追いつけなくなるほどです。そこで、自動的に応答できるマルチエージェントシステムを作り始めました。 最初のアイデアはもちろん最も素朴なものでした――全知全能のエージェントを一人作り、SGLangのドキュメントやコード、料理本をすべて詰め込み、すべてに答えさせるというものでした。 それはうまくいかなかった。 なぜそうなのかを説明するのにハーネス工学理論は必要ありません。コンテキストウィンドウはRAMではありません。詰め込めば詰め込むほど、モデルの注意が散り散りになり、答えはどんどん悪くなります。エージェントが量子化、PD分解、拡散サービング、ハードウェア互換性を同時に理解しようとすると、どれも深く理解できません。 最終的に決定した設計は、多層的なサブドメインエキスパートアーキテクチャです。SGLangのドキュメントにはすでに自然な機能の境界があり、高度な機能、プラットフォーム、サポートモデルなど、モデルごとに整理された料理本があります。各サブドメインを独立したエキスパートエージェントにし、エキスパートディベーティングマネージャーが質問を受け取り、サブクエスチョンに分解し、エキスパートルーティングテーブルを参照して適切なエージェントを起動し、並列で解決し、回答を統合する役割を担いました。 振り返ってみると、この設計はハーネスエンジニアリングコミュニティが推奨するパターンにほぼ完璧に一致しています。でも作っていた時は、これらのパターンに名前があるとは全く知りませんでした。そして、私はそれをする必要もなかった。 1. プログレッシブ・ディスクロージャー — すべての書類を特定のエージェントに押し付けることはありません。各ドメインエキスパートは自分のドメイン知識のみを読み込み、マネージャーは質問タイプに基づいて誰を起動するかを決定します。私の直感では、この設計はより強力なモデルに交換したよりもはるかに多くの改善をもたらしたと思います。この決定を下すのに「プログレッシブ・ディスクロージャー」と呼ばれるものだと知る必要はありません。一度「全部詰め込む」方法を試して失敗するのを見ればいいのです。 2. リポジトリを真実のソースとして — ワークフロー全体がハウツースグラングリポジトリに保存されています。すべての専門エージェントはリポジトリ内のマークダウンファイルから知識を引き出し、外部文書や口頭の合意に依存しません。初期の頃、すべてを網羅した大規模な sglang-maintain.md を書きたいという衝動がありました。しかし、それがうまくいかないとすぐに分かりました。OpenAIのCodexチームも同じミスを犯しました。巨大な AGENTS.md を一つだけ試みた結果、予測可能な形で腐っていくのを見守ってしまったのです。この地雷を自分で踏みつけるのに、彼らのブログを読んでいなくても十分です。これは「モノリシックなドキュメントは必ず古くなる」という古典的なソフトウェア工学の問題ですが、エージェントの文脈ではその結果はさらに悪化します。古くなったドキュメントは単に読まれないだけでなく、エージェントを誤導します。 3. 構造化ルーティング — エキスパートルーティングテーブルは、問題タイプをエージェントに明示的に割り当てます。GLM-5 INT4に関する質問は、クックブックドメインエキスピクトとクオンタイゼーションドメインエキスピクトの両方を同時に起動させます。マネージャーは推測しない;構造化されたインデックスに従っています。ハーネス工学の人々はこれを「機械化された制約」と呼んでいます。私はこれを通常の工学と呼んでいます。 ハーネス工学の考え方が悪いと言っているわけではありません。引用された研究は堅実で、SWE-agentのACI概念は本当に知っておく価値があり、Anthropicのデュアルエージェントアーキテクチャ(初期化エージェント+コーディングエージェント)は長期的な作業を行う人にとって貴重な参考資料です。私がうんざりするのは、新しい用語が絶えず生まれることです。確立された工学の常識を新しい分野としてパッケージ化し、「この言葉を知らないと遅れている」という不安を作り出すのです。 プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング――これらは同じものの異なる側面です。来月、誰かがスキャフォールドエンジニアリングやオーケストレーションエンジニアリングを新たに出し、同じSWEエージェント論文を引用する長いエッセイを書き、コミュニティは新たな増幅のサイクルを始めるでしょう。 実際に「sglangの使い方」から学んだことは、新しい語彙なしでも述べられます: エージェントに提供される情報は最小限で正確なものであって、最大限にすべきではありません。複雑なシステムは、全知的なエージェントとして構築されるのではなく、専門的なサブモジュールに分割されるべきです。すべての知識はリポジトリに存在しなければならず、口頭での合意は存在しません。ルーティングや制約は構造的なものでなければならず、エージェントの判断に委ねてはいけません。フィードバックループはできるだけ厳密にすべきです。現在はすべてのクエリの推論チェーンをログシステムで記録しており、LLMを裁判官として検証するためにCodexも使い始めていますが、まだ理想的とは言えません。 これらはすべて新しいことではありません。従来のソフトウェア工学では、これらは関心の分離、単一責任原則、ドキュメント・アズ・コード、シフトレフト制約と呼ばれます。今はLLMの職場環境に適用しているだけで、新しい名前にする価値があると感じる人もいます。 この分野であとどれだけ新しい用語が生まれるのかはわかりません。しかし、少なくとも今日では、より強力なモデルを入れ替えることで「How to sglang(スグラングの使い方)」の質的な飛躍を達成したことは一度もないと確信しています。実際に画期的な進展を生んだのは、環境レベルの改善でした。より正確な知識分割、より良いルーティングロジック、より緊密なフィードバックループです。ハーネスエンジニアリング、コンテキストエンジニアリング、あるいは何でもないと呼んでも、それは良いエンジニアリングの実践です。それ以上でもそれ以下でもない。 ただ一つ、私が本当に理解できていない疑問があります。もしモデルの能力が指数関数的に拡大し続けるなら、いつかモデルが自分で環境を構築できるほど強くなる日が来るのでしょうか?OpenClawを観察したとき、まさに同じ混乱を覚えました。1か月で40万回線から100万回線に増え、完全にAI自身によって動かされたのです。そのプロジェクトの環境を作ったのは誰ですか?人間か、それともAIか?もしAIが原因なら、今日議論している設計原則のうち、2年後にはどれだけのものが完全に無意味になるでしょうか? わからない。しかし少なくとも今日、私が観察できるすべての実際の実践において、これは依然として人間の仕事であり、最も価値のある仕事です。

最近、強化学習に携わる多くの人と話をしていますが、興味深いことに気づきました。会話が強化学習インフラに向かうとき、ほとんどの場合一つの話題に引き寄せられます:トレイン推論アライメントです。トレーニングと推論方針を一貫性に保つ方法。非政策の程度をどう管理するか。非同期導入後の対数確率差の扱い方。これらはすべて重要な問いであることは間違いありません。しかし、私はますます、RL Infraが注意の大きな誤配分に苦しんでいると確信しています。最近の同僚との議論から借りると、私はこれを「強化学習インフラのバレル効果」と呼んでいます。 樽は最も短い棒と同じ量しか入れません。強化学習(RL)トレーニングシステムのスループットや正確性も同じように機能します。最適化したモジュールではなく、最も怠ったモジュールによって決まります。トレイン推論のアライメントは、あなたが完璧に研磨・磨き上げた板材のことです。しかし、もしサンドボックスの安定性が破滅的で、報酬パイプラインが常に停止し、エンドツーエンドの観測性がほぼ存在しないなら、完璧なアライメントに何の役に立つでしょうか?システムの容量はすでに他の弱点すべてによって制限されています。 これは推論システムの最適化とは根本的に異なります。推論エンジンとして、SGLangは最適化のための膨大な戦略空間を持っていますが、そのパイプラインは比較的直線的です — プロセス要求、プリフィル、デコードです。モジュールごとにボトルネックを分離でき、コンポーネント間の結合も管理可能です。強化学習トレーニングはまったく別の領域です。悪夢のように複雑なマルチシステムループです。ロールアウト生成は推論エンジンに依存し、報酬計算は外部環境に依存し、ポリシー更新はトレーニングフレームワークに依存し、次の展開は更新されたポリシーに依存します。1本のリンクが切れると、ループ全体が崩壊します。 残念ながら、過去1年で見てきた限りでは、依然として過小評価されている弱点が多数存在します。 エージェント・サンドボックスの信頼性。これはおそらく、現在の現実インフラで最も汚れていて、最も過酷で、学術的に最も華やかでない仕事です。エージェントベースの強化学習には、ロールアウトのための信頼できる実行サンドボックスが必要です。シンプルに聞こえますが、実は悪夢のようなものです。コンテナの安定性、コールドスタートの遅延、リソース分離の信頼性、サンドボックス状態管理など、これらは紙面上は切り離されているように見えますが、市場に出ているサンドボックス製品は一貫して期待を下回るパフォーマンスを発揮しています。エージェントサンドボックスはアルゴリズムの問題ではありませんが、データ生成効率を直接決定し、それがトレーニング速度を決定します。 観察可能性。事前学習のデバッグは比較的シンプルで、損失曲線を観察し、勾配ノルムを確認するだけで、問題の原因を特定できることが多いです。しかし、強化学習のデバッグにはエンドツーエンドのトレース機能が必要です。ロールアウト品質分布、報酬統計、オフポリシー度、ポリシー更新の大きさ、さらにはlogprob差の帰属(差は推論側からのものか、非同期トレーニングのバージョン遅延によるものか?)までです。残念ながら、私が出会ったほとんどのチームはこれらの次元でほぼ手探りで動いています。これにより、トレーニング結果が悪いとどのモジュールを責めるべきか分からなくなるという厄介な状況が生じます。 スケールのジレンマ。多くの強化学習インフラ最適化は、十分なスケールでしか測定可能な影響を示しません。小規模な実験では意味のある違いが見つからないことが多いのです。最適化が無意味だからではなく、ノイズが高すぎてステップ数が少ないため信号が表れにくいのです。しかし、大規模な実験は非常に高額です。これが悪循環を生み出します。小規模で最適化が効果的であることを証明できず、大規模な実験のための資源を確保することもできません。大規模な検証がなければ、最適化は「理論上は役立つはず」という段階で永遠に止まってしまいます。 業界のRL Infraへの投資は、その実際の複雑さと大きく不釣り合いです。ほとんどのチームはこれをインフラの事前訓練に加えて補修作業として扱っています。既製のトレーニングフレームワークを用意し、推論エンジンを取り付け、スクリプトでそれらをつなぎ合わせて、それを強化インフラと呼びます。しかし、強化学習トレーニングと事前トレーニングのシステムの複雑さは同じレベルには及びません。事前学習パイプラインは線形で均質、外部依存関係がほとんどありません。強化学習のトレーニングパイプラインは周期的で異種的で、外部環境に大きく依存しています。前者の建築的思考を後者に適用すると、規模が大きくなると必ず壁にぶつかる。 システム工学の本当の難しさは、特定のモジュールを極限まで押し上げることではなく、モジュール間の結合とグローバルなトレードオフ空間を理解することにあります。これは推論システムに当てはまり、特に結合次元が大きく、フィードバックループが長く、デバッグ情報密度がはるかに低い強化インフラ(RL Infra)において顕著です。 最後に、ずっと考えている2つの質問で締めくくりたいと思います。この分野で活動している方々の意見をぜひ聞きたいです。 列車推論アライメントの限界リターンは正確にどこから減少し始めるのでしょうか?非同期が導入されると、オフポリシーの度合いはすでにかなりのものになります。その基準点で、さらなるアライメントによる増分的な利益は、サンドボックスの安定性、報酬パイプラインの最適化、または観測可能性インフラに同じエンジニアリング労力を投資するよりも、実際に高いROIになるのでしょうか?私には暫定的な答えがありますが、この問いはもっと多くの人が真剣に考えるべきだと思います。単に最も目立つ話題だからといって、最優先事項として「アライメント」をデフォルトにするのではなく。そして、それが最も目立つのには理由があります。トレイン推論アライメントは数学的に明確に形式化され、優雅なアブレーションを生み出すため、論文に自然に適合しているのです。しかし、サンドボックスの安定性について論文を書くにはどうすればよいのでしょうか?コンテナオーケストレーションの信頼性を学術的な物語としてどのように捉えていますか?本当に無理だ。だからこそ、これらの問題は集団的に無視されてしまうのです。たとえRL Infraシステムがビットレベルのトレイン推論アライメントを実現しても、ボトルネックがずっと前に別の場所に移ったため、全体的な効率は依然として低迷することがあります。 強化学習インフラはどの程度標準化できるのでしょうか?推論システムは比較的明確なベンチマーク指標(TTFT、TBT、スループット)を持っています。これらの客観的な指標により、最適化の影響を明確に評価できます。では、強化学習インフラの評価基準は何でしょうか?トレーニングスループット?サンプル効率?端から端までの壁時計の時間?最適なアーキテクチャはシナリオによって大きく異なる場合があります(コード生成、エージェント、推論)。「良い強化学習インフラ」が何かについて合意がなければ、この分野の工学的知識を蓄積し再利用するのは非常に困難になるでしょう。 強化学習がモデル能力向上の重要な道かどうかは、その判断はまだ進化途中です。しかし、もし答えがイエスなら、インフラはその道の中で最も過小評価されているボトルネックです。誰も取り組んでいないからではなく、集合的な注意が誤った配分されているからです。バレル効果の残酷さはこれです:どんなに高いステープでも、システム自体を救えません。 現実学習インフラは二次的な問題ではありません。これは独立した高複雑度システム工学の領域です。それを一級市民として扱うことで初めて、現実学習をスケールさせるチャンスは生まれます。

ヒューストンの配管エンジニアは、コーディング経験ゼロで生産ソフトウェアを8週間で出荷できますが、多くのYCスタートアップではエンジニア5人で12週間で出荷できません。違いは、彼が業界が何を必要としているかを20年間正確に知り、建築の議論に時間を無駄にしないことです。これが垂直型ソフトウェアの未来です。ドメインの専門家が開発し、推論APIで駆動され、週末に作った職人に年収5万ドルを請求する汎用的なSaaS企業にとっては、まさに恐ろしいもの@toddsaunders