Resolución Inteligente de Entidades

¿Qué hace Resolución Inteligente de Entidades?

Resuelve identidades al nivel de esfuerzo más bajo que establezca una respuesta confiable. Escala solo cuando los identificadores existentes, las asignaciones o las pruebas de corroboración sean insuficientes. Esta skill se aplica a registros genuinamente ambiguos de personas y organizaciones, incluidos perfiles o candidatos mediáticos en competencia; las tareas ordinarias de manejo de imágenes y las uniones deterministas de ID no la requieren.

Principio Fundamental

Trata la resolución de entidades como una investigación por etapas, no como una consulta. La búsqueda exacta, la búsqueda por slug, la popularidad y el juicio del LLM son señales útiles, pero ninguna debe dominar silenciosamente a las demás.

Separa tres preguntas:

• Cobertura: ¿enumeramos todas las entidades solicitadas?
• Identidad: ¿este candidato representa a la persona u organización solicitada?
• Utilidad: ¿es este el mejor registro utilizable para la tarea?

Un registro de alta utilidad con evidencia de identidad débil es un riesgo de falso positivo. La identidad prevalece sobre la popularidad, la integridad del perfil, la disponibilidad de imágenes y el ranking de búsqueda.

Niveles de Resolución

Elige el nivel suficiente más bajo; un nivel superior no es un requisito previo obligatorio.

• Nivel 0 — Identificación directa: Coincide con un ID estable autoritativo, URL canónica o identificador de cuenta verificado. Detente cuando eso resuelva la tarea.
• Nivel 1 — Reconciliación determinista: Utiliza cruces explícitos, alias revisados, IDs de fuentes específicas documentados o enlaces de identidad verificados. Nunca inventes una asignación.
• Nivel 2 — Identificación contextual: Corrobora un nombre utilizando eventos, sesiones, afiliación apropiada en el tiempo, perfil personal, propiedad del proyecto o identificadores de fuente verificados de forma independiente. Escala cuando los candidatos o las pruebas estén en conflicto.
• Nivel 3A — Descubrimiento de perfil oficial: Encuentra sitios web y cuentas de redes sociales controlados por la entidad, páginas oficiales de oradores, directorios de empleadores o perfiles de proyectos y autores. Prefiere perfiles enlazados desde otra fuente confiable.
• Nivel 3B — Corroboración independiente: Compara identificadores, alias, eventos, proyectos, afiliaciones y fechas en fuentes independientes. Las copias sindicadas de una biografía no cuentan como confirmación separada.
• Nivel 3C — Reconciliación de alias e histórica: Resuelve nombres artísticos, variantes ortográficas, transliteraciones, empleadores históricos, adquisiciones y apariciones en eventos utilizando asignaciones explícitas o corroboración independiente. Mantén las afiliaciones con ámbito temporal.
• Nivel 3D — Recuperación de candidatos: Busca alias y nombres contextualizados, prueba IDs directos, URLs y slugs, y usa un LLM para sugerir sondas de recuperación dirigidas solo cuando la búsqueda ordinaria no encuentre registros plausibles. Los candidatos generados no son identidades verificadas.
• Nivel 3E — Adjudicación de alta fidelidad: Compara evidencia de identidad, autoridad de la fuente, consistencia histórica, registros conflictivos y alternativas significativas. Un LLM puede resumir o reordenar candidatos, pero no puede reemplazar la identificación respaldada por fuentes.
• Nivel 4 — Sensible o no resuelto: Requiere revisión explícita cuando las identidades permanecen ambiguas, las fusiones duraderas o la publicación serían consecuentes, se expondría información privada o la identificación biométrica sería necesaria. Devuelve ambiguous, needs_review o unresolved.

Fuentes Preferidas

Para identidad y autopresentación actual, prioriza fuentes controladas por la entidad:

1. Sitio web personal, blog o dominio personal verificado.
2. Cuenta de X/Twitter.
3. Perfil de LinkedIn.
4. Perfil de GitHub.
5. Perfil de Hugging Face.
6. Perfil de Google Scholar, Semantic Scholar, ORCID o arXiv.
7. Canal personal de YouTube.
8. Perfil de Substack, Medium o Dev.to.
9. Cuenta de Bluesky o Mastodon.

