karpathy/llm-council View GitHub Homepage for Latest Official Releases

複数のAIモデルに問い合わせを行い、ピアレビューを可能にし、議長モデルを通じて回答を統合する、マルチLLMコラボレーションツール

Pythonllm-councilkarpathy 11.2k Last Updated: November 22, 2025

LLM Council - マルチモデルAIコラボレーションプラットフォーム

プロジェクト概要

LLM Councilは、Andrej Karpathy氏によって作成された革新的なオープンソースプロジェクトであり、単一モデルのAIインタラクションを、協調的なマルチモデル合意システムへと変革します。単一のLLMプロバイダーに依存するのではなく、このツールは複数の最先端AIモデルを連携させ、互いの出力をレビューし、民主的なプロセスを通じて統合された応答を生成します。

コアコンセプト

LLM Councilの基本的なアイデアは、個々のモデルのバイアスを最小限に抑えながら、異なるAIモデルの強みを活用することです。「AI諮問委員会」を設立することで、ユーザーは単一のモデルの視点に依存するのではなく、より包括的でピアレビューされた複雑な質問への回答を得ることができます。

アーキテクチャとワークフロー

3段階のプロセス

ステージ1：第一印象

  • ユーザーのクエリは、OpenRouter APIを介してすべての評議員モデルに同時に送信されます。
  • 各LLMは、他のモデルの出力を参照せずに、独立した応答を生成します。
  • 個々の応答は、並べて比較できるようにタブビューに表示されます。
  • デフォルトの評議員には、GPT-5.1、Gemini 3.0 Pro、Claude Sonnet 4.5、Grok 4が含まれます。

ステージ2：匿名ピアレビュー

  • 各モデルは、他のすべての評議員からの匿名化された応答を受け取ります。
  • モデルは、精度と洞察に基づいて各応答を評価およびランク付けします。
  • IDの匿名化により、評価におけるバイアスやえこひいきを防ぎます。
  • モデル間の評価により、驚くべきパターンが明らかになります（モデルは競合他社を高く評価することがよくあります）。

ステージ3：議長による統合

  • 指定された議長LLM（構成可能）は、すべての元の応答をレビューします。
  • ピアレビューのランキングと評価を考慮します。
  • 最良の要素を組み込んだ最終的な統合された回答を生成します。
  • 包括的な応答をユーザーに提供します。

技術スタック

バックエンド

  • フレームワーク: FastAPI (Python 3.10+)
  • HTTPクライアント: 非ブロッキングAPI呼び出しのためのasync httpx
  • API統合: マルチモデルアクセスのためのOpenRouter API
  • ストレージ: data/conversations/内のJSONベースの会話永続化
  • パッケージ管理: 最新のPython依存関係管理のためのuv

フロントエンド

  • フレームワーク: 高速な開発とビルドのためのReactとVite
  • レンダリング: フォーマットされた出力のためのreact-markdown
  • UI: モデル比較のためのタブビューを備えたChatGPTのようなインターフェース
  • 開発サーバー: ポート5173上のVite開発サーバー

主な機能

マルチモデルディスパッチ

  • 複数の最先端モデルにわたる同時クエリ実行
  • backend/config.pyを介した構成可能な評議員メンバーシップ
  • OpenAI、Google、Anthropic、xAIなどのモデルのサポート

客観的なピアレビュー

  • 匿名化された応答評価により、モデルのバイアスを防ぎます。
  • 精度と洞察のための定量的なランキングシステム
  • モデルの好みと強みにおける興味深いパターンを明らかにします。

統合された合意

  • 議長モデルは、多様な視点を集約します。
  • 複数の視点を組み込んだ一貫性のある最終的な回答を生成します。
  • 冗長性、洞察、簡潔さのバランスを取ります。

透明な比較

  • すべての個々の応答の並列ビュー
  • ピアレビューランキングへの完全な可視性
  • ユーザーはAIの合意と並行して独自の判断を下すことができます。

会話の永続化

  • 会話履歴の自動保存
  • 簡単なデータ移植のためのJSONベースのストレージ
  • 過去の評議会セッションをレビューおよび分析する機能

