アーカイブ / LLM
コード学習は推論の何を助けるのか――構造と意味を分けて検証
On Code-Induced Reasoning in LLMs
On Code-Induced Reasoning in LLMsの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: We construct parallel code and natural language instruction datasets, apply targeted modifications (rule-based and generative-based perturbations, single programming language ablations), and fine-tune a separate LLM on each modified dataset. We then evaluate the resulting models across general natural language, code, and math reasoning tasks.
概要
- 著者らは、構造を変える操作が意味を担う要素の変更より成績を下げやすく、特に数学とコードの課題で差が大きいと報告した。
- 疑似コードやフローチャートは一部の課題で元のコードと同程度以上だったが、コード生成では詳しいコード表現が有利だった。
- 3331件の実験で学習データの表現を比較した。コード評価は実行成否ではなく、GPT-4o-miniによる1～10点の採点を用いた。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、On Code-Induced Reasoning in LLMsの仕組み
- 01コードの指示と回答
- 02表現を変更
- 03モデルを追加学習
- 04各課題への回答
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
コードで追加学習した大規模言語モデルは、数学などプログラミング以外の推論課題でも成績が上がると報告されてきた。ただ、役立つのが分岐や繰り返しの構造なのか、名前やコメントが伝える意味なのかは明確でなかった。
この違いは学習データの作り方に関わる。コードをそのまま集める場合と、処理の流れを別の形で記す場合とでは、用意するデータや点検する内容が変わるためだ。
手法
著者らは、指示と回答の組をコードと自然言語でそれぞれ12万件作った。コードの回答は十のプログラミング言語で用意し、空白の削除、変数名の置換、コメントの入れ替えなどを施す。例えば文字を順に調べるコードから空白を除き、見た目の区切りが学習結果にどう関わるかを比べる。変更後も例の数は保つ。
別の変更では、コードを疑似コードやフローチャートに書き換える。疑似コードは特定言語の細かな文法を使わず処理順を記す表現で、フローチャートは分岐などの流れを図で表すものだ。各データでモデルを別々に教師あり追加学習し、指示に対する回答を学ばせた後、自然言語、数学、コードの課題で評価する。
新規性
著者らの前進は、自然言語とコードの指示データを並行して作り、コードの構造や意味を担う要素を変えた複数のデータで、それぞれモデルを追加学習させた点にある。変更後も例の数を保ち、学習データの表現が結果にどう関わるかを調べた。
さらに、十のプログラミング言語に加え、疑似コードやフローチャートも比較した。コードのどの性質が有効かを、自然言語、数学、コードの課題別に検討している。
従来手法との違い
基準は追加学習なし、コードのみ、自然言語のみ、両者を半分ずつ使う追加学習である。コードの変更を調べる際は、変更していないコードで追加学習したモデルと比べる。例には空白の削除、変数名やコメントの変更、別形式への書き換えがある。
著者らは、ほぼすべての変更で基準より成績が下がり、構造を変える変更の影響が数学とコードの課題で特に大きいと報告する。一方、疑似コードやフローチャートが元のコードに並ぶ、または上回る場合もあり、効果は課題によって異なる。
実験結果
著者らは五つのモデル系列、八つの規模、十のプログラミング言語にまたがる3331件の実験を報告した。自然言語課題と一部の数学課題は正答率、GSM8KとHRM8Kの自由記述問題は正解との完全一致で測る。コード理解と生成では、GPT-4o-miniが課題ごとの採点基準を作り、同じモデルが1～10点で採点した。
14種類の基礎モデルを通じ、コードのみか半々の追加学習が最高成績となった割合は、自然言語課題で64％、数学とコード理解の課題で86％、コード生成の課題で全てだったと著者らは述べる。これらは比較条件の中で最高成績となった割合であり、個々の課題の正答率ではない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内の開発支援モデルに、仕様から処理手順案を作らせる用途を試す。入力に使う学習データは、利用許可を確認したコード課題と模範解答である。解答の分岐や繰り返しを保って疑似コードに書き換え、人が内容を点検してから追加学習に使う。
利用時は開発者の短い仕様を入力し、手順案とコード案を出力する。元コードで学習した場合との比較を想定した仮説で、業務での改善は未検証である。評価には別の課題と正解、動作確認用のテストが必要で、センサーは使わない。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：利用許可のあるコード課題と模範解答を集め、分岐や繰り返しを保つ疑似コードに変換して人が点検する。同じ基礎モデルを使い、元コード版と疑似コード版で同数の課題・解答を追加学習する。学習に使わない仕様と正解、動作確認用のテストを別に確保する。
両版に同じ仕様を入力し、手順案が正しい割合と生成コードがテストを通る割合を測る。社内特有の書き方に合わせる場合は、その例と正解を追加して再評価する。必要なのは課題、解答、評価用の正解とテストであり、センサーは使わない。
限界と課題
著者らは計算資源の制約により、追加学習した最大のモデルは80億パラメータだと述べる。また、小規模な変更後のモデルは実行可能なコードを出しにくいため、コード評価には実行結果でなく別のモデルによる採点を採用したと説明している。
編集上の検証事項は、その採点が実際の動作や開発者の判断とどの程度一致するかである。日本語の業務仕様や社内コードにも同じ傾向が出るかは、この実験からは判断できない。確認できた本文の範囲では結論の末尾が途切れており、それ以降の記述は確認できない。
出典
元のタイトル・要旨を確認する（英語）
On Code-Induced Reasoning in LLMs
Code data has been shown to enhance the reasoning capabilities of large language models (LLMs), but it remains unclear which aspects of code are most responsible. We investigate this question with a systematic, data-centric framework. We construct parallel instruction datasets in ten programming languages and apply controlled perturbations that selectively disrupt structural or semantic properties of code. We then finetune LLMs from five model families and eight scales on each variant and evaluate their performance on natural language, math, and code tasks. Across 3,331 experiments, our results show that LLMs are more vulnerable to structural perturbations than semantic ones, particularly on math and code tasks. Appropriate abstractions like pseudocode and flowcharts can be as effective as code, while encoding the same information with fewer tokens without adhering to original syntax can often retain or even improve performance. Remarkably, even corrupted code with misleading signals remains competitive when surface-level regularities persist. Finally, syntactic styles also shape task-specific gains with Python favoring natural language reasoning and lower-level languages such as Java and Rust favoring math. Through our systematic framework, we aim to provide insight into how different properties of code influence reasoning and inform the design of training data for enhancing LLM reasoning capabilities.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01