Esta publicación se centra en una técnica particular llamada búsqueda por similitud textual. En este tipo de búsqueda, un usuario introduce una consulta corta en texto libre, y los documentos se clasifican según su similitud con la consulta. La similitud de texto puede ser útil en una variedad de casos de uso:

• Respuestas a preguntas: Dada una colección de preguntas frecuentes, busca preguntas similares a la que introdujo el usuario.

• Búsqueda de artículos: En una colección de artículos de investigación, devuelven artículos con un título estrechamente relacionado con la consulta del usuario.

• Búsqueda de imágenes: En un conjunto de datos de imágenes con subtítulos, encuentra imágenes cuyo pie de foto sea similar a la descripción del usuario.

Un enfoque sencillo para la búsqueda por similitud sería clasificar los documentos según cuántas palabras compartan con la consulta. Pero un documento puede ser similar a la consulta aunque tengan muy pocas palabras en común; una noción más robusta de similitud tendría en cuenta también su contenido sintáctico y semántico .

La comunidad de procesamiento de lenguaje natural (PLN) desarrolló una técnica llamada incrustación de texto que codifica palabras y oraciones como vectores numéricos. Estas representaciones vectoriales están diseñadas para capturar el contenido lingüístico del texto y pueden emplear para evaluar la similitud entre una consulta y un documento.

Esta publicación explora cómo las incrustaciones de texto y el tipo de dense_vector de Elasticsearch podrían usar para apoyar la búsqueda por similitud. Primero daremos una visión general de las técnicas de incrustación y luego pasaremos por un prototipo sencillo de búsqueda por similitud usando Elasticsearch.

¿Qué son las incrustaciones de texto?

Echemos un vistazo más de cerca a los diferentes tipos de incrustaciones de texto y cómo se comparan con los enfoques tradicionales de búsqueda.

Incrustaciones de palabras

Un modelo de incrustación de palabras representa una palabra como un vector numérico denso. Estos vectores buscan capturar las propiedades semánticas de la palabra: palabras cuyos vectores están muy cerca deben ser similares en términos de significado semántico. En una buena incrustación, las direcciones en el espacio vectorial están ligadas a diferentes aspectos del significado de la palabra. Por ejemplo, el vector de "Canadá" podría estar cerca de "Francia" en una dirección y cerca de "Toronto" en otra.

Las comunidades de PLN y búsqueda llevan tiempo interesadas en representaciones vectoriales de palabras. En los últimos años hubo un resurgimiento del interés por las incrustaciones de palabras, cuando muchas tareas tradicionales se revisaban empleando redes neuronales. Se desarrollaron algunos algoritmos exitosos de incrustación de palabras, incluyendo word2vec y GloVe. Estos enfoques emplean grandes colecciones de texto y examinan el contexto en el que aparece cada palabra para determinar su representación vectorial:

• El modelo Skip-gram word2vec capacita una red neuronal para predecir las palabras de contexto alrededor de una palabra en una oración. Los pesos internos de la red dan la palabra embeddings.

• En GloVe, la similitud de las palabras depende de la frecuencia con la que aparecen junto a otras palabras contextuales. El algoritmo capacita un modelo lineal simple sobre los conteos de co-ocurrencia de palabras.

Muchos grupos de investigación distribuyen modelos que fueron preentrenados en grandes corpus de texto como Wikipedia o Common Crawl, lo que los hace cómodos de descargar e integrar en tareas posteriores. Aunque a veces se emplean versiones preentrenadas directamente, puede ser útil ajustar el modelo para ajustarlo al conjunto de datos y tarea objetivo específicos. Esto a menudo se logra ejecutando un paso de 'ajuste fino' sobre el modelo preentrenado.

Las incrustaciones de palabras demostraron ser bastante robustas y efectivas, y ahora es práctica común usar incrustaciones en lugar de tokens individuales en tareas de PLN como la traducción automática y la clasificación de sentimiento.

