BoB はどう作られているか

たいていの AI ツールは、モデルを製品そのものとして扱い、その周囲のコードを接着剤とみなす。BoB はこれを逆転させる。モデルは CPU のように交換可能な部品にすぎない。BoB を信頼でき、生産的で、そしてあなた自身のものたらしめているのは、モデルを取り巻く ハーネス である。本稿はそのハーネスを手短に案内するものだ。

4 つのサービス

BoB は協調して働く 4 つの部品からなる。

core が全体を取り仕切る。作業をルーティングし、モデルのフリートに分散して実行し、結果を検証し、そのすべてを永続的な記録として残す。
gateway は入り口。ログイン、会話、プロジェクト、承認を備えた Web および API のレイヤーだ。
pipeline はプランニング層のための薄いラッパー。
app はデスクトップクライアント。チャット、ルーティングビュー、チームビルダーを備えた、日常使いの本命だ。

本質的な処理はすべて core の内部で起こる。リクエストが流れていくコンパイル済みのグラフとして。

フリート

BoB は 1 つのモデルに頼らない。作業はベンダーではなく ロール として表現される。

タスクを計画し分解する apex、
実際の労働をこなす workers、
その成果を敵対的に検査する critics。

各ロールはルーティング層を通じて具体的なモデルへと解決される。そのため同じタスクを、1 体の安価なワーカーとして走らせることも、数十体へのファンアウトとして走らせることも、熟議するカウンシルとして走らせることも、コードではなく設定によって切り替えられる。ここで意図的に敷かれているルールが クロスファミリーの脱相関 だ。critic は必ず、自らが監査する worker とは別のモデルファミリーから選ばれる。こうして、あるモデルが自分と同種の誤りを追認してしまうことがない。

検証の背骨

ここが、安価なモデルを信頼できるモデルへと変える部分である。ある結果を通す前に、BoB はそれを検査する。

事後条件チェック は、脱相関された critic に対し、主張された結果が実際に成立しているかを問う。
主張含意ゲート は、定量的な主張があればその引用元を改めて開き直し、この出典は本当にこの数値を裏づけているのかと問う。
デフォルト不合格での終了 は、あらゆる完了基準を最初は未検証として扱い、各基準が検証されるか、あるいは正直に不明と記されたときにのみ作業が出荷されることを意味する。

「完了」は BoB が前提とするものではなく、勝ち取るものである。

3 つのレーン

同じ背骨が、3 種類の作業を駆動する。

build レーン は契約に沿ってコードを書き、それを信頼する前に隔離されたサンドボックス内で実行する。
research レーン は、実際に読み直した出典をもって問いに答える。
computer-use レーン は実際のソフトウェアを操作し、画面が意図したとおりに変化したかを確認する。

メモリと基盤

BoB は、生きたローカルの知識ベースの上に築かれる。知識は一度コンパイルされ、その後も最新に保たれる。だから BoB は、セッションごとにゼロから始めるのではなく、時間とともにあなたの仕事について鋭くなっていく。その下では、追記専用の台帳が記録の正本となる。BoB は、モデルのコンテキストウィンドウにたまたま残っているものを信用するのではなく、その台帳を切り出すことでコンテキストを再構成する。

設計としての主権

ロジックの中でどのモデルも名指しされず、フォールバックチェーンを持つケイパビリティクラスだけが記述されているため、単一のベンダーが屋台骨を担うことはない。あるモデルが禁止されても、鍵を失っても、価格が急騰しても、そのクラスは次のプロバイダーへと再解決される。望むならローカル推論にまで下りていく。これこそが、輸出禁止措置を生き延びる性質だ。ハーネスはあなたが所有する。知能のほうは、その週に最も安く手に入るところから借りればよい。

詳しい解説は、技術ホワイトペーパーを参照のこと。