EN Umów prezentację

Obsigen · Pomiar · stan na 2026-10-22 · 137 raportów od 28.08

Metodologia pomiarów

Każda liczba na tej stronie ma w przypisie źródło, datę i konfigurację. Tę samą zasadę stosujemy w produkcie.

GRID uczymy na własnych scenach testowych. Dane klientów nie są używane do pomiarów ani do uczenia - są przechowywane w ich tenantach.

1371

tyle raportów pomiarowych od 28.08. Licznik i data pochodzą z repozytorium przy każdym buildzie tej strony.

1Zasada

Liczba bez źródła i daty nie istnieje. W produkcie liczby z plików, danych i stron trafiają do odpowiedzi jako komponent z odwołaniem do źródła (plik, strona, URL, data). Na tej stronie tę rolę pełnią przypisy: każdy indeks prowadzi do raportu ewaluacyjnego (nazwa i data) z konfiguracją, na której powstał wynik.

Do pomiarów i uczenia GRID - tylko własne sceny testowe. Sceny baterii, na których mierzymy modele i uczymy tabelę doboru GRID, przygotowujemy sami. Pliki, rozmowy i wyniki klientów nie trafiają do baterii, raportów ani do uczenia GRID.

Raporty są plikami w repozytorium produktu: cel, konfiguracja, wynik z rubryki, koszt biegu, co zmieniliśmy, czego nie wiemy. Pełne wersje udostępniamy w toku rozmów o wdrożeniu, po podpisaniu umowy o poufności (NDA).

2Bateria

Bateria to zestaw scen testowych, które przygotowujemy sami - z danych syntetycznych i nagrań stron publicznych (fixtures) - oceniany przez sędziego - model z rubryką, nie człowieka „na oko” - i sprawdzany przez człowieka tam, gdzie rubryka nie wystarcza.

klasaco sprawdza
K1–K10konwersacja: tożsamość, źródła, odmowy, obsługa niepewności, „armata nie strzela do dzień dobry” (K10: 6/62 - proste pytanie nie uruchamia ciężkiego trybu)
Rton: docenienie, domknięcie, sycophancy, ban-lista fraz
Ddokumenty: specyfikacje, przedmiary, rysunki CAD (Obsigen Magnify), arkusze
D-deviceto samo z plikami na urządzeniu usera (Forge, Runtime): zgody, ścieżki, undo

Licznik: 137 raportów pomiarowych1 - od pierwszego raportu baterii 28.08. Licznik i data pochodzą z repozytorium przy każdym buildzie tej strony, nie z ręki.

3Reguły decyzji

  1. Szum sędziego to 0,1–0,15 → próg 0,23. Różnica poniżej progu nie jest wynikiem - nie zmieniamy przez nią niczego.
  2. Default zmienia się tylko po dwóch sparowanych przebiegach na tych samych fixtures, z tym samym sędzią.
  3. Słaby sygnał → brak akcji destrukcyjnej. Jeśli pomiar nie rozstrzyga, zostaje stan obecny.
  4. Sesje „zero zmian” mają bramkę identyczności: refaktor musi dać ten sam wynik bajt w bajt (snapshot), inaczej nie wchodzi.
  5. Wpis bez dowodu nie jest stosowany: tabela, z której Obsigen wybiera model do zadania, przyjmuje tylko wiersze z raportem.

4Koszt i czas jako KPI

Nie „działa / nie działa”, tylko trzy liczby na turę: jakość z rubryki, koszt modelu i czas do odpowiedzi. Tryb domyślny wybieramy z tej trójki, nie z rankingu modeli. Na stronie podajemy koszt i czas względnie - kwoty i minuty są w pełnych raportach.

Jakość w baterii: Titan 18/20, model flagowy 19/20 Jakość w baterii / 20 Titan 18/20 model flagowy 19/20 Koszt tury: Titan ≈ 10, model flagowy 100 Koszt tury indeks, model flagowy = 100 Titan ≈ 10 model flagowy 100 Czas tury: Titan ≈ 24, model flagowy 100 Czas tury indeks, model flagowy = 100 Titan ≈ 24 model flagowy 100
Titan · model flagowy - 18/204 wobec 19/204 · ≈ 10× niższy koszt tury4 · ≈ 4× krótszy czas tury4

Domyślnym trybem jest Titan, nie model flagowy - bo 18/204 wobec 19/204 to jeden punkt mniej, a w zamian ≈ 10×4 niższy koszt i ≈ 4×4 krótszy czas tury.

Zużycie każdego zadania widzicie w panelu zużycia. Koszt w pomiarze to koszt modelu, nie cena dla klienta - jak rozliczamy.

wskaźnikwynikkontekst
Jakość - tryb Titan18/204orkiestracja GRID · modele open-weight
Koszt - tryb Titan≈ 10× niższy4względem modelu flagowego
Czas - tryb Titan≈ 4× krótszy4względem modelu flagowego
Model flagowy - punkt odniesienia19/204pojedynczy model, bez orkiestracji
Router - zgodność decyzji39/39 (100 %)5automatyczny dobór trybu pracy, w baterii testowej
Ton odpowiedzi3,8 → 4,8 / 56rzeczowo, bez pustych komplementów
Sycophancy (przytakiwanie)0 %6fakty zamiast aprobaty, w baterii testowej
Testy automatyczne828 testów7cała platforma

