AI łączy rekordy: jak nie skleić dwóch klientów w jedną osobę

W bazie są dwie Anny Nowak. Mają podobne adresy e-mail, korzystają z tej samej domeny firmowej i zamawiały materiały na to samo wydarzenie. System proponuje scalenie. Człowiek widzi dwa podobne wiersze, klika „zatwierdź”, a potem okazuje się, że jedna Anna organizuje wydarzenie, druga reprezentuje dostawcę. Wspólne nazwisko nie wymaga przecież wspólnego folderu spraw.

Łączenie rekordów wspomagane AI może porządkować bałagan, ale może też stworzyć bardzo spójny zapis osoby, która nie istnieje. Problem zaczyna się wtedy, gdy poszukiwanie podobnych rekordów płynnie przechodzi w decyzję o ich tożsamości. Audyt powinien rozdzielić te kroki oraz sprawdzić, co dzieje się z danymi po scaleniu.

Najłatwiej oceniać taki proces na kontrolowanej bazie syntetycznej. Przy jej przygotowaniu sprawdź spójność relacji i zdarzeń w danych syntetycznych, zwłaszcza ról i historii przypisanych do każdej osoby. Można w niej celowo umieścić homonimy, wspólne skrzynki i zmienione nazwy bez narażania prawdziwych relacji z klientami. Z góry znamy odpowiedź i potrafimy sprawdzić zarówno błędne połączenie, jak i przeoczony duplikat.

Najpierw ustal, co właściwie reprezentuje rekord

Jeden wiersz może opisywać osobę, firmę, oddział, miejsce dostawy albo relację osoby z organizacją. Dwa rekordy tej samej osoby nie zawsze powinny stać się jednym wierszem, jeżeli przechowują różne role. Zanim ocenisz mechanizm dopasowania, zapisz jednostkę bazy i dozwolone relacje między jednostkami.

W fikcyjnym katalogu kontaktów Anna może występować jako pracowniczka firmy oraz osoba kontaktowa konkretnego zamówienia. Zmiana pracodawcy nie oznacza, że stare zamówienie powinno otrzymać nową firmę. Jeśli model danych nie rozróżnia osoby i jej relacji, narzędzie do scalania nie naprawi tej niejednoznaczności samym trafnym odgadnięciem nazwiska.

Podobny problem dotyczy organizacji. Marka, podmiot i oddział mogą mieć wspólne słowa w nazwie, a pełnić różne role w procesie. Nie zakładaj automatycznie, że dłuższa nazwa to pełniejsza wersja krótszej. Osoba oceniająca potrzebuje kryterium tożsamości odpowiadającego temu, do czego baza będzie używana.

Przy deduplikacji bazy firm przed przeniesieniem do CRM porządkowanie pól jest częścią przygotowania danych. Tu interesuje nas szczególnie moment, w którym narzędzie proponuje połączenie i system zaczyna traktować dwa źródła jako jeden obiekt. To moment wymagający własnej kontroli oraz śladu decyzji.

Na tym etapie rozpisz trzy możliwe wyniki: ten sam obiekt, różne obiekty i brak podstaw do rozstrzygnięcia. Ostatnia odpowiedź jest potrzebna. Jeżeli aplikacja wymaga zawsze „tak” albo „nie”, część niepewnych przypadków trafi do jednej z tych kategorii tylko dlatego, że interfejs nie przewidział innej drogi.

Kandydat do sprawdzenia nie jest poleceniem scalenia

OpenRefine w opisie klastrowania komórek przedstawia grupowanie podobnych wartości tekstowych oraz zatwierdzanie proponowanych zmian przez użytkownika. Podobieństwo zapisu służy tam porządkowaniu wartości. Samo znalezienie podobnych nazw nie ustala tożsamości osób czy organizacji.

Własny proces oceń więc w dwóch etapach. Najpierw sprawdź, czy mechanizm znajduje pary warte obejrzenia. Następnie zbadaj, czy reguła podejmowania decyzji odróżnia duplikat od mylącego sąsiada. Dobry dobór kandydatów może współistnieć ze zbyt odważnym automatycznym scalaniem. Jeden ogólny wynik „trafności” zasłania tę różnicę.

Przygotuj pary łatwe i trudne. Ta sama syntetyczna osoba może mieć literówkę w nazwisku, dawny adres lub numer zapisany z innymi odstępami. Różne osoby mogą mieć to samo imię i nazwisko, wspólny numer centrali albo skrzynkę działową. Każda para powinna mieć uzasadnienie oczekiwanego wyniku, zapisane przed uruchomieniem narzędzia.

