Mit #6: 99,9% trafności

99,9% trafności, ale w czym?

W prezentacjach rozwiązań AI cały czas pojawiają się hasła typu „99,9% trafności”. I ta liczba może być nawet prawdziwa. Problem w tym, że bez informacji o tym, co dokładnie testowano, niewiele z niej wynika.

Zwykle test jest wąski i przeprowadzany w kontrolowanych warunkach. Daj modelowi dokument i poproś o wyciągnięcie konkretnej informacji. Daj mu umowę i poproś o podsumowanie warunków dostawy. Przekaż zestaw faktów i zadaj pytania na ich podstawie. Kiedy wszystkie informacje potrzebne do udzielenia odpowiedzi znajdują się bezpośrednio przed modelem, wyniki mogą być bardzo dobre.

Tak jednak nie wygląda większość decyzji operacyjnych.

Czy możemy podzielić tę wysyłkę?

Twój zespół znacznie częściej zapyta: „Czy możemy podzielić tę wysyłkę i nadal dotrzymać terminu uzgodnionego z klientem?”. Żeby odpowiedzieć, system może potrzebować danych o otwartych zamówieniach, zapasach z kilku różnych systemów, potwierdzeń od dostawców, terminów produkcji i warunków umowy. Musi też rozumieć, że dwa systemy mogą inaczej definiować „dostępny zapas”, że potwierdzenie od dostawcy nie zawsze jest wiarygodne albo że dany klient ma konkretne zasady dotyczące częściowych dostaw.

99,9% trafności osiągnięte w teście polegającym na odczytywaniu informacji z dokumentu praktycznie nic nie mówi o tym, jak system poradzi sobie z takim pytaniem.

Trafność spada, gdy brakuje informacji, źródła są ze sobą sprzeczne, trzeba zastosować reguły biznesowe albo model musi przejść przez kilka etapów, zanim udzieli odpowiedzi. Oparcie modelu na zweryfikowanych danych firmy bardzo pomaga, ale nie eliminuje błędów ani halucynacji.

Uważaj na dostawcę, który twierdzi, że jego AI nigdy nie halucynuje.

Dzisiejsze modele językowe halucynują. Lepsze modele mogą ograniczyć ten problem, a oparcie ich na zweryfikowanych danych może znacząco zmniejszyć jego skalę, ale przy obecnej architekturze nie da się go całkowicie wyeliminować. Ryzyko nigdy nie spada do zera.

Dlatego podchodziłabym ostrożnie do każdego dostawcy, który twierdzi, że jego system „nie halucynuje”. Ważniejsze pytanie nie brzmi, czy udało mu się w jakiś sposób wyeliminować ten problem, ale czy zaprojektował system tak, żeby sobie z nim radzić.

Dobrze zaprojektowany system zakłada, że błędy mogą się zdarzyć. Pobiera fakty ze zweryfikowanych źródeł, zamiast polegać na „pamięci” modelu, pozwala prześledzić ważne informacje aż do ich źródła, rozpoznaje brakujące lub sprzeczne dane i potrafi się zatrzymać, zamiast uzupełniać luki wiarygodnie brzmiącą odpowiedzią. Tam, gdzie błąd może mieć istotne konsekwencje, decyzja powinna wymagać zatwierdzenia przez człowieka.

Nie pytaj więc, czy system halucynuje. Zapytaj: co się dzieje, kiedy to robi?

12 kroków. Tylko 54% szans, że wszystkie będą poprawne.

Jest jeszcze jeden problem z deklarowaną trafnością: rzeczywiste procesy biznesowe zazwyczaj składają się z wielu etapów. System może najpierw pobrać dane, potem je zinterpretować, porównać z innym źródłem, zastosować regułę, przygotować rekomendację, a na końcu wykonać określone działanie. Błąd na jednym etapie może wpłynąć na wszystko, co wydarzy się później.

Jeśli proces składa się z 12 niezależnych kroków, a każdy z nich jest poprawny w 95% przypadków, prawdopodobieństwo, że wszystkie 12 zostanie wykonanych prawidłowo, wynosi około 54%. Rzeczywiste procesy są oczywiście bardziej skomplikowane, a błędy nie zawsze są od siebie niezależne. Ten prosty przykład pokazuje jednak, dlaczego trafność pojedynczego kroku i niezawodność całego procesu to dwie różne rzeczy.

Model może więc osiągać świetne wyniki w izolowanym teście, podczas gdy proces zbudowany wokół niego nadal będzie zawodny. Liczy się nie tylko to, jak często poprawna jest pojedyncza odpowiedź modelu, ale przede wszystkim to, czy cały proces prowadzi do właściwego rezultatu.

Niech demo naprawdę coś udowodni.

Kiedy dostawca pokazuje Ci wskaźnik trafności, zadaj trzy pytania.

Trafność w jakim zadaniu? Wynik testu podsumowywania dokumentów albo odczytywania z nich danych ma znaczenie tylko wtedy, gdy właśnie do tego zamierzasz używać systemu.

Na czyich danych została zmierzona? Benchmark lub test przeprowadzony przez dostawcę może być przydatny, ale chciałabym powtórzyć go na własnych danych, również tych niekompletnych, sprzecznych i pełnych wyjątków, z którymi zespół spotyka się w codziennej pracy.

Jaka jest trafność całego procesu od początku do końca? Jeżeli system pobiera dane, interpretuje je, uzgadnia rozbieżności, przygotowuje rekomendację i podejmuje działanie, chcę wiedzieć, jak niezawodnie działa cały ten proces, a nie tylko jeden jego element.

Zmieniłabym również sposób prowadzenia demo. Zadaj systemowi prawdziwe pytanie biznesowe, a potem dokładnie przeanalizuj odpowiedź. Skąd pochodzi ta liczba? Pokaż źródło. Dlaczego system wykorzystał właśnie to źródło? Co zrobi, jeśli zabraknie informacji? Co się stanie, jeśli dwa systemy pokażą coś innego? Pokaż przykład, w którym system odmawia udzielenia odpowiedzi, ponieważ nie ma wystarczających danych.

Takie testy znacznie lepiej pokazują, jak rozwiązanie będzie zachowywać się po wdrożeniu w Twojej firmie.

Sprawdź trafność AI na własnych danych dzięki bezpłatnej ocenie gotowości blueclip →