マルチターゲット・コード生成タスクの入力―処理―出力分解 ―― ワークドエグザンプル

著者: Asher Bond (asher.bond@distillative.ai)

要旨

あえて単純なタスク ―― 複数のプログラミング言語にわたって「Hello, World!」プログラムを生成し検証する ―― を用いて、コーディングエージェントが、小さく再利用可能な関数群の 入力―処理―出力(IPO) 分解として構造化され、それが 生成 → 実行 → 検証 → 修正 のループに包まれる様子を示す。このタスクを選んだのは、その正しさのオラクルが自明である(プログラムが期待どおりの文字列を出力しさえすればよい)からであり、これによって論述の焦点はタスクの難しさではなく「パイプラインの構造」そのものに定まる。分解には標準的な関数合成 [1, 2, 3] を用い、検証ループは確立された二つの系譜の上に立つ ―― 信頼性を得るためのサンプリング・アンド・チェック(その文書化された一例が自己一貫性である)[4] と、不確実性下での受容/棄却の判断を定式化する信号検出理論 [5] である。転用可能な成果はパイプラインの構造であり、具体的な言語数や出力例は例示にすぎない。生成の不確実性そのものは、より広い文献において未解決の問題として残っている [6]。

1. 序論

コーディングアシスタントへのありふれた依頼 ―― 「Xをあらゆる言語で書け」 ―― は、格好の教材である。出力ごとの正しさの検査が曖昧さを含まないからだ。すなわち、プログラムは目標の文字列を出力するか否か、それだけである。この明快さゆえに、このタスクは「基盤となるタスクがどれほど難しいか」という問いから切り離して、「エージェントをどう構造化するか」を示す直接的な題材となる。この例の価値は、それが露わにする構造にある ―― 依頼を分解し、コードを生成し、それを実行し、出力を検証し、失敗すればループを回して、出力が通るまで繰り返すエージェントである。具体的な言語数や出力例は説明のための舞台設定にすぎず、生成を実行可能なオラクルに対して閉じるループこそが転用される部分である。

2. 関連研究

合成的なパイプライン構造。 エージェントを、小さく単一目的の関数群として構成し、それらをより大きなパイプラインへ合成することは、標準的な関数型プログラミングの規律であり [1, 2]、抽象化と第一級関数という言語理論上の概念に立脚する [3]。

生成・検証による信頼性。 修正ループの核心 ―― 候補となる出力を生み、それをオラクルに照らして検査し、通ったものだけを残す ―― は、文書化された信頼性戦略である。複数の推論経路をサンプリングし、合意によって選択すること(自己一貫性)は、連鎖思考の信頼性を測定可能な形で改善する [4]。受容/棄却の判断が不確実性下(オラクルが雑音を含む、あるいは部分的である場合)でなされるとき、適切な形式的枠組みは信号検出理論であり、これは弁別性を判断基準から分離する [5]。「Hello, World!」の場合、オラクルは厳密であるため判断は自明である。検証器そのものが不完全であるとき、その重みを担うのが信号検出理論の枠組みである。

なぜ検証が不可欠か。 言語モデルによる生成は、流暢でありながら誤った出力を免れない。幻覚(ハルシネーション)は生成システム全般にわたって未解決の問題として残っている [6]。明示的な実行ベースの検証器は、生成のみのパイプラインが欠いている、まさにその外部的検査である。

3. IPO分解

タスクは複数の段階に分解され、各段階が再利用可能な関数群の上に成る一つのIPOの三つ組をなす。

  1. 計画 ―― 入力: 依頼。処理: 目標言語を列挙し、プロジェクト構成を定義し、必要なツールチェーンを列挙する。出力: 計画構造。
  2. 生成 ―― 入力: 計画。処理: 各言語について、ソースファイルと、それをビルド/実行するのに必要なスクリプト、およびドキュメントを生成する。出力: 内容の埋まったプロジェクトツリー。
  3. 実行 ―― 入力: プロジェクトツリー。処理: 各プログラムをビルドして実行し、標準出力とエラーを捕捉する。出力: 言語ごとの実行結果。
  4. 検証と修正 ―― 入力: 実行結果。処理: 各プログラムの出力を期待される文字列と比較し、不一致があれば診断し、編集し、再実行する。出力: すべてが通るプログラム群、あるいは通し得なかったものの報告。
  5. パッケージ化 ―― 入力: 検証済みの成果物。処理: READMEを備えた配布可能なアーカイブへ組み上げる。出力: 納品物。

構造的に重要なのは段階(4)である。すなわち、生成を実行可能なオラクルに対して閉じるループである。このループこそが ―― 具体的な言語やその数ではなく ―― 転用可能な着想である。

[ILLUSTRATIVE] ある具体的な実行は、ありふれた言語をいくつか対象とし、修正ループが一方でコンパイラフラグの問題を、他方でクラス構造の問題を解消したのちに、各言語が期待される文字列を出力したと報告する。これらの具体は説明のための舞台設定である。「あらゆる言語」とはパターンを名指すのであって、有限に列挙された集合を指すのではない。

根拠と適用範囲

これはパイプライン構造のワークドエグザンプルであって、ベンチマークではない。言語数、フォルダ構成、結果メッセージは、論述のために構築された舞台設定である。主張は生成―検証―修正のループそのものであり、それは確立された研究に立脚する ―― サンプリング・アンド・チェックについては自己一貫性 [4]、受容/棄却の判断については信号検出理論 [5] である。「Hello, World!」は厳密かつ安価なオラクルを備える。現実のタスクの検証器が不完全である場合にも同じ構造が保たれ、受容/棄却の判断は、誤受容/誤棄却のトレードオフを調整すべき検出問題 [5] となる。ループは誤った出力を緩和するが、それを消し去りはしない。一般の場合には幻覚とサイレント障害が現実のリスクとして残り [6]、だからこそ実行可能な検証器がループの中に置かれるのである。

References

  1. John Backus (1978). Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs. Communications of the ACM. [1977 ACM Turing Award Lecture]
  2. John Hughes (1989). Why Functional Programming Matters. The Computer Journal.
  3. Christopher Strachey (2000). Fundamental Concepts in Programming Languages. Higher-Order and Symbolic Computation. [Reprint of 1967 lecture notes]
  4. Xuezhi Wang et al. (2023). Self-Consistency Improves Chain of Thought Reasoning in Language Models. International Conference on Learning Representations (ICLR). arXiv:2203.11171.
  5. David M. Green & John A. Swets (1966). Signal Detection Theory and Psychophysics. Wiley.
  6. Ziwei Ji et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys. arXiv:2202.03629.