Sprawdź wszystko tanio, zbadaj dokładnie tylko potrzebne przypadki

Weźmy ilustracyjną partię 10 000 aktualizacji kontaktów. Każdy rekord można wysłać do modelu po nowy osąd jego pól. W ten sposób jedna decyzja o mapowaniu zmieniłaby się w 10 000 powtarzanych decyzji.

Zacznij od tańszego pytania: czy rekord spełnia znane warunki zatwierdzonego mapowania? Sprawdź w kodzie obecność pól, typy danych, wersję schematu i wyraźne wymagania dotyczące zgody. Rekordy, które nie przejdą kontroli lub pozostaną niejednoznaczne, skieruj do węższej analizy.

To ilustracyjny projekt, nie wynik pomiarów Tajo. Interesującą liczbą nie jest liczba rekordów przepuszczonych przez pierwszy etap. Jest nią liczba istotnych błędów przepuszczonych niesłusznie.

Specjalistyczny proces omówiony w tej prezentacji zaczyna od szerokiego rozróżnienia między przypadkami prawidłowymi i nieprawidłowymi, a następnie bada oznaczone przypadki. Ta dziedzina ma inne stawki i dowody niż dane marketingowe. Źródło pokazuje decyzję etapową, ale nie dowodzi ani kosztu, ani deterministycznego charakteru pierwszego algorytmu. W integracji tania, deterministyczna kontrola może objąć znane warunki, zanim niepewne przypadki otrzymają dokładny przegląd.

Pierwszy etap powinien rozstrzygać zwykłe przypadki

Dobra kontrola wstępna pyta o coś, na co kod może odpowiedzieć na podstawie dostępnych danych. „Czy pole źródłowe istnieje?” to jedno pytanie. „Czy wartość pasuje do zadeklarowanego typu pola docelowego?” to drugie. „Czy to wersja schematu, dla której zatwierdzono mapowanie?” to trzecie.

Reguła może działać na każdym wierszu bez wymyślania nowej interpretacji. Może też wyjaśnić wynik. Odrzucony wiersz może wskazać, że docelowe pole birthday oczekuje daty, a źródło podało swobodny tekst. To użyteczniejsze od komunikatu „niska pewność AI”.

Przewodnik Tajo po konektorze Brevo wyjaśnia, dlaczego definicje atrybutów w systemie docelowym są ważne. Konektor może wysłać żądanie HTTP, a system odbierający zignoruje niezadeklarowany atrybut. Kontrola zadeklarowanych pól przed zapisem wykrywa jedną klasę błędów. Późniejszy odczyt wyniku może wykryć inną. Żadnej nie należy mylić z opinią modelu, że kontakt „wygląda dobrze”.

Celem nie jest usunięcie osądu. Chodzi o zachowanie go dla pytania, które go wymaga.

1. Nowa partia synchronizacji

2. NAJPIERW

   Sprawdź znane reguły

   • Tożsamość, typ pola i zakres konta
3. POTEM

   Rozstrzygnij jasne przypadki

   • Przepuść zwykłe rekordy; wstrzymaj znane błędy
4. GDY TRZEBA

   Zbadaj nierozstrzygnięte

   • Sprawdź dowody, których reguły nie rozstrzygają

5. Sprawdzony wynik lub jawne wstrzymanie

Dokładny etap musi dostać właściwe przypadki

Załóżmy, że 9800 z ilustracyjnych 10 000 rekordów przechodzi pierwszą kontrolę. Pozostałe 200 trafia do dokładniejszego badania. Brzmi wydajnie. O poprawności nic to nie mówi, dopóki ktoś nie sprawdzi próbki z 9800 oraz wyników 200.

Pierwszy etap może popełnić dwa rodzaje błędów. Może oznaczyć zwykły przypadek, niepotrzebnie zużywając czas przeglądu. Groźniejsze jest przepuszczenie przypadku, który należało zatrzymać. To, który błąd kosztuje więcej, zależy od procesu. Brak opcjonalnej etykiety i brak zgody na email marketingowy nie powinny mieć tego samego progu.

Uczciwy zarzut brzmi: „Skoro model rozumie każdy rekord, po co ufać kruchej regule?”. Ponieważ ponowne pytanie modelu nie czyni zwykłych rekordów poprawniejszymi. Słabość reguły jest widoczna: po zmianie kontraktu źródła lub celu jej założenia mogą się zestarzeć. Dlatego trzeba monitorować kontrakt i badać próbkę zaakceptowanych przypadków, a nie zastępować każdą stabilną kontrolę nieograniczonym osądem.

Przekazanie dalej też może być węższe niż pełny przegląd ludzki. Znany błąd dostawcy może mieć udokumentowaną naprawę. Nowe znaczenie pola może wymagać propozycji mapowania od agenta. Niejednoznaczna zgoda może wymagać decyzji odpowiedzialnej osoby. Pierwsza kontrola powinna kierować każdy przypadek do najmniejszej instancji, która może go rozstrzygnąć.

Poradnik integracji narzędzi biznesowych opisuje wybór źródła prawdy i zdarzenia wyzwalającego przed wyborem narzędzi. Te decyzje określają, którym wyjątkom poświęcić uwagę. Nieścisłość pola, którego nie używa żaden dalszy proces, może poczekać. Nieścisłość pola wybierającego odbiorców kampanii nie może.

Mierz błędy, które uciekły, a nie tylko oszczędność

System etapowy może stworzyć atrakcyjny wykres: dużo przypadków obsłużonych tanio, niewiele przekazanych dalej. To niepełny obraz. Dodaj drugą miarę: ile spośród przypadków przepuszczonych przez pierwszy etap nie przeszło późniejszej kontroli stanu docelowego lub niezależnego przeglądu próbki?

Pomiar powinien odnosić się do właściwego zadania. Jeśli chodzi o zgodność kontaktów, sprawdzaj stan kontaktu w systemie docelowym. Jeśli chodzi o grupę odbiorców, sprawdzaj, kto został dodany, a kto wykluczony. Liczba błędów bez mianownika i dalszych skutków jest łatwa do świętowania, a trudna do zaufania.

Praktyczny test może zacząć się na małą skalę. Zapisz zestaw ocenionych zwykłych i wyjątkowych rekordów. Uruchom na nich tanią regułę. Sprawdź każdy przeoczony wyjątek. Potem testuj ją równolegle na rzeczywistym ruchu bez pozwalania jej zatwierdzać nowych działań. Dopiero gdy znasz jej przeoczenia, niech decyduje, które przypadki ominą głębszą analizę.

Przewodnik po reverse ETL opisuje powtarzalny przepływ danych stojący za taką pracą. Pytanie o selekcję stoi obok pipeline’u: które obserwacje powiedzą nam, że stabilna reguła przestała być stabilna?

Dokładny etap poświęć temu, czego szeroki etap nie może wiedzieć.