• Habla con los LLMs implementando un ChatLanguageModel y un ChatMemory

• Conserva el historial de chats en memoria para recordar el contexto de una conversación previa con un LLM

Esta entrada del blog trata sobre cómo:

• Crear incrustaciones vectoriales a partir de ejemplos de texto

• Almacenar incrustaciones vectoriales en el almacenamiento de incrustaciones de Elasticsearch

• Búsqueda de vectores similares

Crear incrustaciones

Para crear embeddings, necesitamos definir un EmbeddingModel a emplear. Por ejemplo, podemos usar el mismo modelo de mistral que usamos en la publicación anterior. Estaba corriendo con ollama:

Un modelo es capaz de generar vectores a partir de texto. Aquí podemos comprobar el número de dimensiones generadas por el modelo:

Para generar vectores a partir de un texto, podemos usar:

O si también queremos proporcionar metadatos para filtrar cosas como texto, precio, fecha de lanzamiento o lo que sea, podemos usar Metadata.from(). Por ejemplo, aquí agregamos el nombre del juego como campo de metadatos:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step5EmbedddingsTest.java .

Agregar Elasticsearch para almacenar nuestros vectores

LangChain4j proporciona un almacén de incrustación en memoria. Esto es útil para realizar pruebas sencillas:

Pero obviamente, esto no podría funcionar con un conjunto de datos mucho mayor porque este almacén almacena todo en memoria y no tenemos memoria infinita en nuestros servidores. Así que, en su lugar, podríamos almacenar nuestras incrustaciones en Elasticsearch, que por definición es "elástico" y puede escalar hacia arriba y hacia fuera con tus datos. Para ello, agregamos Elasticsearch a nuestro proyecto:

Como notasteis, también agregamos el módulo Elasticsearch TestContainers al proyecto, para poder iniciar una instancia de Elasticsearch a partir de nuestras pruebas:

Para usar Elasticsearch como almacén de embebed, "solo" tienes que cambiar del almacén de datos en memoria de LangChain4j al de Elasticsearch:

Esto almacenará tus vectores en Elasticsearch en un índice default . También puedes cambiar el nombre del índice por algo más significativo:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step6ElasticsearchEmbedddingsTest.java .

Búsqueda de vectores similares

Para buscar vectores similares, primero necesitamos transformar nuestra pregunta en una representación vectorial usando el mismo modelo que usamos anteriormente. Ya lo hicimos, así que no es difícil hacerlo de nuevo. Ten en cuenta que en este caso no necesitamos los metadatos:

Podemos construir una solicitud de búsqueda con esta representación de nuestra pregunta y pedir al almacén de incrustaciones que encuentre los primeros vectores principales:

Podemos iterar sobre los resultados ahora e imprimir algo de información, como el nombre del juego que proviene de los metadatos y el puntaje:

Como era de esperar, esto nos da "Out Run" como primer éxito:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step7SearchForVectorsTest.java .

Tras bambalinas

La configuración predeterminada para la tienda de incrustación de Elasticsearch emplea la consulta aproximada kNN detrás de escena.

Pero esto podría cambiar proporcionando otra configuración (ElasticsearchConfigurationScript) distinta a la predeterminada (ElasticsearchConfigurationKnn) en la tienda de incrustación:

La implementación ElasticsearchConfigurationScript ejecuta entre bastidores una consulta script_score usando una función cosineSimilarity.

Básicamente, al llamar:

Esto ahora llama:

En ese caso, el resultado no cambia en términos de "orden", sino que solo se ajusta el puntaje porque la llamada cosineSimilarity no emplea ninguna aproximación, sino que calcula el coseno para cada uno de los vectores emparejados:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step7SearchForVectorsTest.java .

Conclusión

Explicamos lo fácil que es generar incrustaciones a partir de tu texto y cómo puedes almacenar y buscar los vecinos más cercanos en Elasticsearch usando dos enfoques diferentes:

• Usando la consulta de knn aproximada y rápida con la opción de ElasticsearchConfigurationKnn por defecto

• Usando la consulta de script_score exacta pero más lenta con la opción ElasticsearchConfigurationScript

El siguiente paso será construir una aplicación completa de RAG, basada en lo que aprendimos aquí.

