Resolución de entidades con Elasticsearch, parte 4: el desafío final

Ya hemos visto cómo se implementa la resolución inteligente de entidades de dos maneras. Ambos enfoques comienzan de la misma forma: preparación y extracción de entidades, seguidas de la recuperación de candidatos con Elasticsearch. A partir de ahí, evaluamos a esos candidatos usando un modelo de lenguaje grande (LLM), ya sea mediante generación de JSON basada en prompts o mediante llamadas de funciones, y exigimos que el modelo ofrezca una explicación transparente de su juicio.

Como vimos en la entrada anterior, la consistencia que aportan las llamadas a funciones no es solo una optimización interesante; es esencial. Una vez que eliminamos los errores estructurales del ciclo de evaluación, los resultados en escenarios estándar (como los de los sets de datos de nivel 4) mejoraron significativamente.

Sin embargo, queda una pregunta obvia por responder:

¿Funciona de igual manera este enfoque cuando todo se complica realmente?

La resolución de entidades del mundo real rara vez falla debido a casos simples. Falla cuando los nombres atraviesan idiomas, culturas, sistemas de escritura, períodos de tiempo y límites organizacionales. Falla cuando las personas se mencionan por sus cargos en lugar de por sus nombres, cuando las empresas cambian de nombre, cuando las transliteraciones no son consistentes y cuando el contexto (no la ortografía) es lo único que vincula una mención a una entidad del mundo real.

Así que, para la publicación final de esta serie, sometimos el sistema a lo que llamamos el desafío definitivo.

¿Qué hace que esto sea el desafío definitivo?

En evaluaciones anteriores, probamos el sistema con sets de datos cada vez más complejos. Para cuando llegamos al nivel 4, analizado en la publicación anterior, ya estábamos lidiando con una mezcla de apodos, cargos, nombres multilingües y referencias semánticas. Esas pruebas demostraron que la arquitectura en sí era estable, pero que los problemas de confiabilidad, especialmente el JSON mal formado, estaban reduciendo la capacidad de recuperación.

Con la llamada a funciones implementada, finalmente conseguimos una base estable. Eso nos dio la oportunidad de hacer una pregunta más interesante:

¿Puede una única pipeline unificada gestionar muchos tipos diferentes de problemas de resolución de entidades al mismo tiempo?

El set de datos del desafío final se diseñó precisamente para poner a prueba esa dimensión.

En lugar de centrarse en una sola dificultad (como apodos o transliteración), este sets de datos combina más de 50 tipos distintos de desafíos, incluyendo:

• Convenciones de nomenclatura cultural.
• Referencias basadas en cargos.
• Relaciones comerciales y cambios históricos de nombre.
• Menciones multilingües y entre sistemas de escritura.
• Desafíos compuestos que mezclan varios de los anteriores.

Lo importante es que no se trata de optimizar para un solo caso de uso concreto. Se trata de probar si el patrón de diseño se mantiene cuando las reglas cambian de entidad a entidad.

Resumen del set de datos

El set de datos del desafío final consta de:

• 50 entidades, que abarcan personas, organizaciones e instituciones.
• ~60 artículos, con estructuras y complejidad lingüísticas variables.
• 51 categorías distintas de desafíos, agrupadas en términos generales en:
  • Convenciones de nomenclatura cultural.
  • Títulos y contexto profesional.
  • Relaciones empresariales y organizacionales.
  • Desafíos multilingües y de transliteración.
  • Escenarios combinados y de casos límite.

Al principio de la serie, vimos que usar IA generativa (GenAI) para crear sets de datos puede tener pros y contras. Sin eso, sería muy difícil reunir datos de prueba lo suficientemente amplios y variados. Pero si no se controla, el modelo tiende a facilitar demasiado todo.

En una fase inicial de generación, por ejemplo, descubrimos que el modelo había incluido frases como «el presidente ruso» como alias explícitos para Vladimir Putin. Eso podría parecer razonable hoy en día, pero anula el propósito de probar la resolución contextual. ¿Qué pasa si el artículo habla de Rusia en la década de 1990? El sistema debería deducir la entidad correcta a partir del contexto, en lugar de basarse en un alias predefinido.

Por esa razón, este set de datos fue diseñado deliberadamente para que los atajos no funcionen. Los alias no se enumeran explícitamente cuando se espera que el sistema deduzca su significado. Las frases descriptivas no están previnculadas a entidades. Las coincidencias correctas suelen depender del contexto del artículo, no solo del texto local.

