Resolución de entidades con Elasticsearch y LLMs, parte 2: emparejamiento de entidades con evaluación de LLM y búsqueda semántica

En Parte 1, preparamos nuestra lista de reproducción y extrajimos menciones de entidades. Ahora estamos listos para responder la pregunta difícil: ¿A qué entidad te refieres realmente con una mención? Volvamos al ejemplo del primer blog de esta serie, que establece por qué necesitamos la resolución de entidades: " ¡La actualización de Swift ya está aquí! " Imagina que este titular va acompañado de un poco más de contexto:

1. ¡La nueva actualización de Swift está aquí! Los desarrolladores están ansiosos por probar las nuevas características.
2. ¡La nueva actualización de Swift está aquí! El nuevo álbum se lanzará el próximo mes.

Con este contexto añadido, deberíamos ser capaces de resolver el nombre "Swift" a la entidad correcta.

En la publicación anterior, configuramos nuestra lista de seguimiento y enriquecimos las entidades con contexto adicional. Al ver nuestros ejemplos anteriores, necesitamos tener, al menos, las siguientes dos entidades en la lista: Taylor Swift y Swift Programming Language. También explicamos cómo extraemos las menciones de entidades del texto. Ambos ejemplos extraerían "Swift". Con estos ingredientes en su lugar, la lista de vigilancia enriquecida y las entidades extraídas, finalmente estamos listos para presentar la estrella del espectáculo: la coincidencia de entidades.

Recuerda: Este es un prototipo didáctico diseñado para enseñar conceptos de emparejar entidades. Los sistemas de producción pueden usar diferentes modelos de lenguaje grandes (LLM), reglas de coincidencia personalizadas, pipelines de evaluación especializados o enfoques conjuntos que combinan varias estrategias de coincidencia.

El problema: Por qué la coincidencia es difícil

El lenguaje humano es algo extraordinario. Una de sus propiedades más interesantes es su creatividad infinita. Podemos generar y entender un número infinito de frases nuevas. ¿Es de extrañar, entonces, que las coincidencias exactas en la resolución de entidades sean raras? Los autores se esfuerzan por ser creativos cuando pueden. Sería bastante tedioso si tuviéramos que escribir y leer nombres completos cada vez que se menciona una entidad. Entonces, si bien las coincidencias exactas son fáciles, la realidad es que necesitamos un enfoque más sofisticado para la resolución de entidades: uno que sea lo suficientemente robusto para manejar al menos parte de la creatividad ilimitada de los autores humanos. Por eso dividimos el problema en dos pasos: usar Elasticsearch para recuperar candidatos plausibles a escala, y luego usar un LLM para evaluar si esos candidatos realmente se refieren a la misma entidad del mundo real.

La solución: Emparejamiento en tres pasos con evaluaciones transparentes de LLM

Estamos en medio de un cambio de paradigma en la forma en que usamos las computadoras. Así como el auge de internet nos llevó de la computación localizada a una red globalmente conectada, la IA generativa (GenAI) está cambiando fundamentalmente la forma en que se crean el contenido, el código y la información. De hecho, el prototipo educativo que acompaña a esta serie fue casi exclusivamente "codificado con onda" usando un LLM con indicaciones cuidadosas del autor. Esto no quiere decir que los LLM tengan o incluso alcancen el tipo de productividad inherente al lenguaje humano, pero sí significa que ahora tenemos un recurso poderoso para ayudar con la resolución de entidades.

Un patrón común que usamos con GenAI es Retrieval-Augmented Generation (RAG). Aquí, recuperación significa recuperar candidatos de entidades (no generar respuestas), y el LLM se utiliza estrictamente para la evaluación y explicación de coincidencias. Si bien podríamos pedirle a un LLM que nos ayude con la resolución de entidades de extremo a extremo, ese es un enfoque costoso, tanto en términos de tiempo como de dinero. La RAG ayuda a los LLM a hacer su trabajo mediante el uso de formas más eficientes de proporcionar contexto al LLM, lo que permite que el LLM ayude de manera eficiente con la resolución de la entidad.

Para la parte de recuperación de RAG, volvemos a Elasticsearch. Primero encontramos posibles coincidencias usando una combinación de coincidencia exacta, coincidencia con alias y búsqueda híbrida, que combina búsqueda por palabras clave y búsqueda semántica. Una vez que encontramos estas posibles coincidencias, las enviamos a un LLM para su evaluación. El LLM actúa como el evaluador final de coincidencias. También hacemos que el LLM explique su razonamiento, un diferenciador importante con otros sistemas de resolución de entidades. Sin estas explicaciones, la resolución de entidades es una caja negra; con ellas, podemos ver por nosotros mismos por qué una coincidencia tiene sentido.

Conceptos clave: Coincidencia de tres pasos, búsqueda híbrida y evaluación transparente del LLM

