Model generuje dwieście „prawdziwych klientów” z imionami, firmami i historią. Testy przechodzą, a raport twierdzi, że proces działa dla wszystkich. Syntetyczni ludzie są uprzejmi, konsekwentni i nie mają złego dnia. Prawdziwi użytkownicy przynoszą skan ukośny i pytają o coś innego.
Dane syntetyczne są przydatne do kontroli formatu, reguł i przypadków brzegowych. Nie zawsze wystarczają do oceny rzeczywistych zachowań i danych. Dobierz uzupełniające badania lub źródła do pytania oraz możliwości bezpiecznej weryfikacji. Powinny być projektowane z jawnym celem i ograniczeniem.
Zacznij od ryzyka przypadku
Zapisz, co chcesz przetestować: format, walidację, uprawnienia, kodowanie, brak danych, konflikt, awarię. Nie generuj całej fikcyjnej populacji przed pytaniem. Jedno dobrze zaprojektowane wejście wystarcza na początek.
Opisz, co jest celowo nietypowe. Nietypowy format, długi opis, brak źródła albo dwie osoby o tym samym nazwisku. Każdy przypadek powinien odpowiadać na ryzyko, a nie tylko zwiększać liczbę rekordów.
Nie przedstawiaj wyniku jako dowodu dla całego rynku. Syntetyczne dane pokazują zachowanie systemu na przygotowanym wejściu, nie rozkład problemów u klientów.
Oddziel fixture od syntetycznego badania
Fixture to kontrolowany przypadek testowy z oczekiwanym wynikiem. Może być fikcyjny i nadal bardzo użyteczny. Syntetyczne badanie opinii tworzy odpowiedzi modelu jako rzekome doświadczenia ludzi. To różne rzeczy.
Przy teście formularza użyj fikcyjnych danych i sprawdź skutek. Przy badaniu użyteczności potrzebujesz prawdziwych zachowań. Nielsen Norman Group opisuje ograniczenia syntetycznych użytkowników, w tym uproszczenia i niezgodność zachowania.
Nie nazywaj wygenerowanego komentarza „głosem klienta”. Może być przykładem tekstu do analizy, ale nie dowodem opinii.
Nie kopiuj prawdziwej osoby
Nie proś modelu o stworzenie syntetycznej wersji konkretnego klienta z rozpoznawalnymi danymi. Może zachować unikalne cechy i stworzyć nową, przypadkową historię powiązaną z osobą. To jest ryzyko, nie anonimizacja.
Projektuj przypadek od struktury bez rzeczywistych identyfikatorów. Firma A, osoba B, dokument X. Dodaj tylko wymagane cechy procesu. Nie używaj prawdziwego adresu, numeru, zdjęcia ani cytatu.
Przy potrzebie zachowania trudności dokumentu przepisz go ręcznie na fikcyjny wariant i odejmij szczegóły. Zasady opisuje przewodnik o RODO przy AI.
Zachowaj rzeczywistą strukturę błędów
Syntetyczne dane powinny zawierać rzeczywiste typy problemów: polskie znaki, różne formaty dat, puste komórki, konflikt wersji, nieznane statusy. Losowy tekst nie testuje procesu tak samo dobrze jak przypadek zmapowany z incydentu.
Nie przepisuj błędów z pamięci bez właściciela. Sprawdź źródło i skutek. Fikcyjny przypadek powinien zachowywać mechanizm, a nie dokładną historię klienta.
Przy OCR przygotuj obrazy z podobnymi trudnościami, ale bez poufnych treści. Test ma oceniać odczyt i odbiór, a nie odgadywać prawdziwy dokument.
Różnicuj bez sztucznej losowości
Nie zmieniaj tylko imion i nazwisk. Zmieniaj format, długość, jakość, rolę, wersję, braki i konflikty. Dwieście rekordów z różnymi imionami testuje mniej niż dwadzieścia dobrze dobranych.
Dodaj przypadki łatwe i trudne. Jeżeli wszystkie są trudne, nie wiesz, czy podstawowy proces działa. Jeżeli wszystkie łatwe, test pokazuje tylko ścieżkę szczęśliwą.
Zachowaj powtarzalność. Nie generuj nowego zestawu przy każdej zmianie bez powodu. Regresja wymaga wspólnych przypadków i kontrolowanego dodawania nowych.
Oczekiwany wynik przed generowaniem
Zapisz, co system powinien zwrócić lub zablokować. Nie akceptuj odpowiedzi modelu jako oczekiwanej tylko dlatego, że wygląda sensownie. Właściciel powinien zatwierdzić kryteria.
Przy otwartym wyniku zapisz reguły zamiast pełnego tekstu. Fakt, źródło, format, skutek, ograniczenie. To ogranicza dopasowanie oczekiwań do propozycji.
Przy błędzie oczekiwania popraw je z datą i powodem. Nie zmieniaj go dla zielonego raportu.
Nie trenuj na danych testowych przypadkowo
Oddziel dane używane do przykładów promptu od zestawu oceny. Model może zapamiętać oczekiwane odpowiedzi i wyglądać lepiej. Test powinien zawierać nowe, nieużywane przypadki.
Ogranicz dostęp agenta do oczekiwanych wyników przy generowaniu kodu lub odpowiedzi. Testy powinny sprawdzać proces, a nie kopiowanie. Przy few-shot zachowaj osobną próbkę końcową.
Przy zmianie promptu nie dodawaj przypadków kontrolnych jako przykładów. To zwiększa ryzyko przecenienia jakości.
Przykład: dwie osoby o tym samym nazwisku
Tworzysz dwa fikcyjne kontakty o tym samym imieniu, nazwisku i firmie, ale różnych rolach i identyfikatorach. Test sprawdza, czy system proponuje scalenie i czy wymaga dodatkowych dowodów. Oczekiwany wynik: brak automatycznego merge.
Nie używaj prawdziwych nazwisk. Nie potrzebujesz ich do ryzyka. Fikcyjne wartości zachowują przypadek bez tworzenia relacji z osobą.
Po teście sprawdź historię i zgody. Brak scalenia nie wystarcza, jeżeli integracja przeniosła dane między rekordami. Odbiór obejmuje skutek, nie tylko propozycję modelu.
Przykład: polskie znaki i nietypowy format
Przygotuj dokument z nazwami zawierającymi diakrytykę, datą słowną, pustym polem i tabelą z komórką scaloną. Oczekiwane wartości zapisujesz ręcznie. Test ocenia ekstrakcję, kodowanie i eksport.
Dodaj wariant z nieczytelnym fragmentem. System powinien oznaczyć brak zamiast zgadywać. Fikcyjna nieczytelność jest lepsza niż kolejny idealny PDF.
Przy takich testach pomocne są zasady z artykułu o polskich znakach w dokumentach AI. Dane syntetyczne pozwalają je wykonywać bez klientów.
Oceniaj pokrycie zestawu
Zapisz, jakie role, formaty, wersje, błędy i ryzyka obejmuje zestaw. Nie przedstawiaj samej liczby rekordów jako pokrycia. Duża liczba podobnych przypadków zwiększa koszt bez nowej wiedzy.
Dodawaj nowe przypadki z produkcji po anonimizacji lub przepisaniu. Zachowaj mechanizm i usuń identyfikatory. Nie każdy błąd powinien wejść do testów automatycznie.
Przeglądaj stare przypadki. Jeżeli proces już ich nie obsługuje, oznacz je jako eksperymentalne lub usuń z głównego zestawu. Nie zmieniaj oczekiwania bez powodu.
Dane syntetyczne i prywatność
Fikcyjne dane nie zawsze są bezpieczne. Jeżeli powstały na podstawie prawdziwej osoby lub zawierają unikalny przypadek, mogą identyfikować. Oceń kontekst przed udostępnieniem.
Nie przechowuj pełnych źródeł przy zestawie, jeżeli nie są potrzebne. Fixture powinien zawierać minimum do wykonania testu. Ogranicz dostęp do wersji produkcyjnych.
Nie używaj syntetycznych danych do wzbogacenia profilu klienta. Mają służyć testowi, a nie nowym decyzjom o prawdziwych osobach.
Kiedy potrzebne są prawdziwe dane
Przy ocenie częstości, reprezentatywności, zachowania użytkowników i rzeczywistych błędów potrzebujesz danych produkcyjnych lub badań. Syntetyczne dane nie odpowiadają na pytanie, jak często coś występuje.
Przy wysokim ryzyku oceń rzeczywiste przypadki z właściwym dostępem. Możesz ograniczyć pola i użyć próbki. Nie zastępuj tego większą liczbą fikcyjnych osób.
Przy badaniu użyteczności stosuj prawdziwych użytkowników i zasady z artykułu o badaniach z AI. To inny typ dowodu.
Karta zestawu testowego
Zapisz cel, przypadki, oczekiwane wyniki, źródło pochodzenia, ograniczenia i właściciela. Nie musisz ujawniać wszystkiego każdemu. Zachowaj wersję dla powtarzalności.
Po zmianie modelu lub procesu uruchom zależne przypadki i kontrolne. Zapisz, które są nowe i dlaczego. To ogranicza przypadkowe dopasowanie.
Kiedy model może pomóc przygotować przypadki
Model jest dobry do proponowania wariantów formatu i nietypowych sytuacji, ale właściciel wybiera je według ryzyka. Nie akceptuj całej wygenerowanej listy. Część będzie powtarzała ten sam scenariusz z innymi imionami.
Poproś o przypadki przeciwne do obecnych: brak źródła, konflikt, nowa rola, nietypowy kanał. Sprawdź, czy rzeczywiście dodają nową wiedzę. Potem zapisz oczekiwany wynik ręcznie lub przez właściciela procesu.
Nie przekazuj oczekiwanego wyniku jako części promptu testowanego procesu. Model pomagający projektować test i model testowany powinny być oddzielone procesowo. To ogranicza dopasowanie.
Jak opisać pochodzenie fixture
Zapisz, czy przypadek jest fikcyjny, przepisany z rzeczywistego mechanizmu, czy zanonimizowany. Nie musisz opisywać klienta, ale musisz znać źródło reguły. To pomaga przy ocenie, czy przypadek nadal jest aktualny.
Przy przepisywaniu usuń unikalne szczegóły i zachowaj tylko problem. Właściciel potwierdza, że mechanizm jest zachowany. Nie przedstawiaj wyniku jako pomiaru produkcji.
Przy nowej wersji procesu oceń, czy stara fixture nadal ma sens. Może wymagać aktualizacji lub archiwizacji z powodem.
Odbiór zestawu przez osobę z zadaniem
Pokaż kilka przypadków osobie wykonującej proces. Zapytaj, czy przypominają rzeczywistą pracę i jakich brakuje. Taki przegląd nie zastępuje potrzebnego badania użytkowników, ale może wychwycić sztuczne założenia przed wdrożeniem.
Jeżeli przypadki są zbyt łatwe, dodaj rzeczywiste trudności bez danych osobowych. Jeżeli zbyt trudne, zachowaj podstawową kontrolę. Zestaw powinien pokrywać decyzję i skutek, a nie tylko pokazywać awarie.
Przy kolejnych rundach zachowaj wspólny zestaw i dodawaj nowe przypadki osobno. Pozwala to porównywać wersje bez utraty stabilnej bazy. Nie przepisuj oczekiwanych wyników dla nowego modelu bez decyzji.
Jeżeli test kończy się zgodą na wszystkie przypadki, sprawdź, czy nie są zbyt podobne. Model może rozwiązywać tylko jeden typ zadania. Dodaj przypadek spoza zakresu z oczekiwanym zatrzymaniem.
Przy publikowaniu wyniku opisz źródło danych i ograniczenia. Nie przedstawiaj testu syntetycznego jako badania rynku ani potwierdzenia częstości. Czytelnik powinien wiedzieć, co było kontrolowane i czego nie mierzono.
Przy zakończeniu projektu zachowaj fixture i właściciela. Nowy zespół powinien móc powtórzyć testy bez prawdziwych klientów i bez odtwarzania ich historii.
Przy zmianie właściciela przekaż cel zestawu i ograniczenia. Nowa osoba nie powinna interpretować fikcyjnych historii jako rzeczywistych przypadków. Zaznacz, które dane były projektowane i które zanonimizowane.
Jeżeli testy wymagają nowych danych produkcyjnych, oceń kanał i minimalizację. Nie uzupełniaj zestawu przez eksport wszystkiego. Może wystarczy nowy przypadek syntetyczny z tym samym mechanizmem.
Przy przeglądzie usuń przypadki nieaktualne i duplikaty. Zestaw ma odpowiadać na obecne ryzyko, a nie tylko rosnąć z każdą wersją.
Przy odbiorze nowego zestawu sprawdź, czy przypadki nie powielają tej samej intencji. Duża liczba podobnych tekstów nie zwiększa pokrycia. Wybierz różne mechanizmy błędów.
Zapisz właściciela każdego oczekiwanego wyniku. Jeżeli jest niejasny, popraw przypadek przed testem zamiast dopasowywać go do odpowiedzi modelu.
Przy odbiorze końcowym zaznacz, czy test obejmuje zarówno poprawny wynik, jak i zatrzymanie. Sam wynik pozytywny nie wystarcza przy kontroli granic. Dodaj przypadek wymagający odmowy.
Zachowaj metodę i wersję zestawu. Przy kolejnym przeglądzie nowa osoba powinna umieć odróżnić kontrolowane przypadki od prawdziwych badań.
Aeneia Audit pomaga dobrać przypadki i odbiór. Przy większym procesie pomocny jest przewodnik Aeneia Signal o workflow.
Zestaw testowy powinien zawierać także sytuację, w której brakuje danych potrzebnych do odpowiedzi. Przy takim przypadku zapisz oczekiwane zatrzymanie lub pytanie o uzupełnienie, zanim zobaczysz wynik modelu. Fikcyjna próbka pozwala sprawdzić ten mechanizm bez ujawniania klienta, ale sama nie potwierdza skuteczności procesu na rzeczywistych danych.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
