Przejdź do treści
Quantima.AI

BLOG

Skąd wiesz, że wdrożenie AI naprawdę działa? Testy akceptacyjne zamiast wrażeń

7 września 2026 · Paweł Marszałko · Quantima.AI

Pilotaż AI kończy się zwykle tak samo: narzędzie działa na pokazie, wszystkim się podoba, a potem miesiącami nikt nie potrafi podjąć decyzji o wpuszczeniu go do realnej pracy. Powód rzadko leży w technologii. Leży w tym, że nikt na początku nie zapisał, co znaczy „działa”. Klasyczne oprogramowanie testuje się prosto: wpisujesz dane, sprawdzasz, czy wynik jest ten sam co w specyfikacji. Model językowy nie daje takiej gwarancji — na to samo pytanie zadane dwa razy odpowie inaczej, i obie odpowiedzi mogą być poprawne albo obie błędne. Odbiór przez porównanie z oczekiwanym wynikiem tu nie zadziała. Zadziała coś innego: zestaw kilkudziesięciu realnych przypadków z Waszej firmy, jasny sposób oceniania odpowiedzi i próg, poniżej którego wdrożenia się nie przyjmuje. To da się przygotować w dwa dni i bez zespołu technicznego — a bez tego pilotaż nie ma jak się skończyć, bo nie ma linii mety.

Dlaczego „wygląda nieźle” jest najdroższą oceną w projekcie

Demo asystenta AI robi wrażenie, bo pyta się o rzeczy, które się zna. Człowiek prowadzący prezentację zadaje pytania, na które zna odpowiedź, więc od razu widzi, że odpowiedź jest sensowna, i przechodzi dalej. Nikt nie pyta o umowę sprzed czterech lat z nietypowym aneksem, bo nikt nie pamięta jej treści na tyle, żeby ocenić wynik.

Ten mechanizm powoduje dwa błędy naraz, w przeciwnych kierunkach. Pierwszy: firma wpuszcza na produkcję narzędzie, które ładnie odpowiada na łatwe pytania i myli się na trudnych, czyli dokładnie tych, dla których je kupowała. Drugi, częstszy: firma nie wpuszcza niczego, bo ktoś zawsze znajdzie jedną złą odpowiedź i zada pytanie „a skąd wiemy, że tak nie będzie zawsze?”. Bez danych ta rozmowa nie ma końca i pilotaż umiera z wyczerpania.

Jedna zła odpowiedź nie jest argumentem, tak samo jak jedna dobra nie jest dowodem. Argumentem jest liczba: na stu realnych pytaniach narzędzie odpowiedziało poprawnie na osiemdziesiąt siedem, w dziewięciu przypadkach uczciwie napisało, że nie wie, a w czterech podało nieprawdę. Dopiero mając taką liczbę, można podjąć decyzję biznesową — bo dopiero wtedy wiadomo, ile pracy zostaje po stronie człowieka i czy to nadal się opłaca.

Zestaw testowy: pięćdziesiąt pytań, które znacie na pamięć

Podstawą odbioru jest zbiór realnych przypadków z Waszej firmy razem z odpowiedziami, które uznajecie za prawidłowe. Nie muszą to być setki pozycji. Pięćdziesiąt dobrze dobranych przypadków wystarcza, żeby zobaczyć, gdzie narzędzie pęka, a taki zestaw zbiera się w jedno popołudnie, jeśli sięgnie się po materiał, który już istnieje.

Najlepszym źródłem są rzeczy, które ludzie i tak robią: maile z pytaniami klientów z ostatniego kwartału, zgłoszenia z helpdesku, pytania, które nowy pracownik zadaje w pierwszym miesiącu, sprawy, o które dzwonią handlowcy. Weźcie je dosłownie, z literówkami i skrótami — model produkcyjnie dostanie właśnie takie, a nie wygładzone przez kogoś, kto wie, jak zadać pytanie.

Ważniejszy od liczby jest skład zestawu. Jeśli wszystkie przypadki są łatwe, wynik będzie wysoki i bezwartościowy.

  1. Około połowy to sprawy typowe i częste — to, co narzędzie będzie robić codziennie. Tu oczekujecie prawie stuprocentowej skuteczności.
  2. Około jednej czwartej to przypadki trudne, ale realne: wyjątek od zasady, klient na innych warunkach, dokument z nieoczywistym aneksem, dwa sprzeczne zapisy w różnych wersjach procedury. Tu zaczyna się prawdziwa ocena.
  3. Kilkanaście procent to pytania, na które prawidłowa odpowiedź brzmi „nie mam takiej informacji”. To najważniejsza kategoria i najczęściej pomijana — narzędzie, które nigdy nie mówi „nie wiem”, zawsze coś zmyśli.
  4. Kilka przypadków spoza zakresu: pytanie o urlop skierowane do asystenta ofertowego, prośba o poradę prawną, próba wyciągnięcia danych, do których pytający nie ma dostępu. Sprawdzacie, czy narzędzie zna swoje granice.
  5. Kilka przypadków wrażliwych na uprawnienia: to samo pytanie zadane przez osobę z działu i spoza niego powinno dać różne odpowiedzi.