¿Qué es la coincidencia de tres pasos? Al inicio de este proyecto, planteamos la hipótesis de que la búsqueda semántica sería una parte crucial del sistema, pero no todas las coincidencias requieren una búsqueda tan sofisticada. Para encontrar coincidencias de manera eficiente, adoptamos un enfoque progresivo para solucionar el problema. Primero, buscamos coincidencias exactas mediante la búsqueda por palabra clave. Si encontramos dicha coincidencia, nuestro trabajo está terminado y podemos seguir adelante. Si falla la coincidencia exacta, recurrimos a la coincidencia de alias. En el prototipo, la coincidencia de alias también se efectúa usando la coincidencia exacta con palabras clave, para simplificar. En producción, puedes ampliar este paso con normalización, reglas de transliteración, coincidencia difusa o tablas de alias seleccionadas. Si aún no hemos encontrado una posible coincidencia en los dos primeros pasos, entonces es hora de incorporar la búsqueda semántica a través de la búsqueda híbrida de Elasticsearch con fusión de rango recíproco (RRF, por sus siglas en inglés).

¿Qué es la búsqueda híbrida? En Elasticsearch, puedes utilizar la búsqueda semántica para encontrar coincidencias significativas que tengan en cuenta el contexto. Elasticsearch se emplea ampliamente para la búsqueda vectorial y la recuperación híbrida. La similitud semántica es muy útil para el significado, pero no sustituye al filtrado estructurado (por ejemplo, por rangos de tiempo, ubicaciones o identificadores), y a menudo es innecesaria cuando se dispone de una coincidencia exacta. Elasticsearch hizo su marca con la búsqueda léxica, que es excelente en tareas donde la búsqueda semántica no encaja. Para aprovechar al máximo ambos enfoques, utilizamos la búsqueda léxica junto con la búsqueda semántica en una única consulta híbrida. Luego combinamos los resultados para encontrar las coincidencias más probables usando RRF. En el prototipo, los dos primeros resultados se convierten en posibles coincidencias que pueden enviarse para la evaluación del LLM.

¿Por qué una evaluación del LLM? Las evaluaciones y explicaciones del LLM permiten que nuestro sistema maneje la ambigüedad y el contexto de manera transparente. Esto es vital para casos como "el presidente", que podría referirse a múltiples entidades, dependiendo del contexto, pero también hace que cosas como los apodos y las variaciones culturales funcionen bien en el sistema. Por último, cuando consideramos tareas de misión crítica, como identificar entidades de listas de sanciones, necesitamos saber por qué se aceptó una coincidencia para poder confiar en el sistema. Fundamentalmente, el LLM no busca en todo el corpus; evalúa solo el pequeño conjunto de candidatos devuelto por Elasticsearch.

Resultados del mundo real: Coincidencia con el razonamiento del LLM

Un gran desafío para cualquier tarea de procesamiento de lenguaje natural es la creación de un documento de referencia, una "clave de respuestas" que nos dice cuáles son los resultados previstos. Sin esto, es casi imposible evaluar el rendimiento de un sistema en una tarea, pero crear un documento de este tipo puede ser un proceso laborioso. Para el prototipo de resolución de entidades, volvimos a recurrir a la GenAI para ayudar a configurar datos contra los que pudiéramos probar.

Primero definimos varios tipos de desafíos, como apodos y transliteraciones, y luego pedimos al LLM que creara una colección escalonada de sets de datos que se hiciera progresivamente más grande y desafiante para el sistema. La creación de los sets de datos fue menos sencilla de lo que cabría esperar. El LLM tenía una fuerte tendencia a "hacer trampa" al hacer demasiado fácil obtener la respuesta correcta. Por ejemplo, uno de los tipos de desafíos se centró en el contexto semántico. Este tipo incluyó cosas como resolver "autor ruso" a "León Tolstói". El LLM colocó incorrectamente "autor ruso", como alias de "León Tolstói", lo que eliminó la necesidad de hacer una búsqueda híbrida para encontrar la coincidencia.

Después de varias refactorizaciones para solucionar problemas como este, teníamos cinco niveles de sets de datos con los que trabajar. Los niveles 1 a 4 eran progresivamente más amplios y presentaban más tipos de desafíos. El Nivel 5 fue el "desafío definitivo" de sets de datos, compuesto por los ejemplos más complicados de todos los tipos de desafíos. Todos los datos de las pruebas están disponibles en el directorio de evaluación exhaustiva.

Para evaluar nuestro enfoque de resolución de entidades basado en indicaciones, centramos nuestra atención en los sets de datos de nivel 4. Una nota importante es que la evaluación se hizo como un experimento controlado para que pudiéramos concentrarnos en la calidad de la coincidencia de entidades. Los datos de la lista de vigilancia se enriquecieron previamente con contexto y las entidades se extrajeron del artículo antes de tiempo. Así se garantizó que la evaluación se centrara en la coincidencia y no en la precisión de la extracción. Esto aísla la calidad de la coincidencia; el rendimiento de extremo a extremo dependería adicionalmente de la recuperación de la extracción y la calidad del enriquecimiento.

