Kolejna „rewolucja”, która ma uratować nas przed bzdurami generowanymi przez sztuczną inteligencję – tym razem poprzez zmuszenie modeli do wzajemnego pilnowania się. LLM Council to technika, w której kilka modeli debatuje nad odpowiedzią, zamiast bezrefleksyjnie rzucać pierwszym lepszym faktem. Według zapewnień to koniec ery halucynacji, ale w rzeczywistości to raczej kosztowny komitet kolejkowy, w którym każdy ma swoje zdanie, a rachunek za tokeny i tak płacisz Ty.
Czym jest LLM Council i dlaczego w ogóle powstał?
W świecie idealnym Twój asystent AI zawsze mówi prawdę. W świecie realnym GPT, Claude czy Gemini potrafią z kamienną twarzą kłamać na temat daty bitwy pod Grunwaldem. LLM Council (znany również jako Multi-Model Voting) to próba naprawienia tego problemu za pomocą starej jak świat zasady: co dwie (lub trzy) głowy, to nie jedna.
LLM Council to open-source’owy projekt, który zamiast pytać jeden model, pyta kilka naraz. Konkretnie: wysyła Twoje zapytanie do GPT, Claude Sonnet, Gemini Pro i Groka (lub dowolnej innej kombinacji modeli dostępnych przez OpenRouter API). Każdy model odpowiada niezależnie, bez wiedzy, co napisali inni. Potem – i tutaj zaczyna się magia – wszystkie modele dostają anonimowe odpowiedzi swoich „konkurentów” i muszą je ocenić jak recenzenci naukowi. Na końcu model „przewodniczący” (np. Gemini Pro) zbiera wszystkie odpowiedzi, ranking i kompiluje ostateczną, zsyntetyzowaną odpowiedź.
Brzmi jak science fiction? To działający kod na GitHubie, napisany w weekend, głównie przez AI assistants. Karpathy nazywa to „vibe code project” i szczerze mówi: „Nie zamierzam tego w żaden sposób wspierać”. Ale mimo tego disclaimer’a LLM Council zebrał ponad 3 tysiące gwiazdek na GitHubie w kilka tygodni i wywołał niemałe dyskusje.
Jak to działa? Trzy etapy demokratycznej rewolucji AI
Stage 1: Initial Response – każdy model na swoim torze
Twoje pytanie trafia równolegle do wszystkich modeli w „radzie”. GPT odpowiada po swojemu. Claude Sonnet 4.5 idzie w innym kierunku. Gemini ma własny flow. Grok dorzuca swoją perspektywę. Kluczowe: żaden model nie widzi, co napisali inni. Zero myślenia stadnego na starcie. To zapobiega sytuacji, w której jeden model dominuje narrację i reszta tylko przytakuje.
Stage 2: Recenzja koleżeńska – modele oceniają się nawzajem
Teraz zaczyna się prawdziwa zabawa. System anonimizuje wszystkie odpowiedzi (usuwa nazwę modelu) i wysyła je z powrotem do wszystkich uczestników. Każdy model dostaje prompt: „Przeczytaj te cztery odpowiedzi i uszereguj je od najlepszej do najgorszej, biorąc pod uwagę logikę, poprawność i użyteczność”. Modele głosują. Niektóre są brutalne w swojej krytyce. Inne są bardziej dyplomatyczne. Ale wszyscy muszą wystawić ranking.
Stage 3: Final Synthesis – przewodniczący zbiera głosy
Na końcu wchodzi model „przewodniczący” – Karpathy sugeruje Gemini Pro lub GPT-5.1, ale możesz wybrać dowolny. Przewodniczący dostaje: oryginalne pytanie, wszystkie odpowiedzi z Stage 1 i wszystkie rankingi z Stage 2. Jego zadanie: zsyntetyzować to wszystko w jedną, spójną, ostateczną odpowiedź, która uwzględnia najlepsze elementy z każdej perspektywy. To nie jest zwykłe uśrednianie, a synteza, która powinna być lepsza niż jakakolwiek pojedyncza odpowiedź.
Kto powinien się tym przejmować?
LLM Council to nie narzędzie dla każdego. To nie jest ChatGPT, który możesz otworzyć i użyć za darmo. To narzędzie dla konkretnej grupy ludzi, którzy mają konkretne problemy.
- Deweloperzy i inżynierowie AI, którzy męczą się z wyborem „najlepszego” modelu do danego zadania, nagle mają sposób, żeby testować wszystkie naraz. Zamiast iterować między modelami ręcznie, mogą wysłać prompt i zobaczyć, jak każdy model podchodzi do problemu – plus dostać zsyntetyzowaną odpowiedź, która łączy mocne strony wszystkich.
- Enterprise AI teams, które budują systemy wymagające wysokiej wiarygodności (code review, analiza ryzyka, strategic planning), mogą używać LLM Council jako warstwy konsensusu. Jeśli cztery różne modele dochodzą do podobnych wniosków, prawdopodobieństwo halucynacji spada. Jeśli modele się drastycznie różnią – to sygnał, że problem jest bardziej skomplikowany niż myślałeś.
- Twórcy aplikacji opartych na LLM, którzy chcą budować działające chatboty, aplikacje do robienia reaserchu czy tworzenia treści. Multi-model może być świetnym backendem dla aplikacji, które nie mogą sobie pozwolić na błędy.
- I oczywiście wyznawcy Karpathy’ego – ludzie, którzy wiedzą, że jeśli Andrej coś publikuje, to warto przynajmniej sprawdzić. Bo nawet jeśli to „tylko weekend hack”, jest w tym jakaś mądrość, którą można zaaplikować gdzie indziej.
Reality Check: dlaczego nie wszyscy używają tego od jutra?
OK, czas na trzeźwe spojrzenie. Bo LLM Council brzmi fantastycznie na papierze, ale ma kilka fundamentalnych problemów, które sprawiają, że to nie jest silver bullet.
Koszty API: Twój portfel płacze
Każde zapytanie w LLM Council to minimum trzy do pięciu wywołań API. Stage 1: cztery modele odpowiadają (4x API call). Stage 2: cztery modele oceniają odpowiedzi (4x API call). Stage 3: przewodniczący syntetyzuje (1x API call). To dziewięć API calls na jedno pytanie. Jeśli używasz premium model, Twoje koszty rosną eksploracyjnie. W praktyce jedno „proste” pytanie w LLM Council może kosztować $0.50-$2.00, w zależności od długości promptu i odpowiedzi. Dla porównania: jedno zapytanie do GPT-4 Turbo bezpośrednio to około $0.01-$0.05.
Według zapewnień entuzjastów – „warto za jakość”. Ale jeśli robisz 100 zapytań dziennie, Twój miesięczny rachunek z OpenRouter urośnie do $3,000-$6,000. To nie jest zabawka dla freelancerów z budżetem $50/miesiąc.
Latencja: Czas to pieniądz (i frustracja użytkownika)
Single model query: 2-5 sekund. LLM Council: 15-30 sekund (a czasem więcej, jeśli jeden z modeli jest pod obciążeniem). To 3-5x wydłużenie czasu odpowiedzi. W produkcyjnych aplikacjach, gdzie liczy się real-time UX (chatboty, assistants, live Q&A), to może być dealbreaker. Nikt nie będzie czekał pół minuty na odpowiedź, jeśli GPT daje mu coś sensownego w 3 sekundy.
„Demokratyczny konsensus” nie znaczy „prawda”
Tutaj wchodzimy w filozoficzny problem metod zespołowych. Jeśli większość modeli halucynuje w tym samym kierunku (bo wszystkie były trenowane na podobnych danych, z podobnymi biasami), konsensus tylko wzmacnia błąd.
Przewodniczący może być równie uprzedzony jak indywidualne modele. Jeśli Gemini (jako przewodniczący) preferuje określone style myślenia, będzie faworyzował odpowiedzi zgodne z tym podejściem – nawet jeśli inne modele miały rację.
Vibe Code = No Support = Musisz być technicznie biegły
Karpathy jasno mówi: „I’m not going to support it in any way”. To eksperyment, nie produkt. Co to oznacza w praktyce? Dane leżą w zwykłych JSONach na dysku. Nie ma logowania użytkowników – kto znajdzie twój endpoint, ten używa twojego API key. Nie zobaczysz na bieżąco, ile właśnie spalasz na API callach. A jak jeden model się zawiesi? Cała operacja idzie w diabły.
Kiedy to ma sens, a kiedy to overkill?
Nie ma co pudrować rzeczywistości: LLM Council to narzędzie niszowe. W większości przypadków jeden dobrze sprofilowany model wystarczy, ale istnieją scenariusze, gdzie wielomodelowa weryfikacja faktycznie zrobi robotę.
Scenariusze, w których warto dopłacić:
- Synteza strategii i złożone analizy: gdy pytasz o optymalną strategię SEO na 2026 rok dla e-commerce, pojedynczy model zazwyczaj faworyzuje jedną metodę (np. tylko techniczne aspekty). LLM Council pozwala na równoległe wygenerowanie podejść skoncentrowanych na content marketingu, UX oraz danych strukturalnych. Finalna odpowiedź jest agregatem tych perspektyw, co daje znacznie szerszy horyzont planowania.
- Wielopoziomowe Code Review: różne architektury wykazują odmienną czułość na konkretne problemy w kodzie. Jeden model lepiej radzi sobie z logiką biznesową, inny szybciej wyłapie podatności na ataki lub nieoptymalne zarządzanie pamięcią. Zespół modeli dostarcza kompletny raport z audytu, którego pojedyncza instancja mogłaby nie „dowieźć”.
- Minimalizacja biasu (uprzedzeń): każdy model ma swoje skrzywienia wynikające z wag i zestawów treningowych. Przy procesach krytycznych, takich jak automatyczny screening CV czy systemy scoringowe, konsensus kilku modeli od różnych dostawców działa jak bezpiecznik, ograniczając ryzyko jednostronnej, błędnej decyzji.
Kiedy to czysta strata zasobów?
- Pytania o fakty: jeśli chcesz wiedzieć, kto wygrał Mundial w 2022 roku, zwoływanie „rady” jest absurdalne. Jeden model połączony z mechanizmem RAG poda poprawną informację szybciej i taniej niż proces głosowania czterech agentów.
- Proste zadania definicyjne: wyjaśnienie pojęcia rekurencji nie wymaga recenzji koleżeńskiej. To zadanie deterministyczne, z którym radzą sobie nawet mniejsze, tańsze modele typu Llama 3.
- Systemy czasu rzeczywistego: LLM Council generuje potężną latencję. Jeśli Twój system musi odpowiadać w czasie poniżej 2 sekund, proces przesyłania promptu do kilku API i późniejsza analiza wyników przez sędziego po prostu zabiją UX.
- Ograniczony budżet: matematyka jest nieubłagana. Uruchomienie trzech modeli to trzykrotnie wyższe koszty za tokeny. Jeśli Twój budżet na API zamyka się w okolicach 400 PLN miesięcznie, LLM Council spali go w kilka dni, nie oferując w zamian proporcjonalnego skoku jakości.
Źródła:
- GitHub – karpathy/llm-council: https://github.com/karpathy/llm-council
- Analytics Vidhya – LLM Council: Andrej Karpathy’s AI for Reliable Answers: https://www.analyticsvidhya.com/blog/2025/12/llm-council-by-andrej-karpathy/
- VirtusLab Blog – llm-council: AI Consensus mechanism: https://virtuslab.com/blog/ai/llm-council/
