LLM Council - 多模型 AI 協作平台

項目概述

LLM Council 是一個由 Andrej Karpathy 創建的創新開源項目，它將單模型 AI 互動轉變為協作、多模型共識系統。此工具不依賴單一 LLM 提供者，而是協調多個前沿 AI 模型協同工作、互相審查彼此的輸出，並透過民主程序產生綜合的回應。

核心概念

LLM Council 背後的基本理念是利用不同 AI 模型的優勢，同時最大限度地減少個別模型的偏見。透過創建一個「AI 顧問委員會」，使用者可以獲得更全面、經過同儕審查的複雜問題答案，而不是依賴單一模型的觀點。

架構與工作流程

三階段流程

階段 1：第一意見

• 使用者查詢透過 OpenRouter API 同時發送到所有委員會成員模型
• 每個 LLM 產生其獨立的回應，而無需查看其他模型的輸出
• 個別回應顯示在標籤視圖中，以便進行並排比較
• 預設委員會成員包括：GPT-5.1、Gemini 3.0 Pro、Claude Sonnet 4.5 和 Grok 4

階段 2：匿名同儕審查

• 每個模型都會收到來自所有其他委員會成員的匿名回應
• 模型根據準確性和洞察力評估並排名每個回應
• 身份匿名化可防止評估中的偏見和偏袒
• 跨模型評估揭示了令人驚訝的模式（模型通常將競爭對手排名更高）

階段 3：主席綜合

• 指定的主席 LLM（可配置）審查所有原始回應
• 考慮同儕審查排名和評估
• 產生最終的綜合答案，其中包含最佳元素
• 向使用者提供全面的回應

技術堆疊

後端

• 框架：FastAPI (Python 3.10+)
• HTTP 客戶端：用於非阻塞 API 呼叫的 async httpx
• API 整合：用於多模型存取的 OpenRouter API
• 儲存：基於 JSON 的對話持久性，位於 data/conversations/ 中
• 套件管理：用於現代 Python 依賴管理的 uv

前端

• 框架：使用 Vite 的 React，用於快速開發和建置
• 渲染：用於格式化輸出的 react-markdown
• UI：類似 ChatGPT 的介面，帶有標籤視圖，用於模型比較
• 開發伺服器：Vite 開發伺服器，位於埠 5173 上

主要功能

多模型分派

• 跨多個前沿模型同時執行查詢
• 可透過 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

2. 在 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% vibe coded」的星期六駭客專案
• 在 AI 協助下快速開發
• 創作者不承諾長期支援
• 「程式碼現在是短暫的，而函式庫已經結束」的哲學

開源與靈感

• 按原樣提供，以供社群靈感
• 鼓勵使用者透過自己的 LLM 進行修改
• 代表 AI 編排的參考架構
• 演示了應用於語言模型的集成學習

企業影響

編排中介軟體

• 揭示了多模型協調的架構
• 解決了供應商鎖定的問題
• 證明了模型不可知應用程式的可行性

品質控制層

• 同儕審查增加了單模型系統中沒有的驗證
• 減少了個別模型的偏見
• 提供了 AI 決策的透明度

參考實作

• 顯示了集成 AI 的最小可行架構
• 指導企業平台的建置與購買決策
• 解釋了多模型編排的複雜性

限制與考量

成本

• 需要 OpenRouter API 點數才能用於所有委員會成員和主席
• 每個查詢的多個模型呼叫會增加營運成本
• 沒有可用的免費層級操作

速度

• 三階段流程比單模型查詢慢
• 多個 API 呼叫會增加延遲
• 速度與品質/共識之間的權衡

模型可用性

• 依賴於 OpenRouter 模型目錄
• 需要有效的 API 金鑰和點數
• 受模型提供者速率限制的約束

維護

• 創作者明確表示不提供持續支援
• 僅限社群驅動的改進
• 使用者負責調整和更新

技術考量

匿名化策略

• 將隨機 ID (A, B, C, D) 分配給回應
• 防止同儕審查中基於身份的偏見
• 維持評估的客觀性

API 整合

• 透過 OpenRouter 的單一整合點
• 抽象化個別提供者 API
• 簡化多模型協調

資料隱私

• 本機 Web 應用程式在使用者機器上執行
• 對話以 JSON 格式儲存在本機
• API 呼叫透過 OpenRouter（第三方）進行

社群與生態系統

相關專案

• Swarms Framework：實作了受此專案啟發的 LLMCouncil 類別
• Hugging Face Spaces：提供社群部署
• Medium/VentureBeat 報導：企業分析和影響

類似方法

• 機器學習中的集成學習
• 專家混合架構
• 多代理 AI 系統
• 分散式系統中的共識協定

未來方向

雖然 Karpathy 明確表示沒有計劃進行改進，但潛在的社群擴展可能包括：

• 擴展模型支援：新增來自新興提供者的更多委員會成員
• 自訂排名標準：使用者定義的評估維度
• 串流回應：即時顯示模型輸出
• 進階綜合：更複雜的主席演算法
• 成本最佳化：基於查詢類型智慧選擇模型
• 效能分析：追蹤模型準確性和偏好模式
• 整合 API：將委員會功能嵌入到其他應用程式中

開始使用

1. 克隆儲存庫：git clone https://github.com/karpathy/llm-council
2. 按照上面的安裝說明進行操作
3. 配置您偏好的委員會模型
4. 開始查詢並比較觀點
5. 嘗試不同的模型組合
6. 分析同儕審查模式

結論

LLM Council 代表了一種透過集成編排解決單模型限制的務實方法。雖然它被呈現為一個隨意的週末專案，但它提供了對多模型架構、同儕審查機制以及 AI 編排中介軟體的未來有價值的見解。對於探索單一提供者解決方案之外的開發人員、研究人員和企業來說，該專案既提供了靈感，又為建構更強大、共識驅動的 AI 系統提供了具體的參考實作。

該專案的極簡方法——幾百行程式碼實現了複雜的多模型協調——表明集成 AI 的技術障礙低於許多人假設的。真正的挑戰不在於路由提示，而在於治理、成本管理以及確定共識是否真正改善了個別模型回應的結果。