TL;DR:

Oceny AI eliminują domysły – systematyczne mierzenie zamiast „patrzenia na oko”
N8N oferuje wbudowane narzędzia – węzły oceny bez potrzeby zewnętrznych systemów
Wywoływanie narzędzi to częsty problem – agenci nie wybierają właściwych narzędzi w systemach wielonarzędziowych
Prosta zmiana promptów może dać dramatyczne efekty – poprawa z 30% do 80% trafności
Panel umożliwia przechodzenie do szczegółów – analiza konkretnych błędów i wykrywanie problemów
Dostępne też dla własnych instalacji – wersja społecznościowa obsługuje jedną ocenę, Pro/Enterprise bez ograniczeń

Poniższy artykuł powstał na podstawie notatek z webinaru N8N „From Prompt to Production: Smarter AI with Evaluations”. Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą od rozmówców: Angel Menendez (główny rzecznik deweloperów N8N, wcześniej cyberbezpieczeństwo w Palo Alto Networks) i Elvis Saravia (ekspert od oceny AI, współpracował nad Galactica w Meta AI, Fair, PyTorch).

Dlaczego oceny przestały być tylko dla badaczy

Angel Menendez zwraca uwagę na paradoks: większość użytkowników N8N już wykonuje oceny, jednak robi to w sposób nieustrukturyzowany. Deweloperzy często ograniczają się do „patrzenia na oko” na wyniki przepływów pracy AI.

Z kolei Elvis Saravia podkreśla fundamentalny problem leżący u podstaw tej sytuacji: modele językowe są niedeterministyczne. W rezultacie dla tego samego promptu nie można zagwarantować identycznego wyniku. Ta cecha prowadzi w konsekwencji do niewiarygodności, halucynacji i niebezpiecznych rezultatów.

Dlatego też, jak wyjaśnia Saravia, oceny pozwalają „systematycznie mierzyć niezawodność i wydajność aplikacji”. Zamiast zgadywać, czy system działa poprawnie, otrzymujesz konkretne dane oraz możliwość:

Pewnego skalowania – budowanie aplikacji klasy produkcyjnej
Śledzenia degradacji – monitorowanie zmian w LLM, promptach, modelach
Ciągłego monitorowania – kontrola zdrowia systemu w czasie

Saravia formułuje również kluczową obserwację: „Wielu deweloperów po prostu rezygnuje z budowania aplikacji i obwinia AI, kiedy system zawodzi. Dzieje się tak dlatego, że nie mają systemu do mierzenia rzeczy.”

Rodzaje ocen: od prostych do zaawansowanych

Saravia dzieli oceny na dwie główne kategorie, które różnią się stopniem zaawansowania.

Lekka ocena obejmuje kilka przykładów, które deweloper ocenia wizualnie. Polega na wykonaniu przepływu pracy na małym zbiorze danych i ręcznej ocenie wyników jako dobre lub złe. Jest to typowe podejście stosowane przed wdrożeniem.

Ocena oparta na metrykach jest natomiast potrzebna do aplikacji produkcyjnych. Jak tłumaczy Saravia: „Nie da się skalować tylko patrzeniem na wyniki”, gdy system ma obsłużyć tysiące przypadków testowych. W środowisku produkcyjnym pojawiają się bowiem liczne przypadki brzegowe, które wymagają systematycznej analizy.

Budowanie zbioru danych: najpierw zakres, potem dane

Saravia zwraca uwagę na częsty błąd metodologiczny w procesie przygotowania oceny. Deweloperzy zaczynają od zbierania danych, nie definiując wcześniej zakresu. W rezultacie dopiero po zebraniu zbioru danych zastanawiają się, co właściwie chcą mierzyć.

Dlatego też w swoim przykładzie Saravia skupia się na wywoływaniu narzędzi – jednym konkretnym aspekcie systemu. Uzasadnia to następująco: „Zauważyłem, że moje systemy agentowe zwykle nie wywołują narzędzi we właściwej kolejności lub pomijają ważne narzędzie.”

Lista kontrolna: Budowanie zbioru danych oceny

Krok 1: Definiowanie zakresu

Określ konkretny aspekt systemu do mierzenia
Zdefiniuj co oznacza „sukces” dla Twojego przypadku
Wybierz reprezentatywne scenariusze użycia

Krok 2: Zbieranie i formatowanie

Wykonaj przepływ pracy na przykładowych danych wejściowych
Zastosuj strukturę: dane wejściowe + oczekiwane wyniki
Wykorzystaj węzeł N8N do automatycznego eksportu do Arkuszy Google

Konkretne przykłady ze zbioru danych Saravia:

„What is five times five?” → Oczekiwane narzędzia: [kalkulator]
„How much did OpenAI pay to acquire Windsurf?” → Oczekiwane narzędzia: [przeszukaj_bazę, kalkulator, podsumowywacz]

