1 ポイント 投稿者 GN⁺ 2025-04-03 | 1件のコメント | WhatsAppで共有

核心的な主張: LLMからはできるだけ早く抜け、長く留まらないこと

  • LLMに意思決定やビジネスロジックを任せてはいけない → 正確性と安定性が不足している
  • ほとんどの場合、LLMは単にユーザーとアプリケーションAPIの間のインターフェースとして機能するべき
  • 中核ロジックは専用システムやエンジンで実行し、LLMはユーザーの要求をAPI呼び出しに変換し、その結果を再び自然言語に変換する役割だけを担うべき

なぜそうなのか?

  • チェスボットの例: ユーザーがWhatsAppで「自分のビショップでナイトを取って」と送る → LLMがチェス盤の状態維持やプレイ自体も不可能ではないが、信頼性、性能、保守性の面で問題が多い

  • 性能: LLMのチェス能力は驚くべきものではあるが、それでも専用チェスエンジン(例: Stockfish)と比べると遅く、精度も劣る

  • デバッグや調整が困難: なぜその判断をしたのか分かりにくく、意図した動作をするよう修正するのが難しい

  • その他の問題:

    • LLMの出力はテストしにくい
    • 数学や乱数生成の性能が低い
    • バージョン管理や監査が難しい
    • 状態を自然言語で維持する方式は脆弱
    • API料金や速度制限などの問題が発生する
    • セキュリティ境界が曖昧になる

さまざまな例から見る適切な役割分担

  • ゲームで「プレイヤーXをヴォーパルソードで攻撃したい」 → LLMはこれを attack(player=X, weapon="vorpal_sword") の形に変換してゲームロジックに渡す役割だけを果たすべき
  • 交渉エージェント → LLMは交渉判断を行わず、ユーザー入力を整形して交渉エンジンに渡し、結果を伝える
  • ランダム応答の生成 → LLMが選択するのではなく、外部の乱数関数で処理するべき

LLMが得意なこと

  • LLMは変換、解釈、コミュニケーションに特化している
  • 例:
    • 「オークを剣で攻撃する」 → attack(target="orc", weapon="sword") に変換
    • { "error": "insufficient_funds" } → 「ゴールドが足りません」と自然に説明
    • ユーザー入力が戦闘コマンドか、インベントリ確認か、ヘルプ要請かを分類できる
    • 人間の概念(例: blade = sword, smash = attack)をよく理解する
  • 重要なのは複雑な判断や状態管理ではないということ → 単にユーザーの意図をシステムにつなぐ橋渡しの役割

今後の展望と変わらない原則

  • 技術は急速に進歩しており、今は不可能なことも近いうちに可能になるかもしれない
  • しかし、LLMでは解決できない構造的な問題は今後も残る可能性が高い:
    • LLMを使わないロジックのほうが理解しやすく、保守やバージョン管理もしやすい
    • 実行コストもより安い
  • 将来も同様に、LLMはインターフェース役に集中し、中核ロジックは専用システムに任せるべき

1件のコメント

 
GN⁺ 2025-04-03
Hacker Newsの意見
  • ロジックには2つの種類がある

      1. 本質的に正確かつ厳密でなければならないロジック
      1. コンピュータの性質上そうなってきたロジック
  • 1つ目のタイプは、セキュリティ、金融、数学などの分野に当てはまる

  • 2つ目のタイプは、AIに置き換えられる可能性が高い

  • 同じアプリケーションでも、別の部分は1つ目または2つ目に適している場合がある

  • 最近のハッカソンで教育用ゲームを制作した

    • LLMを使ってゲームを生成・実行したが、ゲームの流れは良くなかった
    • 最終的には、多くのPythonコードと複数のプロンプトを使ってゲーム状態を管理した
    • LLMは大きなシステムの小さな部品として使うのが最もよい
  • LLMはロジックを実装すべきではない

    • ロジック、最適化、制約プログラミングは別々の手法である
    • 現代論理学の創始者はGeorge Booleであり、彼はGeoffrey Everest Hintonの祖父である
  • LLMの機能を理解するのは難しい

    • 読者は簡単な答えを求める
    • LLMは単純な状態機械を書くのに苦労することがある
    • 研究論文が人気を集めており、2025年になってもLLMを完全に理解している人はいないだろう
  • LLMの応答を高速かつ低コストにしたいなら、短いプロンプトと小さなモデルを使うべきである

    • 多くの情報は大きなモデルを使うことを前提にしている
    • 従来型のUIのほうがより良い選択肢かもしれない
  • LLMだけではテストが難しい

    • 個人のスタイルがインタラクションに影響する
    • 保守コストが高くなる可能性がある
    • API呼び出しに変換するほうが合理的である
  • LLMをビジネスロジックに使うのは危険である

    • 言語処理には適している
  • AI生成画像を使って記事を要約できる