Incrustaciones de sentencias

Más recientemente, los investigadores empezaron a centrar en técnicas de incrustación que representan no solo palabras, sino también secciones más largas de texto. La mayoría de los enfoques actuales se basan en arquitecturas de redes neuronales complejas y, a veces, incorporan datos etiquetados durante el entrenamiento para ayudar a capturar información semántica.

Una vez capacitados, los modelos pueden tomar una oración y producir un vector para cada palabra en contexto, así como un vector para toda la oración. De forma similar a la incrustación de palabras, existen versiones preentrenadas de muchos modelos, lo que permite a los usuarios saltar el costoso proceso de entrenamiento. Aunque el proceso de entrenamiento puede ser muy intensivo en recursos, invocar el modelo es mucho más ligero — los modelos de incrustación de oraciones suelen ser lo suficientemente rápidos como para usar como parte de aplicaciones en tiempo real.

Algunas técnicas comunes de incrustación de oraciones incluyen InferSent, Universal Sentence Encoder, ELMo y BERT. Mejorar la incrustación de palabras y frases es un área activa de investigación, y es probable que se introduzcan modelos más estables.

Comparación con los enfoques tradicionales de búsqueda

En la recuperación tradicional de información, una forma común de representar el texto como un vector numérico es asignar una dimensión a cada palabra del vocabulario. El vector de un fragmento de texto se basa entonces en el número de veces que aparece cada término en el vocabulario. Esta forma de representar el texto suele denominar "bolsa de palabras", porque simplemente contamos las apariciones de palabras sin tener en cuenta la estructura de las oraciones.

Las incrustaciones de texto difieren de las representaciones vectoriales tradicionales en algunos aspectos importantes:

• Los vectores codificados son densos y relativamente de baja dimensión, a menudo con una dimensión que oscila entre 100 y 1.000 dimensiones. En cambio, los vectores de la bolsa de palabras son escasos y pueden comprender 50.000+ dimensiones. Los algoritmos de incrustación codifican el texto en un espacio de dimensión inferior como parte del modelado de su significado semántico. Idealmente, las palabras y frases sinónimas terminan con una representación similar en el nuevo espacio vectorial.

• Las incrustaciones de oraciones pueden tener en cuenta el orden de las palabras al determinar la representación vectorial. Por ejemplo, la frase "tune in" puede asignar como un vector muy diferente a "in tune".

• En la práctica, las incrustaciones de oraciones a menudo no se generalizan bien a grandes secciones de texto. No se usan comúnmente para representar textos más largos que un párrafo corto.

Uso de incrustaciones para la búsqueda de similitud

Supongamos que tuviéramos una gran colección de preguntas frecuentes. Un usuario puede hacer una pregunta, y queremos recuperar la pregunta más similar de nuestra colección para ayudarlo a encontrar una respuesta.

Podríamos usar incrustaciones de texto para permitir recuperar preguntas similares:

• Durante la indexación, cada pregunta se pasa por un modelo de incrustación de oraciones para producir un vector numérico.

• Cuando un usuario introduce una consulta, esta se ejecuta a través del mismo modelo de incrustación de frases para producir un vector. Para clasificar las respuestas, calculamos la similitud del vector entre cada pregunta y el vector de consulta. Al comparar vectores de incrustación, es común usar similitud coseno.

Este repositorio ofrece un ejemplo sencillo de cómo esto podría lograr en Elasticsearch. El script principal indexa ~20.000 preguntas del conjunto de datos StackOverflow, y luego permite al usuario introducir consultas en texto libre sobre el conjunto de datos.

Pronto repasaremos cada parte del guion en detalle, pero primero veamos algunos resultados de ejemplo. En muchos casos, el método es capaz de captar similitudes incluso cuando no hubo una fuerte superposición de palabras entre la consulta y la pregunta indexada:

• "comprimir archivos" devuelve "Comprimir / Descomprimir carpetas y archivos"

