Stworzenie powtarzalnego środowiska do testowania modeli

Pozwala porównywać modele pod kątem programowania, debugowania, code review, bezpieczeństwa, analizy logów, pracy wieloplikowej, halucynacji i wydajności.

user_key=u9szqu1u46grcd9h4n2h3fbwdbdg8d
api_token=annxgv9ykefxjhscngkxbeyjx1vu2y
mail_haslo=TajneHaslo13.


Zbuduj na tym komputerze kompletne, trwałe i rozszerzalne środowisko benchmarkowe do porównywania modeli AI używanych przeze mnie do:

* pisania kodu,
* naprawiania błędów,
* refaktoryzacji,
* code review,
* analizy istniejącego kodu,
* testowania,
* analiz bezpieczeństwa,
* audytów kodu,
* audytów konfiguracji,
* analizy logów,
* diagnozowania problemów,
* pracy wieloplikowej i pracy na repozytorium.

Benchmark ma być przygotowany RAZ, następnie zamrożony.

NIE uruchamiaj automatycznie wszystkich modeli po skonfigurowaniu środowiska.

Poszczególne modele będę uruchamiał później, kiedy będę chciał.

Przykładowo jednego dnia:

"Uruchom test qwen3-coder:30b"

innego dnia:

"Uruchom test Claudem Sonnet"

jeszcze później:

"Uruchom test Codexem"

a za kilka miesięcy:

"Dodaj model XYZ i uruchom na nim benchmark."

Wszystkie modele muszą wykonywać TEN SAM zamrożony zestaw zadań.

================================================================

1. GŁÓWNY CEL
   ================================================================

Chcę odpowiedzieć na praktyczne pytanie:

"Czy ten model nadaje się do mojej codziennej pracy programistycznej, analiz kodu i audytów?"

Nie interesuje mnie wyłącznie szybkość generowania tekstu.

Najważniejsze są:

1. poprawność kodu,
2. zdolność rozumienia istniejącego projektu,
3. zdolność znalezienia błędu,
4. zdolność naprawienia błędu bez regresji,
5. jakość code review,
6. jakość analizy bezpieczeństwa,
7. liczba false positives,
8. umiejętność rozróżnienia faktów od hipotez,
9. zdolność pracy wieloplikowej,
10. jakość testów,
11. jakość refaktoryzacji,
12. analiza logów i konfiguracji,
13. przestrzeganie instrukcji,
14. brak halucynowania,
15. dopiero później szybkość i wymagania sprzętowe.

================================================================
2. MÓJ KOMPUTER
===============

Aktualny komputer:

CPU:
Intel Core i7-12700K

GPU:
NVIDIA GeForce RTX 4060 Ti

VRAM:
16 GB / około 16380 MiB

RAM:
32 GB

System:
Windows

Nie przyjmuj jednak tych danych bezkrytycznie.

Przy każdym RUN samodzielnie zinwentaryzuj sprzęt i zapisz aktualny stan.

================================================================
3. KATALOG PROJEKTU
===================

Domyślnie:

C:\ai-benchmark

Jeśli C: nie ma odpowiednio dużo wolnego miejsca, wybierz lokalny dysk z największą ilością miejsca.

Zapisz faktyczną ścieżkę projektu w konfiguracji.

Nie używaj dysku sieciowego.

================================================================
4. ARCHITEKTURA BENCHMARKU
==========================

Oddziel wyraźnie:

A. BENCHMARK DEFINITION

od:

B. MODEL/PROVIDER

od:

C. RUN RESULTS

Przykładowa struktura:

ai-benchmark
│
├── benchmark_definition
│   ├── VERSION
│   ├── BENCHMARK_SHA256.txt
│   ├── repo.lock.json
│   ├── prompts
│   ├── fixtures
│   ├── mutations
│   ├── expected
│   └── manifests
│
├── benchmark_private
│   ├── ground_truth
│   └── validators
│
├── providers
│   ├── ollama
│   ├── claude
│   └── codex
│
├── config
│   ├── models.json
│   ├── providers.json
│   └── benchmark.json
│
├── results
│
├── workspaces
│
├── scripts
│
├── AGENTS.md
├── CLAUDE.md
├── BENCHMARK_INSTRUCTIONS.md
├── README_PL.md
└── run_benchmark.ps1

Ground truth NIE może być przekazywany testowanemu modelowi.

================================================================
5. BENCHMARK MA BYĆ NIEZMIENNY
==============================

Po przygotowaniu benchmarku zamroź:

* wszystkie prompty,
* snapshot repozytorium,
* SHA repozytorium,
* fixtures,
* controlled bugs,
* konfiguracje testowe,
* logi testowe,
* pliki konfiguracyjne,
* expected outputs,
* walidatory,
* profile benchmarku.

Policz SHA256 całej definicji.

Zapisz:

benchmark_definition\BENCHMARK_SHA256.txt

Każdy RUN musi zapisywać ten hash.

Jeśli benchmark zostanie zmieniony, wygeneruj nową wersję benchmarku.

Nigdy nie zmieniaj po cichu istniejącej wersji.

Jeśli hash różni się między dwoma RUN-ami:

COMPARABLE_1_TO_1 = NO

================================================================
6. PUBLICZNE REPOZYTORIUM
=========================

Jako główne repozytorium wykorzystaj:

https://github.com/nikic/FastRoute

Przy pierwszym przygotowaniu:

1. sklonuj repozytorium,
2. pobierz aktualny commit,
3. zapisz:
   git rev-parse HEAD
4. zapisz URL,
5. zapisz datę,
6. utwórz lokalny snapshot.

Zapisz:

benchmark_definition\repo.lock.json

Każdy przyszły test musi używać dokładnie tego samego commita.

Nie wykonuj później automatycznego git pull.

================================================================
7. BASELINE
===========

Zainstaluj wymagane zależności.

Sprawdź:

* PHP,
* Composer,
* istniejące testy,
* lint,
* inne dostępne mechanizmy walidacji.

Zapisz baseline.

Oryginalny snapshot MUSI przechodzić testy przed zamrożeniem benchmarku.

================================================================
8. DODATKOWE FIXTURES
=====================

FastRoute nie pokrywa wszystkich sytuacji, które chcę testować.

Dlatego utwórz niewielkie, realistyczne i zamrożone fixtures przeznaczone specjalnie do benchmarku.

Niech obejmują m.in.:

* PHP,
* SQL,
* prostą warstwę API,
* autoryzację/uprawnienia,
* konfigurację serwera WWW,
* konfigurację PHP,
* przykładowe logi systemowe/aplikacyjne,
* fragment pliku dependency/lock,
* prostą konfigurację deploymentu.

Fixtures mają być małe, ale realistyczne.

Nie twórz zagadek akademickich.

Chcę sprawdzić zachowanie podobne do rzeczywistej pracy.

================================================================
9. DWA RODZAJE PORÓWNANIA
=========================

Przygotuj dwa osobne tryby.

---

## MODE A — STRICT MODEL BENCHMARK

Model:

* nie ma autonomicznego dostępu do repozytorium,
* nie ma wyszukiwarki internetowej,
* nie może czytać innych plików,
* nie widzi ground truth,
* nie widzi odpowiedzi innych modeli.

Harness przekazuje mu dokładnie określone pliki i prompt.

Każdy model otrzymuje ten sam materiał.

Jest to benchmark zdolności samego modelu.

---

## MODE B — AGENT BENCHMARK

Dla modeli/narzędzi agentowych takich jak:

* Claude Code,
* Codex CLI,

utwórz świeżą kopię workspace.

Agent może:

* czytać wskazane repozytorium,
* wyszukiwać w nim pliki,
* edytować kod,
* uruchamiać testy,
* uruchamiać lint,
* wykonywać bezpieczne lokalne polecenia.

Agent NIE może:

* przeglądać internetu,
* szukać rozwiązania na GitHubie,
* czytać ground truth,
* czytać wyników innych modeli,
* opuszczać swojego izolowanego workspace.

Dostęp do sieci wymagany wyłącznie do komunikacji z usługą Claude/OpenAI nie jest traktowany jako browsing.

STRICT i AGENT mają osobne rankingi.

Nigdy nie porównuj wyniku agenta bezpośrednio z wynikiem model-only bez zaznaczenia różnicy.

================================================================
10. PROVIDERY
=============

Przygotuj modularne adaptery.

Minimum:

OLLAMA
CLAUDE_CODE
CODEX_CLI

W przyszłości ma być łatwo dodać:

ANTHROPIC_API
OPENAI_API
INNY_PROVIDER

Provider nie może być na stałe zaszyty w logice benchmarku.

================================================================
11. OLLAMA
==========

Jeżeli Ollama nie jest zainstalowana, zainstaluj aktualną oficjalną wersję dla Windows.

Nie pobieraj automatycznie wszystkich dużych modeli podczas samego SETUP.

Utwórz początkowy katalog modeli zawierający m.in.:

qwen3.5:9b
devstral-small-2:24b
qwen3-coder:30b
north-mini-code-1.0
qwen3.8:27b
glm-4.7-flash

Ale oznacz je jako:

AVAILABLE_TO_TEST

a nie automatycznie:

INSTALLED.

Jeżeli później poproszę:

"Uruchom test qwen3-coder:30b"

i model nie jest pobrany:

1. sprawdź wolne miejsce,
2. pobierz WYŁĄCZNIE ten model,
3. zapisz digest,
4. uruchom benchmark.

================================================================
12. NOWE MODELE
===============

System MUSI umożliwiać testowanie modeli, które pojawią się w przyszłości.

Przygotuj polecenie/obsługę podobną do:

.\run_benchmark.ps1 -AddModel -Provider Ollama -Model "nowy-model:tag"

lub równoważne.

Po dodaniu modelu nie zmieniaj benchmark definition.

Nowy model ma po prostu wykonać istniejący benchmark.

================================================================
13. CLAUDE CODE
===============

Obsłuż Claude Code jako provider.

Wykorzystuj istniejące uwierzytelnienie użytkownika.

Nie zapisuj tokenów ani sekretów do raportów.

Przy każdym RUN zapisz:

* Claude Code version,
* wybrany model,
* rzeczywisty model ID, jeśli CLI go ujawnia,
* ustawienia,
* dostępne informacje o tokenach,
* czas.

Jeśli używany jest alias typu "sonnet" lub "opus" i nie można ustalić dokładnej niezmiennej wersji:

MODEL_PINNED = NO

i zaznacz, że przyszły test może nie używać identycznego modelu.

================================================================
14. CODEX
=========

Obsłuż Codex CLI jako osobny provider.

Benchmarkowany Codex ma być uruchamiany jako czysta, niezależna sesja/proces.

Nie oceniaj sesji Codexa, która właśnie konfiguruje benchmark.

Runner powinien uruchamiać oddzielny Codex CLI dla konkretnego tasku/RUN.

Zapisz:

* Codex CLI version,
* model,
* reasoning effort,
* sandbox/config,
* token usage, jeśli dostępne,
* czas.

================================================================
15. LIMIT CLAUDE / CODEX
========================

To bardzo ważne.

Benchmark musi być odporny na wyczerpanie limitu.

Każde zadanie jest osobnym checkpointem.

Po ukończeniu zadania:

STATUS = COMPLETE

i wynik zostaje zapisany.

Jeżeli limit zostanie osiągnięty podczas kolejnego zadania:

RUN STATUS = INCOMPLETE
REASON = PROVIDER_LIMIT

Częściowej odpowiedzi z niedokończonego tasku NIE traktuj jako wyniku.

Przy następnym uruchomieniu:

"Uruchom test Claudem"

jeżeli istnieje zgodny, nieukończony RUN tego samego modelu na tym samym BENCHMARK_SHA256:

wznów najnowszy nieukończony RUN.

Ukończonych wcześniej zadań nie wykonuj ponownie.

Niedokończone zadanie zacznij od początku.

Dodaj również jawne:

-Resume
-Restart

lub równoważne opcje.

================================================================
16. PROFILE TESTÓW
==================

Przygotuj trzy profile.

CORE

Najważniejszy benchmark służący do porównywania wszystkich modeli.

EXTENDED

Dodatkowe trudniejsze zadania.

FULL

CORE + EXTENDED + stress tests.

Porównywać bezpośrednio można tylko wyniki tego samego profilu.

Domyślnie polecenie:

"Uruchom test modelem X"

ma uruchamiać CORE.

Polecenie:

"Uruchom pełny test modelem X"

ma uruchamiać FULL.

================================================================
17. CORE — LISTA ZADAŃ
======================

CORE ma zawierać minimum poniższe zadania.

---

## TASK 01 — ARCHITEKTURA PROJEKTU

Model dostaje zestaw rzeczywistych plików FastRoute.

Ma:

* opisać architekturę,
* wskazać odpowiedzialności klas,
* przepływ danych,
* najważniejsze zależności,
* sposób działania routingu,
* istotne decyzje projektowe.

Oceniamy:

* poprawność,
* zrozumienie zależności,
* brak wymyślonych elementów.

---

## TASK 02 — MULTI-FILE REASONING

Przekaż kilka powiązanych plików.

Zadaj pytanie, którego nie da się poprawnie rozwiązać analizując tylko jeden plik.

Sprawdź:

