Po ludzku: to są różne sposoby spięcia kilku modeli AI z prawdziwym obliczeniem (solverem) - a my je MIERZYMY, żeby wybrać taki układ, który daje odpowiedź najpewniejszą i najlepszą. Krótko: pokazujemy tu, który układ daje wynik, któremu można najbardziej zaufać.
Efekt praktyczny: dzięki temu testowaniu finalne narzędzie jest pewne w swojej dziedzinie - nie zgaduje liczb, bo liczby liczy silnik, a model jedynie ubiera wynik w zrozumiałą odpowiedź. To, co poniżej (ranking, podium, karty), to dowód rygoru: jak dokładnie sprawdziliśmy, który układ wygrywa.
Każdy scenariusz ma własny graf przepływu i hipotezę, którą chcemy potwierdzić albo obalić. Różnią się tym, który model rozmawia z którym, gdzie wchodzi solver i co dokładnie weryfikujemy. Wyniki dochodzą z benchmarku - poniżej ranking pokolenia 0, aktualizowany na bieżąco.
Co tu widzisz: sprawdzaliśmy, czy jeden bardzo mocny model lokalny wystarczy zamiast całego panelu wielu modeli - i czy nadal można mu zaufać. Znaczenie praktyczne: prościej i taniej, przy tej samej pewności.
Wpięliśmy DeepSeek-V4 jako suwerenny silnik VEES (lokalnie, bez chmury) i zmierzyliśmy go naszym oraclem: kompilatorem i testami dla kodu, solverem HDD dla inżynierii. Trzy twarde liczby z nocy:
Teza: jeden bardzo mocny lokalny silnik (DeepSeek-V4) plus nasze osadzenie dorównuje złożonym panelom wielu modeli - i na kodzie, i na inżynierii. Prościej, taniej, suwerennie. Uczciwie: porównania solo kontra panel są na razie jedno-ziarnowe, a wariancja DeepSeeka to realne ± 0,03 - bez wielu ziaren na obu nie wskazujemy lepszego. Lekcja nocy: pojedyncze ziarno dawało optymistyczne 0,988, dopiero N>=3 pokazało prawdę 0,948. Mierzymy, nie zgadujemy.
Co tu widzisz: orkiestrator to warstwa sterująca, która rozdziela zadanie między modele robocze i składa odpowiedź. Sprawdziliśmy pięciu chmurowych kandydatów, każdego w trybie myślenia, po trzy razy na różnych ziarnach - kto najpewniej poprowadzi VEES. Orkiestrator decyduje o jakości całości, dlatego wybieramy go twardym pomiarem, a nie reputacją.
Oracle: kompilator + testy (twarda prawda na kodzie). SCORE = correctness + 0,3 x kompilowalność - 0,2 x wariancja - koszt. N=3 (ziarna 1000/1001/1002), wariancja zmierzona, 0 błędów chmury.
| # | Orkiestrator | Correctness | Wariancja | Latencja | SCORE |
|---|---|---|---|---|---|
| 1 | MiniMax-M2 (minimax/minimax-m2) | 100% | 0,000 | 146 s |
1,281
|
| 2 | DeepSeek-V3.2 (deepseek/deepseek-v3.2) najszybszy | 100% | 0,000 | 79 s |
1,276
|
| 3 | Qwen3-235B Thinking (qwen/qwen3-235b-a22b) | 100% | 0,000 | 100 s |
1,262
|
| 4 | Kimi-K2 Thinking (moonshotai/kimi-k2) | 100% | 0,000 | 98 s |
1,250
|
| 5 | GLM-4.7 (z-ai/glm-4.7) | 93,3% | 0,044 | 155 s |
1,161
|
Dwie lekcje, obie o pomiarze. Pierwsza: przy jednym przebiegu (N=1) prowadził GLM-4.7. Po zmierzeniu rozrzutu na trzech ziarnach GLM spadł na koniec - jako jedyny bywa niestabilny (raz na trzy razy gubi test). Druga, ważniejsza: Qwen3-235B i Kimi początkowo wypadały słabo NIE z winy modelu, tylko NASZEGO harnessu - przy ciasnym budżecie tokenów ich rozumowanie puchło i obcinało odpowiedź, zanim padł kod. Po naprawie (zapas tokenów dla modeli myślących) oba wskoczyły na perfekcyjne 100% przy zerowej wariancji. Wniosek: czterech z pięciu orkiestratorów jest bezbłędnych - o czołówce decydują już niuanse kosztu i szybkości (DeepSeek-V3.2: perfekcyjny i najszybszy). Uczciwie: słaby wynik bywa wadą stanowiska pomiarowego, nie zawodnika - dlatego zanim skreślimy model, sprawdzamy własny harness.
Co tu widzisz: tabelę wyników - który układ daje odpowiedź, której można najbardziej zaufać, a który zawodzi. Im wyżej, tym pewniej. Najważniejszy wniosek po ludzku: o jakości decyduje to, czy w układzie pracuje prawdziwe obliczenie (solver) i czy modele mają sensowne role - nie sama liczba modeli. Dlatego finalne narzędzie nie zgaduje liczb.
Podstawa statystyczna: SCORE = correctness - 0,6 x halucynacje - 0,2 x wariancja - koszt. Liczone jako średnia z wielu przebiegów przy różnych ziarnach (N >= 3 na przypadek), n to liczba przebiegów. Pokolenie 0 DOMKNIĘTE - wszystkie 12 scenariuszy policzone jednolicie, po n=18. Wniosek z danych: warianty osadzone solverem zbiegają na tę samą poprawność (0,945) - to solver dociąga je do prawdy, więc o miejscu decyduje OBECNOŚĆ solvera i sensowny przydział ról, nie sama szerokość panelu. Dwa warianty z przetasowanymi lub osłabionymi rolami (E4) załamały się - to również twardy wynik.
| # | Scenariusz | Region | Correctness | Wariancja | n | SCORE |
|---|---|---|---|---|---|---|
| 1 | Osadzony panel heterogeniczny (grounded-panel) | panel | 94,5% | 0,000 | 18 |
0,895
|
| 2 | Szerokość 1 - jeden drafter (E1_width_w1) | szerokość | 94,5% | 0,000 | 18 |
0,895
|
| 3 | Szerokość 2 - dwie rodziny (E1_width_w2) | szerokość | 94,5% | 0,000 | 18 |
0,895
|
| 4 | Szerokość 4 - cztery rodziny (E1_width_w4) | szerokość | 94,5% | 0,000 | 18 |
0,895
|
| 5 | Osadzenie - solver w środku (E3_g2_solver_middle) | osadzenie | 94,5% | 0,000 | 18 |
0,895
|
| 6 | Osadzenie - solver na wejściu (E3_g3_solver_first) | osadzenie | 94,5% | 0,000 | 18 |
0,895
|
| 7 | Role - przypisanie bazowe (E4_r1_base_assignment) | role | 94,5% | 0,000 | 18 |
0,895
|
| 8 | Solver najpierw, cienka warstwa modelu (baseline_solver_first) | baseline | 92,6% | 0,013 | 18 |
0,881
|
| 9 | Osadzenie - bez solvera (E3_g1_no_solver) | osadzenie | 87,0% | 0,023 | 18 |
0,816
|
| 10 | Goły model (bez solvera) (baseline_single) | baseline | 68,5% | 0,044 | 18 |
0,650
|
| 11 | Role - przetasowani weryfikatorzy (E4_r2_shuffled_verifiers) | role | 27,8% | 0,037 | 18 |
0,220
|
| 12 | Role - mocniejsza fizyka i inna synteza (E4_r3_strong_physics_qwen_synth) | role | 0,0% | 0,000 | 18 |
0,000
|
Pierwszy twardy wniosek (oś osadzenia, porównanie kontrolowane na wspólnym podzbiorze): solver na zadaniach ilościowych daje głównie POWTARZALNOŚĆ - ścina wariancję do zera, plus jest około 4-5x szybszy i około 2.6x tańszy w tokenach. Najsłabszy jest goły model bez żadnej obudowy.
Pobieram katalog z scenarios.json i rysuję grafy przepływu...