• "determinar si algo es una IP" devuelve "¿Cómo sabes si una cadena es una IP o un nombre de host"

• "translate bytes to doubles" devuelve "Convert Bytes to Floating Points Numbers in Python"

Detalles de implementación

El script comienza descargando y creando el modelo de incrustación en TensorFlow. Elegimos el Codificador Universal de Oraciones de Google, pero es posible usar muchos otros métodos de incrustación. El script emplea el modelo de incrustación tal cual, sin ningún entrenamiento o ajuste fino adicional.

A continuación, creamos el índice Elasticsearch, que incluye mapeos para el título de la pregunta, las etiquetas y también el título de la pregunta codificado como vector:

En el mapeo para dense_vector, debemos especificar el número de dimensiones que contendrán los vectores. Al indexar un campo title_vector, Elasticsearch comprueba que tenga el mismo número de dimensiones especificado en el mapeo.

Para indexar documentos, pasamos el título de la pregunta por el modelo de incrustación para obtener un array numérico. Este array se agrega al documento en el campo title_vector.

Cuando un usuario introduce una consulta, el texto se pasa primero por el mismo modelo de incrustación y se almacena en el parámetro query_vector. A partir de la versión 7.3, Elasticsearch proporciona una función cosineSimilarity en su lenguaje de scripting nativo. Así que para clasificar las preguntas según su similitud con la consulta del usuario, usamos una consulta script_score:

Nos cercioramos de pasar el vector de consulta como parámetro de script para evitar recompilar el script() en cada nueva consulta. Como Elasticsearch no permite puntajes negativos, es necesario agregar una a la similitud coseno.

| Nota: esta entrada de blog originalmente usaba una sintaxis diferente para funciones vectoriales que estaba disponible en Elasticsearch 7.3, pero que fue obsoleta en la 7.6. |

Limitaciones importantes

La consulta script_score está diseñada para envolver una consulta restrictiva y modificar los puntajes de los documentos que devuelve. Sin embargo, proporcionamos una consulta match_all, lo que significa que el script se ejecutará sobre todos los documentos del índice. Esta es una limitación actual de la similitud vectorial en Elasticsearch: los vectores pueden usar para puntuar documentos, pero no en el paso inicial de recuperación. El soporte para la recuperación basado en la similitud vectorial es un área importante de trabajo en curso.

Para evitar escanear todos los documentos y mantener un rendimiento rápido, la consulta de match_all puede ser reemplazada por una consulta más selectiva. La consulta adecuada para la recuperación probablemente dependerá del caso de uso específico.

Aunque vimos algunos ejemplos alentadores arriba, es importante señalar que los resultados también pueden ser ruidosos y poco intuitivos. Por ejemplo, "comprimir archivos" también asigna puntajes altos a "Partial .csproj Archivos" y "Cómo evitar .pyc ¿archivos?". Y cuando el método arroja resultados sorprendentes, no siempre está claro cómo depurar el problema: el significado de cada componente vectorial suele ser opaco y no corresponde a un concepto interpretable. Con las técnicas tradicionales de puntaje basadas en solapamientos de palabras, a menudo es más fácil responder a la pregunta "¿por qué este documento está muy bien clasificado?"

Como se mencionó antes, este prototipo está pensado como un ejemplo de cómo los modelos de incrustación podrían usar con campos vectoriales, y no como una solución lista para producción. Al desarrollar una nueva estrategia de búsqueda, es fundamental probar cómo funciona el enfoque con tus propios datos, cerciorándote de comparar con una línea base estable como una consulta de coincidencia. Puede ser necesario realizar cambios importantes en la estrategia antes de que logre resultados estables, incluyendo afinar el modelo de incrustación para el conjunto de datos objetivo o probar diferentes formas de incorporar incrustaciones como la expansión de consultas a nivel de palabra.

Conclusiones

