Aaron の 7 つのプルリクエスト。ひとつがリークを見つけた

Aaron（@aarochu）は、2 日目の朝に 7 つのプルリクエスト（PR）を出しました。3 つは、100B トークンの学習の準備です。2 つは、記憶用の回路の中身を見られるようにします。2 つは、スウォームを試します。そのうちの 1 つが、すでに公開していた実験の欠陥を見つけました。7 つともマージしました。コミットは、彼が書いたままです。テストスイートのテストは 46 個になりました。

017 つのプルリクエストで加わったもの

02リーク

分割スウォームでは、4 つのエージェントが、ひと続きのテキストの連続する 4 つの窓を読みます（スウォームの記事を参照）。各エージェントは、自分の窓のすべての位置で次のバイトを予測します。この配置の 2 つの性質が組み合わさります。

• エージェント 1 が最後に予測するバイトは、エージェント 2 が最初に読むバイトです。エージェント 2 と 3 も、同じように継ぎ目を共有します。エージェント 3 と 4 も同じです。
• 64 バイトのチャンクごとに、各エージェントは読んだ内容の平均を掲示板に投稿します。どのエージェントも、それより前のチャンクの投稿を読めます。エージェント 2 の最初の投稿は、継ぎ目のバイトで始まるチャンクから計算されます。エージェント 1 は、最後のバイトを予測するときに、その投稿を読めます。

そのため、エージェント 1 から 3 は、原理的には予測対象を 1 つずつ掲示板から読み取れました。エージェントあたり、512 個の対象のうち 1 個です。エージェント 4 には継ぎ目がありません。対照は、掲示板に仲間がいない状態で学習しました。そのため、リークを使う手段がありませんでした。

03どれだけ変わるか

ハイブリッドでのスウォームの結果は、バイトあたりビット数で約 0.012 以上の改善として成り立ちます。公開した数値は、少し高すぎました。TONN だけのモデルでの結果は、見かけより弱いものです。

04修正

• ローダーは、分割スウォームで継ぎ目の予測対象を隠します（mask_seams）。そのため、仲間がすでに投稿したバイトで学習や採点をするエージェントはいません。
• experiments/swarm_text.py は、残した予測対象だけで平均を取るようになりました。これがないと、隠した対象が損失ゼロとして数えられます。その結果、すべての条件のスコアが約 0.002 下がってしまいます。
• リーク、隠した継ぎ目、修正した採点処理を、テストで確かめています。

05この記事が示していないこと

この記事は、訂正後の正確な数値を示していません。ハイブリッドのスウォーム実験（両方のシード）と、TONN だけのモデルの実験（これまでどおり 1 シード）は、修正を入れて再実行するためにキューに入っています。今夜 0.1B の実行が終わったあと、Mac で始まります。結果は次の記事で報告します。スウォームの記事からも、その記事にリンクします。

06次にやること

新しいツールのうち 3 つは、まだ実際に使われていません。どれも、最初に取り組む課題に向いています。

• 0.1B のプリセットで exealm.eval.speed を実行し、生成の数値を結果のページに加える。
• Wikipedia の知識タスクで show_retrieval.py を実行し、検索が外れたときに何を返しているかを見る。
• 候補のデータ配合に重複除去スクリプトをかけ、ソース間の重なりを報告する。

フォームから参加登録するか、プルリクエストを出してください。