Buenas pruebas para la confianza del sistema

Una buena prueba es una prueba que aumenta la confianza de cada persona involucrada en el proceso de creación y mantenimiento de un sistema informático. Las pruebas no están pensadas para ser rápidas, geniales ni para aumentar artificialmente la cobertura del código. Las pruebas desempeñan un papel vital para garantizar que:

• Lo que queremos entregar va a funcionar en producción.

• El sistema cumple con los requisitos y los contratos.

• No habrá regresiones en el futuro.

• Los desarrolladores (y otros miembros del equipo implicados) están seguros de que lo que crearon funcionará.

Por supuesto, esto no significa que las pruebas no puedan ser frías, rápidas o aumentar la cobertura del código. Cuanto más rápido podamos ejecutar nuestra suite de pruebas, mejor. Simplemente, en la búsqueda de reducir la duración total de la suite de pruebas, no deberíamos sacrificar la fiabilidad, la mantenibilidad y la confianza que nos brindan las pruebas automatizadas.

Unas buenas pruebas automatizadas hacen que los distintos miembros del equipo se sientan más seguros:

• Desarrolladores: pueden confirmar que lo que hacen funciona (incluso antes de que el código en el que trabajan salga de su máquina).

• Equipo de control de calidad: tienen menos que probar manualmente.

• Los operadores de sistemas y los SRES: son más relajados, porque los sistemas son más fáciles de desplegar y mantener.

Por último, pero no menos importante: la arquitectura de un sistema. Nos encanta cuando los sistemas están organizados, son fáciles de mantener y la arquitectura es limpia y cumple su propósito. Sin embargo, a veces podemos ver una arquitectura que sacrifica demasiado por la excusa conocida como "así es más comprobable". No hay nada de malo en ser muy comprobable: solo cuando el sistema está escrito principalmente para ser comprobable en lugar de servir a las necesidades que justifican su existencia, vemos una situación en la que la cola mueve al perro.

Dos tipos de pruebas: Mocks y dependencias

Hay muchas formas en que las pruebas pueden ver y, por tanto, clasificar. En esta publicación me centraré solo en un aspecto de dividir los exámenes: usar mocks (o stubs, o fakes, o ...) frente a usar dependencias reales. En nuestro caso, la dependencia es Elasticsearch.

Los exámenes con mocks son muy rápidos porque no necesitan iniciar dependencias externas y todo ocurre solo en memoria. El mocking en pruebas automatizadas ocurre cuando se emplean objetos falsos en lugar de reales para probar partes de un programa sin usar las dependencias reales. Por eso son necesarias y por las que destacan en cualquier prueba de detección rápida en red, por ejemplo. Validación de la entrada. No es necesario abrir una base de datos y hacer una llamada solo para verificar que no se permiten números negativos en una solicitud, por ejemplo.

Sin embargo, introducir simulacros tiene varias participaciones:

• No todo y cada vez se puede burlar fácilmente, por eso los mocks tienen impacto en la arquitectura del sistema (que a veces es genial, a veces no tanto).

• Las pruebas que se ejecutan en mocks pueden ser rápidas, pero desarrollar tales pruebas puede llevar bastante tiempo porque las mocks que reflejan profundamente los sistemas que imitan normalmente no se ofrecen gratis. Alguien que sepa cómo funciona el sistema necesita escribir los mocks de la manera correcta, y este conocimiento puede venir de la experiencia práctica, el estudio de documentación, etc.

• Los simulacros deben mantener. Cuando tu sistema depende de una dependencia externa y necesitas actualizar esa dependencia, alguien tiene que cerciorar de que los mocks que imitan la dependencia también se actualicen con todos los cambios: fallos, documentados y no documentados (lo que también puede afectar a nuestro sistema). Esto resulta especialmente doloroso cuando quieres actualizar una dependencia pero tu suite de pruebas (usando solo simulaciones) no puede darte confianza en que todos los casos probados estén garantizados para funcionar.

• Se necesita disciplina para cerciorar que el esfuerzo se destine a desarrollar y probar el sistema, no a los simulacros.