Jak oceniać odpowiedź, której nie da się porównać znak w znak

Model napisze to samo na dziesięć sposobów, więc porównywanie tekstu do wzorca nie ma sensu. Sensowna ocena rozkłada się na kilka pytań zadawanych osobno, bo mieszanie ich w jedną notę „dobrze / źle” gubi informację o tym, co właściwie naprawić.

Pierwsze pytanie: czy odpowiedź jest zgodna z prawdą i z Waszymi dokumentami. Drugie: czy jest kompletna, czyli czy nie pominęła warunku, który zmienia wynik. Trzecie: czy narzędzie wskazało źródło i czy to źródło faktycznie zawiera to, co narzędzie twierdzi — najczęstszy błąd systemów opartych na dokumentach to poprawny cytat podpięty pod nieprawdziwy wniosek. Czwarte: czy kiedy nie wie, mówi, że nie wie, zamiast improwizować.

Oceniać powinien człowiek, który zna materię — czyli osoba z działu, nie osoba od IT ani od zakupu narzędzia. Piętnaście przypadków na godzinę to realne tempo, więc pięćdziesiąt pozycji to niecałe cztery godziny pracy jednej osoby. To cały koszt zbudowania podstawy do decyzji, przy wdrożeniu, które kosztuje kilkadziesiąt tysięcy.

Jest też droga na skróty, którą warto znać: drugi model ocenia odpowiedzi pierwszego według Waszych kryteriów. To działa nieźle na powtarzalnych testach po każdej zmianie, ale tylko wtedy, gdy raz sprawdziliście na własnym zestawie, że oceny automatu pokrywają się z ocenami człowieka. Automat, którego nikt nie skalibrował, produkuje wygodne liczby bez pokrycia.

Próg akceptacji ustala się przed testem, nie po nim

To jest jedyna zasada z tego tekstu, którą warto zapamiętać nawet kosztem reszty. Próg negocjowany po zobaczeniu wyniku zawsze wypada tam, gdzie akurat wyszło — bo zawsze znajdzie się wytłumaczenie, że osiemdziesiąt dwa procent to w tym kontekście dobrze.

Próg nie jest jedną liczbą, tylko kilkoma, i nie ma uniwersalnej wartości. Zależy od tego, co się dzieje, gdy narzędzie się pomyli. Przy asystencie, który podpowiada pracownikowi, a pracownik i tak sprawdza wynik, osiemdziesiąt kilka procent trafności bywa w zupełności wystarczające — bo alternatywą jest szukanie po katalogach przez dwadzieścia minut. Przy narzędziu, które wysyła coś do klienta bez kontroli człowieka, ten sam wynik jest nie do przyjęcia.

Osobno warto ustalić próg dla nieprawdy podanej z pewnością siebie, bo to inna kategoria błędu niż „nie znalazłem”. Odpowiedź „nie wiem” kosztuje minutę pracy człowieka. Odpowiedź nieprawdziwa, która brzmi wiarygodnie, kosztuje reklamację albo błędną ofertę. W większości wdrożeń, które prowadzimy, ten drugi wskaźnik jest twardszym warunkiem odbioru niż ogólna trafność.

Zapiszcie te progi w dokumencie odbioru zanim zobaczycie wyniki. Jeżeli pracujecie z dostawcą, ten sam zestaw testowy powinien być załącznikiem do umowy — wtedy odbiór przestaje być dyskusją o wrażeniach i staje się sprawdzeniem, czy warunek jest spełniony.

Co robić, gdy wynik jest za niski

Wynik poniżej progu nie oznacza, że AI się nie nadaje. Oznacza, że macie listę konkretnych porażek, które można obejrzeć pojedynczo — i to jest najbardziej wartościowy produkt całego pilotażu.

Z doświadczenia większość błędów nie ma nic wspólnego z modelem. W dużej części przypadków prawidłowej odpowiedzi nie było w materiale, bo procedura istnieje wyłącznie w głowie jednej osoby, albo w materiale były trzy sprzeczne wersje z różnych lat i nic nie wskazywało, która obowiązuje. To nie jest problem do rozwiązania lepszym promptem — o tym, jak wygląda porządkowanie materiału przed wdrożeniem, pisaliśmy przy danych gotowych na AI.