Nie traktuj wspólnej skrzynki jako kilku niezależnych dowodów. Domena, nazwa organizacji i adres biura mogą opisywać to samo powiązanie z firmą. W raporcie pokaż, czy zespół rozumie, czego dotyczą sygnały. Mechaniczne zsumowanie podobieństw może wyglądać przekonująco właśnie tam, gdzie wszystkie pochodzą z jednej wspólnej cechy.

Dodaj przypadek zmiany danych w czasie. Dawny i nowy adres mogą dotyczyć tej samej osoby, ale mogą też należeć do dwóch kolejnych użytkowników skrzynki funkcyjnej. Potrzebujesz dat i pochodzenia pól, aby ocenić taki przypadek. Zastąpienie starej wartości nową bez historii utrudnia późniejsze wyjaśnienie błędu.

W wyszukiwaniu produktu ze zdjęcia rozdzielamy podobny wygląd i ten sam model. W rekordach podobna nazwa pełni analogiczną rolę pomocniczą. Zamiast pokazywać tylko procent podobieństwa, interfejs przeglądu powinien ujawnić zgodności, różnice i źródła danych potrzebne do decyzji.

Policz oba kierunki pomyłki

Fałszywe połączenie oznacza sklejenie różnych obiektów. Przeoczony duplikat oznacza pozostawienie rozdzielonych zapisów tego samego obiektu. Te błędy mają inne skutki. Pierwszy może pomieszać historię spraw, drugi utrzymać powtarzający się kontakt. Nie ustalaj ich względnego znaczenia wyłącznie na podstawie wygody czyszczenia arkusza.

Dokumentacja oceny Splink opisuje sprawdzanie fałszywych dopasowań i pominiętych połączeń względem oznaczonych przykładów, przy wybranym progu. To użyteczny punkt odniesienia: potrzebny jest znany wynik oraz jawna granica decyzji. Sama liczba utworzonych grup nie mierzy jakości.

Na syntetycznej próbie pokaż liczbę par, które powinny zostać połączone, oraz liczbę par, które powinny pozostać osobno. Obok zapisz wyniki narzędzia. Jeżeli zmieniasz próg, porównuj te same przypadki i oba rodzaje błędu. Spadek liczby duplikatów nie wystarcza, gdy rośnie liczba błędnie sklejonych klientów.

Sprawdź próbę także po przetasowaniu kolejności wejścia. Jeżeli ta sama grupa syntetycznych rekordów kończy się innym wyborem danych, ustal, z czego wynika różnica. Być może reguła zachowuje pierwszy napotkany wpis. To może być zamierzona konfiguracja, lecz trzeba ją nazwać i ocenić względem zadania, zamiast przypisywać wynik jakości rozpoznania osoby.

Wydziel grupę do ręcznego rozstrzygnięcia i sprawdź jej rozmiar. Rozwiązanie może unikać automatycznych błędów, przekazując niemal wszystko człowiekowi. To nie musi być zła decyzja, ale wymaga policzenia rzeczywistej pracy. Zapisz czas potrzebny do rozpatrzenia sprawy oraz dane, których zabrakło oceniającemu.

W zatwierdzaniu działań AI przez człowieka sama obecność przycisku zgody nie gwarantuje sensownej kontroli. Przy scalaniu pokaż przed zatwierdzeniem także skutek: które pola zostaną zachowane, jakie powiązania przejdą do rekordu i czy historia obu źródeł pozostanie dostępna. Bez tego człowiek akceptuje nazwę operacji, a nie jej wynik.

Przetestuj odrzucenie sugestii. Czy po oznaczeniu dwóch Ann jako różnych osób narzędzie za chwilę proponuje tę samą parę ponownie? Czy decyzja ma powód i zakres? Odrzucenie konkretnego połączenia nie powinno blokować sprawdzenia rzeczywistego duplikatu jednej z tych osób w innym miejscu bazy.

Sprawdź grupę, zanim znikną jej osobne elementy

Pary nie opisują jeszcze całej grupy. Rekord A może przypominać B przez wspólny telefon, a B przypominać C przez nazwisko. Nie wynika z tego automatycznie, że A i C opisują tę samą osobę. W próbie dodaj taki łańcuch i obejrzyj końcową grupę. To pozwala wykryć skutki, których nie widać przy ocenianiu pojedynczej sugestii.

Przejdź przez regułę wyboru wartości po scaleniu. Który adres zostaje główny, co dzieje się z pustym polem, jak rozstrzygana jest sprzeczność? „Nowszy rekord” nie jest pełną regułą, jeżeli jedno źródło aktualizowano automatycznie wczoraj, a drugie zawiera potwierdzoną informację sprzed tygodnia. Potrzebna jest podstawa wyboru właściwa dla pola.