Por estas razones, mucha gente defiende ir exactamente en la dirección opuesta: nunca usar mocks (o stubs, etc.), sino confiar únicamente en dependencias reales. Este enfoque funciona muy bien en demos o cuando el sistema es pequeño y solo tiene unos pocos casos de prueba que generan una gran cobertura. Estas pruebas pueden ser pruebas de integración (hablando a grandes rasgos: comprobar una parte de un sistema con dependencias reales) o pruebas de extremo a extremo (usando todas las dependencias reales al mismo tiempo y comprobando el comportamiento del sistema en todos los extremos, mientras se reproducen flujos de trabajo de usuario que definen el sistema como utilizable y exitoso). Un beneficio claro de este enfoque es que también verificamos (a menudo sin querer) nuestras suposiciones sobre las dependencias y cómo las integramos con el sistema en el que trabajamos.

Sin embargo, cuando las pruebas emplean únicamente dependencias reales, debemos considerar los siguientes aspectos:

• Algunos escenarios de prueba no necesitan la dependencia real (por ejemplo, para verificar los invariantes estáticos de una petición).

• Estas pruebas normalmente no se ejecutan en suites completas en las máquinas de los desarrolladores, porque esperar retroalimentación llevaría demasiado tiempo.

• Requieren más recursos en máquinas de CI, y puede que lleve más tiempo ajustar las cosas para no perder tiempo y recursos.

• Puede que no sea trivial inicializar dependencias con datos de prueba.

• Las pruebas con dependencias reales son ideales para cordonar el código antes de una refactorización importante, migración o actualización de dependencias.

• Es más probable que sean pruebas opacas, es decir, que no sean detalladas sobre los componentes internos del sistema en prueba, sino que cuiden sus resultados.

El punto óptimo: usa ambas pruebas

En lugar de probar tu sistema con un solo tipo de prueba, puedes confiar en ambos tipos donde tenga sentido e intentar mejorar tu uso de ambos.

• Ejecuta primero pruebas basadas en mocks porque son mucho más rápidas, y solo cuando todas tengan éxito, haz pruebas de dependencia más lentas solo después.

• Elige mocks para escenarios donde realmente no se necesitan dependencias externas: cuando el mocking llevaría demasiado tiempo, el código debería modificar mucho solo para eso; depender de dependencias externas.

• No hay nada de malo en probar un fragmento de código usando ambos enfoques, siempre que tenga sentido.

Ejemplo de SystemUnderTest

Para las siguientes secciones vamos a usar un ejemplo que se puede encontrar aquí. Es una pequeña aplicación demo escrita en Java 21, que emplea Maven como herramienta de compilación, que se basa en el cliente Elasticsearch y emplea la última incorporación de Elasticsearch, usando ES|QL (el nuevo lenguaje de consultas procedimentales de Elastic). Si Java no es tu lenguaje de programación, deberías poder entender los conceptos que vamos a discutir a continuación y traducirlos a tu stack. Simplemente usar un ejemplo real de código hace que ciertas cosas sean más fáciles de explicar.

El BookSearcher nos ayuda a gestionar la búsqueda y el análisis de datos, siendo en nuestro caso los libros (como se demostró en una de las entradas anteriores).

• Requiere Elasticsearch exactamente en la versión 8.15.x como su única dependencia (ver isCompatibleWithBackend()), por ejemplo, porque no estamos seguros de si nuestro código es compatible hacia adelante, y estamos seguros de que no es compatible hacia atrás. Antes de actualizar Elasticsearch en producción a una versión más reciente, primero lo incluiremos en las pruebas para cerciorar que el comportamiento del Sistema Bajo Prueba se mantenga igual.

• Podemos usarlo para buscar el número de libros publicados en un año determinado (ver numberOfBooksPublishedInYear).

• También podríamos emplearlo cuando necesitemos analizar nuestro conjunto de datos y encontrar los 20 autores más publicados entre dos años determinados (ver mostPublishedAuthorsInYears).

Prueba con simulacros para empezar

Para crear los mocks usados en nuestros exámenes vamos a usar Mockito, una biblioteca de mocking muy popular en el ecosistema Java.

Podríamos empezar con lo siguiente, para que los simulacros se resetear antes de cada examen:

Como dijimos antes, no todo se puede evaluar fácilmente usando simulacros. Pero hay cosas que sí podemos (y probablemente deberíamos). Intentemos verificar que la única versión soportada de Elasticsearch es 8.15.x por ahora (en el futuro podríamos ampliar el rango una vez confirmemos que nuestro sistema es compatible con futuras versiones):

Podemos verificar de forma similar (simplemente devolviendo una versión menor diferente) que nuestro BookSearcher aún no va a funcionar con 8.16.x , porque no estamos seguros de si será compatible con él:

Ahora veamos cómo podemos lograr algo similar al probar contra un Elasticsearch real. Para esto vamos a usar el módulo Elasticsearch de Testcontainers, que solo tiene un requisito: necesita acceso a Docker, porque ejecuta contenedores Docker por ti. Desde cierto ángulo, los Testcontainers son simplemente una forma de operar contenedores Docker, pero en lugar de hacerlo en tu Docker Desktop (o similar), en tu LI o scripts, puedes expresar tus necesidades en el lenguaje de programación que conoces. Esto permite obtener imágenes, iniciar contenedores, recogerlas tras pruebas, copiar archivos de un lado a otro, ejecutar comandos, examinar registros, etc., directamente desde tu código de prueba.

El artículo puede ver así:

En este ejemplo dependemos de la integración de JUnit de Testcontainers con @Testcontainers y @Container, lo que significa que no tenemos que preocuparnos por iniciar Elasticsearch antes de nuestras pruebas y pararlo después. Lo único que tenemos que hacer es crear el cliente antes de cada prueba y cerrarlo luego de cada prueba (para evitar fugas de recursos, que podrían afectar a conjuntos de pruebas más grandes).

Anotar un campo no estático con @Container significa que se iniciará un nuevo contenedor para cada prueba, por lo que no tenemos que preocuparnos por datos obsoletos ni por resetear el estado del contenedor. Sin embargo, con muchas pruebas, este enfoque puede no funcionar bien, así que lo compararemos con alternativas en una de las próximas publicaciones.

Nota:

Conexión con Elasticsearch en pruebas

El cliente Java de Elasticsearch es capaz de conectarse a Elasticsearch ejecutar en un contenedor de prueba incluso con seguridad y SSL/TLS activados (que son los valores predeterminados de las versiones 8.x, por eso no tuvimos que especificar nada relacionado con la seguridad en la declaración del contenedor). Suponiendo que el Elasticsearch que usas en producción también tenga TLS y algo de seguridad activados, se recomienda optar por la configuración de pruebas de integración lo más parecida posible al escenario de producción, y por tanto no desactivarlos en las pruebas.

Cómo obtener los datos necesarios para la conexión, suponiendo que el contenedor esté asignado a campo o variable elasticsearch:

• elasticsearch.getHost() Te dará el host en el que se ejecuta el contenedor (que la mayoría de las veces probablemente será "localhost", pero por favor no lo codifiques de forma fija porque a veces, dependiendo de tu configuración, puede ser otro nombre, por lo que el host siempre debe obtener dinámicamente).

• elasticsearch.getMappedPort(9200) dará el puerto host que tienes que usar para conectarte a Elasticsearch que está dentro del contenedor (porque cada vez que inicias el contenedor, el puerto exterior cambia, así que también tiene que ser una llamada dinámica).

• A menos que fueron sobreescribir por defecto, el nombre de usuario y la contraseña por defecto son "elastic" y "changeme" respectivamente.

• Si no se especificó ningún certificado SSL/TLS durante la configuración del contenedor, y la conectividad segura no está desactivada (que es el comportamiento por defecto de las versiones 8.x), se genera un certificado autofirmado. Confiar en ella (por ejemplo, como puede hacer cURL) el certificado puede obtener usando elasticsearch.caCertAsBytes() (que devuelve Optional<byte[]>), u otra forma conveniente es obtener SSLContext usando createSslContextFromCa().

El resultado general podría ser el siguiente:

Otro ejemplo de creación de una instancia de ElasticsearchClient se puede encontrar en el proyecto demo.

Nota:

Primera prueba de integración

Nuestra primera prueba, verificando que podemos crear BookSearcher usando Elasticsearch versión 8.15.x, podría ser así:

Como puedes ver, no necesitamos montar nada más. No necesitamos simular la versión devuelta por Elasticsearch, lo único que necesitamos es proporcionar BookSearcher le un cliente conectado a una instancia real de Elasticsearch, que fue iniciada para nosotros por Testcontainers.

A las pruebas de integración les importan menos los componentes internos

Hagamos un pequeño experimento: supongamos que tenemos que dejar de extraer datos del conjunto de resultados usando índices de columna, pero tenemos que confiar en los nombres de las columnas. Así que en el método isCompatibleWithBackend en lugar de

Vamos a tener:

Cuando volvamos a ejecutar ambas pruebas, notaremos que la prueba de integración con Elasticsearch real sigue pasando sin problemas. Sin embargo, los tests con mocks dejaron de funcionar, porque simulábamos llamadas como rs.getInt(int), no rs.getInt(String). Para que pasen, ahora tenemos que simularlos o simularlos a ambos, dependiendo de otros casos de uso que tengamos en nuestro conjunto de pruebas.

Las pruebas de integración pueden ser un cañón para matar a una mosca

Las pruebas de integración son capaces de verificar el comportamiento del sistema, incluso si no se necesitan dependencias externas. Sin embargo, usarlos de esta manera suele ser una pérdida de tiempo y recursos de ejecución. Veamos el método mostPublishedAuthorsInYears(int minYear, int maxYear). Las dos primeras líneas son las siguientes:

La primera afirmación es comprobar una condición, que no depende de Elasticsearch (ni de ninguna otra dependencia externa) de ninguna manera. Por lo tanto, no necesitamos iniciar ningún contenedor solo para verificar que, si el minYear es mayor que maxYear, se lanza una excepción.

Un simple examen de simulación, que además es rápido y no requiere muchos recursos, es más que suficiente para cerciorarlo. Luego de preparar los simulacros, simplemente podemos hacer lo siguiente:

Iniciar una dependencia, en lugar de burlar, sería un desperdicio en este caso de prueba porque no hay posibilidad de tomar una decisión significativa para esta dependencia.

Sin embargo, para verificar el comportamiento que empieza por String query = ..., que la consulta está correctamente escrita, se obtiene los resultados esperados: la biblioteca cliente es capaz de enviar solicitudes y respuestas adecuadas, no hay cambios de sintaxis y por tanto es mucho más fácil usar una prueba de integración, por ejemplo:

De este modo, podemos estar seguros de que cuando alimentemos nuestros datos a Elasticsearch (en esta o cualquier versión futura a la que elijamos migrar), nuestra consulta nos dará exactamente lo que esperábamos: el formato de datos no cambió, la consulta sigue siendo válida y todo el middleware (clientes, controladores, seguridad, etc.) seguirá funcionando. No tenemos que preocuparnos por mantener los mocks actualizados, el único cambio necesario para cerciorar la compatibilidad con, por ejemplo, 8.15 cambiaría esto:

Lo mismo ocurre si decides, por ejemplo, usar el buen y viejo QueryDSL en lugar de ES|QL: los resultados que recibes de la consulta (independientemente del lenguaje) deberían seguir siendo los mismos.

Emplea ambos enfoques cuando sea necesario

El caso del método mostPublishedAuthorsInYears ilustra que un solo método puede probar usando ambos métodos. Y quizá incluso debería estarlo.

• Usar solo mocks significa que tenemos que mantener el mock y no tener ninguna confianza al actualizar nuestro sistema.

• Usar solo pruebas de integración significaría que estamos desperdiciando bastantes recursos, sin necesidad de ellos en absoluto.

Vamos a recapitular

• Es posible usar tanto pruebas de simulación como de integración con Elasticsearch.

• Emplea las pruebas de simulación como una red de detección rápida y solo si pasan con éxito, inicia pruebas con dependencias (por ejemplo, usando ./mvnw test '-Dtest=!TestInt*' && ./mvnw test '-Dtest=TestInt*' o plugins Failsafe y Surefire ).

• Usa mocks para probar el comportamiento de tu sistema ("líneas de código") donde la integración con dependencias externas realmente no importa (o incluso podría saltar).