Nota importante: Aunque demostramos las capacidades del sistema en diversos escenarios, este sigue siendo un prototipo educativo. Los sistemas de producción que manejan el monitoreo de entidades sancionadas en el mundo real requerirían validación adicional, verificaciones de cumplimiento, pistas de auditoría y manejo especializado para casos de uso confidenciales.

¿Por qué estos escenarios son difíciles?

¡En la primera publicación de esta serie, presentamos un ejemplo simple pero ambiguo: “¡La nueva actualización de Swift está aquí!”! El desafío es que “Swift” puede resolverse en múltiples entidades del mundo real, dependiendo del contexto. Ese ejemplo refleja una verdad más amplia: el lenguaje natural es inherentemente ambiguo.

La resolución de entidades, por lo tanto, no es solo un problema de coincidencia de texto. Los humanos solemos basarnos en el conocimiento compartido, las normas culturales y el contexto de cada situación para interpretar las referencias, y casi nunca nos damos cuenta de que lo estamos haciendo.

Considera algunos casos comunes:

• Un título como “el presidente” no tiene sentido sin contexto geopolítico y temporal.
• El nombre de una empresa puede referirse a la empresa matriz, a una filial o a una marca anterior, dependiendo de cuándo se escribió el artículo.
• El nombre de una persona puede aparecer en diferentes órdenes, sistemas de escritura o transcripciones, dependiendo del idioma y la cultura.
• La misma frase puede referirse legítimamente a diferentes entidades en diferentes contextos, y el sistema debe ser capaz de rechazar coincidencias con la misma confianza con la que las acepta.

No existe un único conjunto de reglas que maneje todo esto de manera clara. Por eso este prototipo separa las responsabilidades de forma tan marcada:

• Elasticsearch reduce el espacio de candidatos de manera eficiente y transparente.
• El LLM se usa solo donde se requiere juicio y está obligado a explicarse a sí mismo.
• La recuperación y el razonamiento siguen siendo pasos distintos.

Esta distinción cobra aún más importancia a medida que aumenta la variedad de tipos de desafíos.

Cómo el sistema gestiona la diversidad sin casos especiales

Uno de los resultados más interesantes de esta evaluación es lo que no cambió:

• No agregamos lógica especial para nombres japoneses.
• No agregamos reglas personalizadas para patronímicos árabes.
• No agregamos mapeos codificados para nombres históricos de compañías.

En cambio, el sistema se basó en los mismos elementos principales presentados anteriormente en la serie:

• Entidades enriquecidas con contexto indexadas para búsqueda semántica.
• Recuperación híbrida (exacta, alias y semántica) en Elasticsearch.
• Un conjunto pequeño y bien definido de posibles coincidencias.
• El juicio del LLM está limitado por las llamadas a funciones y los esquemas mínimos.

Esto sugiere que la flexibilidad del sistema proviene de la representación y arquitectura, no de una colección cada vez mayor de reglas.

Cuando el sistema tiene éxito, es porque se recuperan los candidatos adecuados y el LLM tiene suficiente contexto para explicar por qué una referencia mapea (o no) a una entidad específica.

Resultados: ¿cómo funcionó?

En los sets de datos del desafío final, el sistema obtuvo los siguientes resultados generales:

• Precisión: ~91 %
• Recuperación: ~86 %
• Puntuación F1: ~89 %
• Tasa de aceptación en LLM: ~72 %

Rendimiento en los tipos de desafíos

El desglose de resultados por tipo de desafío revela fortalezas y limitaciones:

El mejor desempeño (100 % de puntuación F1) se observó en áreas como:

• Coincidencia entre diferentes sistemas de escritura (entidades comerciales en cirílico, coreano y chino).
• Escenarios hebreos (patronímicos, títulos profesionales, títulos religiosos, transliteración).
• Jerarquías empresariales (aeroespacial, producción diversificada, corporaciones multidivisionales).
• Títulos profesionales (académicos, militares, políticos, religiosos).
• Escenarios japoneses combinados que involucran múltiples sistemas de escritura.

Fuerte rendimiento (80-99 % de puntuación F1) incluido:

• Figuras políticas internacionales (98%).
• Cambios de nombre históricos (90 %).
• Jerarquías empresariales complejas (89 %).
• Nombres de empresas japonesas (93 %).
• Transliteración entre alfabetos (86 %).
• Patronímicos árabes (86 %).