Las técnicas de incrustación proporcionan una forma poderosa de captar el contenido lingüístico de un texto. Indexando incrustaciones y puntaje basándonos en la distancia vectorial, podemos comparar documentos usando una noción de similitud que va más allá de su solapamiento a nivel de palabra.

Esperamos introducir más funcionalidades basadas en el tipo de campo vectorial. El uso de vectores para la búsqueda es un área matizada y en desarrollo — como siempre, nos encantaría conocer vuestros casos de uso y experiencias en Github y en los foros de discusión.

Fondo

Mientras desarrollamos Elasticsearch, ocasionalmente nos encontramos con un problema importante sin un enfoque sencillo o establecido para solucionarlo. Es natural preguntar: "hmm, ¿existe algún artículo académico que aborde esto?" Otras veces, el trabajo académico es una fuente de inspiración. Nos encontramos con un artículo que propone un nuevo algoritmo o estructura de datos y pensamos "¡esto sería muy útil!" Aquí tienes solo algunos ejemplos de cómo Elasticsearch y Apache Lucene incorporan el trabajo académico:

• HyperLogLog++ para agregaciones de cardinalidad

• Algoritmo C3 para la selección adaptativa de réplicas

• Grafos jerárquicos navegables de mundos pequeños (HNSW) para búsqueda vectorial más cercana en Lucene

• Estadística MIC para mejorar la clasificación del aprendizaje automático

• WAND de bloqueo máximo para una recuperación más rápida de top-hits en Lucene

• ... y muchos más

Los artículos académicos son un recurso invaluable para los ingenieros que desarrollan sistemas intensivos en datos. Pero implementarlas puede ser intimidante y propenso a errores: las descripciones de algoritmos suelen ser complejas, omitiendo detalles prácticos importantes. Y las pruebas son un verdadero desafío: por ejemplo, ¿cómo podemos probar a fondo un algoritmo de aprendizaje automático cuya salida depende estrechamente del conjunto de datos?

Evalúa el trabajo como si fuera una dependencia de software

Agregar una nueva dependencia de software requiere una evaluación cuidadosa: si el otro paquete es incorrecto, lento o inseguro, nuestro proyecto también podría serlo. Antes de incorporar una dependencia, los desarrolladores se cercioran de evaluar su calidad.

Lo mismo ocurre con los trabajos académicos que estás considerando implementar. Puede parecer que, porque un algoritmo se publicó en un artículo, debe ser correcto y funcionar bien. Pero aunque pasó un proceso de revisión, un artículo académico puede tener problemas. Quizá la demostración de corrección se basa en suposiciones que no son realistas. O quizá la sección de "experimentos" muestra un rendimiento mucho mejor que la línea base, pero esto solo se cumple en un conjunto de datos específico. Aunque el trabajo sea de gran calidad, su enfoque puede no encajar bien con tu proyecto.

Al pensar si tomar una "dependencia" de un artículo académico, es útil plantear las mismas preguntas que haríamos con un paquete de software:

• ¿La biblioteca está ampliamente empleada y "probada en batalla"? → ¿Otros paquetes implementaron este artículo y les funcionó bien?

• ¿Están disponibles los benchmarks de rendimiento? ¿Te parecen precisos y justos? → ¿El artículo incluye experimentos realistas? ¿Están bien diseñadas?

• ¿Es suficiente una mejora de rendimiento como para justificar la complejidad? → ¿El artículo se compara con un enfoque de línea base fuerte? ¿Cuánto supera esta línea base?

• ¿Se integrará bien este enfoque con nuestro sistema? → ¿Encajan las suposiciones y compensaciones del algoritmo en nuestro caso de uso?

De alguna manera, cuando un paquete de software publica una comparación de rendimiento con sus competidores, ¡el paquete siempre sale más rápido! Si un tercero diseñó los benchmarks, podrían estar más equilibrados. El mismo fenómeno se aplica a los artículos académicos. Si un algoritmo funciona bien no solo en el artículo original, sino que también aparece en otros como una línea base estable, entonces es muy probable que sea estable.

