- 多くの開発者はLLMをコード作成に使おうとして、幻覚（Hallucination）を経験し、信頼を失う
- LLMが存在しないメソッドやライブラリを創作するのはよくあること
- しかしコードにおける幻覚は、最も危険性の低い種類の幻覚である
- 最も危険なのは、LLMがエラーを生み出してもコンパイラやインタプリタで即座に検出されない場合
- 幻覚されたメソッドは実行するとすぐにエラーを起こすため、簡単に見つけられる
- エラーメッセージをLLMに再入力すれば自動で修正できることもある
- 一般的なテキストの幻覚と異なり、コードは実行によって事実確認が可能である
- 自動エラー修正機能を持つLLM
- 一部の開発者は、LLMが幻覚したメソッドを生成したという理由だけで、この技術自体を退けようとする
- しかし効果的に使うには、学習と実験が不可欠である
- 筆者は2年以上にわたってAIベースのコード作成を研究しており、今なお新しい技術を学んでいる
- コードの手動テストは必須
- コードが正常に実行できるからといって、期待どおりに動作する保証はない
- コードレビューや自動テストだけでは、コードの正確性を完全には検証できない
- 実際に動かして検証する工程が不可欠である
- LLMが生成したコードは可読性が高いため、油断してしまう可能性がある
- 人間のコードも同様に、実際に動かしてみるまでは信用すべきではない
- 幻覚を減らす方法
- 別のモデルを使う: 特定のプラットフォームに関する学習データがより豊富なモデルを選ぶ
- 例: Claude 3.7 Sonnet（thinking modeを有効化）、OpenAI o3-mini-high、GPT-4o（Python Code Interpreterを含む）
- コンテキストを活用する: LLMが特定のライブラリを知らなくても、サンプルコードを提供すればパターンを学習できる
- 安定した技術を選ぶ: 古いライブラリを選ぶと、LLMがよりうまく扱える可能性が高い
- コードレビューの重要性
- 「LLMが書いたコードを全部レビューしなければならないなら、自分で書いたほうが早い」という主張に反論している
- これはコードレビュー能力の不足を露呈する発言かもしれない
- LLMが生成したコードのレビューは、実力を向上させる良い機会になり得る
- ボーナス: Claude 3.7 Sonnetからのフィードバック
- 筆者はブログ草稿をClaude 3.7 Sonnetの「extended thinking mode」にレビュー依頼した
- 「この記事の論理に説得力があるか、改善点があるか、抜けている内容があるかを確認してほしい」と依頼した
- Claudeは草稿の語調をより柔らかくするのに役立った
- Claudeフィードバック対話リンク
1件のコメント
Hacker Newsの意見
筆者は前回の記事には同意したが、今回の記事には同意しない
LLMが生成したコードがうまく動いていても、作者でなければバグや論理的欠陥を見つけるのは難しい
LLM生成コードはきれいだが、QAや整理作業により多くの時間を費やすことになる
The PrimeagenとCasey Muratoriが最新のLLMコード生成器の出力をレビューした
Simonが見落としていたもう一つのエラー分類は、モデルが機能を忘れてしまうタイプのハルシネーションである
幻覚されたメソッドは小さな障害であり、これに文句を言う人はシステムを効果的に使う方法を学ぶための最低限の時間すら使っていない、と考える向きがある
ハルシネーション自体は、LLMがもたらす最大のリスクではない
コンパイルエラーという限られた文脈においてのみ、より危険性が低い
LLMで良い結果を得るには多大な労力が必要である
医療センターで患者の「主要」クリニックを見つけるコードを書いた経験