Com vam construir un sistema de resolució d'identitat.
Per a reports generats amb IA.
Cerca "Maria Garcia, software engineer" a LinkedIn. Obtindràs més de 400 coincidències. Ara imagina que el teu sistema de briefings amb IA tria la persona equivocada i redacta un perfil detallat, coherent i completament incorrecte.
Això és exactament el que ens vam trobar construint el pipeline automàtic de briefings de Reedy Meet. Els LLM són excel·lents sintetitzant informació, però no són eines de verificació d'identitat. No tenen un mecanisme nadiu per detectar quan els resultats de "Michael Smith" barregen dades de tres persones diferents amb el mateix nom. Resoldre-ho requereix un enfocament diferent: quantificar certesa, no inferir-la.
Vista general del detall de la reunió.
El punt clau: la identitat a la web no és binària
No hi ha un llindar net que separi "és aquesta persona" de "no ho és". L'evidència disponible varia massa. De vegades tens cinc senyals independents que convergeixen en el mateix perfil. Altres vegades, només una menció en un directori desactualitzat del 2019.
Modelar aquesta incertesa com un valor continu entre 0 i 1 no és només elegant: és el que permet calibrar què sap el sistema i ser honestos amb el que no sap. La confiança amb què s'afirma una dada ha de ser proporcional a l'evidència que la sosté.
Aquest índex es tradueix en quatre nivells operatius que controlen directament com es redacta el dossier:
| Nivell | Rang | Què fa el sistema |
|---|---|---|
| HIGH | ≥ 0.90 | Fets expressats directament: "L'Elena és enginyera de ML a Nexus AI." |
| MEDIUM | 0.60–0.89 | Llenguatge matisat: "Segons fonts web, l'Elena treballa a Nexus AI." |
| LOW | 0.30–0.59 | Només s'inclouen camps d'alta confiança; la resta s'omet. |
| FAILED | < 0.30 | No es genera dossier. El silenci és millor que el soroll. |
La diferència entre HIGH i MEDIUM no és cosmètica. La manera com redactes un fet canvia el pes que li dona el lector i la confiança que diposita en el sistema.
Context: una barrera de control dins d'un pipeline més gran
El sistema de generació de briefings funciona com un agent que encadena múltiples eines: cerca, extracció, verificació i síntesi. Aquest post cobreix només la verificació: la barrera de control que se situa entre resultats de cerca en cru i informe final.
El model de scoring s'executa per a cada participant extern de la reunió. Els participants interns (mateix domini de correu que l'amfitrió) s'exclouen completament. La resolució d'identitat només és rellevant per a persones externes, així que no apliquem una penalització: fem una exclusió contextual abans d'avaluar cap senyal.
Deu senyals, cadascun amb un pes
La premissa és simple: un sol senyal pot fallar o ser enganyós. Deu senyals independents apuntant en la mateixa direcció són molt més difícils de rebatre.
Cada senyal és una pregunta binària (dispara o no dispara) i cadascun té un pes segons el seu poder discriminatiu real. Els senyals positius sumen a l'índex; els negatius resten.
Senyals positius
| Senyal | Pes | Què valida |
|---|---|---|
| Email exact match | +0.25 | Apareix el correu literal de la persona en algun resultat indexat? El correu és un identificador únic i és evidència directa. |
| Domain name consistency | +0.30 | En quin percentatge de resultats coapareixen el nom de la persona i l'empresa esperada? Per sobre del 70% és un senyal fort. També funciona amb Gmail. |
| Corporate email domain match | +0.20 | El domini del correu (john@acme.com) coincideix semànticament amb una empresa com "Acme Corp"? És diferent de la consistència estadística del senyal anterior. |
| LinkedIn verified | +0.25 | No n'hi ha prou amb "tenir LinkedIn": el perfil ha de mostrar explícitament nom + empresa esperada. |
| Name + title in result heading | +0.15 | Nom i empresa apareixen junts al títol o titular del resultat? El títol té més pes semàntic que el cos del text. |
| Role consistency | +0.10 | El rol actual apareix en dues o més fonts independents? |
| Recent activity | +0.05 | Hi ha indicadors de recència ("2025", "2026", "recently")? Té poc pes, però ajuda a desempatar. |
Senyals negatius
| Senyal | Penalització | Què valida |
|---|---|---|
| Conflicting company | −0.20 | Els resultats associen la persona a una empresa coneguda diferent de l'esperada. |
| Generic name without disambiguators | −0.15 | Nom molt comú sense LinkedIn clar, empresa o rol específic. Aquesta penalització només s'aplica quan realment falten identificadors. |
| Stale information | −0.10 | Predominen indicadors de dades antigues: "former", "previously", "ex-", o anys com 2020–2022. |
El càlcul
Score = sum of weights of fired signals Índex final = clamp(Score, 0, 1)
Dos exemples ho il·lustren.
Elena Rodriguez — elena.rodriguez@nexusai.com
| Senyal | Dispara? | Contribució |
|---|---|---|
| Email exact match | ✓ | +0.25 |
| Domain name consistency | ✓ (9/10 results mention nexusai) | +0.30 |
| Corporate email domain match | ✓ | +0.20 |
| LinkedIn verified | ✓ | +0.25 |
| Name + title in heading | ✗ | 0 |
| Role consistency | ✓ ("ML Engineer" in 3 sources) | +0.10 |
| Recent activity | ✓ | +0.05 |
| Conflicting company | ✗ | 0 |
| Generic name | ✗ | 0 |
| Stale information | ✗ | 0 |
Índex brut: 1.15 → ajustat a 1.00 → HIGH
Carlos Lopez — carlos.lopez@gmail.com
| Senyal | Dispara? | Contribució |
|---|---|---|
| Email exact match | ✗ (not indexed) | 0 |
| Domain name consistency | ✗ (results scattered across 5+ people) | 0 |
| Corporate email domain match | ✗ (generic email) | 0 |
| LinkedIn verified | ✗ (multiple profiles, no clear company) | 0 |
| Name + title in heading | ✗ | 0 |
| Role consistency | ✗ (contradictory roles across results) | 0 |
| Recent activity | ✓ | +0.05 |
| Conflicting company | ✗ | 0 |
| Generic name | ✓ | −0.15 |
| Stale information | ✓ | −0.10 |
Índex: −0.20 → ajustat a 0.00 → FAILED
El problema no és Gmail en si. El problema és l'absència total de senyals positius combinada amb un nom molt comú. Un Carlos Lopez amb Gmail però amb LinkedIn actiu, empresa clara i rol consistent puntuaria molt diferent.
Quan la primera passada no és suficient: desambiguació adaptativa
Els índexs per sota de 0.7 no passen directament a FAILED. En lloc d'això, el sistema activa una segona cerca més específica amb tots els identificadors disponibles:
"Carlos Lopez" "carlos.lopez@gmail.com" "DataCorp" "LinkedIn profile"
Cada resultat d'aquesta cerca secundària es tracta com un candidat i es puntua amb una escala diferent:
| Condició | Punts |
|---|---|
| Literal email in result content | +50 |
| Corporate domain in URL | +30 |
| Expected company in content | +20 |
| Name in result title | +15 |
| LinkedIn URL | +10 |
| Recent information | +10 |
El millor candidat guanya només si supera 40 punts i treu més de 20 punts al segon. Si el marge és menor, es marca com "massa ajustat per decidir" i no es genera dossier.
En producció, aquesta segona capa resol aproximadament el 85% dels casos que no havien passat la primera.
Confiança per camp, no només índex global
Un índex global de 0.75 no vol dir que tots els fets del perfil siguin igual de fiables. L'empresa i el rol actual poden estar corroborats per cinc fonts, mentre que l'educació pot aparèixer en un únic resultat del 2019. Tractar-los igual seria un error.
El sistema classifica cada camp per prioritat i pel nombre de senyals crítics activats:
- Camps d'alta prioritat (empresa, rol, LinkedIn): verificats si l'índex ≥ 0.6
- Camps de prioritat mitjana (experiència, web corporativa): verificats només si l'índex ≥ 0.9 o almenys 2 senyals crítics
- Camps de baixa prioritat (formació, notícies antigues): sempre no verificats
El generador del dossier rep instruccions explícites per a cada nivell:
- Fets verificats → redactats com afirmacions directes
- Dades no verificades → redactades amb llenguatge condicional ("segons fonts web...") o omeses
El resultat és un informe honest sobre el seu propi grau de certesa, no una barreja indiferenciada de fets i suposicions.
Per què no entrenar directament un classificador?
Dues raons.
La primera és pragmàtica: etiquetar prou casos per entrenar un model fiable té cost real en temps i diners. Els pesos ajustats iterativament donen taxes d'error del 2-3% en casos HIGH, i això és suficient per al problema.
La segona, més important, és la interpretabilitat. Quan el sistema retorna un MEDIUM de 0.67, pots veure exactament per què: quins senyals han disparat, quins no, i quina informació faltava. Un model de caixa negra retorna un número sense explicació. En un producte on la confiança depèn de poder auditar decisions, aquesta diferència pesa més que una millora marginal de precisió.
Els pesos també són només paràmetres. Si email_exact_match és més discriminatiu del previst, es pot pujar de 0.25 a 0.30 sense tornar a entrenar.
Números de producció
Distribució d'índex sobre tots els participants processats:
| Nivell | Proporció |
|---|---|
| HIGH (≥ 0.9) | 42% |
| MEDIUM (0.6–0.9) | 31% |
| LOW (0.3–0.6) | 18% |
| FAILED (< 0.3) | 9% |
El 73% dels casos arriba a confiança suficient per generar dossier. El 27% restant reflecteix limitacions reals del sistema, no un error de disseny. Un sistema honest amb la incertesa és més útil que un que la maquilla.
De la validació manual setmanal (50 casos aleatoris):
- Falsos positius (HIGH incorrecte): 2-3%
- Falsos negatius (LOW/FAILED per a la persona correcta): 8-10%, sobretot per canvis recents de feina encara no reindexats
- Precisió en casos HIGH/MEDIUM: ~88%
El 23% dels casos activa la capa de desambiguació. D'aquests, el 85% es resolen amb prou confiança per continuar.
Modes de fallada coneguts
El sistema funciona especialment bé per a professionals tecnològics amb presència digital activa: enginyers amb GitHub, LinkedIn, blogs o aparicions en conferències. També per a executius amb cobertura en premsa.
Tres escenaris redueixen el rendiment de manera consistent:
Canvis recents de feina. La web triga setmanes o mesos a reindexar. Si algú ha canviat d'empresa fa tres setmanes, encara pot aparèixer principalment amb el rol anterior. L'índex baixa correctament, però el sistema no pot determinar amb total certesa quina versió és l'actual.
Professionals de sectors tradicionals. El sistema està optimitzat per a entorns tech, on la petjada digital és més gran. En sectors amb baixa presència online, els scores tendeixen a baixar fins i tot si la persona és identificable per altres vies.
Homònims dins la mateixa empresa. Dues persones amb el mateix nom a la mateixa companyia poden confondre el sistema fins i tot quan el domini coincideix. És la principal font de falsos positius, amb un 2-3% en casos HIGH.
Vista del report generat per a un participant.
Conclusió
Resoldre identitat a la web és un problema d'acumulació d'evidència, no de cerca. La diferència entre "trobar informació sobre algú" i "verificar que la informació trobada pertany a aquella persona concreta" pot semblar subtil, però canvia completament com s'ha de dissenyar el sistema.
El model de scoring que hem descrit no és perfecte, com tampoc ho és cap sistema heurístic. Però és interpretable, ajustable i calibrat en la direcció correcta: prefereix el silenci abans que errors segurs.
En productes on un error d'identitat compromet la credibilitat, aquesta és exactament la postura adequada.
Construïm junts
Unim experiència i innovació per portar el teu projecte al següent nivell.