* czy model łączy informacje,
* czy rozumie przepływ między klasami,
* czy nie pomija ważnych zależności.

---

## TASK 03 — CODE REVIEW PRAWDZIWEGO KODU

Nie wprowadzaj kontrolowanej podatności.

Model wykonuje normalne code review.

Ma rozdzielić:

CONFIRMED
POTENTIAL
STYLE/MAINTAINABILITY

Chcę mierzyć false positives.

---

## TASK 04 — CLEAN CODE / FALSE POSITIVE TEST

Daj modelowi poprawny, dobrze przetestowany fragment.

Poproś o znalezienie krytycznych problemów.

Ground truth:

brak celowo wprowadzonego krytycznego błędu.

Ten task ma sprawdzić, czy model wymyśla problemy tylko dlatego, że został poproszony o audyt.

---

## TASK 05 — CONTROLLED BUG: LOGIKA

Wprowadź realistyczny błąd logiczny.

Oryginał:

PASS

Mutacja:

FAIL

Model ma:

* znaleźć przyczynę,
* wyjaśnić,
* przygotować unified diff.

Patch musi być automatycznie przetestowany.

---

## TASK 06 — CONTROLLED BUG: EDGE CASE

Drugi problem, dotyczący przypadku brzegowego.

Nie może być oczywistą literówką.

---

## TASK 07 — CONTROLLED BUG: OBSŁUGA BŁĘDU

Trzeci problem, np.:

* niewłaściwe zachowanie wyjątku,
* błędny fallback,
* nieprawidłowy stan po błędzie.

---

## TASK 08 — ROOT CAUSE Z FAILING TEST

Model otrzymuje:

* kod,
* failing test,
* output testu.

Ma znaleźć root cause.

Nie wystarczy "naprawić test".

Ma ustalić przyczynę w kodzie.

---

## TASK 09 — REFACTORING BEZ ZMIANY ZACHOWANIA

Model ma przygotować refactor.

Automatycznie sprawdź:

* patch,
* syntax,
* test suite,
* regresje,
* niepotrzebne zmiany.

---

## TASK 10 — NAPISANIE TESTÓW

Model dostaje kod i istniejące testy.

Ma dopisać wartościowe testy.

Sprawdź:

* czy się uruchamiają,
* czy stare testy przechodzą,
* czy nowe testy faktycznie coś wykrywają.

Jeśli możliwe, wykorzystaj controlled mutation do sprawdzenia wartości testu.

---

## TASK 11 — IMPLEMENTACJA MAŁEJ FUNKCJONALNOŚCI

Przygotuj realistyczną specyfikację zmiany.

Model ma zaimplementować funkcję zgodnie z wymaganiami.

Ukryte testy sprawdzają:

* happy path,
* edge cases,
* kompatybilność,
* regresje.

---

## TASK 12 — PERFORMANCE ANALYSIS

Daj fragment z rzeczywistym problemem lub potencjalnym hot path.

Model ma:

* zidentyfikować koszt,
* określić złożoność,
* zaproponować sensowną poprawę,
* oddzielić istotne problemy od mikrooptymalizacji.

---

## TASK 13 — SECURITY AUDIT: VULNERABLE FIXTURE

Przygotuj mały realistyczny fixture zawierający kilka kontrolowanych problemów bezpieczeństwa.

Przykładowe klasy problemów:

* niewłaściwa walidacja danych,
* SQL injection,
* authorization/access-control flaw,
* path traversal,
* niebezpieczna obsługa danych wejściowych,
* błędna konfiguracja bezpieczeństwa.

Nie dawaj modelowi listy faktycznie wprowadzonych błędów.

Ground truth przechowuj prywatnie.

Model ma dla każdego znaleziska podać:

* lokalizację,
* opis,
* wpływ,
* warunki wykorzystania,
* severity,
* confidence,
* proponowaną naprawę.

Mierz:

TRUE POSITIVES
FALSE POSITIVES
FALSE NEGATIVES

---

## TASK 14 — SECURITY AUDIT: CLEAN FIXTURE

Przygotuj osobny fixture bez celowo wprowadzonych krytycznych podatności.

Sprawdź skłonność modelu do halucynowania podatności.

================================================================
18. EXTENDED — ZADANIA DODATKOWE
================================

---

## TASK 15 — AUTHORIZATION AUDIT

Mała aplikacja z:

* użytkownikami,
* rolami,
* zasobami,
* endpointami.

Wprowadź subtelny błąd kontroli dostępu.

Sprawdź, czy model odróżnia:

authentication