Sé creativo con las pruebas

Los algoritmos de artículos académicos suelen tener un comportamiento más sofisticado que los tipos de algoritmos que habitualmente nos encontramos. Quizá sea un algoritmo de aproximación que sacrifica la precisión por una mejor velocidad. O quizá sea un método de aprendizaje automático que absorbe un gran conjunto de datos y produce resultados (a veces inesperados). ¿Cómo podemos escribir pruebas para estos algoritmos si no podemos caracterizar su comportamiento de forma sencilla?

Enfoque en invariantes

Al diseñar pruebas unitarias, es común pensar en términos de ejemplos: si damos al algoritmo esta entrada de ejemplo, debería tener esa salida. Desafortunadamente, para la mayoría de los algoritmos matemáticos, las pruebas basadas en ejemplos no cubren suficientemente su comportamiento.

Consideremos el algoritmo C3, que Elasticsearch emplea para determinar qué nodo debe gestionar una solicitud de búsqueda. Clasifica cada nodo usando una fórmula matizada que incorpora el servicio y los tiempos de respuesta previos del nodo, así como el tamaño de su cola. Probar un par de ejemplos realmente no verifica que entendiéramos bien la fórmula. Ayuda dar un paso atrás y pensar en probar invariantes: si aumenta el tiempo de servicio, ¿disminuye el rango del nodo? Si el tamaño de la cola es 0, ¿el rango se determina por el tiempo de respuesta, como afirma el artículo?

Centrar en los invariantes puede ayudar en varios casos comunes:

• ¿Se supone que el método es agnóstico respecto al orden? Si es así, pasar los datos de entrada en un orden diferente debería dar el mismo resultado.

• ¿Algún paso del algoritmo produce probabilidades de clase? Si es así, estas probabilidades deberían sumar 1.

• ¿Es la función simétrica alrededor del origen? Si es así, invertir el signo de la entrada debería simplemente invertir el signo de la salida.

Cuando implementamos C3 por primera vez, tuvimos un error en la fórmula donde accidentalmente usamos el inverso del tiempo de respuesta en lugar del tiempo de respuesta. ¡Esto significaba que los nodos más lentos podían estar más bien clasificados! Al solucionar el problema, nos cercioramos de agregar comprobaciones invariantes para evitar futuros errores.

Comparar con una implementación de referencia

Junto al artículo, los autores esperan publicar una implementación del algoritmo. (Esto es especialmente probable si el artículo contiene experimentos, ya que muchas revistas requieren que los autores envíen el código para reproducir los resultados.) Puedes probar tu enfoque con esta implementación de referencia para cerciorarte de que no te perdiste detalles importantes del algoritmo.

Mientras desarrollábamos la implementación HNSW de Lucene para la búsqueda de vecinos más cercanos, probamos contra una biblioteca de referencia de los autores del artículo. Ejecutamos tanto Lucene como la biblioteca con el mismo conjunto de datos, comparando la precisión de sus resultados y el número de cálculos que realizaron. Cuando estos números coinciden de cerca, sabemos que Lucene implementa fielmente el algoritmo.

Al incorporar un algoritmo en un sistema, a menudo necesitas hacer modificaciones o extensiones, como escalarlo a múltiples núcleos o agregar heurísticas para mejorar el rendimiento. Lo mejor es implementar primero una versión "vanilla", probarla con la referencia y luego hacer cambios incrementales. Así puedes estar seguro de que capturaste todas las piezas clave antes de hacer personalizaciones.

Duelo contra un algoritmo existente

