Dane syntetyczne z AI: każdy wiersz wygląda dobrze, całość się nie zgadza

Próbna wypożyczalnia ma świetne dane. Każdy stojak ma nazwę, każda rezerwacja numer, każda data poprawny zapis. Dopiero po połączeniu plików okazuje się, że jeden stojak wrócił dzień przed wydaniem, a inny został wypożyczony równocześnie trzem osobom. Wiersze zachowują się wzorowo. Kłopot zaczyna się, kiedy się poznają.

To fikcyjny przykład zestawu wygenerowanego do sprawdzenia procesu. Syntetyczne dane, czyli dane wytworzone zamiast bezpośredniej kopii rzeczywistych rekordów, mogą wyglądać przekonująco i nadal nie tworzyć użytecznego świata próbnego. Ocena kilku ładnych rekordów nie pokaże, czy powiązania, kolejność i liczba przypadków pasują do zadania.

Przed generowaniem zapisz, co ma sprawdzić zestaw. Innych danych wymaga demonstracja katalogu, innych próba blokowania kolizji rezerwacji, a jeszcze innych ocena modelu uczonego na przykładach. Nie używaj jednego określenia „dobre dane testowe” jako wspólnej oceny tych trzech zastosowań.

Najpierw opisz świat, w którym rekordy mogą istnieć

W naszej wypożyczalni są typy wyposażenia, poszczególne egzemplarze, rezerwacje oraz zdarzenia wydania i zwrotu. Typ stojaka nie jest tym samym co konkretny stojak z numerem magazynowym. Rezerwacja dziesięciu sztuk wymaga innego powiązania niż rezerwacja jednego egzemplarza. Ustal te znaczenia przed poleceniem AI, żeby przygotowała setkę realistycznych pozycji.

Dla każdego obiektu wskaż identyfikator, czyli wartość pozwalającą rozpoznać dokładnie ten rekord. Następnie zapisz dopuszczone relacje. Egzemplarz należy do istniejącego typu wyposażenia. Pozycja rezerwacji wskazuje właściwy egzemplarz lub uzgodnioną liczbę sztuk danego typu. Zdarzenie zwrotu odnosi się do konkretnego wydania, a nie tylko do nazwiska osoby, która kiedyś wypożyczyła coś podobnego.

Dopilnuj wspólnego znaczenia identyfikatorów w kolejnych plikach. „Egzemplarz01” wygenerowany niezależnie dla dwóch magazynów może oznaczać dwie różne sztuki. Po połączeniu paczek aplikacja zobaczy jeden niejednoznaczny numer. Ustal, czy rozpoznanie wymaga także oznaczenia magazynu, i sprawdzaj całą uzgodnioną kombinację. Nie naprawiaj zderzenia przez zmianę numeru tylko w katalogu: odwołania w rezerwacjach i zdarzeniach muszą nadal wskazywać tę samą rzecz. Każda część paczki może wyglądać poprawnie osobno, a zestaw ujawni konflikt dopiero po scaleniu.

Zacznij od małego, ręcznie sprawdzonego świata. Kilka typów wyposażenia i egzemplarzy wystarczy, żeby ujawnić niejasności schematu. Dopiero potem zwiększaj liczbę rekordów. Jeśli nie potrafisz ustalić powiązań między sześcioma rekordami, tysiąc wierszy wygenerowanych przez AI raczej nie dopowie za ciebie zasad procesu.

Reguły mogą dotyczyć pojedynczego pola, całego rekordu albo zestawu. Dodatnia liczba sztuk to warunek pola. Data zwrotu późniejsza od daty wydania to relacja czasów. Brak dwóch aktywnych rezerwacji tego samego egzemplarza w kolidujących terminach wymaga porównania różnych rekordów. Sam poprawny format dat nie obejmuje pozostałych poziomów.

Oddziel regułę od wygodnego założenia. Czy wypożyczalnia dopuszcza zwrot częściowy? Czy jeden transport może obsługiwać kilka rezerwacji? Czy planowaną rezerwację można anulować przed wydaniem? Właściciel procesu powinien odpowiedzieć na takie pytania. Nie zakazuj generatorowi zdarzeń, które są rzeczywiście możliwe, wyłącznie dlatego, że utrudniają pierwszy przykład.

W kontroli danych JSON z AI sprawdzasz między innymi znaczenie wartości w rekordzie. Tu dochodzi cały zestaw: poprawna pozycja może wskazywać niewłaściwy obiekt albo łamać regułę czasu dopiero po zestawieniu z inną pozycją.

Istniejący identyfikator to dopiero początek relacji

