Evaluating LLMs in the Context of a Functional Programming Course: A Comprehensive Study

この論文は、OCaml という低リソースな関数型プログラミング言語の教育環境における大規模言語モデル（LLM）の能力を評価し、構文や型エラーの修正、基本的な概念の解説においては効果的であるものの、Python や Java などの高リソース言語に比べて課題解決能力は限定的であることを示すとともに、3 つの新しいベンチマークを提案しています。

要約

この論文は、**「最新の AI（大規模言語モデル）が、プログラミングの授業で学生を助けることができるのか？」という問いに、特に「OCaml（オックラム）」**という少し特殊で難しい言語を使って答えた研究です。

OCaml は、Python や Java のように世界中で広く使われている「高資源言語」ではなく、使っている人が少ない「低資源言語」です。この研究は、AI が有名な言語では得意でも、マイナーな言語ではどうなるのか、そして教育現場で本当に役立つかを詳しく調べました。

以下に、この研究の内容を**「料理教室」や「魔法の助手」**のような身近な例えを使って解説します。

---

🍳 研究の舞台：特殊な料理教室（OCaml 講座）

この研究は、マギル大学の 2 年生向け「関数型プログラミング（OCaml）」の授業で行われました。
通常のプログラミング言語（Python など）は、AI が大量のレシピ（データ）を食べて勉強しているので得意ですが、OCaml は**「希少な食材」**を使った料理です。AI はこの食材のレシピをあまり持っていない可能性があります。

研究者たちは、AI の能力を測るために**3 つの「テスト課題」**を用意しました。

1. 📝 課題：λCodeGen（レシピ作成テスト）

• 内容: 「この料理を作ってください」という自然な言葉の指示（宿題）を与え、AI にコード（レシピ）を書かせる。
• 例え: 「卵とトマトを使って、卵焼きを作ってください」と言われて、AI がレシピを書く。
• 結果:
  • トップクラスの AI（GPT-4o, o3-mini など）: 約 70% の確率で、完璧なレシピ（正解）を出せました。
  • しかし: 有名な言語（Python）のテストでは 90% 以上正解する AI でも、この特殊な言語では少し失敗しました。また、**「レシピは合っているけど、材料の使い方が無駄」や「指示された特別な調理法（関数）を使っていない」**といった、細かいミスも多かったです。
  • 下位の AI: 50% 以上が「そもそも料理が作れない（コンパイルエラー）」という状態でした。

2. 🔧 課題：λRepair（失敗料理の直しテスト）

• 内容: 学生が作った「失敗した料理（バグったコード）」と「失敗の理由（エラーメッセージ）」を AI に見せ、直させる。
• 例え: 「卵が焦げています」「塩を入れすぎています」というメモ付きで、失敗した料理を渡して「直して」と頼む。
• 結果:
  • 得意分野: 「焦げ（構文エラー）」や「塩分量（型エラー）」の直しは、トップ AI が80% 以上の確率で完璧に直しました。これは AI が非常に得意です。
  • 苦手分野: 「味が変（論理エラー）」のような、根本的な考え方のミスは、直すのが難しく、成功率が少し下がりました。
  • 面白い発見: 小さな AI モデルでも、この「直し作業」だけは、ゼロから作るよりも上手にできました。

3. 🗣️ 課題：λExplain（料理の理論説明テスト）

• 内容: 「なぜこの調理法が必要なのか？」「この食材の性質は？」といった理論的な質問に答える。
• 例え: 「なぜ卵焼きは裏返す必要があるのか？」「この料理の原理を説明して」と頼む。
• 結果:
  • トップ AI: 約 60〜80% の確率で正しく説明できました。
  • 問題点: 正解でも、**「必要以上に長々とお説教をする（冗長）」**という癖がありました。学生が「簡潔に教えて」と頼んでも、AI は「実は卵焼きには歴史があって…」と余計な話を加えてしまうのです。
  • 下位 AI: 理論的な説明になると、トップ AI と下位 AI の差が最も激しく開きました。

---

🌟 研究の結論：AI は「万能の助手」だが「完璧な先生」ではない

この研究からわかった重要なポイントは以下の通りです。

1. AI は「便利すぎる」が「油断できない」

   • AI は構文や型の間違いを直すのが非常に得意で、初心者にとって「魔法の助手」として役立ちます。
   • しかし、**「論理的なミス」や「複雑な理論」になると、AI も間違えます。しかも、「自信満々に間違ったことを言う」**ことが多いので、学生がそのまま信じてしまうと危険です。