od:

authorization.

---

## TASK 16 — SQL / DATA ACCESS AUDIT

Fixture zawierający:

* kilka zapytań SQL,
* filtrowanie,
* paginację,
* transakcję.

Sprawdź:

* poprawność,
* bezpieczeństwo,
* race/data consistency,
* wydajność zapytań.

---

## TASK 17 — WEB/PHP CONFIG AUDIT

Przygotuj zamrożony zestaw realistycznych konfiguracji, np.:

* serwer WWW,
* PHP,
* vhost,
* TLS/security headers,
* permissions.

Model ma wykonać audyt.

Musi rozdzielić:

FACT
RISK
RECOMMENDATION
NOT ENOUGH DATA

Nie może udawać, że wie coś, czego nie ma w plikach.

---

## TASK 18 — LOG INCIDENT ANALYSIS

Przygotuj zestaw zamrożonych logów.

Niech występują:

* normalny szum,
* co najmniej jeden rzeczywisty problem,
* powiązane zdarzenia z kilku źródeł,
* kilka mylących wpisów.

Model ma:

* ustalić chronologię,
* wykryć ważne zdarzenia,
* skorelować wpisy,
* odróżnić symptom od przyczyny,
* oddzielić fakty od hipotez,
* zaproponować dalszą diagnostykę.

---

## TASK 19 — AUDYT ZALEŻNOŚCI OFFLINE

Nie korzystaj z bieżącego Internetu.

Przygotuj zamrożony fixture:

dependency list + lock file + lokalny zestaw advisories.

Model ma skorelować dane i wskazać rzeczywiste ryzyka.

Dzięki temu wynik nie zależy od daty uruchomienia benchmarku.

---

## TASK 20 — REVIEW DIFF / REGRESSION RISK

Daj modelowi:

* przed,
* diff,
* po.

Ma ocenić zmianę jak reviewer PR.

Sprawdź:

* czy znajduje regresję,
* czy rozumie wpływ zmiany,
* czy zauważa brakujące testy.

---

## TASK 21 — SPECIFICATION ANALYSIS

Daj krótką specyfikację zawierającą:

* wymagania,
* jedno subtelne niedoprecyzowanie,
* potencjalną sprzeczność,
* przypadek brzegowy.

Model ma przed implementacją wskazać:

* co jest jasne,
* czego brakuje,
* jakie są ryzyka,
* jakie decyzje trzeba podjąć.

Chcę mierzyć, czy model bezmyślnie zaczyna pisać kod.

---

## TASK 22 — BŁĘDNA HIPOTEZA UŻYTKOWNIKA

Prompt zawiera fałszywe założenie dotyczące działania kodu.

Model powinien je zweryfikować na podstawie źródeł i skorygować, zamiast ślepo zaakceptować.

To jest test podatności na sugestię.

================================================================
19. FULL / STRESS TESTS
=======================

FULL zawiera również:

---

## TASK 23 — LONG CONTEXT 16K

Duży wieloplikowy input.

Sprawdź:

* retencję informacji,
* zależności,
* poprawność,
* szybkość.

---

## TASK 24 — LONG CONTEXT 32K

Analogiczny test 32K.

Jeśli model/provider nie obsługuje:

UNSUPPORTED

Jeśli lokalny model nie daje rady sprzętowo:

NOT_PRACTICAL / OOM

Nie uznawaj przez to całego modelu za FAIL.

---

## TASK 25 — LARGE CHANGE PLANNING

Model dostaje szerszy fragment projektu i specyfikację zmiany.

Najpierw ma przygotować plan:

* pliki do zmiany,
* kolejność,
* ryzyka,
* testy.

Następnie implementację.

Sprawdź zgodność planu z faktycznymi zmianami.

---

## TASK 26 — AGENT DEBUG LOOP

Tylko MODE B.

Agent otrzymuje repo z błędem i może:

* czytać kod,
* odpalać testy,
* poprawiać,
* ponownie testować.

Zmierz:

* liczbę kroków,
* liczbę komend,
* czas,
* końcowy wynik,
* niepotrzebne zmiany.

================================================================
20. PRZYGOTOWANIE CONTROLLED BUGS
=================================

Każda kontrolowana mutacja musi być zweryfikowana.

Automatycznie potwierdź:

ORIGINAL -> PASS
MUTATED -> FAIL
REVERTED -> PASS

Dopiero potem zamroź fixture.

Ground truth zawiera:

* dokładną zmianę,
* oczekiwany symptom,
* oczekiwany fix,
* test wykrywający problem.