インストールとセットアップ

前提条件

  • Python 3.10以上
  • Node.jsとnpm
  • OpenRouter APIキー（クレジットの購入が必要）

バックエンドのセットアップ

# uvを使用して依存関係をインストールする
uv sync

フロントエンドのセットアップ

# フロントエンドディレクトリに移動する
cd frontend

# npmの依存関係をインストールする
npm install

cd ..

構成

  1. プロジェクトルートに.envファイルを作成します。
OPENROUTER_API_KEY=sk-or-v1-your-key-here
  1. backend/config.pyで評議会を構成します。
COUNCIL_MODELS = [
    "openai/gpt-5.1",
    "google/gemini-3-pro-preview",
    "anthropic/claude-sonnet-4.5",
    "x-ai/grok-4",
]
CHAIRMAN_MODEL = "google/gemini-3-pro-preview"

アプリケーションの実行

オプション1：クイックスタートスクリプト

./start.sh

オプション2：手動起動

# ターミナル1 - バックエンド
uv run python -m backend.main

# ターミナル2 - フロントエンド
cd frontend
npm run dev

アプリケーションにアクセスします：http://localhost:5173

ユースケース

読書と文学分析

  • Karpathy氏の元のユースケース：複数のAI視点による書籍の読解
  • 異なるモデルは、異なる文学的側面を強調します。
  • 解釈スタイルの比較分析

調査と分析

  • 複数の視点を必要とする複雑な質問
  • 技術ドキュメントの評価
  • ビジネス戦略の評価

コンテンツ評価

  • 法的文書の分析
  • 科学論文の解釈
  • コードレビューと技術文書作成

モデル比較

  • 異なるLLM機能のベンチマーク
  • モデルの強みと弱みの理解
  • プロバイダー間のバイアスパターンの特定

興味深い発見

モデルの自己評価

  • モデルは、競合他社の応答を自身よりも優れていると頻繁に選択します。
  • ピアレビュープロセスにおける驚くべき客観性を示しています。
  • アプローチと品質における真の違いを明らかにします。

ランキングパターン

Karpathy氏による書籍の章でのテストでは：

  • 合意された勝者: GPT-5.1は一貫して最も洞察力があると評価されました。
  • 合意された敗者: Claudeは一貫して最も低いランク付けでした。
  • 中間層: Gemini 3 ProとGrok-4は両極端の中間でした。

人間の判断とAIの判断の乖離

  • AIの合意は、人間の好みと一致しない場合があります。
  • GPT-5.1は洞察力があると賞賛されましたが、Karpathy氏からは「言葉が多すぎる」と批判されました。
  • Claudeはピアによって最も低いランク付けでしたが、作成者からは簡潔さで好まれました。
  • Geminiは、凝縮された処理済みの出力で高く評価されました。
  • モデルは簡潔さよりも冗長性を好む可能性があることを示唆しています。

プロジェクトの哲学

「Vibe Coded」アプローチ

  • 「99％バイブコード化」された土曜日のハックプロジェクトとして説明されています。
  • AI支援による迅速な開発
  • 作成者からの長期的なサポートコミットメントはありません。
  • 「コードは今や一時的なものであり、ライブラリは終わった」という哲学

オープンソースとインスピレーション

  • コミュニティのインスピレーションのために現状のまま提供されます。
  • ユーザーは独自のLLMを介して変更することが推奨されます。
  • AIオーケストレーションのリファレンスアーキテクチャを表します。
  • 言語モデルに適用されるアンサンブル学習を示しています。

エンタープライズへの影響

オーケストレーションミドルウェア

  • マルチモデル連携のアーキテクチャを明らかにします。
  • ベンダーロックインの懸念に対処します。
  • モデルに依存しないアプリケーションの実現可能性を示します。

品質管理レイヤー

  • ピアレビューは、単一モデルシステムにはない検証を追加します。
  • 個々のモデルのバイアスを軽減します。
  • AIの意思決定における透明性を提供します。