La última sección plantea otra idea para un invariante de prueba: comparar la salida del algoritmo con la salida de un algoritmo más simple y mejor entendido. Como ejemplo, consideremos el algoritmo WAND de bloques máximas en Lucene, que acelera la recuperación de documentos saltar documentos que no pueden aparecer en los resultados principales. Es difícil describir exactamente cómo debería comportar la WAND con bloque máximo en todos los casos, pero sí sabemos que aplicarla no debería cambiar los mejores resultados. Así que nuestras pruebas pueden generar varias consultas de búsqueda aleatoria, luego ejecutarlas tanto con como sin la optimización WAND y comprobar que sus resultados siempre coinciden.

Un aspecto importante de estas pruebas es que generan entradas aleatorias sobre las que realizar la comparación. Esto puede ayudar a resolver casos que no consideraste y a sacar a la luz problemas inesperados. Por ejemplo, la prueba de comparación aleatoria de Lucene para el puntaje BM25F ayudó a detectar errores en casos extremos sutiles. La idea de alimentar a un algoritmo con entradas aleatorias está estrechamente relacionada con el concepto de fuzzing, una técnica común de pruebas en seguridad informática.

Elasticsearch y Lucene emplean frecuentemente este enfoque de prueba. Si ves una prueba que menciona un "duelo" entre dos algoritmos (TestDuelingAnalyzers, testDuelTermsQuery...), entonces sabes que esta estrategia está en acción.

Emplea la terminología del artículo

Cuando otro desarrollador trabaje con tu código, necesitará consultar el documento para seguir sus detalles. El comentario sobre la implementación de HyperLogLog++ de Elasticsearch lo dice bien: "Intentar entender qué hace esta clase sin leer el artículo se considera aventurero." Este comentario sobre el método también da un buen ejemplo. Incluye un enlace al artículo académico y destaca qué modificaciones se hicieron al algoritmo tal y como fue descrito originalmente.

Como los desarrolladores basan su comprensión del código en el papel, es útil usar exactamente la misma terminología. Dado que la notación matemática es concisa, esto puede dar lugar a nombres que normalmente no se considerarían de "buen estilo", pero que son muy claros en el contexto del artículo. Las fórmulas de artículos académicos son una de las pocas ocasiones en las que te encontrarás con nombres de variables crípticos en Elasticsearch, como rS y muBarSInverse.

La forma recomendada por el autor de leer un artículo: con un café grande.

Puedes enviar un email al autor

Al trabajar en un trabajo difícil, puedes pasar horas dándole vueltas a una fórmula, sin saber si estás malinterpretando o si simplemente hay un error tipográfico. Si fuera un proyecto de código abierto, podrías hacer una pregunta en GitHub o StackOverflow. Pero, ¿a dónde puedes acudir para un artículo académico? Los autores parecen ocupados y pueden molestar por tus correos.

Al contrario, a muchos académicos les encanta saber que sus ideas se están poniendo en práctica y están encantados de responder preguntas por email. Si trabajas en un producto que ellos conocen, ¡incluso pueden poner la solicitud en su sitio web!

También hay una tendencia creciente de académicos a debatir artículos en público, empleando muchas de las mismas herramientas del desarrollo de software. Si un artículo incluye un paquete de software adjunto, puede que encuentres respuestas a preguntas comunes en Github. Las comunidades de Stack Exchange como "Theoretical Computer Science" y "Cross Validated" también contienen discusiones detalladas sobre artículos populares. Algunas conferencias empezaron a publicar todas las reseñas de artículos en línea. Estas revisiones contienen conversaciones de ida y vuelta con los autores que pueden aportar ideas útiles sobre el enfoque.

Continuará

Esta publicación se centra en los fundamentos para elegir un trabajo académico y

Implementarlo correctamente, pero no cubre todos los aspectos del despliegue real del algoritmo. Por ejemplo, si el algoritmo es solo un componente en un sistema complejo, ¿cómo cercioramos que los cambios en el componente conduzcan a mejoras de extremo a extremo? ¿Y qué pasa si integrar el algoritmo requiere modificaciones o extensiones sustanciales que el artículo original no cubre? Son temas importantes sobre los que esperamos compartir más en futuras publicaciones.