Zachowaj identyfikatory wejściowych rekordów oraz pochodzenie przejętych wartości. Taki zapis pomaga prześledzić, dlaczego numer telefonu znalazł się przy danym kontakcie. Nie chodzi o kopiowanie całej bazy do raportu. Zakres danych w kontroli powinien odpowiadać zadaniu, co warto powiązać z rejestrem przepływu danych AI.

Dla pól objętych scalaniem pokaż przynajmniej jeden przypadek konfliktu oraz jeden przypadek braku wartości. Numer wpisany do pustej komórki wymaga innej oceny niż zastąpienie istniejącego numeru. Jeśli raport łączy obie operacje jako „uzupełniono kontakt”, trudno zauważyć, że część poprawnych wartości została nadpisana. W podglądzie zmian rozdziel dodanie, zastąpienie i pozostawienie danych bez zmian.

Po scaleniu otwórz także powiązane obiekty: sprawy, zamówienia i przypisane role, jeżeli występują w danym systemie. Rekord kontaktu może wyglądać poprawnie, podczas gdy dawne zamówienie otrzymało niewłaściwą organizację. Odbiór samego wiersza pomija skutki, dla których w ogóle porządkujemy bazę.

Dodaj powtórny import jednego z rekordów źródłowych. Sprawdź, czy system rozpoznaje jego dotychczasowe powiązanie, czy tworzy nowego klienta i zaczyna scalanie od początku. Ten przypadek odróżnia jednorazowe czyszczenie pliku od procesu, do którego stale dopływają dane. Zapis powiązań musi pomagać również przy kolejnym zasileniu bazy.

Przy relacji wiele-do-jednego sprawdź, czy wszystkie źródłowe identyfikatory nadal wskazują właściwy obiekt. Dla fikcyjnej Anny mogą istnieć trzy prawidłowe zapisy z różnych systemów. Połączenie dwóch z nich i pozostawienie trzeciego bez rozpoznawalnego związku nie oznacza zakończenia zadania. Jednocześnie nie wolno dołączyć podobnego rekordu drugiej Anny tylko dla uzyskania jednej eleganckiej grupy.

Wykonaj kontrolowane rozdzielenie błędnej grupy. Czy da się odtworzyć źródłowe rekordy i przypisania? Co z danymi dopisanymi już po scaleniu? Jeśli narzędzie nie oferuje prostego cofnięcia, trzeba przed uruchomieniem procesu ustalić sposób naprawy oraz zakres automatycznych zmian. Kopia wejścia pomaga, ale sama nie rozstrzyga, do kogo należy późniejsza notatka.

Operacyjny przegląd w Aeneia Audit może zacząć się od syntetycznej próbki, opisu reguł oraz widoku końcowej grupy. Pozwala to sprawdzić logikę procesu, zanim praca porządkowa zmieni historię rzeczywistych kontaktów.

Odbierz także wykorzystanie uporządkowanej bazy

Jeżeli baza służy do zbiorczych analiz, obejrzyj wynik po scaleniu. Błędne połączenie może zmienić liczbę klientów, odpowiedzi albo kontaktów z daną sprawą. Przy analizie otwartych odpowiedzi z ankiety szczególnie trzeba wiedzieć, czy liczymy wypowiedzi, osoby czy zdarzenia. „Usunięto duplikaty” nie zastępuje tej definicji.

Na zakończenie zapisz także zakres, w którym automatyczne scalanie nie zostało dopuszczone. Może chodzić o wspólne skrzynki działowe albo rekordy bez identyfikatora źródła. Właściciel procesu powinien wiedzieć, gdzie nadal stosować odrębną kontrolę, bez wyciągania wniosku o gotowości całej bazy z dobrego wyniku łatwiejszych par.

Ustal, które zmiany uruchamiają ponowne sprawdzenie próby: nowy typ źródła, zmienione reguły wyboru pól lub inny mechanizm tworzenia grup. Nie wystarczy porównać liczby pozostałych wierszy. Wróć do trudnych par i łańcuchów, obejrzyj decyzje oraz sprawdź możliwość naprawy.

Na koniec poproś osobę korzystającą z bazy o odnalezienie obu syntetycznych Ann i wyjaśnienie ich ostatnich spraw. Jeśli potrafi odtworzyć źródła, role oraz powód połączenia albo rozdzielenia zapisów, porządkowanie przyniosło użyteczny rezultat. Mniej wierszy jest wtedy skutkiem zrozumiałych decyzji, a obie Anny nadal mają własną historię kontaktu.