Enginetric · projekt w testach

VEE — Virtual Enginetric Expert

Suwerenny silnik ekspercki klasy Enterprise. Jedna maszyna, modele zamknięte w środku, jeden orkiestrator dyrygujący rojem — uziemiony deterministycznym solverem i retrievalem. Dane nie wychodzą na zewnątrz.

QQQQQQQ SOLVER ∑ RETRIEVAL VEE orkiestrator
1 maszyna
modele zamknięte lokalnie
Orkiestrator
klasy Kimi (replikacja Abiego)
1
orkiestrator dyrygujący całością
≤ kilkanaście
modeli roboczych w roju
100%
lokalnie — dane nie wychodzą
ślad
pod każdą liczbą
Koncept

Jeden ekspert, w środku rój

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.

Silnik LICZY, AI ubiera.

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.

Każda liczba ma ślad do solvera, każda norma — do źródła.

To jest „moat" Enginetrica: anti-halucynacja jako produkt klasy Enterprise. Audytowalność i suwerenność, których czyste modele językowe nie dają.

Architektura

Warstwy jednej maszyny

Wszystko zamknięte w jednej obudowie — od warstwy rozumowania, przez rój, po uziemienie w prawdzie.

  • 1Orkiestrator (klasa Kimi). Replikacja Abiego — warstwa kontrolna. Rozumie zadanie, planuje, rozdziela pracę, robi finalne QA i pilnuje fortecy. To z nim „rozmawia" użytkownik.
  • 2Rój modeli roboczych (do kilkunastu). Qweny lub pokrewne — drafterzy, weryfikatorzy, strażnicy. Liczą równolegle, głosują, kontrują się nawzajem.
  • 3Uziemienie w prawdzie. Deterministyczny solver (Rust HDDSuite) liczy fizykę, retrieval podaje normy ze źródła. Tu rodzi się fakt, nie w modelu.
  • 4Suwerenność. Jedna maszyna, modele i dane zamknięte lokalnie. Nic nie wychodzi na zewnątrz — naturalne dla zastosowań Enterprise.
JEDNA SUWERENNA MASZYNA ORKIESTRATOR · VEE klasa Kimi — replikacja Abiego RÓJ MODELI ROBOCZYCH QQQQQ SOLVER ∑ deterministyczna fizyka RETRIEVAL normy ze źródła
Konfiguracje

Układy, które uruchamiamy i badamy

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.

Łańcuch 3 ról

Drafter → weryfikator → strażnik na jednym modelu (qwen3.6:35b-a3b) — trzy system-prompty, łańcuch szeregowy. Strażnik realnie koryguje draft.

Rdzeń

Self-consistency

N drafterów liczy niezależnie, bierzemy medianę liczb. Tłumi pojedyncze wpadki — ale nie naprawia błędu wspólnego dla wszystkich.

Głosowanie
⟨/⟩

Tryb kodowy

Role przełączone na programistyczne (autor → reviewer → integrator), głosowanie wyłączone. Produkuje kompletny, uruchamialny kod — nie urywki.

Zweryfikowany ✓

Most do solvera

Rój nie zgaduje fizyki — woła deterministyczny solver Rust: frac-out, hydraulika, balastowanie, dopasowania reologiczne. Każdy wynik ze śladem.

Działa ✓
📚

Retrieval norm

Każda norma/wartość tablicowa cytowana ze źródła z korpusu, zamiast „pamięci" modelu. Następny element uziemienia.

W budowie

Skalowanie roju

Mocniejszy sprzęt → więcej instancji → warstwy równoległe biegną naprawdę równolegle, orkiestrator rozdziela zadania na wolne modele.

Roadmap
Testy — dobra czy zła koncepcja?

Co dziś wiemy z twardych liczb

Tu trzymamy werdykty. Nie „wydaje się" — tylko zmierzone. Zakładki pokazują kolejne testy i to, czy dany kierunek potwierdził się, czy upadł.

✓ Koncepcja potwierdzona

Most rój → solver działa

Rój przestaje zgadywać fizykę — woła deterministyczny solver Rust. Zamiast liczby z modelu: liczba z kodu, ze śladem.
frac-out (przebicie)
OK
hydraulika rury
OK
walidacja braków
OK
obsługa błędu
OK
Testy mostu: 4/4 zaliczone. To zwrot z benchmarku v1 — zamiast „więcej modeli", prawda spoza modelu.

Realne liczby z solvera

Nie z modelu — z deterministycznego kodu.
Frac-out — ratio1.12
Frac-out — p_frac0.084 MPa
Frac-out — margines−0.010
Hydraulika — ΔP1.574 bar
Hydraulika — moc pompy3.15 kW
determinizmślad pod liczbąrola „POLICZ"
~ Poniżej progu — kierunek do zmiany

Rój vs pojedynczy model

Rubryka 8 pytań (wiertnictwo / reologia / mikrotunelowanie), skala 0–96. Próg sukcesu z góry: +6 nad baseline.
Pojedynczy model
81
VEE (rój)
próg 87
85
Rój dał +4 (85 vs 81), a próg wynosił +6 (87). Do tego na czystym teście odporności pojawiła się regresja — strażnik wkleił zmyśloną normę.
✗ Sam rój nie wystarcza

Twardy wniosek

Najważniejsza lekcja całego projektu.

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.

To dlatego zbudowaliśmy most do solvera. Benchmark v2 sprawdzi rój z solverem — próg: brak halucynacji rośnie ORAZ ΔSuma ≥ +6.
✓ Działa na jasnej specyfikacji

Produkcja kodu trybem --code

Zadanie: samodzielny kalkulator HTML (siły przeciskowe mikrotunelowania). Sprawdzian: czy rój złapie, że siła od długości jest LINIOWA, nie wykładnicza.
Kompletny kod
Fizyka poprawna
Bez pułapki wykł.
Pierwszy strzał
Rój (~36 s) wyprodukował 281 linii używalnego HTML ze wzorem liniowym F = F_czoło + μ·π·D·L·σ — tam, gdzie benchmark Q&A poległ.

Dlaczego tu poszło lepiej

Inny obraz niż Q&A (+4 < próg).

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ć.

jasna specreviewer = realny zyskbez iteracji
Kierunek: uziemienie w prawdzie

Co potwierdziły testy — w jednym miejscu

Stan na dziś, bez upiększania.
⌬ Sam rój modeli (więcej głosów / ról)✗ za mało
⟨/⟩ Tryb kodowy na jasnej spec✓ dobra
⚙ Most do deterministycznego solvera✓ dobra
📚 Retrieval norm ze źródła~ w budowie
⇶ Skalowanie na więcej instancji~ roadmap
Sedno: wartość nie rodzi się z liczby modeli, tylko z prawdy spoza modelu. Dlatego ciężar VEE jest na uziemieniu — solver i retrieval jako źródła faktu, rój jako warstwa rozumowania, orkiestrator jako kontrola.

To dziennik drogi do super-eksperta.

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.

Faza 1 — pre-alfa

Most do solvera działa. Następne: solver jako rola „POLICZ" w łańcuchu, retrieval norm, benchmark v2 z twardym progiem, dobór orkiestratora.