Com validar l’enrichment amb IA abans que arribi als reps

Tracteu una resposta d’IA com tracteu un email sense verificar

Ja tenim una regla per als proveïdors. Alguns tornen noms i URLs de LinkedIn i poca cosa més, així que tractem els seus emails i telèfons com a no verificats per a ICPs fora dels Estats Units fins que alguna cosa independent els confirmi. Ningú discuteix aquesta regla. No és un insult al proveïdor. És una afirmació sobre el que el camp és realment: una declaració, no un fet.

Doneu el mateix estatus a cada columna d’IA. Un resultat d’IA és una declaració amb una confiança que ningú ha mesurat. Continua sense verificar fins que un xequeig determinista, una font citada o una persona diguin el contrari.

Tot el que ve a continuació és com imposar-ho sense convertir la vostra taula en una feina de revisió manual.

Pas 1: filtreu l’entrada abans de preocupar-vos per la sortida

La majoria de columnes d’IA que tornen brossa van rebre brossa. Al model se li va demanar llegir un web que no va carregar, investigar una empresa gairebé sense petjada pública o classificar una fila els camps d’origen de la qual encara no havien acabat de normalitzar-se.

Així que el primer control no és un prompt. És un pre-check que corre per sobre de la columna d’IA i decideix quines files són tan sols elegibles per investigar.

Al nostre workflow de deduplicació això és un pas literal: la normalització s’assenta, després corre una porta de Company Quality Pre-Check, i només llavors es disparen les cerques per nivells. La mateixa forma funciona per a l’enrichment. Abans que corri la columna d’IA, comproveu que el domini resol, que el web torna contingut i que els camps d’identitat amb què feu match estan omplerts i normalitzats. Les files que no passen el pre-check no van al model. Van a un fitxer retingut.

Hi ha una segona versió, menys òbvia. Quan puntuem comptes amb senyals públics, filtrem primer per cobertura d’indexació, perquè una empresa mal indexada torna un fals zero i un zero es llegeix com un senyal fort. La mateixa trampa, una altra columna. Si no sabeu si la font tenia res a dir, no podeu interpretar el que el model en va dir.

Pas 2: escriviu un esquema que pugui negar-se a respondre

Un prompt que exigeix una resposta per a cada fila n’obtindrà una per a cada fila, incloses les files on no existeix cap resposta. Heu posat l’al·lucinació dins la mateixa petició.

La nostra regla fixa a la porta de qualificació és contundent: desconegut no és no. Un no endevinat esborra en silenci compradors reals, i un sí endevinat us compra sense fer soroll una factura d’enrichment. Així que el contracte de sortida té quatre parts, i totes quatre són obligatòries.

Un valor acotat. Un d’un conjunt fix, no prosa lliure. Sí, no, desconegut. O un vocabulari controlat, com fem amb la funció i la seniority: una llista congelada de valors permesos, mai un camp obert.

Un motiu d’una línia. Amb les paraules del mateix model, per què va respondre així. Això és el que fa que una mostra es revisi en segons en lloc de minuts.

Un valor de confiança. La majoria d’equips ja el capturen. Gairebé ningú hi filtra, cosa que el converteix en decoració.

Una font. La URL d’on va sortir la resposta, o la cita en què es va basar. Només marquem un senyal de propensió com a sí quan hi ha una font pública verificable al darrere; si no, és desconegut, mai no. Una columna d’IA hauria de complir el mateix llistó. Sense cita, no hi ha afirmació.

El requisit de font fa més feina que el score de confiança. Un model que ha de dir on va llegir alguna cosa tornarà desconegut moltes més vegades, que és exactament el comportament pel qual esteu pagant.

Pas 3: mostregeu la columna abans de llançar la taula

Tothom sap que cal provar un prompt en unes quantes files. Gairebé ningú defineix què vol dir aprovar, cosa que converteix la prova en teatre.

Fixeu per escrit el llindar d’acceptació abans de llançar-la.

1. Primer, files de prova. De tres a cinc files, revisades a mà contra la font real. Això caça els bugs del prompt abans que es converteixin en la factura de la taula sencera.
2. Després, una mostra amb un número associat. Validem les fusions contra una mostra del deu per cent i comparem els registres closed-won amb Stripe amb un llindar de variació del dos per cent. Copieu aquesta disciplina. Traieu el deu per cent de la sortida de la columna d’IA, o cent files, el que sigui menor, i comproveu cadascuna contra la font citada.
3. Decidiu per endavant què desencadena una mostra suspesa. Per sota del vostre llindar, la columna no surt. Es torna a escriure el prompt i es torna a mostrejar, o s’esborra. Una columna que suspèn la mostra i surt igualment és pitjor que no tenir columna, perquè ara les respostes errònies carreguen amb la credibilitat del vostre equip.
4. No dictamineu mai sobre els casos ambigus. Quan vam normalitzar càrrecs en un projecte industrial, nou contactes amb el càrrec exacte "Manager" es van apartar per validar-los un a un en lloc de classificar-los per regla, i un càrrec, "Workshop Manager", va anar a revisió en comptes d’endevinar-se. Això no és perfeccionisme. És la diferència entre una taxonomia i un desastre amb etiquetes molt segures de si mateixes.