Ground truth nie może być dostępny testowanemu modelowi.

================================================================
21. IZOLACJA
============

Każdy TASK i MODEL otrzymuje świeży workspace.

Nigdy:

MODEL A -> workspace -> MODEL B

Zawsze:

BASE SNAPSHOT
|
+-> fresh MODEL A workspace
|
+-> fresh MODEL B workspace

Agent nie może widzieć katalogu:

benchmark_private

ani:

results\inne-modele

================================================================
22. IDENTYCZNE INPUTY
=====================

Dla MODE A zapisuj pełny request.

Policz:

SHA256 inputu.

Dla każdego tasku wszystkie modele powinny dostawać semantycznie identyczny materiał.

Różnice wynikające wyłącznie z technicznego chat template providera dokumentuj osobno.

================================================================
23. PARAMETRY OLLAMA
====================

Dla modeli lokalnych jako główny CORE benchmark:

num_ctx = 16384

W miarę możliwości:

temperature = 0
seed = 42
stream = false

Ustal rozsądny i ten sam maksymalny output dla porównywanych tasków.

Nie wyłączaj jednak obowiązkowego mechanizmu reasoning danego modelu, jeśli powodowałoby to testowanie go w nienaturalnym trybie.

Dokumentuj wszystkie różnice.

================================================================
24. METRYKI OLLAMA
==================

Zapisuj:

model
tag
digest
quantization
parameters
task
prompt_eval_count
prompt_eval_duration
eval_count
eval_duration
load_duration
total_duration
done_reason
generation tokens/s
prompt processing tokens/s
num_ctx
peak VRAM
peak RAM
GPU utilization
temperature
power

================================================================
25. METRYKI CLOUD/CLI
=====================

Dla Claude i Codex zapisuj, jeśli dostępne:

model ID
CLI version
input tokens
output tokens
cached tokens
reasoning tokens
wall time
provider-reported usage
provider-reported cost

Jeśli czegoś provider nie ujawnia:

N/A

Nie zgaduj.

Ze względu na różne tokenizery NIE przedstawiaj tokens/s Claude i Ollama jako idealnie równoważnej miary jakości.

Wall-clock time może być porównywany osobno.

================================================================
26. ZAPIS SUROWYCH ODPOWIEDZI
=============================

Każda odpowiedź modelu ma być zachowana dokładnie.

Przykład:

results
BENCHMARK_VERSION
MODEL
RUN_ID
strict
task_01
response.md
request.json
raw_response.json
metrics.json
validation.json
agent
...

Nie poprawiaj odpowiedzi.

Nie usuwaj błędów.

Nie poprawiaj patchy.

================================================================
27. WALIDACJA PATCHY
====================

Jeżeli model zwraca patch:

1. zapisz raw response,
2. wyodrębnij unified diff,
3. zastosuj do świeżego fixture,
4. uruchom syntax/lint,
5. uruchom target test,
6. uruchom pełne testy,
7. zapisz diff,
8. policz zmienione pliki,
9. policz zmienione linie.

Status:

PATCH_INVALID
PATCH_APPLIED
TARGET_TEST_PASS
FULL_TEST_PASS
REGRESSION
OVERMODIFICATION

================================================================
28. AUTOMATYCZNA OCENA
======================

Automatycznie oceniaj wyłącznie rzeczy obiektywne:

* build/lint,
* test,
* hidden test,
* mutation killed,
* patch applied,
* regression,
* expected output,
* ground-truth vulnerability detection.

Nie używaj automatycznie innego LLM jako sędziego.

================================================================
29. OCENA ANALIZ
================

Dla odpowiedzi jakościowych przygotuj pola do ręcznej oceny:

accuracy 0-10
depth 0-10
usefulness 0-10
false_positives 0-10
clarity 0-10
uncertainty_handling 0-10

Pozostaw je puste.

Dodatkowo dla zadań z ground truth automatycznie policz tam, gdzie możliwe:

TP
FP
FN
precision
recall

================================================================
30. WYNIKI WEDŁUG ZASTOSOWANIA
==============================

Nie chcę tylko jednego wyniku "MODEL SCORE".

Raport ma mieć oddzielne sekcje:

CODING
DEBUGGING
CODE UNDERSTANDING
CODE REVIEW
TESTING
REFACTORING
SECURITY AUDIT
CONFIG AUDIT
LOG ANALYSIS
SPEC ANALYSIS
LONG CONTEXT
SPEED
RESOURCE USAGE

Dzięki temu mogę stwierdzić np.:

"Model A jest najlepszy do szybkiego kodowania."

"Model B jest wolniejszy, ale znacznie lepiej robi audyty."

================================================================
31. OPCJONALNY OVERALL SCORE
============================

Możesz przygotować mechanizm wag, ale nie ukrywaj składowych.

config\scoring.json

Przykładowo:

coding: 25
debugging: 20
analysis: 15
security: 20
testing: 10
instruction_following: 10

Ale domyślnie raport ma przede wszystkim pokazywać wyniki kategorii.

================================================================
32. FALSE POSITIVES SĄ WAŻNE
============================

Model, który zgłasza 20 "podatności", z których 18 nie istnieje, nie jest dobrym audytorem.

Raport bezpieczeństwa musi pokazywać:

TP
FP
FN
precision
recall

Nie nagradzaj modelu wyłącznie za liczbę znalezionych problemów.

================================================================
33. INSTRUCTION FOLLOWING
=========================

W kilku taskach dodaj proste wymagania formatu.

Przykładowo:

* tylko JSON,
* tylko unified diff,
* maksymalnie 5 findings,
* rozdziel FACT/HYPOTHESIS.

Sprawdź automatycznie, czy model ich przestrzega.

================================================================
34. ANTI-HALLUCINATION
======================

Kilka testów musi zawierać sytuację, gdzie poprawną odpowiedzią jest:

* brak błędu,
* brak wystarczających danych,
* nie da się stwierdzić,
* potrzebny jest dodatkowy log/config.

Chcę premiować model za prawidłowe przyznanie braku danych.

================================================================
35. RUN ID
==========

Każdy RUN:

YYYY-MM-DD_HH-MM-SS

Nie nadpisuj wyników.

================================================================
36. STATUS RUN
==============

Każdy RUN ma posiadać:

PENDING
RUNNING
INCOMPLETE
COMPLETE
FAILED

oraz per-task:

NOT_STARTED
RUNNING
COMPLETE
INTERRUPTED
FAILED
SKIPPED_UNSUPPORTED

================================================================
37. WZNAWIANIE
==============

Przy wznowieniu sprawdź:

BENCHMARK_SHA256
repo SHA
provider
model identity
profile

Jeżeli się zgadzają:

można kontynuować.

Jeśli się nie zgadzają:

nie łącz wyników.

================================================================
38. POLECENIA
=============

Przygotuj wygodny interfejs.

Minimum:

setup

list-models

add-model

run

resume

status

compare

report

Przykładowo:

.\run_benchmark.ps1 -Setup

.\run_benchmark.ps1 -ListModels

.\run_benchmark.ps1 -Provider Ollama -Model "qwen3-coder:30b"

.\run_benchmark.ps1 -Provider Claude -Model "sonnet"

.\run_benchmark.ps1 -Provider Claude -Model "opus" -Profile Full

.\run_benchmark.ps1 -Provider Codex -Profile Core

.\run_benchmark.ps1 -Resume

.\run_benchmark.ps1 -Compare

Składnię możesz zaprojektować lepiej, jeśli będzie prostsza.

================================================================
39. INSTRUKCJE DLA AGENTÓW
==========================

Utwórz:

BENCHMARK_INSTRUCTIONS.md

oraz odpowiednie pliki instrukcji projektowych dla Claude Code i Codex.

Dzięki temu, gdy później otworzę projekt i napiszę:

"Uruchom test Claudem"

agent ma wiedzieć:

* NIE przebudowywać benchmarku,
* NIE zmieniać promptów,
* NIE aktualizować repo,
* znaleźć właściwy provider,
* użyć CORE,
* wznowić kompatybilny przerwany RUN, jeśli istnieje,
* zapisać wyniki.

Dla:

"Uruchom pełny test Claudem"

użyj FULL.

Dla:

"Uruchom test nowym modelem XYZ"

jeśli model nie jest jeszcze w config:

dodaj go do katalogu modeli, ale NIE zmieniaj benchmark definition.

================================================================
40. PORÓWNANIE MODELI
=====================

compare ma wybierać tylko:

COMPLETE runs
ten sam BENCHMARK_SHA256
ten sam PROFILE
ten sam MODE

Jeżeli model został przetestowany kilka razy, domyślnie użyj najnowszego COMPLETE run, ale pozwól wybrać konkretny.

================================================================
41. RAPORT HTML
===============

Generuj lokalny:

comparison.html

Powinien zawierać:

* tabelę modeli,
* wyniki tasków,
* wyniki kategorii,
* PASS/FAIL,
* TP/FP/FN,
* czas,
* zasoby,
* informacje o modelu,
* datę testu,
* benchmark hash.

Dodaj możliwość kliknięcia modelu/tasku i zobaczenia jego pełnej surowej odpowiedzi.

Raport ma działać lokalnie bez serwera [WWW](http://WWW).

================================================================
42. PORÓWNANIE SPRZĘTU
======================

Dla lokalnych modeli zapisuj dokładny sprzęt.

Chcę móc później wykonać ten sam model np. na:

RTX 4060 Ti 16 GB

a następnie:

RTX 3090 24 GB

i porównać:

tokens/s
prompt speed
VRAM
RAM
GPU utilization
power
czas.

Jakość odpowiedzi nie musi być ponownie oceniana, jeśli digest, benchmark i parametry są identyczne, ale zachowaj nowy RUN.

================================================================
43. MODEL IDENTITY
==================

Dla Ollama:

digest jest kluczowy.

Dla cloud:

zapisuj najdokładniejszy identyfikator, jaki provider udostępnia.

Jeśli model jest aliasem mogącym zmienić się w przyszłości:

MODEL_PINNED = NO

i raport ma to wyraźnie pokazywać.

================================================================
44. SETUP NIE URUCHAMIA PEŁNEGO BENCHMARKU
==========================================

Po wykonaniu tego promptu:

1. zbuduj benchmark,
2. zweryfikuj fixtures,
3. zweryfikuj controlled bugs,
4. zweryfikuj baseline,
5. zamroź benchmark,
6. wygeneruj BENCHMARK_SHA256,
7. skonfiguruj providery,
8. sprawdź, czy Ollama/Claude/Codex są wykrywane,
9. wykonaj mały connectivity/self-test providerów, jeśli możliwe bez dużego zużycia limitów,
10. NIE wykonuj właściwego CORE/FULL benchmarku żadnym modelem bez mojego polecenia.

================================================================
45. WALIDACJA BENCHMARKU
========================

Przed zamrożeniem upewnij się, że:

* każdy controlled bug rzeczywiście psuje właściwy test,
* każdy hidden test działa,
* clean fixtures faktycznie nie zawierają celowo planted vulnerabilities,
* vulnerable fixtures mają udokumentowany ground truth,
* task prompts nie zdradzają odpowiedzi,
* żaden testowany model nie ma dostępu do benchmark_private,
* każdy task jest powtarzalny.

================================================================
46. README PO POLSKU
====================

Przygotuj:

README_PL.md

Wyjaśnij:

* czym jest benchmark,
* jak uruchomić model Ollama,
* jak uruchomić Claude,
* jak uruchomić Codex,
* jak wznowić test po wyczerpaniu limitu,
* jak dodać nowy model,
* jak uruchomić CORE,
* jak uruchomić FULL,
* jak porównać wyniki,
* gdzie są surowe odpowiedzi,
* jak interpretować TP/FP/FN,
* jak powtórzyć test po zmianie GPU.

================================================================
47. NIE ULEPSZAJ BENCHMARKU PODCZAS RUN
=======================================

Jeśli podczas testowania modelu zauważysz, że coś w benchmarku można byłoby zrobić lepiej:

NIE zmieniaj aktywnej wersji.

Zapisz sugestię do:

benchmark_improvements.md

Zmiana benchmarku wymaga stworzenia nowej wersji.

Np.:

Benchmark v1

Benchmark v2

Wyników v1 i v2 nie mieszaj jako 1:1.

================================================================
48. PODSUMOWANIE SETUP
======================

Po zakończeniu konfiguracji przedstaw mi:

* ścieżkę projektu,
* FastRoute SHA,
* BENCHMARK VERSION,
* BENCHMARK_SHA256,
* liczbę tasków CORE,
* liczbę tasków EXTENDED,
* liczbę tasków FULL,
* wykryte providery,
* dostępne modele,
* które modele Ollama są już zainstalowane,
* które są tylko zapisane w katalogu,
* jak uruchomić pierwszy benchmark.

Na końcu podaj mi kilka gotowych przykładów:

"Uruchom test qwen3-coder:30b"

"Uruchom test Claudem Sonnet"

"Uruchom pełny test Codexem"

"Kontynuuj przerwany test Claude"

"Dodaj nowy model Ollama XYZ i przetestuj go"

"Porównaj wszystkie ukończone modele"

Nie uruchamiaj właściwego benchmarku, dopóki wyraźnie o to nie poproszę.