仕組み — コードを「知識」に変換する

BRK は Python のソースコードを構造知識に変換して圧縮するコンパイラです。2.0GB のソースを 4.75MB に圧縮しながら、API シグネチャの正確さを保っています。その仕組みを解説します。

何をしているか

このサイトは、AI にコードを書かせる際に 実在が検証済みの API シグネチャを一緒に渡しています。 AI が「存在しないメソッドを呼ぶ」「引数名を間違える」といった誤りは、 知識の欠落や記憶の曖昧さから起きます。正確な情報を手元に置けば、 その種の誤りは減らせます。

BRK フォーマット

BRK は、ソースコードを 5 種類の関係 （defines / contains / inherits / calls / imports）に分解し、 バイナリコンテナに格納します。実装本体・空白・コメントは保存しません。 保存するのは「何が存在し、どう繋がっているか」だけです。

4 つの圧縮機構

1. ファクトグラフ変換 —— コードを (主語, 述語, 目的語) の三つ組に分解します。 この時点で実装の中身は存在しません。
2. 知識ナップサック —— サイズ上限を「情報予算」として扱い、価値／バイト比の低い知識から 捨てます。ただし公開 API は保護され、予算が厳しくても残ります。
3. テンプレート畳み込み —— __repr__(self) のような同形シグネチャの大群を、 鋳型 1 個とメンバー ID リストに畳み込みます。
4. 多段バイナリ圧縮 —— 文字列インターン、varint／差分エンコード、セクションごとの 圧縮方式実測選択を組み合わせます。

実測値

公開 API を守る仕組み

圧縮率を上げるだけなら簡単です。全部捨てれば 0 バイトになります。 難しいのは「利用者が実際に知りたい API を残すこと」です。

当初は重要度スコア（PageRank）で残す API を選んでいましたが、 これは失敗でした。PageRank は「よく呼ばれるか」を測りますが、 公開 API のエンドポイントはライブラリ内部からはほとんど呼ばれません ——呼ぶのは外部の利用者だからです。結果、内部ヘルパーばかりが生き残り、 最も知りたい入口 API が消えていました。

現在は保護層方式を採っています。 「公開されており、docstring がある」ものは刈り取りの対象から外します。 これにより 91% を削減しても主要ライブラリの表 API は残ります。

限界

• 呼び出し解決は静的解析のベストエフォートです。動的ディスパッチや getattr 経由の呼び出しは追跡できません。
• BRK からソースコードは復元できません（一方向変換です）。
• 現在は Python のみ対応しています。
• コードを生成するのは AI であり、BRK ではありません。BRK は 検索と知識提供を担当します。