Klasyczną aplikację można przetestować, porównując określony input z oczekiwanym outputem. W systemach wykorzystujących sztuczną inteligencję sytuacja jest bardziej złożona. Ten sam prompt może prowadzić do różnych poprawnych odpowiedzi, jakość wyniku zależy od kontekstu i danych, a w rozwiązaniach RAG czy agentowych trzeba dodatkowo sprawdzić retrieval, integracje, uprawnienia i działania wykonywane w innych systemach.
Dlatego testowanie AI nie powinno kończyć się na pytaniu: „czy model udzielił poprawnej odpowiedzi?”. Produkcyjny system AI trzeba oceniać jako całość – od danych wejściowych, przez retrieval i zachowanie modelu, aż po bezpieczeństwo, integracje, wydajność i monitoring po wdrożeniu.
Najważniejszy wniosek: w systemie AI jakość nie zależy wyłącznie od modelu. Wynik jest efektem działania całego łańcucha: dane → retrieval → model → prompt → integracje → permissions → aplikacja → monitoring. Strategia QA powinna obejmować każdą z tych warstw.
W tym artykule pokazujemy, czym testowanie systemów AI różni się od klasycznego QA, jakie obszary warto zweryfikować przed wdrożeniem LLM, RAG lub agenta AI na produkcję oraz jak określić kryteria, które pozwolą podjąć decyzję go/no-go przed release’em.
Dlaczego klasyczne QA nie wystarczy w systemach AI?
W tradycyjnym oprogramowaniu znaczna część testów opiera się na przewidywalnym zachowaniu systemu. Dla określonych warunków wejściowych oczekujemy konkretnego rezultatu. W przypadku komponentów generatywnych odpowiedź może być niedeterministyczna – dwie różne odpowiedzi mogą być jednocześnie akceptowalne.
To zmienia sposób definiowania jakości. Zamiast sprawdzać wyłącznie, czy wynik jest identyczny z oczekiwanym, trzeba ocenić jego poprawność, kompletność, zgodność z kontekstem, bezpieczeństwo oraz zachowanie systemu w określonych scenariuszach.
| Klasyczna aplikacja | System wykorzystujący AI |
|---|---|
| Input prowadzi do oczekiwanego outputu. | Ten sam input może prowadzić do kilku akceptowalnych odpowiedzi. |
| Assertion: wynik jest zgodny albo niezgodny. | Evaluation: wynik może wymagać oceny według kilku kryteriów. |
| Regresja wynika przede wszystkim ze zmian w kodzie. | Regresję może wywołać zmiana modelu, promptu, danych, retrieval albo integracji. |
| Testy koncentrują się na aplikacji i integracjach. | Trzeba dodatkowo ocenić dane, model, kontekst, retrieval i zachowanie AI. |
| Release stabilizuje zachowanie aplikacji. | Jakość trzeba obserwować także po wdrożeniu. |
AI QA nie zastępuje klasycznego QA. Nadal trzeba testować API, UI, integracje, autoryzację, wydajność i procesy biznesowe. Dochodzi jednak nowa warstwa – ocena zachowania komponentu AI i jego zależności od danych oraz kontekstu.
Warto wiedzieć: NIST ujmuje testowanie, ewaluację, walidację i weryfikację AI w ramach podejścia TEVV, a AI Risk Management Framework odnosi zarządzanie ryzykiem do całego cyklu życia systemu. Zobacz NIST AI RMF 1.0.
7 warstw testowania systemu AI
Największym błędem byłoby przetestowanie samego endpointu modelu i uznanie całego rozwiązania za zweryfikowane. W środowisku produkcyjnym model jest tylko jednym z elementów architektury.
| Warstwa | Co testujemy? | Przykładowe ryzyko |
|---|---|---|
| 1. Data / Input | Jakość, kompletność, format i przypadki brzegowe. | Model dostaje niepełne albo błędne informacje. |
| 2. Retrieval / RAG | Czy pobierany jest właściwy kontekst? | Model generuje wiarygodnie brzmiącą odpowiedź na podstawie niewłaściwego dokumentu. |
| 3. Model / Output | Poprawność, kompletność, zgodność z instrukcją i źródłami. | Halucynacja lub nieuzasadniona pewność odpowiedzi. |
| 4. Security | Prompt injection, dane poufne, próby obejścia zasad. | Użytkownik uzyskuje informacje, których nie powinien zobaczyć. |
| 5. Agents / Tools | Dobór narzędzi, parametry, działania, permissions i workflow. | Agent wykonuje technicznie poprawną, ale niewłaściwą operację biznesową. |
| 6. Non-functional | Latency, availability, scalability i koszt. | System działa dobrze w demo, ale jest zbyt wolny lub kosztowny na produkcji. |
| 7. Production | Regresja, monitoring, anomalie i zmiany jakości. | Jakość spada po zmianie danych, promptu albo providera. |
1. Dane i input: czy testujemy również to, co dostaje AI?
Jeżeli dane wejściowe są niekompletne, nieaktualne albo niespójne, nawet dobry model może wygenerować słaby wynik. Dlatego testowanie systemu AI powinno zaczynać się przed samym modelem.
Warto przygotować zestaw przypadków odzwierciedlających nie tylko scenariusze idealne, ale również dane, z którymi system rzeczywiście spotka się na produkcji.
Co sprawdzić?
- brakujące informacje,
- duplikaty i sprzeczne rekordy,
- nietypowe formaty,
- bardzo krótkie i bardzo długie inputy,
- błędy użytkownika,
- dane w różnych językach,
- nieaktualne informacje,
- przypadki rzadkie i brzegowe.
Red flag: zestaw testowy składa się wyłącznie z kilkunastu przykładów, które wcześniej wykorzystano do projektowania promptu. Taki test może potwierdzić działanie znanych przypadków, ale niewiele mówi o zachowaniu systemu przy nowych danych.
Jeżeli problem pojawia się już na poziomie źródeł, ownershipu, freshness czy pipeline’ów, warto najpierw sprawdzić czy dane są gotowe do wykorzystania przez AI.
2. Jak testować RAG i retrieval?
W architekturze RAG jakość odpowiedzi zależy nie tylko od możliwości LLM. Najpierw system musi znaleźć właściwy fragment wiedzy. Jeżeli retrieval zwróci nieodpowiednie dokumenty, model może wygenerować bardzo przekonującą odpowiedź na podstawie niewłaściwego kontekstu.
Pytanie → retrieval → kontekst → LLM → odpowiedź
Dlatego evaluation warto rozdzielić na co najmniej dwa poziomy:
Retrieval qualityCzy system pobiera dokumenty i fragmenty, które rzeczywiście są potrzebne do odpowiedzi? | Answer qualityCzy model prawidłowo wykorzystuje pobrany kontekst i nie dodaje informacji, których w nim nie ma? |
W testach RAG warto sprawdzić m.in.:
- czy właściwy dokument znajduje się wśród pobranych wyników,
- czy retrieval nie zwraca zbyt dużej ilości nieistotnego kontekstu,
- jak system zachowuje się, gdy odpowiedzi nie ma w bazie wiedzy,
- czy informacje po aktualizacji dokumentu pojawiają się w wynikach,
- czy użytkownik otrzymuje odpowiedź wyłącznie z danych, do których ma dostęp,
- czy chunking i sposób indeksowania nie powodują utraty istotnego kontekstu.
Ważne: zmiana modelu nie naprawi problemu, jeżeli właściwa informacja w ogóle nie trafiła do kontekstu. W przypadku RAG testowanie retrieval powinno być oddzielnym elementem strategii QA.
Źródło eksperckie: Microsoft Foundry rozdziela evaluation RAG na ocenę jakości odpowiedzi oraz ocenę procesu retrieval, uwzględniając m.in. groundedness, relevance i document retrieval. Zobacz dokumentację RAG Evaluators.
3. Jak oceniać odpowiedzi LLM?
W przypadku generatywnego AI często nie istnieje jedna idealna odpowiedź, którą można zapisać jako klasyczny expected result. Potrzebne są więc jawnie zdefiniowane kryteria oceny.
| Kryterium | Pytanie testowe |
|---|---|
| Correctness | Czy odpowiedź jest merytorycznie poprawna? |
| Groundedness | Czy odpowiedź jest oparta na dostarczonym kontekście i nie wprowadza nieuzasadnionych informacji? |
| Completeness | Czy zawiera informacje potrzebne użytkownikowi w danym procesie? |
| Relevance | Czy odpowiada na rzeczywiste pytanie zamiast generować poboczną treść? |
| Instruction following | Czy system przestrzega zasad i formatu określonego dla danego use case’u? |
| Uncertainty / abstention | Czy system potrafi powstrzymać się od odpowiedzi, gdy nie ma wystarczających danych? |
Golden dataset zamiast kilku ręcznych promptów
Dobrą podstawą evaluation jest stabilny zestaw reprezentatywnych scenariuszy zawierający pytania, wymagany kontekst, kryteria akceptacji oraz przypadki, w których system powinien odmówić odpowiedzi lub poprosić o dodatkowe informacje.
Taki dataset pozwala porównywać kolejne wersje promptów, modeli, retrieval i konfiguracji według tych samych kryteriów. Dzięki temu zespół może sprawdzić nie tylko, czy zmiana poprawiła konkretny przypadek, ale również czy nie pogorszyła zachowania w innych scenariuszach.
Automatyczna ewaluacja nie musi oznaczać pełnej automatyzacji decyzji. Część kryteriów można mierzyć automatycznie, a część może wymagać oceny eksperta domenowego. W bardziej krytycznych zastosowaniach warto łączyć automated evaluation z human evaluation zamiast polegać na jednym evaluatorze.
4. AI security testing: co dzieje się, gdy użytkownik lub dane wejściowe nie zachowują się zgodnie ze scenariuszem?
System powinien być testowany nie tylko na poprawnych pytaniach. Użytkownik może próbować ominąć ograniczenia, uzyskać poufne informacje albo zmienić zamierzone zachowanie systemu. Zagrożenie może pochodzić także z zewnętrznej treści przetwarzanej przez AI.
Scenariusze do uwzględnienia:
- direct prompt injection – złośliwe instrukcje przekazane bezpośrednio przez użytkownika,
- indirect prompt injection – instrukcje ukryte w dokumentach, stronach, wiadomościach lub innych źródłach przetwarzanych przez AI,
- próby ujawnienia instrukcji systemowej,
- próby dostępu do danych innego użytkownika,
- manipulowanie formatem lub strukturą wejścia,
- RAG poisoning – wprowadzanie do bazy wiedzy treści mających wpłynąć na zachowanie modelu,
- próby wymuszenia działania poza zakresem roli systemu,
- manipulowanie narzędziami lub parametrami wywołań agenta.
Szczególnie ważne przy RAG i agentach: AI nie powinno umożliwiać użytkownikowi uzyskania informacji lub wykonania operacji, do których nie ma on uprawnień w systemie źródłowym.
Źródło eksperckie: OWASP opisuje zarówno direct, jak i remote/indirect prompt injection, a także RAG poisoning oraz ataki specyficzne dla agentów. Zobacz OWASP LLM Prompt Injection Prevention Cheat Sheet.
5. Jak testować agentów AI i wykonywane przez nich działania?
W chatbocie błędna odpowiedź może oznaczać przede wszystkim problem informacyjny. W systemie agentowym konsekwencje mogą być większe, ponieważ AI może zmodyfikować rekord, wysłać wiadomość, utworzyć zgłoszenie, wywołać API albo uruchomić kolejny proces.
Dlatego testowanie agentów powinno obejmować nie tylko jakość końcowego wyniku, ale również obserwowalny przebieg działania i granice autonomii: jakie narzędzia agent wybiera, jakie przekazuje parametry, w jakiej kolejności wykonuje kroki oraz kiedy powinien zatrzymać się i poprosić o akceptację człowieka.
| Obszar | Pytanie testowe |
|---|---|
| Task completion | Czy agent rzeczywiście wykonał zadanie, które miał wykonać? |
| Tool selection | Czy agent wybiera właściwe i potrzebne narzędzie? |
| Tool input | Czy przekazuje do API prawidłowe parametry i wartości? |
| Permissions | Czy może wykonać tylko operacje dostępne dla danego użytkownika lub roli? |
| Sequence | Czy kolejne działania wykonywane są we właściwej kolejności i bez zbędnych kroków? |
| Human approval | Czy operacja wymagająca akceptacji zatrzymuje się przed wykonaniem? |
| Failure handling | Co dzieje się, gdy API zwraca błąd albo część procesu nie powiedzie się? |
Najważniejszy test nie brzmi wyłącznie: „Czy agent potrafi wykonać zadanie?”.
Trzeba również sprawdzić: „Czy potrafi zatrzymać działanie, kiedy nie ma wystarczających danych, uprawnień albo wymaganej zgody?”.
Źródło eksperckie: Microsoft Foundry rozróżnia w evaluation agentów ocenę całego rezultatu od oceny kolejnych kroków workflow. Wśród obszarów process evaluation wskazuje m.in. tool selection, tool input accuracy, tool output utilization i tool call success. Zobacz dokumentację Agent Evaluators.
6. Latency, availability i koszt – czyli AI również wymaga testów niefunkcjonalnych
System może udzielać bardzo dobrych odpowiedzi, a mimo to nie nadawać się do produkcji. Powodem może być czas odpowiedzi, ograniczenia API, brak skalowalności albo koszt pojedynczej operacji.
Przed produkcją warto sprawdzić:
- czas odpowiedzi dla różnych typów zapytań,
- zachowanie przy zwiększonej liczbie równoległych użytkowników,
- timeouty i retry,
- zachowanie przy niedostępności modelu lub zewnętrznego API,
- limity i rate limits dostawcy,
- fallback mechanisms,
- średni koszt pojedynczej interakcji lub procesu,
- wpływ długości kontekstu na latency i koszt,
- zachowanie systemu przy bardzo dużych inputach.
Proof of Concept może pokazać, że AI działa. Testy przed produkcją muszą odpowiedzieć na inne pytanie: czy rozwiązanie będzie działało wystarczająco szybko, stabilnie i ekonomicznie przy realnym wykorzystaniu?
To właśnie na tym etapie wiele projektów odkrywa problemy, których nie było widać podczas demonstracji. Szerzej opisujemy je w materiale o tym, dlaczego projekty AI zatrzymują się między PoC a produkcją.
7. AI QA nie kończy się na deployment – regression testing i monitoring produkcyjny
W klasycznej aplikacji nowa wersja kodu jest oczywistym triggerem do regresji. W rozwiązaniu AI potencjalnych źródeł zmiany jest więcej.
Regresję warto uruchomić m.in. po zmianie:
- modelu lub jego wersji,
- providera,
- system promptu,
- prompt templates,
- parametrów generowania,
- embedding modelu,
- chunkingu lub retrieval logic,
- źródeł danych,
- narzędzi dostępnych agentowi,
- uprawnień lub integracji.
Co monitorować po wdrożeniu?
| Obszar | Przykład |
|---|---|
| Quality | Spadek jakości odpowiedzi w konkretnych kategoriach zapytań. |
| Errors | Błędy API, retrieval i narzędzi. |
| Latency | Wydłużenie czasu odpowiedzi. |
| Cost | Wzrost kosztu pojedynczego procesu. |
| Usage | Zmiana sposobu korzystania z systemu przez użytkowników. |
| Security events | Nietypowe próby uzyskania danych lub wykonania operacji. |
W systemach AI produkcja staje się częścią procesu QA. Testy przed deploymentem pozostają konieczne, ale środowisko produkcyjne ujawnia rzeczywiste kombinacje inputów, zachowań użytkowników i warunków działania, których nie zawsze da się w pełni odtworzyć wcześniej.
Źródło eksperckie: NIST wskazuje różnicę między pre-deployment evaluation w kontrolowanych warunkach a monitoringiem po wdrożeniu w realnym środowisku, gdzie mogą ujawnić się nieprzewidziane outputy i konsekwencje działania systemu. Zobacz NIST AI 800-4.
Jak ustalić kryteria akceptacji dla systemu AI?
Samo przeprowadzenie testów nie daje jeszcze odpowiedzi, czy system jest gotowy do produkcji. Zespół potrzebuje kryteriów, które określą, jaki poziom jakości, ryzyka, wydajności i kosztu jest akceptowalny dla konkretnego zastosowania.
Nie istnieje jeden uniwersalny próg odpowiedni dla każdego systemu AI. Inne wymagania może mieć wewnętrzny asystent wyszukujący dokumentację, a inne agent wykonujący operacje w systemie finansowym. Kryteria powinny wynikać z use case’u, konsekwencji potencjalnego błędu i tolerancji ryzyka organizacji.
| Obszar | Przykładowe kryterium | Pytanie go/no-go |
|---|---|---|
| Retrieval | Skuteczność odnajdywania właściwych źródeł dla scenariuszy testowych. | Czy system regularnie dostarcza modelowi kontekst potrzebny do odpowiedzi? |
| Output quality | Wynik oceny correctness, groundedness, completeness lub innej rubryki. | Czy jakość odpowiedzi jest wystarczająca dla konkretnego procesu biznesowego? |
| Agent | Task completion, poprawność doboru narzędzi i parametrów. | Czy agent kończy właściwe zadanie bez wykonywania niepożądanych kroków? |
| Security | Brak dostępu do danych lub operacji spoza dozwolonego zakresu. | Czy testy negatywne ujawniły scenariusz przekroczenia uprawnień? |
| Performance | Akceptowalne latency przy zakładanym obciążeniu. | Czy czas odpowiedzi pozwala wykorzystać rozwiązanie w docelowym procesie? |
| Cost | Maksymalny akceptowalny koszt interakcji lub zakończonego procesu. | Czy rozwiązanie zachowuje ekonomikę przy docelowej skali? |
Nie zaczynaj od arbitralnego „95% jakości”. Najpierw określ, które błędy są krytyczne, jaki wpływ mają na użytkownika lub proces oraz które scenariusze muszą działać niezawodnie. Dopiero na tej podstawie warto ustalać konkretne progi.
Checklista: czy system AI jest gotowy do testów przed produkcją?
Przed release’em warto sprawdzić, czy zespół potrafi odpowiedzieć „tak” na poniższe pytania.
- Czy mamy reprezentatywny zestaw scenariuszy testowych?
- Czy obejmuje również błędy, przypadki brzegowe i scenariusze negatywne?
- Czy oddzielnie mierzymy jakość retrieval i jakość odpowiedzi?
- Czy mamy zdefiniowane kryteria akceptacji i progi go/no-go dla kluczowych scenariuszy?
- Czy wiemy, jak system powinien zachować się przy braku wystarczających danych?
- Czy testujemy direct oraz indirect prompt injection i próby obejścia ograniczeń?
- Czy permissions działają również w warstwie RAG i agentów?
- Czy agent nie może wykonywać operacji poza swoim zakresem?
- Czy działania wyższego ryzyka mają odpowiedni mechanizm zatwierdzania?
- Czy przetestowaliśmy latency, load, timeouty i niedostępność providera?
- Czy znamy koszt działania systemu przy zakładanym wykorzystaniu?
- Czy zmiany modelu, promptu, retrieval i danych uruchamiają regresję?
- Czy możemy odtworzyć wersję modelu, promptu, danych i konfiguracji dla konkretnego wyniku?
- Czy mamy monitoring jakości i zachowania systemu po produkcji?
Mamy głównie TAKMożna przejść do kontrolowanego release’u i obserwacji rozwiązania na produkcji zgodnie z przyjętymi kryteriami. | Mamy dużo „NIE WIEMY”Najpierw trzeba zdefiniować kryteria jakości, observability, progi akceptacji i sposób reprodukcji wyników. | Mamy dużo NIERelease może oznaczać przeniesienie nierozpoznanego ryzyka bezpośrednio na użytkowników i proces biznesowy. |
Jak Edge One Solutions może wesprzeć testowanie systemów AI?
W Edge One Solutions patrzymy na jakość systemu AI szerzej niż na sam model. Rozwiązanie produkcyjne obejmuje również dane, aplikację, integracje, dostęp, środowisko infrastrukturalne oraz proces utrzymania po wdrożeniu.
W zależności od architektury i use case’u możemy połączyć kompetencje QA, AI, Data Engineering, developmentu i utrzymania, aby zaprojektować testowanie obejmujące cały przepływ systemu.
Testing & QAStrategia testów, automation, regression, integracje, testy systemowe i niefunkcjonalne. | Artificial IntelligenceArchitektura rozwiązania, LLM, RAG, integracja komponentów AI i przygotowanie do produkcji. |
Data EngineeringJakość danych, źródła, pipeline’y, integracje i przygotowanie warstwy danych wspierającej system AI. | Managed ServicesMonitoring, utrzymanie i kontrola działania rozwiązania po wdrożeniu produkcyjnym. |
Jeżeli projekt jest jeszcze na wcześniejszym etapie, warto zacząć od oceny gotowości danych do AI. Jeśli PoC już działa, ale pojawiają się pytania o skalowanie, integracje i utrzymanie, zobacz również materiał o przejściu z AI PoC do produkcji.
W projektach objętych wymaganiami regulacyjnymi pomocny może być również nasz przewodnik dotyczący technicznego przygotowania systemów AI do AI Act.
Budujesz system AI i chcesz zweryfikować jego jakość przed produkcją?
Możemy pomóc zaprojektować podejście do testowania obejmujące aplikację, dane, model, RAG, integracje oraz zachowanie rozwiązania w środowisku produkcyjnym.
Sprawdź nasze kompetencje Testing & QA
Zobacz również rozwiązania AI dla biznesu oraz Data Engineering.
Standardy i materiały, do których warto się odwołać przy projektowaniu AI QA
Poniższe materiały nie zastępują strategii testów dopasowanej do konkretnego systemu, ale stanowią wartościowy punkt odniesienia dla zespołów projektujących evaluation, security testing i monitoring rozwiązań AI.
1. NIST – AI Risk Management Framework i TEVV
Ramy zarządzania ryzykiem AI oraz materiały dotyczące testowania, ewaluacji, walidacji i weryfikacji systemów AI.
2. NIST – monitoring systemów AI po wdrożeniu
Materiał poświęcony wyzwaniom monitorowania wdrożonych systemów AI i różnicy między evaluation w środowisku kontrolowanym a obserwacją realnego działania.
NIST AI 800-4 – Challenges to the Monitoring of Deployed AI Systems
3. OWASP – bezpieczeństwo LLM i RAG
Praktyczne materiały dotyczące prompt injection, indirect prompt injection, RAG poisoning, kontroli dostępu i nowych powierzchni ataku w rozwiązaniach RAG.
OWASP LLM Prompt Injection Prevention ·
OWASP RAG Security Cheat Sheet
4. Microsoft Foundry – evaluation RAG i agentów AI
Dokumentacja pokazująca przykładowe podejście do oceny groundedness, relevance i retrieval oraz do oceny końcowego rezultatu i kroków wykonywanych przez agentów.
Microsoft Foundry – RAG Evaluators ·
Microsoft Foundry – Agent Evaluators
FAQ – testowanie systemów AI
Podsumowanie: nie testujemy modelu – testujemy system
Wybór mocniejszego modelu nie rozwiąże problemu z błędnymi danymi, niewłaściwym retrieval, nieprawidłowymi permissions czy niestabilną integracją. Z tego powodu QA dla AI powinno obejmować całą architekturę rozwiązania.
Przed produkcją warto zweryfikować siedem obszarów: dane, retrieval, output modelu, security, agentów i integracje, wymagania niefunkcjonalne oraz monitoring produkcyjny. Równie ważne jest zdefiniowanie kryteriów akceptacji, które pozwalają ocenić, czy wynik testów faktycznie uzasadnia release.
Dzięki temu decyzja go/no-go nie opiera się na kilku udanych demonstracjach, ale na mierzalnych kryteriach jakości, obserwowalnym zachowaniu systemu i scenariuszach możliwie zbliżonych do rzeczywistego środowiska biznesowego.