Zbierz wszystkie odwołania i sprawdź je wobec właściwych zbiorów. Numer egzemplarza w rezerwacji powinien wystąpić na liście egzemplarzy. Nazwa podobna do istniejącej nie wystarcza. Gdy dwie wersje stojaka różnią się końcówką oznaczenia, automatyczne dopasowanie po słowie „stojak” może połączyć rezerwację z inną rzeczą.

SDMetrics w opisie ReferentialIntegrity sprawdza odnalezienie klucza obcego w kluczu głównym, czyli zgodność odwołania z identyfikatorem. Ta metryka uznaje brakujące wartości za poprawne klucze obce. Jej dobry wynik nie zastępuje więc osobnej reguły wymagającej wskazania obiektu.

Dla naszego zestawu zapisz wprost, czy pozycja rezerwacji może nie mieć jeszcze przypisanego egzemplarza. Być może na etapie wstępnym rezerwuje się tylko typ wyposażenia, a konkretną sztukę dobiera później. Jeśli tak, brak identyfikatora oznacza określony stan procesu. Jeżeli próbujesz obsłużyć wydanie, ten sam brak może uniemożliwiać działanie. Reguła zależy od etapu, nie od samej pustej komórki.

Sprawdź też zgodność egzemplarza z typem wybranym w rezerwacji. Oba identyfikatory mogą istnieć, a relacja nadal być błędna. To odpowiednik sytuacji, w której numer pokoju jest poprawny, tylko pochodzi z innego budynku. W raporcie pokaż konkretną naruszoną zależność i rekordy potrzebne do jej odtworzenia.

Osobny rodzaj błędu pojawia się, gdy generator odwraca relację. „Nowa rezerwacja zastępuje poprzednią” i „poprzednia zastępuje nową” nie znaczą tego samego. Podobne rozróżnienia rozwija tekst o kierunku i podstawie relacji w grafie wiedzy AI. W danych próbnych nazwa połączenia powinna odpowiadać rzeczywistej czynności, którą ma wykonać aplikacja.

Użyj zestawu w zapytaniach potrzebnych do próby. Jeśli pytasz o liczbę rezerwacji, połączenie z wieloma pozycjami może powielić wiersze. Własny mały przykład i znany wynik pomagają ocenić, czy błąd pochodzi z danych, czy z zapytania. Tę różnicę pokazuje poradnik liczba wierszy a liczba spraw w SQL z AI. Test nie powinien potwierdzać się tylko dlatego, że ten sam generator przygotował paczkę i przewidywany rezultat.

Właściwa kolejność zdarzeń wymaga historii

Dla jednej rezerwacji pokaż ciąg: utworzenie, ewentualne potwierdzenie, wydanie, zwrot i zamknięcie. Nie narzucaj go wszystkim stanom bez wyjątku. Anulowana rezerwacja może nigdy nie dojść do wydania, a zwrot częściowy nie musi zamykać całości. Zapisz dozwolone przejścia i warunki, które różnią te drogi.

Sprawdź czas zdarzenia osobno od czasu jego zapisania. Pracownik może odnotować zwrot po faktycznym przyjęciu wyposażenia. Taki późniejszy wpis nie jest tym samym co zwrot przed wydaniem. Jeśli schemat zawiera oba czasy, generator powinien zachować ich znaczenie. Jeżeli masz jedno pole, uzgodnij, który moment ono opisuje.

Kolizje oceniaj według przyjętych zasad dostępności. Czy okresy mogą stykać się granicami? Czy między zwrotem i kolejnym wydaniem przewidziano przygotowanie wyposażenia? Właściciel procesu musi określić odpowiedź. Nie ma jednej magicznej reguły „daty się nie nakładają”, która opisze każde wypożyczenie bez uwzględnienia tych warunków.

Zestaw kontrolny powinien obejmować poprawną historię oraz świadomie błędną. Błąd wprowadzony po to, żeby sprawdzić jego wykrywanie, oznacz w osobnym spisie oczekiwań. Nie naprawiaj go automatycznie podczas przygotowania danych.

Dla czytelnej próby wyjdź od jednej poprawnej historii i zmieniaj jedną zależność naraz. W kopii zamień numer egzemplarza na nieistniejący. W kolejnej zachowaj numery, a przesuń rzeczywisty zwrot przed wydanie. W następnej wprowadź kolidującą rezerwację tej samej sztuki. Dla każdej zapisz, co ma zostać wykryte i co powinno pozostać poprawne. Zestaw z pięcioma niezależnymi usterkami może być przydatny później, ale na początku utrudnia wyjaśnienie, która kontrola naprawdę zadziałała. To plan próby, nie relacja z uruchomienia aplikacji.