Druga grupa to źle postawione zadanie: narzędzie miało odpowiadać na wszystko, zamiast na jedną kategorię spraw. Zawężenie zakresu potrafi podnieść trafność o kilkanaście punktów w jeden dzień i zwykle jest tańsze niż jakakolwiek zmiana techniczna.

Trzecia to brak dostępu do systemu, w którym naprawdę jest odpowiedź — narzędzie zgaduje stan zamówienia, bo nikt nie podpiął go do ERP. To jest moment, w którym wraca temat integracji AI z systemami firmy. Dopiero czwarta grupa, zwykle najmniejsza, to rzeczy do poprawienia w samym rozwiązaniu.

Test to nie jest jednorazowy rytuał

Rozwiązanie oparte na AI nie jest stabilne w czasie, i to jest różnica, której najtrudniej przywyknąć firmom przyzwyczajonym do zwykłego oprogramowania. Dostawca modelu wypuszcza nową wersję i wycofuje starą. Ktoś poprawia instrukcję systemową, żeby naprawić jedną rzecz, i psuje trzy inne. Do bazy trafia nowa wersja cennika, a stara zostaje. Zmienia się to, o co pytają ludzie, bo firma weszła w nowy segment.

Dlatego ten sam zestaw testowy warto przepuścić po każdej większej zmianie i profilaktycznie raz na kwartał. Przy zestawie ocenianym automatycznie to godzina pracy, a przy ocenie ręcznej — pół dnia raz na trzy miesiące. Porównanie z poprzednim wynikiem jest tu ważniejsze niż sama wartość: spadek z osiemdziesięciu siedmiu na siedemdziesiąt jeden procent po zmianie wersji modelu jest sygnałem, którego bez testu nikt by nie zauważył, dopóki nie zauważyłby go klient.

Do tego dochodzi obserwacja realnego ruchu. Wystarczy prosty mechanizm oceny przy odpowiedzi i comiesięczny przegląd kilkudziesięciu losowych rozmów przez osobę z działu. Chodzi o wychwycenie dryfu: pytań, których nikt nie przewidział, i tematów, w których narzędzie systematycznie mija się z prawdą.

Trzy liczby, które warto mieć obok trafności

Trafność mówi, czy narzędzie działa. Nie mówi, czy warto było. Do decyzji o przedłużeniu wdrożenia potrzebne są jeszcze trzy rzeczy, mierzone przed i po.

  1. Czas obsługi jednej sprawy — mierzony na tych samych typach zgłoszeń, nie średnio po wszystkim. Bez pomiaru sprzed wdrożenia nie ma z czym porównać, więc to jedyna liczba, którą trzeba zebrać zanim cokolwiek ruszy.
  2. Udział spraw domkniętych bez eskalacji do człowieka. Ta liczba rośnie powoli i to jest normalne — spada wtedy, gdy zespół przestał ufać narzędziu, co zwykle widać wcześniej niż w ankiecie.
  3. Rzeczywisty koszt miesięczny: licencje plus zużycie modelu plus czas ludzi na utrzymanie, weryfikację i aktualizację materiału. Ten trzeci składnik jest tym, który najczęściej wywraca uzasadnienie — rozwinęliśmy to w tekście o tym, ile kosztuje wdrożenie AI.

Od czego zacząć w tym tygodniu

Jeżeli macie w firmie pilotaż, który stoi w miejscu od dwóch miesięcy, prawdopodobnie brakuje mu nie funkcji, tylko kryterium odbioru. Zacznijcie od najprostszej możliwej rzeczy: wybierzcie proces, wyciągnijcie trzydzieści realnych spraw z ostatniego kwartału, dopiszcie do nich prawidłowe odpowiedzi i ustalcie, jaki procent wystarczy, żeby powiedzieć „tak”. To pół dnia pracy, po którym rozmowa o wdrożeniu przestaje być rozmową o opiniach.

Jeśli dopiero wybieracie dostawcę, ten sam zestaw jest najlepszym narzędziem zakupowym, jakie możecie mieć. Zamiast oglądać cudze demo na cudzych danych, dajcie każdemu kandydatowi te same trzydzieści spraw i porównajcie wyniki. Różnice, które wtedy zobaczycie, nie mają nic wspólnego z tym, co widać na prezentacji.

U nas testy akceptacyjne są częścią każdego wdrożenia, a nie dodatkiem na końcu — zestaw powstaje razem z zakresem prac, zanim zapadną decyzje techniczne. Jak wygląda pierwsza faza takiej pracy, opisaliśmy przy audycie AI w firmie. Zakres konsultingu i wdrożeń AI znajdziesz osobno, stawki w cenniku, a jeśli chcesz przejść przez to na własnym procesie — umów bezpłatną konsultację.

Chcesz sprawdzić, gdzie AI zwróci się w Twojej firmie?

Bezpłatna konsultacja 15–30 minut, wycena w 1 dzień roboczy.