デコーダオンリーの合理性は、生成への特化ではなく、どんな作業も続きを書く形にできることにある

GPTは文章生成に特化しているから、デコーダだけの構成に合理性がある。この説明は、結論は正しく、理由が半分ずれています。特化しているから合理的、という言い回しは、事業計画書でもモデルの解説でも、それ以上考えなくて済む便利な締めとして使われますが、特化した専門家がなぜ翻訳も分類も引き受けているのかを説明できないからです。この記事では、デコーダオンリーの合理性は生成への特化ではなく、どんな作業も続きを書く形に言い換えられ、一つの構造を大きくすることに集中できた点にある、という見方を示します。

三つの型と、GPTの位置

Transformerから派生したモデルは、三つの型に分けられます。

• エンコーダ・デコーダ型: 元のTransformerの形で、翻訳のために設計された。エンコーダが入力文を内部の表現に変え、デコーダがそれを参照しながら出力文を作る
• エンコーダだけの型: BERTが代表。文の理解や分類を得意とする
• デコーダだけの型: GPTが典型。それまでのトークンだけを見て、次のトークンを一つずつ予測する

GPTは大量のテキストで事前学習され、多様な文脈や知識を内部に蓄えています。

生成に特化、という説明は半分しか当たっていません

エンコーダがなくても困らない理由として、まず挙がるのは作業の性質です。プロンプトも続けて生成される文章も、同じ一続きのテキストとして扱えるので、入力を別の表現に変えて保持する部品は必須ではありません。入力の理解は、デコーダの自己注意がそれまでの全トークンの関係を計算することで引き受けています。

ここまでは正しいのですが、これだけなら、デコーダだけの型は生成という一つの仕事の専門家にとどまるはずです。ところが実際のGPTは、翻訳も要約も分類もこなします。特化という言葉では、この広さが説明できません。

どの作業も、続きを書く形に言い換えられます

説明の残り半分は、作業の言い換えにあります。

• 翻訳: 「英語: The meeting was postponed. 日本語:」と書けば、続きとして訳文が来る
• 要約: 長い文章の後に「要するに:」と書けば、続きとして要約が来る。GPT-2の研究では、記事の後に要約を促す短い合図を付けるだけで、要約らしい文章が出ることが示された
• 分類: 「この口コミは肯定か否定か。答え:」と書けば、続きとして分類の答えが来る

翻訳も要約も分類も、続きを書くという一つの仕事に言い換えられます。だから一つの構造で済み、その構造を大きくすることに資源を集中できました。同じ構造のまま、データとモデルの規模を大きくするほど性能が伸びるという性質が、GPTの発展を支えてきました。事前学習の知識は、追加の学習でさまざまな作業に転用もできます。

エンコーダ・デコーダ型が今も合う場面

入力を読む部分と出力を作る部分が分かれている型は、翻訳や要約のように入力と出力の形がはっきり違う作業に、設計として素直に合います。翻訳だけを大量に、安定した品質で行う専用の仕組みなら、この型を選ぶ理由は今もあります。検索用の埋め込みや分類だけが目的なら、エンコーダだけの小さなモデルのほうが軽く済むこともあります。

何でも続きを書く形に言い換えられることは、何でも最も上手にこなせることを意味しません。一つの作業を大量に、決まった形で繰り返すなら、その作業専用の型のほうが速く安い場合があります。デコーダオンリーの合理性が最も効くのは、作業の種類が多く、毎回違う指示を出したい場面です。

仕事を書き出しに言い換えるのは、使う側の仕事です

デコーダオンリーのモデルにとって、プロンプトはこれから書かれる文章の書き出しです。作業の言い換えは、モデルの中で自動的に起きるのではありません。翻訳なのか要約なのか分類なのかが分かる書き出しを、使う側が書いて初めて起きます。

うちの業務は特殊だからAIには無理、という判断の多くは、その業務を続きを書く形に言い換える前に下されています。言い換えに必要な、何を入力とし、何を出力とし、何が書かれていれば合格かが、まだ言葉になっていないからです。処方は、その三つを書き出してから判断することです。書き出してなお言い換えられない業務なら、そこで初めて、AIに向かない仕事だと言えます。

あなたの業務の中で、AIには無理だと思っている仕事を一つ選ぶと、その入力と出力と合格の条件を、一文ずつ書けるでしょうか。書けたとき、それは続きを書く形にならないでしょうか。

この記事の背景にある考え方は、拙著『ChatGPT はじめてのプロンプトエンジニアリング』の1章の「AIとのつきあい方」に書きました。何をAIに作らせるかという最初の発注と、出来上がったものが期待どおりかという最後の検収を人が担い、時間と手間のかかる中間の作業をAIに任せる、というスマイルカーブ理論の節で、発注の段では何をしてもらうかを定義して伝える力が、検収の段では差し戻すかどうかを決める目利き力が問われる、としています。発注のちょっとした言い回しの違いで思ってもみない成果物が出る、と述べたあとに、そこには「そんな残念な事態を避けるためにこそプロンプトエンジニアリングがあります。」とあります。この節を読むと、AIには無理だと思っていた仕事を、発注として書く入力と出力、検収で使う合格の条件に分けて、自分で書き出せるようになります。