Los enlaces recíprocos, los handles consistentes, los dominios compartidos, la propiedad del proyecto y el historial de publicaciones fortalecen la identidad. Un nombre para mostrar coincidente o una insignia de plataforma por sí solos no establecen la propiedad de la cuenta.

Cambia la prioridad de la fuente cuando la pregunta cambie:

• Participación en eventos y afiliación histórica: Los IDs emitidos por el organizador, las páginas oficiales de oradores y los horarios, las biografías específicas del evento, los registros de Sessionize o Accelevents y los materiales de presentación contemporáneos tienen prioridad sobre los perfiles posteriores.
• Rol actual o autopresentación: Un sitio web personal mantenido recientemente, una cuenta de redes sociales verificada o una página de empleador actual tienen prioridad sobre una biografía de conferencia antigua.
• Foto de perfil canónica: Prefiere la imagen de perfil autoseleccionada y verificada de la persona, una foto oficial del organizador o un retrato oficial del evento vinculado a un ID estable. Una URL pública no otorga derechos de redistribución o entrenamiento de imágenes.
• Búsqueda general: Usa resultados web para descubrir candidatos o corroborar hechos; no trates el ranking de búsqueda como prueba.

Nunca trates una miniatura adivinada, una fotografía de una sesión cercana, la similitud facial o una incrustación biométrica como evidencia de identidad verificada.

Flujo de Trabajo

1. Clasifica la consulta antes de buscar. Detecta si es una entidad única, una lista de entidades o una consulta difusa de grupo/reparto/miembro/equipo/org. Términos como members, cast, lineup, team, company, subsidiaries y leadership generalmente significan que se necesita expansión.

2. Analiza las consultas similares a instrucciones antes de la búsqueda. Los usuarios a menudo envuelven pistas de entidades en texto de tareas como encuentra los perfiles completos para..., adivina la agrupación que incluye... o resuelve estos nombres parciales.... Extrae la región de la pista de entidad, conserva la instrucción original como contexto y no envíes la cadena de instrucción completa como una consulta literal a la base de datos.

3. Expande consultas difusas en grupos de entidades solo cuando la identificación directa o las asignaciones documentadas sean insuficientes. Usa un LLM o herramientas de búsqueda cuando sea genuinamente necesario para enumerar individuos u organizaciones. Mantén los alias agrupados bajo una entidad.

4. Busca ampliamente por grupo de entidades. Para cada entidad, busca múltiples alias, variantes limpiadas, candidatos exactos de slug o ID directo cuando la base de datos de destino lo admita, y consultas de nombre corto contextualizadas como <grupo> <nombre corto>. Usa un seguimiento de consultas local por entidad; la deduplicación global de consultas puede privar a entidades posteriores con alias comunes.

5. Considera un planificador de recuperación LLM cuando la recuperación determinista esté vacía o sea débil. La planificación está separada del reordenamiento: pregunta por IDs directos, slugs de URL, sondas de nombre exacto, alias y búsquedas contextuales. Mantén las sondas acotadas y de alta precisión.

6. Fusiona candidatos por identidad de registro estable. Deduplica por ID de perfil, slug, URL canónica, ID de base de datos u otra clave estable. Conserva cada consulta y fuente que encontró al candidato en lugar de mantener solo la ruta de mayor puntuación.

7. Enriquece a los candidatos antes del reordenamiento. Reúne evidencia conceptual sobre identidad, procedencia, utilidad, ambigüedad y confianza. Nunca se debe pedir al reordenador que elija solo a partir de nombres.

8. Usa el reordenamiento LLM acotado solo para candidatos genuinamente en competencia. Continúa solo cuando otro pase pueda mejorar materialmente la cobertura o distinguir identidades probables.

9. Muestra alternativas significativas cuando podrían cambiar la decisión o permitir la corrección; una coincidencia autorizada de ID exacto no necesita rivales fabricados.

10. Trata lo no resuelto e incierto como resultados de primera clase. Prefiere needs review, no plausible match o ambiguous sobre llenar silenciosamente un falso positivo de alta utilidad.

Nombres Parciales e Instrucciones Difusas

