VEE to wyspecjalizowane AI inżynierskie, które w swojej dziedzinie jest dużo silniejsze i pewniejsze niż ogólny asystent z abonamentu. Zamiast jednego modelu, który zgaduje, pracuje dla Ciebie wiele umysłów AI naraz, a wynik potwierdza prawdziwe obliczenie. Dostajesz jedną odpowiedź, której można zaufać.
Pojedynczy model AI potrafi dać różne odpowiedzi przy drobnej zmianie pytania. VEE rozwiązuje to inaczej: pyta wiele modeli naraz, sprawdza ich odpowiedzi prawdziwym obliczeniem i składa z tego jedną, pewną odpowiedź.
Twoje pytanie trafia nie do jednego modelu, lecz do wielu modeli AI pracujących równolegle. Każdy podchodzi do problemu po swojemu, więc słabe i przypadkowe odpowiedzi od razu się ujawniają.
VEE zestawia propozycje modeli i sprawdza je deterministycznym solverem oraz normami ze źródła. Liczby liczy silnik obliczeniowy, a nie zgaduje model. To odcina halucynacje.
Na wyjściu dostajesz jedną, zweryfikowaną odpowiedź wraz ze śladem, czym dokładnie została policzona. Nie kilka sprzecznych wariantów do oceny, lecz wynik, któremu można zaufać.
VEE jest pomyślane dla profesjonalisty, który podejmuje decyzje na podstawie wyników i nie może pozwolić sobie na zgadywanie. Dziś pierwszym obszarem jest wiertnictwo i przewierty HDD; docelowo to ogólnoinżynierski ekspert w walizce.
Pytanie wchodzi z zewnątrz, orkiestrator rozdziela je między drafterów, deterministyczny solver liczy prawdę, weryfikatorzy sprawdzają, a synteza odsyła odpowiedź ze śladem - cała maszyneria zamknięta w jednej maszynie.
VEE to nie czat z modelem. To zamknięty, suwerenny silnik ekspercki: na jednej maszynie żyje orkiestrator klasy Kimi (replikacja Abiego), a pod nim rój modeli roboczych. Orkiestrator rozkłada zadanie, rozdziela je w roju, a prawdę bierze z deterministycznego solvera i ze źródeł - nie z „pamięci" modelu.
Orkiestrator definiuje zadanie → rój modeli rozumuje równolegle → solver liczy → weryfikator powtarza obliczenie → strażnik wyrzuca każdą liczbę bez pokrycia. Na wyjściu: odpowiedź eksperta z pełnym śladem, czym dokładnie została policzona. Całość w jednej obudowie - model klienta nie opuszcza jego maszyny.
To jest „moat" Enginetrica: anti-halucynacja jako produkt klasy Enterprise. Audytowalność i suwerenność, których czyste modele językowe nie dają.
Wszystko zamknięte w jednej obudowie - od warstwy rozumowania, przez rój, po uziemienie w prawdzie.
Każda konfiguracja to inny sposób spięcia roju i narzędzi. Testujemy je po kolei i mierzymy, czy realnie podnoszą jakość - czy tylko spalają moc.
Drafter → weryfikator → strażnik na jednym modelu (qwen3.6:35b-a3b) - trzy system-prompty, łańcuch szeregowy. Strażnik realnie koryguje draft.
RdzeńN drafterów liczy niezależnie, bierzemy medianę liczb. Tłumi pojedyncze wpadki - ale nie naprawia błędu wspólnego dla wszystkich.
GłosowanieRole przełączone na programistyczne (autor → reviewer → integrator), głosowanie wyłączone. Produkuje kompletny, uruchamialny kod - nie urywki.
Zweryfikowany ✓Rój nie zgaduje fizyki - woła deterministyczny solver Rust: frac-out, hydraulika, balastowanie, dopasowania reologiczne. Każdy wynik ze śladem.
Działa ✓Każda norma/wartość tablicowa cytowana ze źródła z korpusu, zamiast „pamięci" modelu. Następny element uziemienia.
W budowieMocniejszy sprzęt → więcej instancji → warstwy równoległe biegną naprawdę równolegle, orkiestrator rozdziela zadania na wolne modele.
RoadmapJednostka mocy to jeden Blackwell - 96 GB pamięci karty (nasz dzisiejszy węzeł). Im więcej kart, tym więcej różnych rodzin modeli pracuje NAPRAWDĘ równolegle i tym większy orkiestrator stać nas utrzymać na własnym sprzęcie, bez chmury. Trzy rozwiązania teoretyczne - poprawność na każdym z nich pilnuje ten sam solver.
Solista uziemiony. Jeden mocny model (qwen3.6:35b-a3b) niesie cały łańcuch, różnorodność dokładają 1-2 mniejsze rodziny, a poprawność dźwiga solver.
Dowód: solista + solver = 0,945 na inżynierii HDD - parytet z całym panelem. Suwerennie i tanio na jednej karcie.
Zmierzone ✓Rada heterogeniczna. Rój rozbity po rolach na dwie karty: drafterzy i synteza na jednej, trzy soczewki weryfikacji (Gemma + Mistral + Phi) na drugiej.
Zysk: panel weryfikatorów biegnie realnie równolegle, różne rodziny naraz - lekarstwo na skorelowane błędy. To pełny rada-solver na sprzęcie.
ProjektVEE pełny. Stać nas na duży orkiestrator klasy Kimi na WŁASNYM węźle (NVFP4) + osobna pamięć na drafterów i weryfikatorów + router + obsługa wielu zapytań naraz.
Zysk: koniec zależności od chmury, dane nie wychodzą z maszyny. Docelowe „jedna maszyna, zamknięte modele, jeden orkiestrator".
CelZasada wspólna Na każdym tierze silnik LICZY, AI ubiera - liczby zawsze z solvera, nigdy z „pamięci" modelu. Throughput i jakość NVFP4 to teoria do zmierzenia baterią, nie obietnica.
Każda topologia to inny pomysł na to, który model rozmawia z którym i po co. Testujemy je po kolei na tej samej baterii pytań i wybieramy najlepszą pod HDDSuite - tę, która najpewniej łapie błąd i najmocniej kotwiczy się w prawdzie solvera.
Spięcie: 3 drafterzy różnych rodzin równolegle (qwen3.6 + gemma4:31b + mistral) -> SOLVER -> 3 weryfikatorzy o różnych soczewkach (phi4 jednostki + gemma4:26b fizyka + qwen-coder wzór) -> synteza gpt-oss.
Dlaczego: Różnorodność rodzin rozbija skorelowane błędy, solver dokłada prawdę. Live: panel złapał niebezpieczny błąd jednego modelu.
Zrobione i przetestowane ✓Spięcie: 1 mocny drafter (gemma4:31b) -> SOLVER -> szeregowy łańcuch weryfikatorów (qwen-coder -> gemma4:26b -> qwen3.6), każdy widzi poprawki poprzednika -> synteza.
Dlaczego: Sekwencyjne pogłębianie zamiast równoległego rozproszenia. Mniej modeli, więcej przejść. Test: czy głębia bije szerokość.
Do testówSpięcie: SOLVER liczy najpierw -> jeden model ubiera wynik w prozę -> jeden weryfikator sprawdza zgodność ze solverem.
Dlaczego: Dla pytań ilościowych: minimalny model, maksymalny solver. Najszybsze i najmocniej zakotwiczone w prawdzie. Czysta forma „silnik LICZY, AI ubiera".
Do testówSpięcie: N drafterów różnych rodzin rozwiązuje niezależnie -> solver jako arbiter liczb -> panel sędziów ocenia każdą całość -> wybór NAJLEPSZEJ + zaszczepienie najlepszych fragmentów.
Dlaczego: Selekcja najlepszej odpowiedzi zamiast uśredniania. Wybrałby model poprawny zamiast mieszać go z błędnym.
Do testówT5 · Router (później): orkiestrator klasyfikuje pytanie i kieruje do najlepszej sub-topologii - najbardziej „VEE".
Tu trzymamy werdykty. Nie „wydaje się" - tylko zmierzone. Zakładki pokazują kolejne testy i to, czy dany kierunek potwierdził się, czy upadł.
Jakości nie da się dołożyć liczbą modeli. Model ręczący za model nie naprawia wspólnego błędu, a głosowanie nie pomaga. Trzeba dołożyć prawdę spoza modelu - solver i retrieval.
Przy generacji kodu z dobrą specyfikacją drafter ma mniej miejsca na konfabulację, a reviewer łapie realne bugi. Wniosek: rój jest mocny tam, gdzie zadanie jest jednoznaczne - i tam ma odciążać.
VEE jest w testach. Ta strona aktualizuje się przy każdym kroku: nowa konfiguracja, nowy benchmark, nowy werdykt - dobra koncepcja czy ślepa uliczka. Bez upiększania, z liczbami.
Most do solvera działa. Następne: solver jako rola „POLICZ" w łańcuchu, retrieval norm, benchmark v2 z twardym progiem, dobór orkiestratora.