2. 言語によって得意・不得意がある

   • 世界中で使われている言語（Python など）に比べると、OCaml のようなマイナーな言語では AI の性能は少し落ちます。これは、AI が勉強した「レシピ集（データ）」が少ないからです。

3. 教育へのアドバイス

   • 学生へ: AI に頼りきるのはやめましょう。AI が出した答えは、自分で「本当に正しいか？」を疑ってチェックするスキルが必要です。
   • 先生へ: 「AI に答えさせる」のではなく、「AI が出した答えの間違いを見つける」や「AI にあえて間違った答えを出させる」といった、批判的思考を鍛える課題を作るべきです。

🎓 まとめ

この論文は、**「AI はプログラミングの授業で強力なパートナーになれるが、まだ完全な信頼は置けない」**と伝えています。

AI は、**「料理の基礎を教える優秀なアシスタント」にはなれますが、「料理の奥義を教える熟練のシェフ」**にはまだなれていません。学生は、このアシスタントを上手に使いこなしつつ、自分で考える力を磨いていく必要があります。

研究者たちは、この研究結果が、より良い AI ツールの開発や、学生が AI とどう付き合うべきかの指針になればと願っています。

技術概要

以下は、提示された論文「Evaluating LLMs in the Context of a Functional Programming Course: A Comprehensive Study」の技術的な要約です。

論文概要

本論文は、大規模言語モデル（LLM）が、リソースが豊富な言語（Python や Java など）ではなく、低リソース言語である OCaml を用いた関数型プログラミングの教育環境において、どの程度効果的かを評価した包括的な研究です。著者らは、コード生成、バグ修正、概念説明の 3 つのタスクを評価するための新しいベンチマークを構築し、9 つの最先端 LLM の性能を定量的・定性的に分析しました。

---

1. 研究背景と課題 (Problem)

• 背景: LLM は学生がコード作成や概念理解を支援するツールとして広く利用されている。しかし、既存の研究の多くは Python や Java などの高リソース言語の入門コースに焦点を当てており、関数型プログラミングや低リソース言語における LLM の能力は十分に評価されていない。
• 課題:
  • 学生は LLM の出力を過信し、誤った情報（ハルシネーション）や冗長な回答を受け入れる傾向がある。
  • 関数型プログラミング（パターンマッチング、継続、型推論など）は論理的な複雑さが高く、LLM が誤ったコードを生成するリスクが特に高い。
  • 教育現場において、LLM の限界を理解し、批判的に評価する能力を学生に身につけさせるための具体的な評価基準が不足している。

2. 研究方法論 (Methodology)

著者らは、マギル大学の 2 年生向け関数型プログラミングコース（Fall 2022 以降）のデータに基づき、以下の 3 つのベンチマークを構築しました。

A. 構築されたベンチマーク

1. λCodeGen (コード生成):
   • 10 個の宿題（計 53 タスク）から構成。
   • 内容：パターンマッチング、高階関数、継続（Continuations）、型推論、インタプリタ実装など。
   • 特徴：単一関数ではなく、複数のタスクを含む自然言語による課題記述を提示し、実際の教育環境に近い複雑さを再現。
2. λRepair (コード修正):
   • 150 個のバグを含むプログラム（学生からの実際の提出物）。
   • 3 種類のエラーに分類：構文エラー (50)、型エラー (50)、論理エラー (50)。
   • 特徴：ゼロショット（例示なし）でエラーメッセージとバグを含むコードを提示し、修正を要求。
3. λExplain (概念説明):
   • 50 個の理論的な概念に関する質問（試験問題や予習用問題から抽出）。
   • 内容：変数のスコープ、帰納法証明、評価戦略（call-by-value vs call-by-name）、置換など。
   • 特徴：コンパイラによる自動判定が不可能なため、人間の評価に依存。

B. 評価対象モデル

9 つの SOTA LLM を対象に評価を行いました。

• 商用モデル: GPT-4o, GPT-4o-mini, o3-mini, Claude 3.7 Sonnet, Gemini 2.0 Flash, Gemini 1.5 Flash 8B
• オープンソースモデル: Llama 3.1 70B, Llama 3.1 8B, Qwen2.5 7B

C. 評価手法

• 自動化評価: OCaml コンパイラと自動採点システム（autograder）を使用し、正解かどうかを判定。
• 手動評価: 教育担当助教 2 名が、以下の 3 つの観点で品質を評価。
  1. 正解性 (Correctness): テストケースの通過率。
  2. アルゴリズム設計 (Algorithm Design): 問題要件（例：末尾再帰の強制、特定の関数使用禁止など）への適合性。
  3. 可読性 (Readability): 冗長さや不要な説明の有無。