Cuando una consulta contiene principalmente nombres de pila, alias cortos, iniciales o nombres de organización parciales, no trates los resultados directos de la base de datos como suficientes. Expande o clasifica cuando los términos de agrupación, la intención de perfil completo o los nombres de un solo token hagan que los resultados directos no sean confiables.

Mantén dos representaciones de la consulta:

• originalQuery: la instrucción completa del usuario y el contexto.
• entityHints: la lista extraída de nombres de candidatos o alias a resolver.

El modelo de expansión debe ver ambas. Pídele que infiera el contexto compartido probable y devuelva entidades concretas con alias agrupados. Para cada entidad expandida, conserva una etiqueta más alias, luego busca esos alias dentro de esa rama de entidad. La ruta de búsqueda directa aún puede ejecutarse para nombres exactos simples, pero no debe suprimir la expansión cuando la cobertura dependa de inferir identidades completas a partir de pistas parciales.

La cobertura es separada del volumen de resultados. Cinco pistas solicitadas que producen muchos candidatos sin procesar no están resueltas hasta que cada pista se asigna a una entidad seleccionada o a un resultado explícito de no resuelto/ambiguo. Rastrea expectedCount, resolvedCount, ambiguousCount y unresolvedHints o campos equivalentes.

Planificación de Recuperación y Reparación de Brechas

No confíes en un reordenador para rescatar registros que la recuperación nunca devolvió. Divide la participación del LLM en roles separados:

• Modelo de expansión: "¿Quiénes o cuáles son las entidades objetivo?"
• Planificador de recuperación o modelo de reparación: "¿Qué IDs exactos, slugs, URLs directas, alias y sondas de búsqueda debe intentar el recuperador para este objetivo?"
• Modelo de reordenamiento: "Dados estos candidatos enriquecidos, ¿cuál es el registro correcto?"

Usa la planificación de recuperación solo cuando los slugs o IDs directos puedan recuperar un registro faltante, o cuando una entidad no tenga candidatos, datos utilizables o solo coincidencias débiles/nombres comunes. Dale al planificador la consulta original, los alias agrupados, las sondas intentadas, las fallas de la fuente y las restricciones relevantes de la fuente. Debe devolver sondas, no una decisión de identidad.

Mantén la reparación acotada y proporcionada. Ejecuta recuperación determinista en sondas útiles, fusiona los candidatos recuperados y marca una entidad como no resuelta cuando sea poco probable que una búsqueda adicional cambie la respuesta.

Registro y Fan-out

Registra la procedencia de la fuente, los IDs seleccionados, la ambigüedad y la cobertura en proporción a la tarea. Evita cargas útiles privadas sin procesar. Cuando grupos de entidades independientes ya se están procesando de forma concurrente, mantén el estado de la rama aislado y fusiona de forma determinista; no introduzcas fan-out, infraestructura de telemetría o reintentos solo para satisfacer esta skill.

Modelo de Evidencia

Mantén la evidencia conceptual y portátil. No te sobreajustes a los campos de un solo sitio.

• Evidencia de identidad: coincidencia exacta de nombre o ID, alias, nombres artísticos, nombres legales, variantes de romanización, tokens compartidos, tokens primarios faltantes, coincidencia de contexto, relación conocida de organización/grupo y nombres conflictivos.
• Evidencia de procedencia: qué consulta encontró al candidato, si provino de búsqueda, slug exacto, URL directa, ID de base de datos, búsqueda API, resultado web, fuente proporcionada por el usuario, sonda del planificador de recuperación o un pase de recuperación.
• Evidencia de utilidad: cantidad de imágenes, integridad del perfil, actividad, popularidad, vistas, votos, cantidad de listas, cantidad de empleados, cantidad de relaciones, estado verificado, actualidad y si el registro tiene medios o metadatos utilizables para la tarea.
• Evidencia de ambigüedad: nombre corto/común, coincidencia solo de apellido, iniciales, registros duplicados, páginas de grupo/proyecto, páginas "y el", registros escasos, alias conflictivos, nombres antiguos, organizaciones fusionadas, subsidiarias o figuras públicas con nombres similares.
• Evidencia de confianza: candidato seleccionado, candidatos finalistas, razón del reordenador, estado no resuelto, indicador de revisión humana y estado de cobertura para la consulta original.

Reglas de Reordenamiento

