Проверете всичко евтино; изследвайте внимателно малкото неясни случаи

Да вземем илюстративна партида от 10 000 актуализации на контакти. Всеки запис може да мине през модел за нова преценка на полетата му. Това би превърнало едно решение за съпоставяне в 10 000 повтарящи се решения.

Започнете с по-евтин въпрос: отговаря ли записът на известните условия на одобреното съпоставяне? Проверете в код наличието на полета, типовете данни, версията на схемата и изричните изисквания за съгласие. Изпратете записите с неуспешна проверка или оставаща неяснота за по-тесен преглед.

Това е илюстративен дизайн, не измерен резултат на Tajo. Интересното число не е колко записа преминават първата проверка. То е колко важни грешки тя неправилно допуска.

Описаният в тази презентация специализиран процес започва с широко разделяне на нормални и отклоняващи се случаи, след което анализира допълнително маркираните. Областта има различни рискове и доказателства от маркетинговите данни. Източникът показва поетапното решение, а не разхода или детерминистичността на първия алгоритъм. При интеграция евтина детерминистична проверка може да покрие известните условия, преди неясните случаи да отидат за внимателен преглед.

Първата проверка трябва да решава обикновените случаи

Добрата първа проверка задава въпрос, на който кодът може да отговори с наличните доказателства. „Присъства ли полето в източника?“ е такъв въпрос. „Отговаря ли стойността на декларирания тип в целевата система?“ е друг. „Това ли е версията на схемата, за която е одобрено съпоставянето?“ е трети.

Правилото може да се приложи към всеки ред, без да измисля ново тълкуване всеки път. То може и да обясни отговора си. За отхвърлен ред може да се посочи, че полето birthday в целевата система очаква дата, а източникът е подал свободен текст. Това е по-полезно от „ниска увереност на AI“.

Ръководството на Tajo за конектора към Brevo обяснява защо определенията на атрибутите в целевата система имат значение. Конектор може да изпрати HTTP заявка, докато приемащата система пренебрегва недеклариран атрибут. Предварителна проверка на декларираните полета улавя един клас грешки преди записа. Последващо прочитане може да улови друг. Нито едното не трябва да се бърка с мнението на модел дали контактът „изглежда добре“.

Целта не е преценката да изчезне. Целта е да я запазим за въпросите, които действително я изискват.

1. Нова партида за синхронизация

2. ПЪРВО

   Проверете известните правила

   • Идентичност, тип поле и обхват на акаунта
3. ПОСЛЕ

   Решете ясните случаи

   • Допуснете обикновените записи; задръжте известните грешки
4. САМО ПРИ НУЖДА

   Прегледайте неясните случаи

   • Разгледайте доказателствата за случаите, които правилата не решават

5. Проверен резултат или изрично задържане

Скъпата проверка трябва да получава правилните случаи

Да допуснем, че 9 800 от илюстративните 10 000 записа преминават първата проверка. Другите 200 се разглеждат по-подробно. Това звучи ефективно. Не казва нищо за правилността, докато някой не провери извадка от 9 800-те и резултатите от 200-те.

Първата проверка може да греши по два начина. Може да маркира обикновен случай и ненужно да изразходва време за преглед. По-сериозно, може да допусне случай, който е трябвало да спре. Коя грешка струва повече зависи от процеса. Липсващ незадължителен етикет и липсващо разрешение за изпращане на маркетингов имейл не трябва да имат общ праг.

Справедливо възражение е: „Ако моделът разбира всеки запис, защо да се доверяваме на крехко правило?“. Защото повтарящите се обикновени записи не стават по-правилни само като питаме модела отново. Слабостта на правилото е видима: когато договорът на източника или целевата система се промени, допусканията му може да остареят. Това е причина да следим договора и да проверяваме извадки от допуснатите случаи. Не е причина да заменим всяка стабилна проверка с неограничена преценка.

Ескалацията може да е и по-тясна от пълен човешки преглед. Известна грешка на доставчик може да изисква документирана поправка. Действително ново значение на поле може да изисква агент да предложи съпоставяне. Неяснота за съгласие може да изисква отговорния човек. Първата проверка трябва да насочва всеки случай към най-малката компетентна инстанция, която може да го реши.

Как да интегрирате няколко бизнес инструмента описва избора на източник на истината и задействащо събитие преди избора на инструменти. Тези решения определят кои изключения заслужават внимание. Несъответствие в поле, което никой процес не използва, може да почака. Несъответствие в полето, което избира аудиторията на кампания, не може.

Измервайте пропуснатите грешки, не само икономията

Поетапна система може да даде привлекателна графика: много случаи обработени евтино, малко изпратени нататък. Тази графика е непълна. Добавете втора мярка: сред случаите, преминали първата проверка, колко са се провалили при по-късна проверка в целевата система или при независим преглед на извадка?

Мярката трябва да е свързана с реалната работа. Ако задачата е да държи контактите съгласувани, проверете състоянието на контактите в целевата система. Ако задачата е да поддържа аудитория, проверете кой е включен и кой е изключен. Броят на грешките лесно изглежда като успех, но трудно заслужава доверие без общия брой случаи и последиците за следващите етапи.

Практичен пробен период може да започне в малък мащаб. Запазете набор от прегледани обикновени и изключителни записи. Пуснете евтиното правило върху тях. Проверете всяко пропуснато изключение. После го изпълнявайте паралелно върху реален поток, без да му позволявате да одобрява ново поведение. Едва след като пропуските му са разбрани, правилото трябва да определя кои случаи пропускат по-дълбок преглед.

Ръководството за reverse ETL обхваща повтарящото се преместване на данни зад такава задача. Въпросът за разпределянето стои до конвейера: кои наблюдения ни показват, че стабилното правило вече не е стабилно?

Използвайте внимателната проверка там, където широката не може да знае.