Sets de datos de evaluación

El set de datos de evaluación de nivel 4 proporciona una prueba integral de las capacidades del sistema:[1]

• Entidades de la lista de vigilancia: 66 entidades de diversos tipos (personas, organizaciones, ubicaciones).
• Artículos de prueba: 69 artículos que abarcan casos de resolución de entidades del mundo real.
• Coincidencias esperadas: 206 coincidencias de entidades esperadas en todos los artículos.
• Tipos de desafíos: 15 tipos diferentes de desafíos que evalúan varios aspectos de la resolución de entidades.

Los tipos de desafíos incluidos en los sets de datos son:

• Apodos: "Bob Smith" → "Robert Smith" (siete artículos).
• Títulos y honoríficos: "Dr. Sarah Williams" → "Sarah Williams" (cinco artículos).
• Contexto semántico: "Autor ruso" → "León Tolstói" (ocho artículos).
• Nombres multilingües: Manejo de nombres en diferentes escrituras (seis artículos).
• Entidades comerciales: Variaciones del nombre corporativo (siete artículos).
• Referencias ejecutivas: "CEO de Microsoft" → "Satya Nadella" (cinco artículos).
• Líderes políticos: Referencias basadas en títulos (cinco artículos).
• Iniciales: "J. Smith " → "John Smith" (tres artículos).
• Variaciones en el orden de los nombres: Diferentes convenciones de ordenamiento de nombres (tres artículos).
• Nombres truncados: Coincidencias parciales de nombres (tres artículos).
• División de nombres: Nombres divididos en el texto (tres artículos).
• Espacios/guiones faltantes: Variaciones de formato (dos artículos).
• Transliteración: Coincidencia de nombres entre sistemas de escritura (dos artículos).
• Desafíos combinados: Varios desafíos en un artículo (seis artículos).
• Negocios complejos: Relaciones comerciales jerárquicas (cinco artículos).

Veamos cómo se desempeñó la resolución de entidades basada en indicaciones.

Rendimiento general

Los resultados muestran que la evaluación de coincidencias basada en LLM es muy prometedora, pero también revelan un importante problema de confiabilidad. Debido a que cada par de candidatos debe ser evaluado por el LLM, las fallas en la salida estructurada pueden suprimir la aceptación y la recuperación incluso cuando la recuperación está funcionando bien.

El problema de la tasa de error

Recuerda que el primer paso que damos en el prototipo es crear posibles pares de coincidencia usando Elasticsearch. Cada una de estas posibles coincidencias necesita ser evaluada por el LLM. Para procesar eficientemente todas esas coincidencias, agrupamos las llamadas a los LLM en batches. Esto reduce los costos y la latencia de la API, pero también aumenta el riesgo de obtener JSON malformado en la salida. A medida que aumenta el tamaño del batch, el JSON se vuelve más largo y complejo, lo que aumenta la probabilidad de que el LLM genere un JSON no válido. De aquí proviene la tasa de error del 30 %. En la evaluación, usamos un tamaño de batch de cinco coincidencias por solicitud. Incluso con este tamaño de batch conservador, seguimos viendo fallos en el análisis de JSON, lo que distorsiona significativamente los resultados de la evaluación.

Lo que sigue: Optimización de la integración del LLM

Ahora que hemos emparejado entidades usando la búsqueda semántica y la evaluación a cargo del LLM, tenemos un pipeline completo de resolución de entidades. Sin embargo, este enfoque introduce un nuevo modo de fallo cuando la evaluación del modelo es correcta, pero su salida no es utilizable. Podemos optimizar la integración de los LLM para mejorar la fiabilidad y la eficiencia de costos. En la próxima publicación, analizaremos cómo usar la llamada de funciones para una salida estructurada, que proporciona una estructura y seguridad de tipo garantizadas a la vez que reduce errores y costos.

Pruébalo tú mismo

¿Quieres ver la coincidencia de entidades en acción? Mira el cuaderno de Entity Matching para obtener una guía completa con implementaciones reales, explicaciones detalladas y ejemplos prácticos. El cuaderno te muestra exactamente cómo hacer coincidir entidades empleando la búsqueda de tres pasos, la búsqueda híbrida con RRF y la evaluación impulsada por LLM con razonamiento.

Recuerda: Este es un prototipo didáctico diseñado para enseñar los conceptos. Al construir sistemas de producción, considera factores adicionales, como la selección del modelo, la optimización de costos, los requisitos de latencia, la validación de calidad, el manejo de errores y la monitorización, que no están cubiertos en este prototipo orientado al aprendizaje.

Notas

1. Estos sets de datos son sintéticos y están diseñados con fines didácticos; se aproximan a desafíos reales pero no son representativos de ningún dominio de producción específico.