AIの弱点、やっぱりプログラミングは人間が(も)勉強しよう / YAPC AI and Programming

2025-11-14に開催されたYAPC::Fukuoka 2025での登壇資料です

Transcript

1. AIコーディングの弱点 やっぱりプログラミングは人間が(も)勉強しよう 2025-11-14 YAPC::Fukuoka 2025 LINEヤフー きしだ なおき
2. 2 Agenda • AIについて • AIの仕組み • AIの弱点 • プログラミング言語 • プログラミングに必要なこと • プログラミング言語機能の概要 • プログラムの最適化 • まとめたい
3. AIについて • AIの仕組み • AIの弱点
4. AIの仕組み • AIとは • Transformer • ChatGPTの進化からみる技術 • AIの計算 • AIの学習
5. 5 AIってなに？ • LLMを中心とした反応システム • LLM=大規模言語モデル • 言語を扱う大規模なニューラルネットワーク • Transformerを基本とする • 仕組み的には、文章の続きを生成
6. Transformer • 2017にGoogleが発表 • Attention is All You Need • アテンション • 文章中の単語がどの単語を注目しているか • O(n^2)
7. 7 Transformerの発展 • AIが賢くなったというときには技術発展がある GPT3 スケーリング則で学習コストをかけて性能をあげる GPT3.5 チャット対応とRLHFで対話が可能に GPT4 MoEで実行時リソースを削減 Function Callingで外部機能呼び出し o1 Reasoningによる推論時スケーリング o3 エージェントで推論の並列化
8. スケーリング則(GPT-3) • 言語モデルの性能がパラメータ数、データセットサイズ、計算予 算を変数としたべき乗になる • OpenAIが予算をつぎ込むキッカケになった Scaling Laws for Neural Language Models (Jared Kaplan, Sam McCandlish et al., 2020-01-23)
9. チャット対応とRLHF(GPT-3.5) • チャットに対応するファインチューニング • 指示応答モデル • 使いやすくなって爆発的人気 • RLHF(Reinforcement Learning from Human Feedback) • 人間の評価による強化学習 • やりとりの心地よさ
10. MoE(Mixture of Experts) (GPT-4) • FFNは知識をうけもつ • すべての知識を同時に使うことはない • 多数の専門家モデルを持っておいて、 推論時に必要なモデルだけを呼び出 すことでリソースを節約 • GPT-oss 120B • エキスパート数 128 • アクティブパラメータ数5.1B
11. Function Calling • LLMから外部関数を呼び出す • OpenAI、Google、Hugging HaceはFunction Calling • Anthropic、AWSはTool Use • AIが幅広い機能をもつようになった • MCP • JSON-RPCを使ってリモートでFunction Calling • MCPサーバーは状態を持つので、JSON-RPCによる分散オブジェクト
12. Reasoningと推論時スケーリング(o1) • CoT(Chain or Thought) • 「段階的に考えて」 • ユーザーに応答を出す前に考察過程を入れる • 推論時にリソースを使うことでも 思考力がスケールする • 推論時スケーリング
13. なぜReasoningが効くか • Transformerでは、トークン同士の関係を見た後でモデルの知識を利用し て回答 • ひとつの層ではアテンションでトークン同士の関係、FFNに知識 • 全体では浅い層でトークン同士の関係、深い層で知識 • トークン同士の関係を見るときに知識が 活かされない • Reasoningで知識を出させておくと ユーザー入力と知識がトランスフォーマに 投入される
14. Agentによる複雑な推論(o3) • o3(恐らく)やGemini Deep ThinkではReasoningを並列に行って一番いいも のを採用して回答 • チャットの中で複数のアイデアを出すのとは違う • コンテキスト(=チャット履歴)の分離が重要 • エージェント=コンテキスト • マルチエージェント • ツール呼び出しや判定を組み入れて複数コンテキストを 管理するシステム
15. AIの計算 • 226-68= ? • 人間だと • 150くらいになりそう • 偶数だな？ • そのあとちゃんと計算して158を求める
16. AIの計算 • 226-68=? • LLMだと(Llama3-8B) • 3桁までの数字は1トークンで扱う • 24層の12439番目のニューロンは引き算が150～180のときに発火 • 30層の1582番目のニューロンは引き算が8で終わるときに発火 • どんどん出現比率をあげて、 最終的に158の確率が高まる • ヒューリスティックを積み上げて 答えの確率を高めていく Arithmetic Without Algorithms: Language Models Solve Math with a Bag of Heuristics https://arxiv.org/abs/2410.21272
17. AIの学習 • AIの学習は都合のいいランダムを選ぶ仕組み • ユニットテストが書けるものは賢くなる • ユニットテストが書きにくいものは苦手
18. AIの学習は都合のいいランダムを選ぶ仕組み • AIの学習は当たりが出やすいようパラメータを調整する仕組み • ハズレの確率が減っていくことを「学習が進む」という • 答えが定義できれば、正解の確率が高まるようパラメータを調整していけ る • 問題と答えを自動生成できれば どんどん賢くなる(人工データ) • 教師を超えることはない • テキストのみで学習なら人類を 超えない(個人は超える) • 機械判定できるなら人類を超える
19. LLMはユニットテストが書けるものは賢くなる • ユニットテストが定義できる問題は学習が進みやすい • ユニットテストが定義できるならテストが通るまで再試行できる • コードとテストが自動生成できるならもっと賢くなる • 部分的なユニットテストが通れば全体もだいたい動くといった コードも書ける • シーケンシャルな処理
20. ユニットテストが書きにくいものは苦手 • 学習ができない • テストが通るまでやりなおす戦略も使えない • 部分が正しくても全体が正しいわけではないものも苦手 • つまり非機能要件 • ユーザビリティ • API設計 • セキュリティ • メンテナンス性
21. AIの弱点 • コンテキスト処理能力 • 知らないことが多い
22. コンテキスト処理能力 • 長いコンテキストに対応できない • コンテキストの汚れに弱い
23. 長いコンテキストに対応できない • 長コンテキスト対応といっても性能出るのは30Kトークンくらい • アテンションはO(n^2)なので長くできない • ウィンドウなどなんらか範囲を限定してる • 学習データがそんなに長くない • プロジェクト全体を一気に把握することができない
24. コンテキストの汚れに弱い • AIにコードを書かせると、「修正しました！」といって２つ前の バグコードを出してきて「アホか！」と暴言を吐きたくなる
25. なぜ同じ失敗が続くのか • 間違い同士で注目して、大事な情報だと認識してしまう 関係 ありそう めちゃ関係 ありそう 関係 ありそう 関係 ありそう めちゃ関係 ありそう 関係 ありそう
26. コンテキストエンジニアリング • コンテキストをコンパクトに保つ • コンテキストが必要な情報だけ持つように管理する • コンテキストは汚れに弱い • 関係ありそうで関係ない情報があると性能劣化 • まったく関係ない話が混じると逆に性能よくなるという説も
27. 知らないことが多い • プログラムの動きを知らない • ソースファイルと解説しか知らない • プログラムの成長を知らない • 完成品しかみてない • 大きなプログラムを知らない • ファイル単位で学習している
28. プログラミング言語 • プログラム言語に必要な機能 • 言語機能の分類 • プログラムの最適化と構成
29. プログラミング言語に必要な機能 • プログラムでやること • プログラムの構成に求めること
30. プログラムでやること • 機能 • 性能 • 使いやすさ • 安全性
31. プログラムの構成に求めること • 機能が追加変更できる • 機能を破壊しない • 機能や変更が明確
32. 言語機能の分類 • 実行のための機能 • 構成のための機能 • 関数とオブジェクト • 計算以外の機能
33. 実行のための機能 • 逐次実行 • 関数 • 関数とループ
34. 構成のための機能 • 構造体 • 抽象データ型 • 部分型とインタフェース • 継承
35. 関数とオブジェクト • 実行と構成の機能 • オブジェクトによる関数 • 関数によるオブジェクト • 関数と型での証明
36. 計算以外の機能 • メモリ管理 • 例外処理 • スレッド
37. メモリ管理 • スタックとヒープ • 手動でのメモリ管理 • 自動的メモリ管理 • 完全自動 • スコープによる管理
38. 例外処理 • 復帰可能な例外と復帰不能な例外 • 戻り値による例外処理 • ジャンプによる例外処理 • 構造的例外処理 • 例外処理の使い分け
39. 並列処理 • スレッドの利用 • データ並列処理 • 非同期処理 • コールバック • 言語による直列記述 • VMによる直列記述
40. プログラムの最適化 • 処理の重複の排除 • 記述の重複の排除 • 変更発生源をまとめる • 依存を減らす • 処理最適化と構成最適化
41. 処理の重複の排除 • 基本は値を使いまわす • キャッシュ • スコープの最小化
42. キャッシュ • 変数による値の使いまわし • hashmapによるキャッシュ func(list) { print("合計": list.sum()); print("平均": list.sum() / list.count()); } func(list) { var sum = list.sum(); print("合計": sum); print("平均": sum / list.count()); }
43. スコープ最小化 • 関数引数やループ変数に依存しない処理を外に出す func() { for (int i = 0; i < 10; ++i) { var n = init(); proc(n, i); } } func() { var n = init(); for (int i = 0; i < 10; ++i) { proc(n, i); } }
44. 記述の重複の排除 • 処理の重複を排除すると減る • 関数を活用する • 多態を活用する
45. 関数を活用する • 処理の共通化は関数の主目的
46. 多態を活用する • 部分型による多態を活用 • テンプレートメソッド abstract class Base { abstract void before(); abstract void after(); void proc() { before(); println("はろー"); after(); } } class School extends Base { @Override void before() { println("起立"); } @Override void after() { println("着席"); } }
47. 関数による実装 • 高階関数だとすっきり書けることも多い void proc(Runnable before, Runnable after) { before.run(); println("はろー"); after.run(); } proc(() -> println("起立"), () -> println("着席"));
48. 変更発生源をまとめる • 単一責務の原則 • 責務はクラスではなくクラス利用者の責務 • たとえば入荷処理・価格決めがある • ふつうは入荷、値付けでわける • それぞれすべての商品を扱う
49. 変更発生源をまとめる • 単一責務の原則 • 責務はクラスではなくクラス利用者の責務 • たとえば入荷処理・価格決めがある • 商品で担当が分かれていれば • 商品ごとに処理をわける
50. 依存の適正化 • 使ってない変数が見えないようにする foo(int a, int b) { for(int i = 0; i < a; ++i) { ..割と長い処理 } for(int i = 0; i < b; ++i) { ..割と長い処理 } } fooa(int a) { for(int i = 0; i < a; ++i) [ ..割と長い処理 } } foob(int b) { for(int i = 0; i < b; ++i) { ..割と長い処理 } } foo(int a, int b) { fooa(a); foob(b); }
51. 原則 • スコープの適正化 • 不要なものをスコープに入れない • 必要なものをスコープにまとめる • SOLIDなどの「原則」はあとからついてくる
52. まとめ • AIは基本的に機能実装しかできない • 非機能要件は人間ががんばる • プログラミングを知る必要がある • がんばりましょう