Las áreas más desafiantes fueron:

• Transliteración avanzada (chino, coreano): 0 % F1.
• Ciertos escenarios japoneses (honoríficos, orden de los nombres, variación del sistema de escritura): ~67 % F1.
• Algunos escenarios árabes (nombres de empresas, referencias institucionales): ~40% F1.

Lo importante aquí es por qué el sistema tuvo dificultades en estos casos. Las fallas no se debieron a la ruptura del enfoque general, sino a limitaciones en componentes específicos, sobre todo el modelo vectorial denso utilizado para la búsqueda semántica en ciertos escenarios multilingües.

Como la recuperación y la evaluación están claramente separadas, para mejorar el rendimiento no hace falta reescribir el sistema. Si se sustituyera por un modelo de incrustación multilingüe más potente, se enriquecería el contexto de las entidades o se perfeccionarían las estrategias de recuperación, se mejorarían los resultados en todas estas categorías sin cambiar la arquitectura central.

Desde el punto de vista arquitectónico, esa es la verdadera medida del éxito.

Qué nos dice esto sobre el diseño

Si vemos nuevamente las series, se observan algunas tendencias:

• La preparación importa más que la coincidencia inteligente. El enriquecimiento de entidades con contexto de antemano reduce drásticamente la ambigüedad posteriormente.
• Los LLM son más valiosos como jueces, no como recuperadores. Pedirles que expliquen por qué una coincidencia tiene sentido es mucho más poderoso que pedirles que realicen una búsqueda.
• La fiabilidad permite la precisión. La llamada a funciones no solo limpió el JSON; desbloqueó la memoria que ya estaba latente en el paso de recuperación.
• La generalización supera a la especialización. Un pequeño número de abstracciones bien seleccionadas manejó decenas de tipos de desafío sin lógica personalizada.

Esta es la razón por la que el prototipo es intencionalmente nativo de Elasticsearch y es intencionalmente conservador en cómo utiliza los LLM. El objetivo no es reemplazar la búsqueda; es hacer que la búsqueda sea explicable en situaciones donde el significado importa.

Reflexiones finales

El desafío final no se trataba de perseguir métricas perfectas; se trataba de responder una pregunta más fundamental:

¿Puede una arquitectura transparente, centrada en la búsqueda y asistida por LLM, manejar la ambigüedad de entidades en el mundo real sin colapsar en reglas o cajas negras?

Para este prototipo educativo, la respuesta es sí, con claras advertencias sobre el fortalecimiento de la producción, el cumplimiento, el monitoreo y la calidad de los datos. Si estás creando sistemas que necesitan justificar por qué se hizo una coincidencia de entidades, este patrón merece ser considerado seriamente. Espero que esta serie haya demostrado que la resolución de entidades no tiene que ser misteriosa. Con una correcta separación de responsabilidades, se convierte en algo sobre lo que puedes razonar, medir y mejorar.

Este trabajo también sugiere un patrón arquitectónico más amplio. Lo que surge es una ligera pero importante evolución de la clásica Retrieval-Augmented Generation (RAG). En lugar de permitir que la recuperación alimente directamente la generación, introducimos un paso de evaluación explícito. El LLM se usa primero para juzgar y verificar el estado de los candidatos recuperados, y solo los resultados aprobados pueden incrementar la generación. Se puede pensar en esto como Generation-Augmented Retrieval-Augmented Generation with Evaluation, o GARAGE, porque a quién no le gusta un buen acrónimo.

¿Qué otros casos de uso podrían beneficiarse de este patrón? Los sistemas que requieren confianza, transparencia y razonamiento justificable son candidatos naturales. Los trabajos futuros en este ámbito deberían ser tan convincentes como los resultados que hemos visto aquí, y tengo muchas ganas de ver hacia dónde lo lleva la comunidad.

Próximos pasos: Pruébalo tú mismo

¿Quieres ver el desafío final en acción? Mira el cuaderno de desafío final para obtener una guía completa con implementaciones reales, explicaciones detalladas y ejemplos prácticos.

El pipeline completo de resolución de entidades demuestra los conceptos del núcleo y la arquitectura necesarios para uso en producción. Se puede usar como base para construir sistemas que monitoreen los artículos de noticias, rastreen las menciones de entidades y respondan preguntas sobre qué entidades aparecen en qué artículos, al tiempo que se mantiene la transparencia y la explicabilidad.