Kontrollera allt billigt, undersök bara det som behövs

Ta en illustrativ grupp om 10 000 kontaktuppdateringar. Varje post skulle kunna skickas till en modell för ett nytt omdöme om fälten. Då blir ett beslut om fältmappning 10 000 upprepade beslut.

Börja med en billigare fråga: uppfyller posten de kända villkoren för den godkända mappningen? Kontrollera i kod att fält finns, datatyper, schemaversion och uttryckliga krav på samtycke. Skicka de poster som inte klarar kontrollen eller förblir tvetydiga till en snävare granskning.

Det här är en illustrativ design, inte ett riktmärke från Tajo. Det intressanta antalet är inte hur många poster som klarar första kontrollen. Det är hur många viktiga fel den felaktigt släpper igenom.

Ett specialiserat arbetsflöde som beskrivs i samtalet börjar med en bred indelning i normalt eller avvikande och analyserar sedan de markerade fallen vidare. Det området har andra risker och annat underlag än marknadsföringsdata. Källan visar den etappvisa bedömningen, inte kostnaden eller om den första algoritmen är deterministisk. I en integration kan en billig deterministisk kontroll täcka kända villkor innan osäkra fall får noggrann granskning.

Första kontrollen ska avgöra vanliga fall

En bra första kontroll ställer en fråga som kod kan besvara med tillgängligt underlag. ”Finns källfältet?” är en sådan. ”Passar värdet målsystemets angivna typ?” är en annan. ”Är det samma schemaversion som mappningen godkändes för?” är en tredje.

Regeln kan köras på varje rad utan att hitta på en ny tolkning varje gång. Den kan också förklara sitt svar. En avvisad rad kan ange att målsystemets fält birthday väntar sig ett datum medan källan gav fri text. Det är mer användbart än ”låg AI-säkerhet”.

Tajos guide till Brevo-anslutningen förklarar varför målsystemets attributdefinitioner spelar roll. En anslutning kan skicka en HTTP-begäran samtidigt som mottagaren ignorerar ett attribut som inte deklarerats. En förhandskontroll av deklarerade fält fångar en sorts fel före skrivningen. En senare återläsning fångar en annan. Inget av detta är samma sak som modellens åsikt att en kontakt ”ser bra ut”.

Målet är inte att få omdömet att försvinna, utan att spara det till frågor där det behövs.

1. Ny grupp för synkronisering

2. FÖRST

   Kontrollera kända regler

   • Identitet, fälttyp och kontogräns
3. SEDAN

   Avgör tydliga fall

   • Släpp igenom vanliga poster; stoppa kända fel
4. BARA VID BEHOV

   Granska olösta fall

   • Undersök underlaget som reglerna inte kunde avgöra

5. Kontrollerat resultat eller uttryckligt stopp

Den dyra kontrollen behöver rätt fall

Anta att 9 800 av de illustrativa 10 000 posterna klarar den första kontrollen. De övriga 200 granskas närmare. Det låter effektivt. Men det säger inget om riktigheten förrän någon kontrollerar ett urval av de 9 800 och resultaten för de 200.

Första kontrollen kan göra två slags fel. Den kan markera ett normalt fall och slösa granskningstid. Allvarligare är att släppa igenom ett fall som borde stoppas. Vilket fel som kostar mest beror på arbetsflödet. En saknad frivillig etikett och avsaknad av tillstånd att skicka marknadsföring ska inte ha samma gränsvärde.

En rimlig invändning är: ”Om en modell kan förstå varje post, varför lita på en skör regel?” Därför att upprepade vanliga poster inte blir riktigare bara för att man frågar modellen igen. Regelns svaghet är synlig: när källans eller målets kontrakt ändras kan antagandena bli gamla. Det är ett skäl att bevaka kontraktet och ta stickprov bland godkända fall, inte att ersätta varje stabil kontroll med obegränsat omdöme.

Eskaleringen kan också vara mindre än fullständig manuell granskning. Ett känt leverantörsfel kan kräva dokumenterad reparation. En helt ny fältbetydelse kan kräva att en agent föreslår en mappning. Oklart samtycke kan kräva ansvarig person. Första kontrollen ska styra varje fall till den minsta befogenhet som kan avgöra det.

Hur man integrerar flera företagsverktyg beskriver valet av styrande källa och utlösande händelse innan verktygen väljs. De besluten avgör vilka undantag som behöver uppmärksamhet. Ett fältfel i data som ingen senare process använder kan vänta. Ett fel i fältet som väljer kampanjmålgrupp kan inte det.

Mät vad som slinker igenom, inte bara besparingen

Ett etappvis system kan skapa en tilltalande graf: många fall behandlas billigt, få skickas vidare. Grafen är ofullständig. Lägg till ett mått: bland fallen som första kontrollen godkände, hur många misslyckades i en senare kontroll i målsystemet eller vid oberoende stickprov?

Knyt mätningen till det verkliga jobbet. Om kontakter ska stämma överens, granska kontakttillståndet i målsystemet. Om en målgrupp ska hållas korrekt, granska vilka som togs med och vilka som uteslöts. En felsiffra utan nämnare och följder längre fram är lätt att fira och svår att lita på.

Ett praktiskt försök kan börja smått. Spara en uppsättning granskade vanliga och avvikande poster. Kör den billiga regeln mot dem. Undersök varje missat undantag. Låt sedan regeln gå parallellt med verklig trafik utan att den får godkänna nytt beteende. Först när missarna är förstådda bör regeln avgöra vilka fall som slipper djupare granskning.

Guiden till reverse ETL behandlar den upprepade dataflytten bakom arbetet. Sorteringsfrågan ligger bredvid pipelinen: vilka observationer visar att den stabila regeln inte längre är stabil?

Lägg den noggranna granskningen där den breda kontrollen inte kan veta.