Registreu la taxa de precisió. És l’únic número que us diu si la columna millora o es podreix, i gairebé cap equip no el té.

Pas 4: una columna d’IA mai escriu pel seu compte

Aquest és el control que us salva. Al nostre workflow de dedupe, els nivells que es resolen de manera determinista es fusionen automàticament. Els nivells que depenen de validació amb IA van a revisió humana, i les escriptures s’activen amb un botó. Mai en automàtic. Els registres marcats per a revisió manual els aprova un revisor amb nom abans de tancar l’execució.

Munteu el mateix a l’enrichment.

Confiança alta més una font citada escriu en una propietat de staging, no al camp que llegeixen els reps. Qualsevol cosa per sota del llindar de confiança, o sense font, va a una cua de revisió. No a un valor per defecte, i mai a un d’endevinat.

L’escriptura al CRM continua darrere de les portes que ja teniu. Res no arriba a HubSpot sense un email verificat. Res no arriba a una seqüència sense passar l’ encreuament amb la llista de supressió.

I poseu un post-check determinista per sota de la IA. Les nostres execucions de fusió acaben amb una passada de col·lisions per domini, després per nom estricte, després per nom flexible, precisament per caçar el que la lògica anterior va deixar passar. Una taula d’enrichment es mereix el mateix: columnes de control senzilles com size_valid, title_valid i region_valid que cacin els errors obvis que el model va deixar passar.

La IA s’ocupa dels casos difusos. Les columnes deterministes cacen els obvis. Cap de les dues pot ser l’única cosa que hi ha entre la suposició d’un model i la boca d’un rep.

Pas 5: poseu la columna al xequeig de salut

Els pipelines es trenquen en silenci. Una vegada vam perdre un mes de dades perquè es va esborrar un webhook entre l’eina d’enviament i Clay i res no es va queixar. Per això fem xequejos de salut automàtics cada setmana que mapen les dades clau i marquen les ruptures per revisar-les.

Una columna d’IA degradada es veu exactament igual que una que funciona. El web va canviar el disseny, el model va començar a llegir un bàner de galetes en lloc d’una pàgina de serveis, i la columna continua tornant valors segurs amb la mateixa taxa d’ompliment. Afegiu tres coses al xequeig setmanal: la taxa de desconeguts, la confiança mitjana i el percentatge de files sense font. Si la taxa de desconeguts cau en picat, això no és una millora. És el vostre model tornant-se menys honest.

El que això us costa de debò

Feu els números en l’ordre en què es gasten els crèdits. La qualificació és la columna més barata de la taula. L’enrichment és la més cara. En una prova interna de proveïdors, una execució amb un sol proveïdor i sense waterfall va costar 227 crèdits per vint-i-cinc comptes, mentre que un waterfall ordenat que s’atura al primer encert va sortir per entre cinc i quinze crèdits per empresa. Aquesta diferència és el premi per encertar l’ordre.

Una qualificació errònia de la IA ho destrueix pels dos costats. Un fals sí paga l’enrichment complet en files a les quals mai no hi anàveu a vendre. Un fals no esborra compradors reals i no us n’assabenteu mai. I fixeu-vos que les columnes d’IA solen córrer amb la vostra pròpia clau del model i no amb crèdits de la plataforma, cosa que vol dir que la despesa ni tan sols apareix al lloc que esteu vigilant.

Després hi ha el cost que ningú posa en un full de càlcul. Un rep obre una trucada amb una dada que la vostra taula es va inventar. Això és una relació, una recomanació i una renovació, i es carrega a la vostra credibilitat, no al vostre pressupost.

Com es veu quan està ben fet

Cada columna d’IA té un pre-check a sobre i columnes de control a sota. Cada resultat porta un valor, un motiu, una confiança i una font. Desconegut és una resposta permesa i se’n vigila la taxa. Existeix una taxa de precisió de la mostra, està escrita i té un llindar que pot aturar un llançament. Cap resultat d’IA no escriu en un camp que llegeixin els reps sense passar una porta o un revisor.

Construïm això als motors d’enrichment com a part del mòdul de Data Enrichment and List Building, i és una de les primeres coses que busquem en una GTM Maturity and Revenue Leak Assessment, perquè el mal enrichment no és un problema de dades. És un problema de prevenció disfressat de problema de neteja.

Si les vostres columnes d’IA tenen taxa d’ompliment però no taxa de precisió, no teniu un sistema d’enrichment. Teniu un generador d’opinions molt ràpid connectat directament al vostre pipeline.