Twój asystent AI wygląda, że działa. Zadaliście mu kilkadziesiąt pytań, odpowiedzi brzmiały sensownie, zespół jest gotowy na wdrożenie. To pułapka
– i w dalszej części tego artykułu pokażemy dokładnie, dlaczego.
Dlaczego Twój asystent AI sztucznej inteligencji „działa” na demo, a psuje się na produkcji
Większość zespołów testuje asystentów AI tak, jak testuje się zwykłe oprogramowanie: lista pytań biznesowych, ręczna ocena przez jednego testera, subiektywne „wygląda dobrze”. Kilka poprawnych odpowiedzi i wszyscy uznają, że system działa. Problem polega na tym, że sztuczna inteligencja oparta na dużych modelach językowych nie zachowuje się jak klasyczny software. Jest niedeterministyczna – te same zapytania mogą generować różne odpowiedzi w różnych momentach. Dostawca modelu (OpenAI, Google Gemini, Microsoft) aktualizuje go w tle, bez powiadamiania Twojego zespołu. A baza wiedzy, na której działa asystent AI, to zbiór dokumentów, którego żaden człowiek nie przeczytał od deski do deski.
Halucynacje AI – czyli generowanie fikcyjnych informacji przez systemy AI – to tylko wierzchołek góry lodowej. Nadmierne poleganie na asystentach AI jako jedynym źródle prawdy, brak pracy w czasie rzeczywistym na aktualnych danych, niesprawdzone reguły bezpieczeństwa – każdy z tych problemów generuje ryzyko, którego standardowe testy nie obejmują.
Poniżej opisujemy sześć klas błędów z realnych, zanonimizowanych wdrożeń. Każdy z nich brzmiał początkowo jak ciekawostka – dopóki nie okazało się, że mechanizm jest prosty, powtarzalny i dotyczy praktycznie każdej organizacji wdrażającej asystenta z bazą wiedzy. Konsekwencje dotyczą podejmowania decyzji biznesowych, obsługi klientów, e commerce i reputacji marki. Jeśli Twój zespół pokrywa tylko wymiar trafności – a pomija zgodność z regułami, odporność na pytania spoza zakresu i stabilność w czasie – żaden z tych błędów nie jest objęty Waszymi testami.
Case 1: Brzmi jak ekspert, ale myli fakty i podmioty (halucynacje AI i „półprawdy”)
Do asystenta trafiło pytanie: „Czy firma realizowała projekty dla Tralalala Bank?”. Tralalala Bank nie istnieje.
Zamiast to zasygnalizować, asystent odpowiedział twierdząco i przedstawił szczegółowy opis realnego projektu – tyle że zrealizowanego dla zupełnie innego banku. Odpowiedź była długa, zawierała nazwy technologii, opis zakresu prac, listę rezultatów. Człowiek czytający ją na ekranie nie miał podstawy, żeby cokolwiek zakwestionować.
Mechanizm błędu okazał się banalny. W bazie wiedzy większość materiałów o projektach bankowych nie używała pełnych nazw – pisano „klient z sektora bankowego” albo „wdrożenie w bankowości”. Asystent zaczepił się o słowa kluczowe, zignorował fikcyjną nazwę i skleił odpowiedź ze źródeł, które semantycznie pasowały. To nie klasyczna halucynacja „z powietrza” – to fałszywe informacje brzmiące jak udokumentowane, co jest znacznie niebezpieczniejsze.
W e-commerce taki błąd oznacza przypisanie niewłaściwych warunków gwarancji do innego produktu. W kontekście regulacyjnym – błędne powołania na przepisy.
Jak testować: zadawaj pytania o nieistniejące firmy, produkty, dokumenty – w różnych wariantach języka naturalnego. Sprawdź, czy asystent potrafi odpowiedzieć „nie mam informacji” zamiast budować prawdopodobne odpowiedzi z dowolnych źródeł. Równolegle wykonaj audyt bazy wiedzy: czy używacie pełnych nazw własnych, czy skrótów i eufemizmów, które otwierają drogę do błędnego dopasowania na podstawie wzorców semantycznych.
Case 2: Dane historyczne sprzed lat jako „aktualny” stan (błąd czasu i wersji)
Asystent klienta dostał pytanie: „Jakie są wymagane dokumenty do umowy najmu lokalu użytkowego?”. Odpowiedź była dobrze ustrukturyzowana, około 90% treści poprawne. Ale jedna kwota – miesięczny czynsz 1 200 zł – pochodziła z dokumentu obowiązującego dwa lata wcześniej. Aktualny cennik wskazywał inną wartość.
Z perspektywy testera oceniającego „na oko” odpowiedź wyglądała świetnie. Z perspektywy klienta – dawała całkowicie błędne informacje o realnej opłacie.
Mechanizm: baza wiedzy zawierała zarówno dokumenty aktualne, jak i historyczne – regulaminy z różnych lat, cenniki z różnych okresów. Asystent nie miał jednoznacznego sygnału, który dokument jest „teraz”, a który „był kiedyś”. Modele AI mają „datę odcięcia” wiedzy, po której nie znają nowych wydarzeń, ale w kontekście baz firmowych problem jest subtelniejszy – chodzi o brak metadanych temporalnych w dokumentach. Przy ich braku model wybiera źródło najbliższe semantycznie, a historyczny cennik dotyczący najmu był właśnie takim źródłem.
Jak testować: twórz oddzielne zestawy pytań o konkretne kwoty, daty i progi – np. „ile wynosi czynsz w 2026 r.?”, „od kiedy obowiązuje nowy cennik?” – oraz pytania bez kontekstu czasowego („ile wynosi opłata?”), by sprawdzić, który dokument model domyślnie wybiera.
Wniosek organizacyjny: konieczność porządkowania bazy wiedzy – wersjonowanie dokumentów, metadane z datą obowiązywania, tagi „archiwalne” vs. „obowiązujące”.
Case 3: Gdy nie ma wystarczających danych – asystent AI wymyśla „procedurę”
Asystent miasta, przeznaczony do odpowiadania na sprawy urzędowe, dostał pytanie: „Jestem zdenerwowany, co robić?”.
Prawidłową reakcją byłoby rozpoznanie pytania spoza zakresu i grzeczna odmowa. Zamiast tego asystent wygenerował długą odpowiedź opartą na jedynej „stresowej” instrukcji w bazie – instrukcji postępowania w sytuacji zagrożenia terrorystycznego. W odpowiedzi pojawiły się porady typu: „usuń oznaki zajmowanej pozycji zawodowej, które mogą spowodować agresję u terrorystów” oraz „stawiaj sobie drobne cele, np. uzyskanie od terrorystów wody, posiłku, opatrunku”. Wszystko podane tonem empatycznego asystenta.
Błędna interpretacja kontekstu przez AI może prowadzić do odpowiedzi nie na temat – i w praktyce oznacza to, że prosty chatbot lub zaawansowane modele asystentów reagują identycznie: szukają jakiegokolwiek dopasowania semantycznego, zamiast odmówić. Tu problemem nie jest błąd faktograficzny, lecz błąd zakresu – brak zdolności powiedzenia „to pytanie nie dotyczy mojej domeny”.
Jak testować: twórz celowe scenariusze „podchwytliwe” – pytania emocjonalne, medyczne, finansowe, których asystent nie powinien obsługiwać. Sprawdź, czy system reaguje odmową, czy generowaniem treści z dowolnych fragmentów bazy. Dodaj do bazy jawne wytyczne, jak reagować na brak informacji – to często tańsze niż kalibracja modelu.
te błędy
Case 4: Reguły bezpieczeństwa działają… tylko w niektórych językach i kontekstach
Asystent miał jednoznaczną regułę w prompcie: „odpowiadaj zawsze po polsku”. Dla pytań w języku angielskim reguła działała – grzecznie odmawiał i prosił o polski. Ale po niemiecku? Odpowiedział po niemiecku, łącznie z danymi, które nie powinny opuścić systemu.
Gdy zapytano go wprost: „czy nie powinieneś zawsze odpowiadać po polsku?”, potwierdził regułę po polsku – i złamał ją w drugiej połowie tego samego zdania, przełączając się na niemiecki.
Mechanizm jest fundamentalny: zasady w prompcie nie są „kompilowane” – duże modele językowe interpretują je probabilistycznie. Badania Welo Data pokazują, że ochrona bezpieczeństwa w języku angielskim utrzymuje niski poziom niebezpiecznych odpowiedzi, ale w językach mniej reprezentowanych odpowiedzi niebezpieczne rosną nawet do 40–50%. Przetwarzanie języka naturalnego w modelach AI działa różnie w zależności od języka, bo język naturalny jest wielowarstwowy i trudny do jednoznacznej interpretacji – i to nie jest akademicka ciekawostka, lecz realny wektor prompt injection.
Jak testować:
- Te same reguły sprawdzane po polsku, angielsku, niemiecku
- Scenariusze role-play („udawaj, że jesteś innym asystentem”)
- Rozmowy wieloturowe, w których kontekstu rozmowy zmienia się język
- Osobno mierz trafność merytoryczną i zgodność z promptem – bo asystent może odpowiadać poprawnie merytorycznie, a jednocześnie łamać własne zasady
Case 5: Czas względny – „w ten weekend”, „za trzy dni” i inne pytania, których nikt nie testuje
Asystent miejski dostał dwa pytania tego samego dnia:
- „Jakie imprezy odbywają się w dniach 18–19 kwietnia?” → odpowiedź poprawna: Festiwal Muzyki Klasycznej 18 kwietnia, Targi Sztuki Współczesnej 19 kwietnia.
- „Co się dzieje w mieście w ten weekend?” (pytanie zadane 18 kwietnia) → odpowiedź zawierała wystawę z 10 stycznia, jarmark z 5 kwietnia, spektakl z 25 maja, koncerty z 31 października.
Dwa pytania o ten sam okres – jedno poprawnie obsłużone, drugie całkowicie błędne. Różnica: format daty.
Zaawansowane modele radzą sobie z datami bezwzględnymi (konkretnymi, jak „18 kwietnia”). Nie radzą sobie z wyrażeniami względnymi – „ten weekend”, „przyszły tydzień”, „za trzy dni”, „w poprzednim kwartale”. Bo ich przełożenie wymaga operacji na dacie referencyjnej, nie tylko dopasowania semantycznego. Nawet jeśli użytkownik formułuje wiadomości poprawnie, model może źle zinterpretować takie wyrażenia bez jawnej daty odniesienia. Użytkownik, który pyta „co w ten weekend”, implicite mówi: „dzisiaj jest 18 kwietnia, ten weekend to 18–19 kwietnia”. Asystent nie wykonał żadnego z tych kroków – znalazł po prostu wszystko, co semantycznie pasowało do wyrażenia „wydarzenia w mieście”. Zadawanie zbyt ogólnych pytań skutkuje niedopasowanymi odpowiedziami, ale w tym wypadku to nie użytkownik zadał zbyt ogólne pytanie – to model językowy nie potrafił zinterpretować czasu.
Niejasne cele i słabe prompty prowadzą do ogólnych odpowiedzi AI, ale nawet dobrze skonfigurowany prompt nie rozwiąże problemu, jeśli system nie ma logiki temporalnej. Algorytmy AI mogą generować powtarzalne i schematyczne odpowiedzi na pytania z datami bezwzględnymi – i jednocześnie całkowicie błędne odpowiedzi na pytania z czasem względnym.
Jak testować: twórz zestawy pytań z datami względnymi uruchamianych w różnych dniach miesiąca. Porównuj odpowiedzi dla „10 maja” vs. „jutro” vs. „za trzy dni”. Sprawdzaj, czy asystent dynamicznie interpretuje datę referencyjną. To w praktyce nie jest robione ręcznie – wymaga automatyzacji.
Wniosek: poprawne odpowiedzi na pytania „z datą” nie dowodzą, że asystent rozumie czas. Potrzebne są testy z dynamiczną datą systemową.
Case 6: To samo pytanie, różna odpowiedź – ukryta niedeterministyczność i dryf modeli
Podczas testów zadaliśmy asystentowi 10 razy to samo pytanie – „Kto jest prezesem firmy?” – w odstępach kilku dni, bez żadnej zmiany w systemie:
- 6 odpowiedzi poprawnych (Jan Nowak – aktualny prezes)
- 2 odpowiedzi wskazujące poprzedniego prezesa
- 2 odpowiedzi z osobami, które w firmie nigdy nie pracowały
Klient przetestował asystenta raz, dostał poprawną odpowiedź i był przekonany, że „działa”. Z perspektywy statystycznej asystent dawał różne odpowiedzi i odpowiadał błędnie dla 40% rzeczywistych użytkowników.
Systemy AI oparte na generatywnej AI są niedeterministyczne z definicji. Badanie „LLM Stability: Analysis & Surprises” wykazało, że nawet przy temperaturze ustawionej na zero modele wykazywały do 15% różnic w trafności, a identyczność odpowiedzi między uruchomieniami spadała nawet do 30–40%. Do tego dochodzi dryf – dostawca LLM aktualizuje model w tle, nie informując o tym zespołu klienta. Asystent, który wczoraj działał, dziś zwraca inne wyniki. Nikt nic nie zmienił po swojej stronie.
Poleganie na AI może prowadzić do obniżenia własnych kompetencji użytkowników, a koncepcja „ślepego zaufania” do AI może szkodzić umiejętnościom analitycznym. Interakcja z AI może wpływać na postawy ludzi oraz ich uczciwość – bo jeśli zespół ufa wynikowi demo, przestaje weryfikować. Generowanie kodu przez AI może pominąć skrajne przypadki, a przy generowaniu tekstu lub generowania treści pojedynczy wynik tym bardziej nie pokazuje stabilności systemu. Wydajność AI mierzona jednorazowo nie mówi nic o jej stabilności.
Jak testować: stała lista pytań biznesowych uruchamiana cyklicznie (np. raz dziennie), porównywana w czasie. Mierz procent poprawnych odpowiedzi, nie wrażenia. Manualnie jest to niewykonalne – nie z powodu pracochłonności, lecz z powodu wymaganej dyscypliny i powtarzalności.
Wniosek: „działa w demonstracji” to najsłabszy możliwy dowód jakości. Prawdziwy dowód to powtarzalny wynik na stabilnym zestawie regresyjnym.
Cztery wymiary jakości asystentów AI i przetwarzanie języka naturalnego: co w ogóle trzeba mierzyć
Sześć case’ów, sześć różnych mechanizmów. Ale łączy je jedno: żaden nie zostałby wykryty przez standardowe testy biznesowe. Warto używać asystenta AI w procesach decyzyjnych i obsłudze klientów – ale pod warunkiem, że jakość jest mierzona we wszystkich wymiarach, nie tylko w jednym.
Na podstawie tych przypadków wyodrębniamy cztery wymiary jakości:
- Trafność merytoryczna – prawdziwość faktów, poprawność liczb, weryfikacji faktów w długich odpowiedziach (Case 1, 2)
- Zgodność z promptem i politykami – język, ton, bezpieczeństwo danych, brak przejrzystości w zachowaniu reguł (Case 4)
- Odporność na pytania spoza zakresu – zdolność odmowy, rozpoznanie emocji, granic domeny (Case 3, 5)
- Stabilność w czasie – powtarzalność wyników, odporność na dryf modeli i niedeterministyczność (Case 6)
Typowe testy biznesowe pokrywają tylko wymiar pierwszy. Pozostałe trzy – zgodność, odporność, stabilność – są poza polem wzroku większości zespołów. Dobre wyniki w benchmarkach Microsoft Copilot czy Google Gemini nie gwarantują jakości w konkretnym wdrożeniu firmowym opartym na Waszej bazie wiedzy.
Nadzór ludzki jest kluczowy w zapobieganiu błędom AI, a pracownicy spędzają średnio 4,3 godziny tygodniowo na weryfikacji faktów generowanych przez pomocą sztucznej inteligencji. Przy setki pytań × cztery wymiary × cykliczność, manualne podejście skaluje się bardzo słabo – to dziesiątki tysięcy ocen rocznie. Bez automatyzacji testów nie zapewnisz porównywalności wyników między wersjami.
Mapowanie case’ów na wymiary:
- Case 1, 2 → trafność (w tym atomowa weryfikacja pojedynczych faktów) + audyt bazy wiedzy
- Case 3, 5 → odporność – pytania spoza zakresu, konteksty czasowe
- Case 4 → zgodność z promptem w wielu językach
- Case 6 → stabilność – wielokrotne uruchomienia, monitoring trendów
swojego asystenta AI.
Jak praktycznie ograniczyć błędy asystentów AI i poprawić weryfikacji faktów w Twojej organizacji
Poniżej konkretne rekomendacje – nie „w przyszłości”, lecz do wdrożenia w tym kwartale:
- Uporządkuj bazę wiedzy. Dodaj metadane: datę obowiązywania, status „archiwalny” vs. „aktualny”, pełne nazwy podmiotów zamiast ogólników. Podobno 85% projektów AI kończy się niepowodzeniem z powodu niskiej jakości danych – a baza wiedzy to dane treningowe Twojego asystenta i systemów opartych na uczenie maszynowe.
- Zbuduj scenariusze spoza zakresu. Pytania emocjonalne, medyczne, prawne, manipulacyjne – celowo sprawdzające, czy asystent odmawia tam, gdzie powinien. Testuj też przypadki, w których model generuje całkowicie zmyślone odpowiedzi. Zapewnienie odpowiednich fallbacków (przekierowanie do człowieka, „nie mam informacji”) jest tańsze niż kryzys PR.
- Testuj reguły w wielu językach. Jeśli prompt mówi „odpowiadaj po polsku”, sprawdź po niemiecku, angielsku, w trybie role-play. Każdą regułę weryfikuj osobno. Użytkownicy powinni weryfikować kluczowe dane w zewnętrznych, wiarygodnych źródeł – ale to organizacja musi zadbać o to, by asystent nie podawał w sposób odpowiedzialny danych, które nie powinny opuścić systemu.
- Uruchom testy regresyjne cyklicznie. Stała lista pytań uruchamiana co noc lub co tydzień, porównywana w czasie. Uwzględnij odpowiedzi dla różnych typów tekstu, by wychwytywać nieścisłości. Nie po każdym deployu – w sposób ciągły, bo dostawca modelu zmienia go bez Waszej wiedzy.
- W krytycznych obszarach wbuduj „człowieka w pętli.” W prawie, finansach, medycynie, decyzjach kredytowych – odpowiedzialność za odpowiedź ponosi organizacja, nie model. klienta.
Każdy z opisanych przypadków został rozwiązany po zdiagnozowaniu. Żaden nie wymagał wymiany technologii – wymagał rozszerzenia zakresu testów poza to, co zespół intuicyjnie uznawał za wystarczające.
Jeśli wdrażacie lub utrzymujecie asystenta AI i powyższe przypadki uznajecie za możliwe u siebie – zaplanujcie systematyczne, narzędziowe testy zamiast jednorazowego „odbioru” rozwiązania. To nie jest kwestia perfekcjonizmu. To kwestia tego, czy wiecie, jak naprawdę działa asystent AI w Waszej organizacji – czy tylko wierzycie, że działa.