5Zdrowie dostawców

Mierzymy odsetek nieudanych wywołań (CFR) osobno dla każdego hosta, modelu i reżimu oraz osobno dla tego, co widzi użytkownik per przycisk. Progi alarmów: ≤ 10 % raw · ≤ 2 % visible8. Do tego tokeny na sekundę per dostawca - wiemy, kiedy „wolno” to dostawca, a nie my.

Fallbacki są in-family (ten sam model u innego dostawcy), a cache przy stałej głowie promptu sięga do 98 %9 na bezpośrednim połączeniu z dostawcą z EOG. Provider churn to fakt; mamy na niego mechanizm, nie nadzieję.

6Bramki inżynierskie

Refaktor kontrolera tury: 4 576 → 170 linii10 - z bramką identyczności: nagrane odpowiedzi przed i po zmianie porównane bajt w bajt w 15 scenariuszach. Testy: 828 testów7; rozszerzenie Forge osobno: 37/37 testów rozszerzenia7.

7Orkiestracja: ten sam model, z GRID i bez

Pytanie badawcze: co wnosi GRID, jeśli model jest ten sam? Pięć bardzo trudnych zadań programistycznych, trzy powtórzenia każdego, ten sam model w obu wariantach - raz samodzielnie, raz prowadzony przez GRID.

Zmierzyliśmy to - ten sam model z Obsigen GRID i bez niego

pomiar 12–13.09.2026

Czy praca w ogóle została oddana?

Przebiegi zakończone działającym wynikiem

Obsigen GRID 12 z 1511 Sam model 4 z 1511

Gdy oba warianty oddadzą wynik, ocena jest zbliżona: 19,6 vs 18,9 / 2011.

Zaliczone zadania

Bardzo trudne zadania, pełna rubryka oceny

0 25 50

Sam model 7 %11Obsigen GRID 47 %11

Koszt jednego zaliczonego zadania

Indeks: sam model = 100. Koszt modelu w pomiarze, nie cena dla klienta

Sam model10011 Obsigen GRID≈ 2611

≈ 3,9× taniej11 - choć pojedynczy przebieg z Obsigen GRID kosztuje 1,8×11 więcej.

Czas jednego przebiegu

Indeks: sam model = 100. Podajemy, bo bez tego reszta nie byłaby uczciwa

Sam model10011 Obsigen GRID≈ 19011

1,9× wolniej11 - sprawdzanie wyniku kosztuje czas.

Źródło: pomiar wewnętrzny Obsigen 12–13.09.2026 · ten sam model w obu wariantach · 5 bardzo trudnych zadań programistycznych × 3 powtórzenia (mała próba) · różnica średniej oceny: p = 0,00211. Zaliczone zadania: 7 % → 47 %11.

Różnica nie leży w tym, jak model pisze - leży w tym, czy praca dojdzie do końca. Na zadaniach łatwych istotnej różnicy nie zmierzyliśmy.

Konfiguracja pomiaru: w pełnym raporcie, udostępnianym po NDA.

Prezentacja · 45 min

Zobacz Obsigen na swoim przykładzie

Pokażemy Obsigen na dokumencie, który przyniesiecie - bez danych poufnych - na żywo, online. Potem wycena i wdrożenie na dedykowanej infrastrukturze.

Umów prezentację Porozmawiajmy

  1. krok 1Prezentacja · 45 minonline, na Waszym przykładzie
  2. krok 2Wycena na jednej stroniew ciągu dwóch dni roboczych
  3. krok 3Wdrożenie i start zespołudedykowany tenant i konta zespołu

Przypisy

  1. licznik przy buildzie · 2026-09-28 · raporty ewaluacji od 28.08
  2. testy akceptacyjne 2026-09-01 · proste pytanie nie uruchamia ciężkiego trybu
  3. metodologia pomiaru 2026-09-05 · rozrzut oceny; dwa przebiegi sparowane
  4. pomiar trybów pracy 2026-08-31 i 2026-09-02 · tryb Titan · orkiestracja GRID, modele open-weight
  5. pomiar doboru modelu 2026-09-02 · decyzje routera zgodne z oczekiwanymi; bateria testowa, pomiar wewnętrzny
  6. pomiar tonu odpowiedzi 2026-09-04/05 · 2026-09-05 · docenienie przy mniejszej liczbie pochwał
  7. raporty testów 2026-09-06/07 · 2026-09-07 · 531 backend + 256 frontend + 37 rozszerzenie + 4 hub - testy automatyczne
  8. raporty telemetrii 2026-08-29 i 2026-09-02 · alarmy dla każdego dostawcy i modelu oraz dla każdego trybu
  9. raport pamięci podręcznej 2026-09 · pamięć podręczna przy stałym początku zapytania; połączenie bezpośrednie z dostawcą w EOG
  10. przegląd kodu 2026-09-05 · kontroler tury; odpowiedzi identyczne przed i po zmianie w 15 scenariuszach
  11. raport zbiorczy 2026-09-13 · przebiegi zakończone działającym wynikiem - Obsigen GRID; 5 bardzo trudnych zadań × 3 powtórzenia, pomiar wewnętrzny