Oddziel paczkę przykładów poprawnych od paczki do sprawdzenia odmowy. Dla drugiej wskaż naruszoną regułę i oczekiwany rodzaj reakcji. Wysoki udział odrzuconych rekordów może być sukcesem próby negatywnej, ale porażką generatora obiecującego poprawny świat. Bez nazwania przeznaczenia zestawu ten sam wynik można dowolnie przedstawić jako sukces albo porażkę.

Poprawność świata i przydatność próby to różne oceny

Wyobraź sobie tysiąc poprawnych rezerwacji z dokładnie jedną pozycją. Każde odwołanie działa, daty są uporządkowane, a aplikacja przechodzi próbę. Nadal nie wiesz, co zrobi z rezerwacją mającą wiele pozycji, częściowym zwrotem albo typem wyposażenia, którego nikt dotąd nie wypożyczył. Duży zestaw może bardzo dokładnie powtarzać wąski przypadek.

SDMetrics w CardinalityShapeSimilarity porównuje rozkład liczby wierszy potomnych przypadających na wiersz nadrzędny w danych rzeczywistych i syntetycznych. Ocenia więc inną własność niż samo istnienie odwołań między tabelami.

Dla naszej próby policz na przykład, ile rezerwacji ma jedną, kilka i wiele pozycji. Sprawdź, czy są egzemplarze bez historii i egzemplarze używane wielokrotnie w kolejnych terminach. Nie musisz odtwarzać rzeczywistych proporcji, jeśli celem jest próba rzadkiego zdarzenia. Musisz natomiast nazwać, czy zestaw ma przypominać zwykły napływ, czy celowo zagęszczać trudne przypadki.

Rozróżnij także różnorodność nazw od różnorodności historii. Sto rezerwacji dla stu fikcyjnych osób może powtarzać ten sam jeden przebieg: jedna sztuka, termin, pełny zwrot. Zmiana imion nie dodaje wtedy próby częściowego wydania, przesunięcia terminu ani anulowania jednej pozycji. Przy odbiorze pokaż listę wymaganych sytuacji i wskaż rekordy, które każdą z nich realizują. Jeżeli brakuje danego przypadku, dopisz go świadomie, zamiast ponownie generować większą paczkę z nadzieją, że tym razem wylosuje się potrzebna historia.

W ocenie zbioru do dostrajania modelu AI dochodzą inne pytania o dobór przykładów i późniejszą niezależną próbę. Nie przenoś automatycznie wyniku testu aplikacji na materiał do uczenia. Paczka idealna do demonstracji trzech ekranów może mieć zbyt mało różnorodności, by sprawdzać zachowanie rozwiązania na innych historiach.

Oznaczenie „syntetyczne” nie jest samo w sobie potwierdzeniem anonimowości. Ustal, skąd pochodzi materiał, na którym działał generator, i co wolno dalej przekazać. Jeżeli celem jest sprawdzenie relacji rezerwacji, często wystarczą całkowicie fikcyjne nazwy i kontakty. Nie dokładaj prawdziwych danych do atrakcyjnego podglądu tylko dlatego, że pozostałe pola zostały wygenerowane.

Uruchamiaj próby w środowisku testowym automatyzacji AI, z odróżnieniem fikcyjnych zdarzeń od bieżącej obsługi. Adres e-mail w danych próbnych nie powinien przypadkiem uruchamiać rzeczywistego powiadomienia klienta. Zgodna paczka i bezpieczne miejsce jej użycia to osobne warunki odbioru.

Zachowaj wersję generatora lub polecenia, schemat, reguły, sam zestaw oraz wyniki jego sprawdzenia. Po korekcie jednej zależności ponów dotyczące jej próby. Ręczne usunięcie kilku kłopotliwych wierszy może zmienić historię pozostałych obiektów. Jeśli skasujesz wydanie, pozostawiony zwrot straci podstawę. Jeżeli usuniesz kolidującą rezerwację, sprawdź także przypisane do niej pozycje i zdarzenia. Korekta powinna obejmować rozpoznany fragment historii, z ponowną kontrolą jego zależności. Nie oceniaj naprawionej paczki na podstawie samego zniknięcia pierwszego komunikatu o błędzie. Zespół powinien wiedzieć, którą paczkę rzeczywiście wykorzystano do potwierdzenia działania.

Do przeglądu Aeneia Audit przygotuj mały zestaw i opis jednego procesu, który ma obsłużyć. Wybierz historię poprawną, brakujące powiązanie oraz zdarzenie w niewłaściwej kolejności. Na nich da się rozpocząć konkretną ocenę jakości materiału. Ładny rekord jest dobrym początkiem. Przed odbiorem pozwól mu jeszcze spotkać się z sąsiadami.