Preverite vse poceni, podrobno raziščite le nekaj primerov

Vzemimo ponazoritveno serijo 10.000 posodobitev stikov. Vsak zapis bi lahko poslali modelu, da ponovno presodi njegova polja. Tako bi eno odločitev o preslikavi spremenili v 10.000 ponovljenih odločitev.

Začnite s cenejšim vprašanjem: ali zapis izpolnjuje znane pogoje odobrene preslikave? V kodi preverite prisotnost polj, podatkovne tipe, različico sheme in izrecne zahteve glede privolitve. Zapise, ki ne ustrezajo ali ostanejo dvoumni, pošljite v ožji pregled.

To je ponazoritvena zasnova, ne meritev Taja. Zanimiva številka ni, koliko zapisov prvi pregled spusti naprej. Zanima nas, koliko pomembnih napak spusti naprej napačno.

Specializirani potek, opisan v tem viru, se začne s široko razvrstitvijo na običajno in neobičajno, nato označene primere analizira podrobneje. Njegovo področje ima drugačna tveganja in dokaze kot trženjski podatki. Vir podpira večstopenjsko odločanje, ne pa stroška ali deterministične narave njegovega prvega algoritma. Pri integraciji lahko poceni deterministično preverjanje pokrije znane pogoje, preden negotovi primeri dobijo pozorno presojo.

Prvi pregled naj razreši običajne primere

Dober prvi pregled postavi vprašanje, na katero lahko koda odgovori iz razpoložljivih dokazov. „Ali izvorno polje obstaja?“ je eno. „Ali vrednost ustreza deklariranemu tipu v ciljnem sistemu?“ je drugo. „Ali gre za isto različico sheme, za katero je bila preslikava odobrena?“ je tretje.

Pravilo lahko teče na vsaki vrstici, ne da bi za vsako posebej izumljalo razlago. Svoj odgovor lahko tudi pojasni. Zavrnjen zapis lahko pove, da polje birthday v ciljnem sistemu pričakuje datum, izvor pa je poslal prosto besedilo. To je uporabnejše kot „nizka gotovost ocene AI“.

Tajov vodnik za priključek Brevo pojasnjuje, zakaj so definicije atributov v ciljnem sistemu pomembne. Priključek lahko uspešno pošlje zahtevo HTTP, prejemni sistem pa prezre nedeklariran atribut. Predhodno preverjanje deklariranih polj ujame eno vrsto napake pred zapisom. Poznejše ponovno branje lahko ujame drugo. Nobenega od obeh ne smemo zamenjati z mnenjem modela, da je stik „videti v redu“.

Cilj ni odpraviti presoje, temveč jo ohraniti za vprašanja, ki jo potrebujejo.

1. Nova serija za sinhronizacijo

2. NAJPREJ

   Preverite znana pravila

   • Identiteta, tip polja in obseg računa
3. NATO

   Razrešite jasne izide

   • Spustite običajne zapise; znane napake zadržite
4. LE PO POTREBI

   Preglejte nerazrešene primere

   • Preučite dokaze, ki jih pravila niso mogla razrešiti

5. Preverjen rezultat ali izrecna zadržitev

Zahtevnejši pregled mora dobiti prave primere

Predpostavimo, da 9.800 od ponazoritvenih 10.000 zapisov prestane prvi pregled. Preostalih 200 obravnavamo natančneje. To zveni učinkovito. O pravilnosti pa ne pove ničesar, dokler nekdo ne preveri vzorca od 9.800 sprejetih in izidov 200 pregledanih.

Prvi pregled lahko naredi dve vrsti napak. Lahko označi običajen primer in po nepotrebnem porabi čas za pregled. Resneje pa lahko spusti primer, ki bi ga moral ustaviti. Katera napaka stane več, je odvisno od poteka dela. Manjkajoča neobvezna oznaka in manjkajoče dovoljenje za trženjsko e-pošto ne smeta imeti istega praga.

Pošten ugovor je: „Če model razume vsak zapis, zakaj zaupati krhkemu pravilu?“ Ker običajni ponavljajoči se zapisi ne postanejo pravilnejši samo zato, ker model vprašamo znova. Slabost pravila je vidna: ko se spremeni tehnična specifikacija izvornega ali ciljnega sistema, lahko njegove predpostavke zastarajo. Zato spremljajte tehnično specifikacijo in vzorčite sprejete primere. To ni razlog, da vsako stabilno preverjanje nadomestite z neomejeno presojo.

Eskalacija je lahko ožja od popolnega človeškega pregleda. Znana napaka ponudnika morda potrebuje dokumentiran popravek. Resnično nov pomen polja lahko zahteva, da agent predlaga preslikavo. Dvoumnost privolitve lahko zahteva odgovorno osebo. Prvi pregled naj vsak primer usmeri do najmanjše pristojnosti, ki ga lahko razreši.

Vodnik za povezovanje več poslovnih orodij pred izbiro orodij opredeli vir resnice in sprožilec. Ti odločitvi določata, katere izjeme zaslužijo pozornost. Neskladje pri polju, ki ga ne uporablja noben nadaljnji proces, lahko počaka. Neskladje pri polju, ki izbira občinstvo kampanje, pa ne.

Merite, kaj uide, ne le prihranka

Večstopenjski sistem lahko ustvari privlačen graf: veliko primerov je obdelanih poceni, malo jih gre naprej. Tak graf je nepopoln. Dodajte drugo merilo: koliko primerov, ki jih je prvi pregled sprejel, ni prestalo poznejšega preverjanja v ciljnem sistemu ali neodvisnega pregleda vzorca?

Meritev vežite na dejansko nalogo. Če želite usklajene stike, preglejte stanje stikov v ciljnem sistemu. Če vzdržujete občinstvo, preverite, kdo je bil vključen in kdo izključen. Število napak brez imenovalca in posledic v nadaljnjem procesu je lahko slaviti, težko pa mu je zaupati.

Praktičen preizkus se lahko začne z majhnim obsegom. Shranite pregledano zbirko običajnih in izjemnih zapisov. Nad njimi zaženite poceni pravilo. Preverite vsako spregledano izjemo. Nato ga preizkusno poganjajte ob živem prometu, ne da bi smel odobriti novo vedenje. Šele ko razumete njegove spreglede, naj pravilo odloča, kateri primeri preskočijo poglobljen pregled.

Vodnik za obratni ETL opisuje ponavljajoče se premikanje podatkov za takšno delo. Vprašanje razvrščanja stoji ob tem cevovodu: katera opažanja nam povedo, da stabilno pravilo ni več stabilno?

Pozoren pregled namenite primerom, ki jih široki pregled ne more razrešiti.