Na ovoj stranici
Uzmite ilustrativnu skupinu od 10 000 ažuriranja kontakata. Svaki bi zapis mogao proći kroz model radi nove prosudbe o svojim poljima. To bi jednu odluku o mapiranju pretvorilo u 10 000 ponovljenih odluka.
Počnite jeftinijim pitanjem: odgovara li zapis poznatim uvjetima odobrenog mapiranja? Kodom provjerite prisutnost polja, vrste podataka, verziju sheme i izričite zahtjeve za privolu. Zapise koji ne prolaze ili ostaju dvosmisleni pošaljite na uži pregled.
To je ilustrativni dizajn, ne Tajov rezultat mjerenja. Zanimljiv broj nije koliko zapisa prva provjera propušta dalje. Važno je koliko važnih pogrešaka pogrešno odobrava.
Stručni tijek rada opisan u ovoj raspravi počinje širokom klasifikacijom normalnog i abnormalnog, a zatim dodatno analizira označene slučajeve. Njegovo područje ima drukčije uloge i dokaze od marketinških podataka. Izvor potvrđuje postupnu odluku, ne trošak ili determinističku prirodu njegova prvog algoritma. U integraciji jeftina deterministička provjera može pokriti poznate uvjete prije pažljivog pregleda nejasnih slučajeva.
Prva provjera treba razriješiti obične slučajeve
Dobra prva provjera postavlja pitanje na koje kod može odgovoriti iz dostupnih dokaza. „Postoji li izvorno polje?” jedno je takvo pitanje. „Odgovara li vrijednost vrsti koju odredište deklarira?” drugo. „Je li to ista verzija sheme za koju je mapiranje odobreno?” treće.
Pravilo se može pokrenuti za svaki redak bez izmišljanja novog tumačenja za svaki. Može i objasniti odgovor. Odbijeni redak može reći da odredišno polje birthday očekuje datum, a izvor je poslao slobodan tekst. To je korisnije od „niska sigurnost modela”.
Tajov vodič za Brevo poveznik objašnjava zašto su definicije atributa odredišta važne. Poveznik može poslati HTTP zahtjev, a primatelj svejedno zanemariti neprijavljeni atribut. Provjera deklariranih polja prije slanja hvata jednu vrstu pogreške prije zapisivanja. Naknadno čitanje odredišta hvata drugu. Nijedno se ne smije brkati s mišljenjem modela da kontakt „izgleda dobro”.
Cilj nije ukloniti prosudbu. Cilj je sačuvati je za pitanje koje je doista treba.
-
Nova skupina za sinkronizaciju
- PRVO
Provjerite poznata pravila
- Identitet, vrsta polja i opseg računa
- ZATIM
Razriješite jasne ishode
- Propustite obične zapise, zaustavite poznate pogreške
- SAMO AKO TREBA
Pregledajte neriješene slučajeve
- Ispitajte dokaze koje pravila nisu mogla razriješiti
-
Provjeren rezultat ili izričito čekanje
Skuplja provjera mora dobiti prave slučajeve
Pretpostavimo da 9800 od ilustrativnih 10 000 zapisa prođe prvu provjeru. Preostalih 200 pobliže se ispituje. To zvuči učinkovito. O ispravnosti ne govori ništa dok netko ne provjeri uzorak od 9800 odobrenih i ishode preostalih 200.
Prva provjera može pogriješiti na dva načina. Može označiti običan slučaj i nepotrebno potrošiti vrijeme pregleda. Ozbiljnije, može odobriti slučaj koji je trebalo zaustaviti. Koja je pogreška skuplja ovisi o tijeku. Polje neobvezne oznake koje nedostaje i izostanak privole za slanje marketinške e-pošte ne smiju imati isti prag.
Pošten prigovor glasi: „Ako model razumije svaki zapis, zašto vjerovati krhkom pravilu?” Zato što obični ponavljani zapisi ne postaju točniji samo zato što model ponovno pitamo. Slabost pravila vidljiva je: kada se ugovor izvora ili odredišta promijeni, njegove pretpostavke mogu zastarjeti. Zato treba pratiti ugovor i uzorkovati odobrene slučajeve. To nije razlog da svaku stabilnu provjeru zamijenimo neograničenom prosudbom.
Eskalacija može biti uža od punog ljudskog pregleda. Poznata pogreška dobavljača može trebati dokumentiran popravak. Doista novo značenje polja može trebati agenta koji predlaže mapiranje. Nejasna privola može trebati odgovornu osobu. Prva provjera trebala bi svaki slučaj usmjeriti najmanjoj ovlasti koja ga može razriješiti.
Vodič za integraciju poslovnih alata opisuje izbor izvora istine i okidača prije izbora alata. Te odluke određuju koje iznimke zaslužuju pozornost. Neslaganje u polju koje nijedan nizvodni proces ne koristi možda može čekati. Neslaganje u polju koje bira publiku kampanje ne može.
Mjerite pogreške koje prolaze, ne samo uštedu
Postupni sustav može napraviti privlačan grafikon: mnogo slučajeva obrađeno jeftino, malo ih je poslano dalje. Taj je grafikon nepotpun. Dodajte drugu mjeru: među slučajevima koje je prva provjera odobrila, koliko ih je palo na kasnijoj provjeri odredišta ili neovisnom pregledu uzorka?
Mjerenje vežite uz stvarni posao. Ako je posao uskladiti kontakte, pogledajte stanje kontakata na odredištu. Ako je posao održavati publiku, pogledajte tko je uključen, a tko isključen. Broj pogrešaka bez nazivnika i nizvodne posljedice lako je slaviti, a teško mu vjerovati.
Praktična proba može početi malim skupom. Spremite pregledane obične i iznimne zapise. Pokrenite jeftino pravilo nad njima. Provjerite svaku propuštenu iznimku. Zatim ga pokrenite na živom prometu u sjeni, bez ovlasti da odobrava novo ponašanje. Tek kada razumijete njegove propuste, pravilo smije odlučiti koji slučajevi zaobilaze dublji pregled.
Vodič za obrnuti ETL pokriva ponavljano premještanje podataka iza ovakva posla. Pitanje trijaže stoji uz taj cjevovod: koja zapažanja govore da stabilno pravilo više nije stabilno?
Pažljivu provjeru potrošite ondje gdje široka provjera ne može znati.
Često postavljana pitanja
Što je jeftina prva provjera u integraciji?
To je deterministička provjera svakog zapisa ili izvođenja, primjerice prisutnosti obveznog polja, verzije sheme ili poznate šifre pogreške. Slučajevi koje ne može razriješiti idu u užu, skuplju istragu.
Kako treba odabrati pravilo prve provjere?
Odaberite pravilo čiji se propusti razumiju i testiraju. Usporedite njegove lažno negativne i lažno pozitivne ishode s pregledanim slučajevima. Udio poslan dalje mjera je troška, a ne dokaz sigurnosti.
Treba li model AI-ja pregledati svaki zapis sinkronizacije?
Stabilno mapiranje i deterministička provjera obično mogu obraditi obične zapise. Model ili stručnu prosudbu koristite za dvosmislene iznimke te mjerite prolaze li važne pogreške kroz prvu provjeru.