Usa el reordenamiento LLM cuando la ambigüedad genuina lo justifique, limitado por la evidencia de la fuente y un presupuesto apropiado para la tarea.

• Dale al reordenador la consulta original, la etiqueta de entidad resuelta, los alias, los nombres/IDs/URLs de los candidatos, la procedencia, la evidencia de identidad, la evidencia de utilidad y las advertencias de ambigüedad.
• Indícale que elija identidad antes que utilidad. No debe elegir un candidato rico en imágenes o popular si la evidencia de identidad es débil.
• Para candidatos plausiblemente de la misma identidad, deja que la utilidad decida. Los registros de nombres artísticos o de marca pública pueden ser mejores que los registros de nombres legales si tienen evidencia más sólida relevante para la tarea.
• Trata los alias de un solo token como ambiguos a menos que estén respaldados por contexto, ID/slug exacto, superposición de alias más rica o evidencia externa sólida.
• Evita reglas de aceptación estrictas. Un acierto de alias directo es una señal, no una prueba.
• Evita reglas de rechazo estrictas. Los registros romanizados, renombrados, escasos o de nombre artístico pueden parecer incompletos pero aún así ser correctos.
• Si un candidato igualmente bien respaldado tiene una utilidad de tarea sustancialmente mejor, exponlo o realiza una comparación adicional justificada en lugar de sobrescribir silenciosamente la evidencia de identidad.
• Registra o muestra la razón del candidato seleccionado y mantén las alternativas visibles.

Modos de Falla

Úsalos como verificaciones de revisión cuando un resolvedor "funciona en su mayoría" pero se siente incorrecto.

• La búsqueda exacta en la base de datos puede perder registros reales. Prueba slugs exactos, URLs directas, IDs o endpoints alternativos cuando estén disponibles.
• Los nombres cortos crean falsos positivos. Lisa, Rose, Sunny, Tiffany, Yuri y nombres similares de un solo token necesitan búsquedas contextuales y advertencias de ambigüedad.
• Los nombres legales pueden ser registros de peor utilidad. Los nombres públicos/artísticos o de marca pueden tener el perfil más completo, más imágenes o metadatos más actualizados.
• Las señales de utilidad son poderosas pero inseguras solas. Los recuentos, votos, vistas y popularidad deben romper empates solo después de la plausibilidad de identidad.
• Los alias compuestos son contexto útil pero a menudo cadenas de búsqueda literales pobres. Divídelos en alias mientras preservas la identidad del grupo.
• La lógica de aceptación directa estricta es frágil. Puede tomar un duplicado genérico solo porque coincidió un alias.
• Las puertas de identidad estrictas son frágiles. Pueden ocultar registros correctos cuando los nombres son escasos, traducidos, romanizados, renombrados o solo de nombre artístico.
• El conteo de cobertura no es corrección. Encontrar 6 de 6 entidades no es éxito si un registro seleccionado es la persona u organización equivocada.
• La deduplicación global de consultas puede privar a entidades posteriores. Los alias comunes deben rastrearse por grupo de entidades.
• La inestabilidad de la fuente es parte del resultado. Los tiempos de espera, 403, 404, reintentos y datos parciales deben mostrarse en los registros de procedencia o depuración.
• Los reordenadores no pueden arreglar candidatos faltantes. Si una rama objetivo tiene cero candidatos, inserta planificación de recuperación o reparación antes del reordenamiento en lugar de esperar que el reordenador infiera un registro oculto.
• El texto de instrucción puede envenenar la búsqueda literal. Elimina las frases de la tarea de la consulta de búsqueda mientras las conservas como contexto para la expansión y el reordenamiento.
• Los resultados directos rápidos pueden suprimir la expansión necesaria. Cuando una consulta solicita explícitamente perfiles completos o desambiguación, no detengas la búsqueda en la primera coincidencia de nombre exacto.

Resumen

La resolución de entidades no es una unión de ID. Es un proceso de investigación que exige una ponderación deliberada de cobertura, identidad y utilidad. La evidencia debe recopilarse antes de que se tomen decisiones; el reordenamiento debe basarse en la evidencia y no al revés. Los estados ambiguos y no resueltos son resultados válidos. Prefiere una revisión explícita a un falso positivo de alta utilidad.