Uruchomiłem cyfrowego bliźniaka na mojej stronie internetowej. Odpowiada on na pytania dotyczące mojego życia i umiejętności. Nadałem mu jedną surową zasadę: nigdy nie zmyślać. Jeśli ktoś zapyta o umiejętność, której nie posiadam, model musi przyznać, że nie wie. Przez miesiące wierzyłem, że system działa poprawnie. Testowałem go ręcznie tu i ówdzie, a odpowiedzi wydawały się solidne. Potem zbudowałem właściwy system ewaluacji. Liczby uderzyły mnie mocno. Z 35 pytań, dziewięć zawierało ewidentne kłamstwa. Z ośmiu pytań zaprojektowanych tak, aby były nieodpowiedzialne, model odmówił odpowiedzi tylko w czterech przypadkach. Mój prompt zapobiegający halucynacjom zawodził mniej więcej w jednej czwartej przypadków. Dostarczałem produkt, który kłamał swoim użytkownikom.
Niezwykle prosty system retrieval
Nie uruchamiałem Pinecone ani żadnej ciężkiej bazy danych wektorowych. Cały system opiera się na zwykłym pliku JSON. Mój kod dzieli mój profil na oddzielne sekcje. Gdy pojawia się pytanie, system oblicza podobieństwo cosinusowe między zapytaniem a każdym fragmentem tekstu, wybiera najbliższe dopasowania i wkleja je do promptu jako kontekst. Model generuje następnie odpowiedź, opierając się ściśle na tym, co widzi w tym oknie.
Dla małej strony osobistej obsługującej wąski zestaw faktów, takie podejście jest szybkie i prawie nic nie kosztuje. Nie ma opóźnień sieciowych związanych z zewnętrznym magazynem wektorowym, nie ma narzutu na indeksowanie ani złożonej orkiestracji. Odczytujesz plik, oceniasz fragmenty, budujesz prompt i gotowe. Jednak prostota backendu nie gwarantuje uczciwości wyniku. Lekki potok przetwarzania danych wciąż może generować poważne problemy, gdy model zdecyduje się na improwizację. Luka między „oto kontekst” a „oto, co o tym powiem” to miejsce, w którym rodzą się halucynacje. Możesz podać modelowi akapit o swojej historii zatrudnienia, a i tak otrzymasz pewną siebie mistyfikację na temat języka programowania, którego nigdy nie dotykałeś.
Liczby, które odebrały mi pewność siebie
Przez miesiące uważałem, że ręczne sprawdzanie doraźne zapewnia wystarczającą kontrolę. Otwierałem czat, zadawałem pytanie, na którego odpowiedź już znałem, i potakiwałem, gdy odpowiedź wydawała się poprawna. To była moja strategia testowania. Wydawała się dokładna, ponieważ sam korzystałem z interfejsu. Tak nie było.
Kiedy w końcu napisałem system ewaluacji, który mógł działać w sposób systematyczny, obraz się zmienił. Zestaw testów zadał bliźniakowi 35 pytań. Dziewięć odpowiedzi zawierało kłamstwa. Dołączyłem również osiem pytań, na które w moim profilu nie było żadnej odpowiedzi. Model powinien odmówić odpowiedzi na wszystkie. Odmówił tylko w czterech przypadkach. Mój starannie opracowany prompt zapobiegający halucynacjom, ten zawierający kategoryczne instrukcje, by nigdy nie zmyślać, zawodził około 25 procent czasu. Jeden na cztery. To nie jest błąd zaokrąglenia. To wadliwy produkt.
Przestań testować za pomocą przyjaznych pytań
Nie znajdziesz błędów, po prostu używając własnego produktu. Znajdziesz je, próbując go zepsuć. Moje ręczne testy były zbyt przyjazne. Zadawałem tylko takie pytania, na które znałem dokładną odpowiedź, co oznaczało, że podświadomie prowadziłem model na bezpieczne terytorium. Nigdy nie badałem granic. Nigdy nie pytałem o umiejętności, które chciałbym posiadać, ani o doświadczenia, które nigdy się nie wydarzyły.
Prawdziwe testowanie wymaga podejścia adversarialnego. Musisz tworzyć pytania zaprojektowane tak, aby zmusić AI do błędu. Chcesz, aby potknął się w laboratorium, aby nie potknął się przed odwiedzającym. Zestaw testów, który jedynie potwierdza to, w co już wierzysz, jest tylko przebranym demo. Jeśli nie tworzysz aktywnie przypadków brzegowych i pytań-pułapek, to nie testujesz. Ty tylko masz nadzieję.
Dwa błędy, które miały znaczenie
Promptowanie nie daje gwarancji. Długa, szczegółowa instrukcja mówiąca AI, aby nie halucynowało, jest tylko sugestią ubraną w szaty polecenia. Model może jej przestrzegać przez większość czasu, ale zignoruje instrukcję w momencie, gdy presja statystyczna popchnie go w innym kierunku. Temperatura, prawdopodobieństwo tokenów i kształt danych treningowych ważą więcej niż zdanie w twoim systemowym prompcie. Musisz mierzyć posłuszeństwo za pomocą danych, a nie nadziei. Silna instrukcja nie jest zweryfikowanym faktem. To prośba, a prośby bywają odrzucane. Jeśli cała twoja strategia bezpieczeństwa opiera się na stanowczym sformułowaniu promptu, zbudowałeś barierki z papieru toaletowego. Potrzebujesz systemu ewaluacji, który liczy, jak często model słucha, w jakich warunkach i dlaczego zawodzi, gdy już zawodzi. Liczby nie przejmują się twoim tonem głosu.
Pętla ewaluacji była wadliwa. Oto subtelna pułapka, która o mało mnie nie zgubiła. Moje pierwotne narzędzie do testowania uruchamiało proces retrieval dwukrotnie. Pierwsze uruchomienie pobierało kontekst, aby sprawdzić go względem ground truth. Drugie uruchomienie pobierało kontekst do faktycznego generowania odpowiedzi. W praktyce oznaczało to, że fragmenty (chunks), które widział sędzia, mogły różnić się od fragmentów, które widział model. Sędzia oceniał odpowiedź na podstawie danych, których AI mogło nigdy nie otrzymać. Ewaluacja, która ocenia niewłaściwe dane wejściowe, jest gorsza niż brak ewaluacji. Daje ona złudne poczucie bezpieczeństwa. Patrzysz na wynik, widzisz wysoki wskaźnik zaliczeń i relaksujesz się. Tymczasem Twoi użytkownicy