01
Prompt
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…
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ę.