Angel Menendez dodaje przy tym praktyczną wskazówkę: można wykorzystać węzeł N8N do automatycznego pobierania wykonań i eksportowania do Arkuszy Google. Dzięki temu eliminuje się czasochłonne ręczne kopiowanie danych.

Metryki: od prostego dopasowania do LLM jako sędziego

Wybór odpowiedniej metryki zależy od specyfiki aplikacji. Saravia wyróżnia jednak kilka głównych podejść:

Proste dopasowanie polega na porównaniu dwóch zbiorów (np. oczekiwanych vs rzeczywistych wywołań narzędzi). Metryki podobieństwa znajdują z kolei zastosowanie w systemach takich jak podsumowywanie, gdzie porównuje się podobieństwo wyników. LLM jako sędzia wykorzystuje natomiast model językowy do oceny jakości wyniku według zdefiniowanych kryteriów.

Podejście LLM jako sędzia okazuje się szczególnie elastyczne. Jak wyjaśnia Saravia: „Jest bardzo dostosowywalny. Możesz użyć LLM do sprawdzenia, czy w wyniku są halucynacje, czy to bezpieczny wynik.”

Dodatkowo N8N umożliwia pełne dostosowywanie – można bowiem zmodyfikować formułę w węźle według własnych potrzeb.

Praktyczne demo: System wielu agentów z problemem wywoływania narzędzi

Saravia prezentuje przykład z prawdziwego świata: agent z dostępem do czterech narzędzi:

Przeszukiwanie bazy danych (wyszukiwanie w magazynie wektorowym Quadrant)
Wyszukiwanie w sieci (gdy nie ma danych w pamięci podręcznej)
Kalkulator (operacje matematyczne)
Podsumowywacz (osobny agent jako narzędzie)

Model wykorzystywany w demo to Gemini 2.5 Pro przez OpenRouter. Saravia uzasadnia ten wybór: „Gdy używasz wielu narzędzi, dobrze jest użyć jednego z mocniejszych modeli.”

Mimo to kluczowy element architektury stanowi optymalizacja wywołań: system najpierw sprawdza dane z pamięci podręcznej w magazynie wektorowym. Jeśli znajdzie potrzebne informacje, pomija wyszukiwanie w sieci. Jak podkreśla Saravia: „To potężne wykorzystanie agenta – optymalizacja systemu do używania danych z pamięci podręcznej.”

Przepływ pracy oceny w N8N składa się z kolei z kilku komponentów:

Węzeł zbioru danych oceny – połączenie z Arkuszami Google
Sprawdzanie czy ocenia – przełączanie między trybem oceny a normalnym działaniem
Analiza narzędzi – skrypty do porównania oczekiwanych vs rzeczywistych wywołań
Ustawianie wyników – zapisanie rezultatów z powrotem do zbioru danych
Ustawianie metryk – konwersja na metryki liczbowe

Saravia wskazuje ponadto na kluczowy element konfiguracji: włączenie opcji „Zwróć kroki pośrednie” w węźle agenta. Dzięki temu otrzymuje się dostęp do pełnych dzienników wszystkich kroków, wywołań narzędzi i odpowiedzi.

Dramatyczna poprawa: z 30% do 80% trafności

Pierwsza iteracja przepływu pracy osiągnęła jedynie 30% trafności. Saravia był jednak pozytywnie zaskoczony rezultatem analizy: „Oczekiwałem, że spędzę wiele godzin na tym, a dosłownie tylko zmieniłem instrukcje.”

Analiza zbioru danych ujawniła bowiem konkretny problem: agent systematycznie pomijał narzędzie przeszukiwania bazy danych. Problem ten był wyraźnie widoczny w kolumnie „Rzeczywiście wywołane narzędzia” w Arkuszach Google.

Rozwiązanie okazało się względnie proste i polegało na wprowadzeniu szczegółowych instrukcji w systemowym prompcie:

Dodanie frazy „Zwróć szczególną uwagę na moje opisy i przepływ oraz logikę”
Wprowadzenie jawnej logiki: „Jeśli używasz tego narzędzia i znajdziesz istotne informacje, nie używaj narzędzia wyszukiwania w sieci”
Wymuszenie wywołania przeszukiwania bazy danych jako elementu optymalizacji

Saravia podsumowuje: „Eliminujemy wszystkie założenia i teraz system może działać znacznie lepiej.”

Panel i wykrywanie błędów: analiza konkretnych problemów

N8N oferuje dedykowany panel oceny z kilkoma kluczowymi funkcjami:

Czas trwania każdej oceny – ważne dla optymalizacji kosztów
Przechodzenie do szczegółów konkretnych wykonań – analiza przyczyn niepowodzeń
Porównanie między iteracjami – łatwe testowanie A/B różnych modeli czy promptów
Śledzenie statusu – monitorowanie stanu: działające/ukończone/nieudane

Saravia przedstawia przy tym praktyczny przykład wykrywania błędów: nieudany przypadek z zapytaniem o przejęcie Windsurf. Panel umożliwił szybkie zidentyfikowanie, że agent pominął przeszukiwanie bazy danych, mimo że dane były dostępne w pamięci podręcznej.

Menendez dodaje: „To jak wyciągnięcie tego, co dzieje się w środku czarnej skrzynki i umieszczenie tego gdzieś użytecznym.”

Zmiana mentalności: od intuicji do systematycznego podejścia

Saravia podkreśla potrzebę fundamentalnej zmiany myślenia: „Większość z nas robi już oceny, po prostu tego nie wie. Patrzymy na wyniki, czasem jesteśmy zadowoleni, czasem sfrustrowany.”

Formułuje również kluczowe przesłanie: „Jeśli nie mierzysz tego, jak poznasz że system oferuje wartość użytkownikom, gdy coś się zepsuje?”

Rozróżnia ponadto podejście w zależności od skali projektu: dla projektu osobistego można zadowolić się „patrzeniem na oko”, jednak skalując do milionów użytkowników potrzebne jest systematyczne podejście.

Praktyczne wskazówki dla produkcji

Podprzepływy jako element separacji
Menendez sugeruje wykorzystanie podprzepływów do oddzielenia logiki AI od rurociągu oceny. Porównuje to do funkcji w kodzie – tworzą się komponenty wielokrotnego użytku, które można wykorzystywać w różnych kontekstach.

Optymalizacja kosztów i opóźnień
Saravia zwraca natomiast uwagę na aspekt ekonomiczny: „Gdy używasz wielu narzędzi, wywołujesz API wyszukiwania w sieci – te rzeczy kosztują. Jeśli możemy po drodze mierzyć to również, pozwoli nam to zoptymalizować system.”

Rozszerzanie zbioru danych z produkcji
Saravia wskazuje ponadto na możliwość ewolucji systemu: „Gdy już masz aplikację działającą w produkcji, możesz rozszerzyć zbiór danych, ponieważ masz rzeczywiste dane od użytkowników.”

Lista kontrolna: Analiza wyników oceny

Po każdej ocenie:

Przeanalizuj ogólny wynik trafności
Zidentyfikuj najczęstsze typy błędów
Sprawdź szczegóły przypadków nieudanych
Porównaj z poprzednimi iteracjami
Sprawdź wzorce w kolumnie „Rzeczywiście wywołane narzędzia”

Dostępność i perspektywy rozwoju

Obecny stan dostępności:

Wersja społecznościowa: obsługuje 1 ocenę
Pro/Enterprise: nieograniczone oceny
Wymagania techniczne: Arkusze Google (planowane wbudowane rozwiązania)

Planowane ulepszenia:

Wbudowane przechowywanie zbiorów danych
Rozszerzony zestaw gotowych metryk
Udoskonalone narzędzia do automatyzacji zbiorów danych

Saravia podsumowuje znaczenie tej funkcjonalności: „Każdy pracujący z agentami w N8N powinien to robić. To nie jest opcjonalne.”

Przełomowa obserwacja

Błędy to kopalnia złota

Standardowo myślimy: Przypadki niepowodzeń to frustracja i problem do uniknięcia – znak, że coś jest nie tak z przepływem pracy AI.

W praktyce okazuje się, że: Przypadki niepowodzeń to najcenniejsze dane w całym procesie oceny. Stanowią bowiem jedyny sposób na systematyczne odkrycie, co dokładnie wymaga poprawy.

Dlaczego to jest istotne: Menendez przyznaje szczerze: „Nie mogę powiedzieć, ile razy to się zdarzyło. Ponieważ nie mogę przejść do szczegółów, bardzo trudno jest mi wiedzieć, jak dostosować mój prompt.” Bez analizy błędów działanie przypomina poruszanie się w ciemno.

Test na jutro: Następnym razem gdy Twój przepływ pracy AI da nieoczekiwany wynik, zamiast frustrować się i poprawiać prompt metodą prób i błędów, skonfiguruj ocenę. Zbierz 10-20 podobnych przypadków niepowodzeń i przeanalizuj wzorce błędów. Sprawdź, czy nie odkryjesz systematycznego problemu, podobnie jak Saravia z pomijanym narzędziem przeszukiwania bazy danych.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: From Prompt to Production: Smarter AI with Evaluations

Tag: Przeplyw Pracy Ai

Od promptu do produkcji: Jak oceny AI zwiększają wydajność przepływu pracy #EN185