• Emplea pruebas de integración para verificar tus suposiciones e integración con sistemas externos.

• No tengas miedo de probar usando ambos enfoques —si tiene sentido— según los puntos anteriores.

Se podría observar que ser tan estricto con la versión (en nuestro caso 8.15.x) es demasiado. Usar solo la etiqueta de versión podría serlo, pero ten en cuenta que en esta publicación sirve como representación de todas las demás características que puedan cambiar entre las versiones.

En la próxima entrega del serial, veremos formas de inicializar Elasticsearch ejecutar en un contenedor de prueba, con conjuntos de datos de prueba. Cuéntanos si creaste algo basado en este blog o si tienes preguntas en nuestros foros de discusión y en el canal comunitario de Slack.

LangChain4j está proporcionando una forma estándar de:

• crear incrustaciones (vectores) a partir de un contenido dado, por ejemplo un texto

• Almacenar incrustaciones en un almacén de incrustaciones

• Busca vectores similares en la tienda de incrustación

• discute con los LLMs

• usar una memoria de chat para recordar el contexto de una conversación con un LLM

Esta lista no es exhaustiva y la comunidad de LangChain4j siempre está implementando nuevas funcionalidades.

Esta entrada cubrirá las primeras partes principales del marco.

Agregando LangChain4j OpenAI a nuestro proyecto

Como en todos los proyectos Java, es solo cuestión de dependencias. Aquí usaremos Maven, pero lo mismo podría lograr con cualquier otro gestor de dependencias.

Como primer paso para el proyecto que queremos construir aquí, usaremos OpenAI, así que solo necesitamos agregar el langchain4j-open-ai artefacto:

Para el resto del código usaremos nuestra propia clave API, que puedes obtener registrándote en OpenAI, o la que proporciona el proyecto LangChain4j solo para demostraciones:

Ahora podemos crear una instancia de nuestro ChatLanguageModel:

Y finalmente podemos hacer una pregunta sencilla y obtener la respuesta:

La respuesta dada podría ser algo así:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step1AiChatTest.java .

Aportando más contexto con langchain4j

Vamos a agregar el artefacto langchain4j :

Este está proporcionando un conjunto de herramientas que puede ayudarnos a construir una integración LLM más avanzada para construir nuestro asistente. Aquí simplemente crearemos una interfaz Assistant que proporcione el método chat que llamará automáticamente a la ChatLanguageModel que definimos antes:

Solo tenemos que pedirle a LangChain4j AiServices clase que construya una instancia para nosotros:

Y luego llama al método chat(String) :

Esto es tener el mismo comportamiento que antes. ¿Entonces por qué cambiamos el código? En primer lugar, es más elegante, pero más que eso, ahora puedes dar algunas instrucciones al LLM usando anotaciones sencillas:

Esto ahora es dar:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step2AssistantTest.java .

Cambiar a otro LLM: langchain4j-ollama

Podemos aprovechar el gran proyecto Ollama. Ayuda tener un LLM localmente en tu máquina.

Vamos a agregar el artefacto langchain4j-ollama :

Como ejecutamos el código de ejemplo usando pruebas, vamos a agregar Testcontainers a nuestro proyecto:

Ahora podemos iniciar/detener contenedores Docker:

Simplemente tenemos que cambiar el objeto model para que se convierta en un OllamaChatModel en lugar del OpenAiChatModel que usamos antes:

Ten en cuenta que puede tardar un tiempo en extraer la imagen con su modelo, pero luego de un rato, podrías obtener la respuesta:

Mejor con la memoria

Si hacemos varias preguntas, por defecto el sistema no recordará las preguntas frecuentes anteriores. Así que si preguntamos luego de la primera pregunta "¿Cuándo nació?", Nuestra solicitud responderá:

Lo cual es una tontería. En su lugar, deberíamos usar Chat Memory:

Hacer las mismas preguntas ahora da una respuesta significativa:

Conclusión

En la próxima publicación, descubriremos cómo podemos hacer preguntas a nuestro conjunto de datos privado usando Elasticsearch como almacén de incrustaciones. Eso nos dará una forma de transformar nuestra búsqueda de aplicaciones al siguiente nivel.