リファレンス実装

  • アンサンブルAIの最小限の実行可能なアーキテクチャを示します。
  • エンタープライズプラットフォームの構築対購入の意思決定をガイドします。
  • マルチモデルオーケストレーションの複雑さを解明します。

制限事項と考慮事項

コスト

  • すべての評議員と議長にOpenRouter APIクレジットが必要です。
  • クエリごとの複数モデルの呼び出しにより、運用コストが増加します。
  • 無料の運用層は利用できません。

速度

  • 3段階のプロセスは、単一モデルのクエリよりも遅くなります。
  • 複数のAPI呼び出しにより、遅延が追加されます。
  • 速度と品質/合意の間のトレードオフ

モデルの可用性

  • OpenRouterモデルカタログに依存します。
  • アクティブなAPIキーとクレジットが必要です。
  • モデルプロバイダーのレート制限の対象となります。

メンテナンス

  • 作成者は、継続的なサポートがないことを明示的に述べています。
  • コミュニティ主導の改善のみ
  • ユーザーは適応と更新に責任があります。

技術的な考慮事項

匿名化戦略

  • ランダムID（A、B、C、D）が応答に割り当てられます。
  • ピアレビューにおけるIDベースのバイアスを防ぎます。
  • 評価における客観性を維持します。

API統合

  • OpenRouterを介した単一の統合ポイント
  • 個々のプロバイダーAPIを抽象化します。
  • マルチモデル連携を簡素化します。

データプライバシー

  • ローカルWebアプリケーションは、ユーザーのマシンで実行されます。
  • 会話はJSONとしてローカルに保存されます。
  • API呼び出しはOpenRouter（サードパーティ）を通過します。

コミュニティとエコシステム

関連プロジェクト

  • Swarms Framework: このプロジェクトに触発されたLLMCouncilクラスを実装します。
  • Hugging Face Spaces: コミュニティのデプロイメントが利用可能です。
  • Medium/VentureBeat Coverage: エンタープライズ分析と影響

同様のアプローチ

  • 機械学習におけるアンサンブル学習
  • Mixture of Expertsアーキテクチャ
  • マルチエージェントAIシステム
  • 分散システムにおける合意プロトコル

今後の方向性

Karpathy氏は計画された改善がないことを明示的に述べていますが、潜在的なコミュニティ拡張には以下が含まれる可能性があります。

  • 拡張されたモデルサポート: 新興プロバイダーからのより多くの評議員の追加
  • カスタムランキング基準: ユーザー定義の評価ディメンション
  • ストリーミング応答: モデル出力のリアルタイム表示
  • 高度な統合: より洗練された議長アルゴリズム
  • コスト最適化: クエリタイプに基づいたインテリジェントなモデル選択
  • パフォーマンス分析: モデルの精度と好みパターンの追跡
  • 統合API: 他のアプリケーションへの評議会機能の埋め込み

はじめに

  1. リポジトリをクローンします：git clone https://github.com/karpathy/llm-council
  2. 上記のインストール手順に従ってください
  3. 好みの評議会モデルを構成します
  4. クエリを開始し、視点を比較します
  5. 異なるモデルの組み合わせを試してください
  6. ピアレビューパターンを分析します

結論

LLM Councilは、アンサンブルオーケストレーションを通じて単一モデルの制限に対処するための実用的なアプローチを表しています。カジュアルな週末プロジェクトとして提示されていますが、マルチモデルアーキテクチャ、ピアレビューメカニズム、およびAIオーケストレーションミドルウェアの将来に関する貴重な洞察を提供します。単一プロバイダーソリューションを超えて探求する開発者、研究者、および企業にとって、このプロジェクトは、より堅牢で合意に基づいたAIシステムを構築するためのインスピレーションと具体的なリファレンス実装の両方を提供します。

このプロジェクトのミニマリストアプローチ—洗練されたマルチモデル連携を実現する数百行のコード—は、アンサンブルAIへの技術的な障壁が多くの人が想定するよりも低いことを示しています。真の課題は、プロンプトのルーティングではなく、ガバナンス、コスト管理、および合意が個々のモデルの応答よりも実際に結果を改善する時期を判断することにあります。

Star History Chart