• 評価基準: 「Mastery (熟達)」「Proficient (熟練)」「Developing (発展)」「Beginning (初級)」「Non-gradable (評価不能)」の 5段階でランク付けし、大学のカリキュラム基準に合わせた文字評価（A〜F）に変換。

---

3. 主要な結果 (Results)

全体傾向

• 上位モデル: o3-mini, Claude 3.7 Sonnet, GPT-4o の 3 つがすべてのタスクで他を大きく引き離し、上位に位置しました。
• 下位モデル: Llama 3.1 8B, Qwen2.5 7B, Gemini 1.5 Flash 8B は多くのタスクで「評価不能」または「初級」レベルの回答が多く、特にコード生成では 50% 以上がコンパイルエラーを起こしました。
• 高リソース言語との比較: 既存の Python/Java ベンチマーク（HumanEval など）では 90% 以上の精度が出るトップモデルでも、OCaml での「Mastery」率は 70% 前後にとどまりました。これは、評価基準に「品質（設計や可読性）」が含まれていることと、低リソース言語のデータ不足が要因です。

タスク別詳細

1. コード生成 (λCodeGen):
   • 上位モデルの Mastery 率は約 70%（GPT-4o: 69.8%, o3-mini: 73.6%）。
   • 専門的なコード合成ツール（BURST）は 11.3% しか解決できず、LLM の汎用性の高さが示されました。
   • 複雑な理論的実装（型推論、継続など）では性能が低下します。
2. コード修正 (λRepair):
   • 構文/型エラー: 修正性能は非常に高く、上位モデルは 75-80% の Mastery 率を達成。専門ツールと競合するレベルです。
   • 論理エラー: 構文エラーに比べ難易度が高く、上位モデルでも 60-70% 程度に留まります。
   • One-shot 学習: 1 つの例を示すことで、特に小規模モデルの修正性能がわずかに向上しました。
3. 概念説明 (λExplain):
   • 上位モデル（o3-mini など）は 80% 以上の Mastery 率を達成し、理論的な説明も得意です。
   • しかし、多くのモデルが過度に冗長な回答をする傾向があり、要点を突かない説明が含まれることが問題視されました。
   • 学生は正誤の判定が難しいため、誤った理論の説明を信じてしまうリスクが高いです。

難易度による影響

• 基本的なタスク（パターンマッチングなど）は高い精度で解決されますが、高度な概念（継続、型推論、自由変数の計算など）になると性能が急激に低下します。
• 特に「プログラミング言語理論」に関する質問では、モデルの能力差が顕著に現れました。

---

4. 主な貢献 (Key Contributions)

1. 初めての包括的ベンチマーク: 関数型プログラミング（OCaml）における LLM の評価を、コード生成、修正、概念説明の 3 つの側面から網羅的に行い、3 つの新しいベンチマーク（λCodeGen, λRepair, λExplain）を公開しました。
2. 定量的・定性的評価の融合: 従来の「テストケース通過率」だけでなく、教育現場で重視される「アルゴリズム設計の適切さ」や「可読性」を人間が評価し、LLM の実用的な有用性と限界を浮き彫りにしました。
3. 教育者への示唆: LLM は「万能なツール」ではなく、特に論理エラーや高度な理論において誤りを生む可能性があることを示しました。これにより、学生に LLM 出力の批判的検証を促す教育デザインの重要性を提言しています。
4. PL 研究コミュニティへの提言: 低リソース言語や複雑なプログラムに対する合成・修正ツールの開発において、ドメイン固有の推論を LLM に統合する必要性を指摘しました。

---

5. 意義と結論 (Significance & Conclusion)

• 学生と教育者にとって: LLM は学習の補助として有用ですが、特に関数型プログラミングの高度な概念においては「盲信」すべきではありません。教育者は、LLM の限界を理解させ、デバッグや検証のスキルを育成する評価課題を設計する必要があります。
• 技術的展望: 現在の LLM はパターンの一致に依存しており、深い理論的理解には欠けるため、コンパイラ技術や形式手法と組み合わせたハイブリッドなアプローチ（例：型チェック器との連携）が今後の発展に不可欠です。
• 総括: 上位の LLM は関数型プログラミングのタスクにおいて「B+/B」レベルの能力を持ち、実用的な価値はありますが、完全な信頼性は得られていません。低リソース言語における LLM の能力は、高リソース言語に比べてまだ発展途上であり、継続的な評価とツールの進化が必要です。