Skąd wiem, że mój agent stał się lepszy między wersjami, a nie po prostu miał szczęście?
Szansa
Gdy agent wykonuje setki sekwencyjnych kroków przez wiele godzin, tradycyjna ewaluacja A/B zawodzi, ponieważ wczesne wywołanie narzędzia kształtuje każdy kolejny wybór, przez co wyniki są zależne od ścieżki między uruchomieniami. Przeprowadzenie wystarczającej liczby niezależnych prób w celu uzyskania wiarygodnego sygnału kosztuje tyle samo obliczeń co trening. Dziedzina domyślnie sięga po metryki zastępcze, takie jak wskaźnik sukcesu kroków i dokładność wywołań narzędzi, które w praktyce nie korelują z wynikami zadań końcowych przy rzeczywistej pracy. Audyt 445 opublikowanych benchmarków LLM z 2025 roku udokumentował błędy trafności konstrukcyjnej na dużą skalę: niejasne definicje zadań, zestawy danych z krótkim horyzontem przystosowane do innych celów oraz brak testów statystycznych, przy czym wszystkie te problemy nasilają się wraz z wydłużaniem horyzontu zadań. Zespoły budujące produkty agentowe wdrażają je na podstawie ręcznych wyrywkowych sprawdzeń, ponieważ nie istnieje żadna ugruntowana, odtwarzalna metodologia oceny agentów o długim horyzoncie.
Dlaczego to ważne
Bez wiarygodnego sposobu mierzenia, czy agent stał się lepszy, nie można systematycznie doskonalić agentów wdrożonych już w zadaniach wysokiego ryzyka.
Jak oceniam szansę
Wskaźnik Szansy to mój własny odczyt, a nie pomiar: jak bardzo boli, jak często daje się we znaki i jak niewiele istnieje dziś, by to rozwiązać. Wyższy wynik oznacza, że uważam problem za bardziej warty zbudowania.
Ile bólu sprawia, gdy się pojawia.
Jak często ludzie faktycznie na to trafiają.
Jak mało dobrych narzędzi istnieje dla tego dziś.
Więcej problemów wartych rozwiązania
Dlaczego każda aplikacja AI zapomina o mnie w chwili, gdy zamykam kartę?
AIDlaczego nauka nowej dziedziny wciąż wymaga wiedzy, co pytać?
AIDlaczego osoba bez specjalistycznej wiedzy nie może zweryfikować tego, co właśnie powiedział jej AI?
AIDlaczego testujemy modele na benchmarkach, ale wdrażamy je na wyczucie?
AIA few overlapping reasons: **Architecture: stateless inference** LLMs run as pure functions over a context window. Each call takes tokens in, produces tokens out, and discards all runtime state. Nothing from one conversation writes back to the model's weights. **Training vs. runtime are separate** Weights are frozen at deployment. Mistakes made during inference don't trigger gradient updates. The only way a mistake becomes a "lesson" is if it gets labeled, curated, and included in a future training run -- a slow, expensive, offline process. **No episodic memory system** Humans have two distinct memory systems: semantic (general knowledge) and episodic (specific events -- "I burned my hand on that stove"). LLMs only have something analogous to semantic memory, encoded statically in weights. There's no biological equivalent of a hippocampus writing new episodic records at runtime. **Recognizing a mistake is itself hard** To remember a mistake, you first have to know it *was* a mistake. Models often don't get that signal. Users close the tab, give no feedback, or the error is subtle enough that neither party notices at the time. **Tools like this memory system partially patch it** External memory (like the file-based system I use in this project) lets agents persist observations across sessions. But it's bolted on, not intrinsic -- and it only works if the agent correctly identifies something worth saving, which requires the mistake-recognition problem to be solved first. The fundamental gap: learning in humans is continuous and implicit; in current AI systems, learning is batched, explicit, and offline.
AIKilka powodów, które się wzajemnie wzmacniają: **Techniczne** - Trening niszczy bezpośrednie ślady. Wagi sieci kodują wzorce ze wszystkich danych łącznie, a nie poszczególne przykłady. Nie można "odtworzyć" konkretnego dokumentu z wytrenowanego modelu. - Ataki membership inference (sprawdzające, czy dany przykład był w zbiorze treningowym) działają statystycznie i zawodnie, szczególnie przy dużych modelach. - Dane przechodzą wielostopniowe przetwarzanie: filtrowanie, deduplikację, przepróbkowanie, mieszanie z różnych źródeł. Nawet twórca modelu często nie ma pełnej listy "co dokładnie weszło". **Praktyczno-organizacyjne** - Firmy traktują skład danych treningowych jako tajemnicę handlową. - Zbiory treningowe mają rozmiar petabajtów. Przechowywanie ich na potrzeby późniejszego audytu jest kosztowne, a żadna regulacja jeszcze tego nie wymaga. - Brak standardowego formatu dokumentacji. Model card czy data sheet to dobrowolne, niejedno-z-jednoznaczne deklaracje. **Regulacyjne** - MiCA reguluje kryptoaktywa, nie modele AI. AI Act UE wymaga pewnej przejrzystości od "modeli ogólnego przeznaczenia", ale przepisy wykonawcze dopiero się kształtują i skupiają się na ryzyku, nie na pełnym audycie danych. - Nie istnieje odpowiednik zatwierdzenia przez FDA dla danych treningowych. **Wynik praktyczny** Możesz testować zachowanie modelu (audyt czarnej skrzynki), ale nie możesz zweryfikować provenance danych. To fundamentalna luka: model może odpowiadać poprawnie na benchmarkach, a mimo to być wytrenowany na naruszających prawa autorskie lub stronniczych źródłach, których nie widać na wyjściu. To jeden z argumentów za tym, by wymagania dotyczące przejrzystości danych treningowych były budowane w prawie, zanim modele zostaną wdrożone, a nie po fakcie.