El conector de almacenamiento vectorial de Semantic Kernel Elasticsearch, ya de fábrica , soporta las abstracciones de almacenamiento vectorial Semantic Kernel, lo que facilita mucho a los desarrolladores integrar Elasticsearch como un almacén vectorial mientras crean agentes de IA.

Elasticsearch tiene una estable base en la comunidad de código abierto y recientemente adoptó la licencia AGPL. Combinadas con el kernel semántico de código abierto de Microsoft, estas herramientas ofrecen una solución poderosa y preparada para compañías. Puedes empezar localmente activando Elasticsearch en unos minutos ejecutando este curl -fsSL https://elastic.co/start-local | sh de comandos (consulta start-local para más detalles) y pasar a versiones alojadas en la nube o autoalojadas mientras produces tus agentes de IA.

En este blog analizamos cómo usar Semantic Kernel Elasticsearch Vector Store Connector al usar Semantic Kernel. En el futuro se pondrá a disposición una versión en Python del conector.

Escenario de alto nivel: Construcción de una aplicación RAG con Kernel Semántico y Elasticsearch

En la siguiente sección repasamos un ejemplo. A un nivel general, estamos construyendo una aplicación RAG (Recuperación Generación Aumentada) que toma la pregunta del usuario como entrada y devuelve una respuesta. Usaremos Azure OpenAI (también se puede usar un LLM local ) como LLM, Elasticsearch como almacén vectorial y Semantic Kernel (.net) como marco para unir todos los componentes.

Si no estás familiarizado con las arquitecturas RAG, puedes hacer una breve introducción con este artículo: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

La respuesta la genera el LLM, que se alimenta con el contexto relevante para la pregunta, recuperado de Elasticsearch vectorstore. La respuesta también incluye la fuente que el LLM empleó como contexto.

Ejemplo RAG

En este ejemplo concreto, construimos una aplicación que permite a los usuarios hacer preguntas sobre hoteles almacenados en una base de datos interna de hoteles. El usuario podría, por ejemplo, Busca un hotel específico, según diferentes criterios, o pide una lista de hoteles.

Para la base de datos de ejemplo, generamos una lista de hoteles con 100 entradas. El tamaño de la muestra es intencionadamente pequeño para que puedas probar la demo del conector lo más fácilmente posible. En una aplicación real, el conector Elasticsearch mostraría sus beneficios sobre otras opciones, como la implementación de almacenamiento vectorial 'InMemory', especialmente cuando se trabaja con cantidades extremadamente grandes de datos.

La aplicación de demostración completa se puede encontrar en el repositorio de conectores de almacenamiento vectorial de Elasticsearch.

Empecemos agregando los paquetes NuGet necesarios y aplicando directivas a nuestro proyecto:

Ahora podemos crear nuestro modelo de datos y proporcionarle atributos específicos del Núcleo Semántico para definir el esquema del modelo de almacenamiento y algunas pistas para la búsqueda de texto:

Los atributos del Esquema del Modelo de Almacenamiento ('VectorStore*') son los más relevantes para el uso real del Conector de Almacenamiento Vectorial Elasticsearch, a saber:

• VectorStoreRecordKey para marcar una propiedad en una clase de registro como la clave bajo la cual el registro se almacena en un almacén vectorial.

• VectorStoreRecordData para marcar una propiedad en una clase de registro como 'datos'.

• VectorStoreRecordVector para marcar una propiedad en una clase de registro como vector.

Todos estos atributos aceptan varios parámetros opcionales que pueden emplear para personalizar aún más el modelo de almacenamiento. En el caso de VectorStoreRecordKey , por ejemplo, es posible especificar una función de distancia diferente o un tipo de índice distinto.

Los atributos de búsqueda de texto (TextSearch*) serán importantes en el último paso de este ejemplo. Volveremos a ellos más tarde.

En el siguiente paso, inicializamos el motor Semantic Kernel y obtenemos referencias a los servicios principales. En una aplicación real, se debe usar inyección de dependencias en lugar de acceder directamente a la colección de servicios. Lo mismo se aplica a la configuración y secretos codificados en fija, que deberían leer usando un proveedor de configuración en su lugar:

El servicio de vectorStoreCollection ahora puede usar para crear la colección e incorporar algunos discos demo:

Esto muestra cómo Semantic Kernel reduce el uso de un almacén vectorial con toda su complejidad a unas pocas llamadas a métodos simples.

En el fondo, se crea un nuevo índice en Elasticsearch y se generan todas las asignaciones de propiedades necesarias. Nuestro conjunto de datos se mapea de forma completamente transparente en el modelo de almacenamiento y finalmente se almacena en el índice. A continuación se muestra cómo se ven los mapeos en Elasticsearch.

El embeddings.GenerateEmbeddingsAsync() llama de forma transparente al servicio configurado Azure AI Embeddings Generation.

Se puede observar aún más magia en el último paso de esta demo.

Con una sola llamada a InvokePromptAsync, se realizan todas las siguientes operaciones cuando el usuario hace una pregunta sobre los datos:

1. Se genera una incrustación para la pregunta del usuario

2. Se busca en el almacén vectorial las entradas relevantes

3. Los resultados de la consulta se insertan en una plantilla de prompt

4. La consulta real en forma de prompt final se envía al servicio de finalización de chat con IA

¿Recuerdas los atributos TextSearch* que definimos previamente en nuestro modelo de datos? Estos atributos nos permiten usar marcadores de posición correspondientes en nuestra plantilla de prompts, que se llenan automáticamente con la información de nuestras entradas en el almacén vectorial.

La respuesta final a nuestra pregunta "Por favor, muéstrame todos los hoteles que tengan un bar en la azotea" es la siguiente:

La respuesta correcta se refiere a la siguiente entrada de nuestro hotels.csv

Este ejemplo muestra muy bien cómo el uso de Microsoft Semantic Kernel logra una reducción significativa de la complejidad gracias a sus abstracciones bien pensadas, además de permitir un nivel muy alto de flexibilidad. Por ejemplo, al cambiar una sola línea de código, el almacén vectorial o los servicios de IA empleados pueden ser reemplazados sin necesidad de refactorizar ninguna otra parte del código.

Al mismo tiempo, el framework proporciona un enorme conjunto de funcionalidades de alto nivel, como la función 'InvokePrompt', o el sistema de plantillas o plugins de búsqueda.

La aplicación de demostración completa se puede encontrar en el repositorio de conectores de almacenamiento vectorial de Elasticsearch.

¿Qué más es posible con Elasticsearch?

• Mapeado de nuevas semantic_text de Elasticsearch: Simplificación de la búsqueda semántica

• Reclasificación semántica en Elasticsearch con los retrievers

• Técnicas avanzadas de RAG parte 1: Procesamiento de datos

• Técnicas avanzadas de RAG parte 2: Consultas y pruebas

• Construyendo RAG con Llama 3 de código abierto y Elastic

• Un tutorial para construir agentes locales usando LangGraph, LLaMA3 y almacenamiento vectorial de Elasticsearch desde cero

Elasticsearch & Semantic Kernel: ¿Qué sigue?

• Mostramos cómo la tienda vectorial de Elasticsearch puede conectarse fácilmente a Semantic Kernel mientras se construyen aplicaciones GenAI en .NET. Estad atentos para la próxima integración de Python.

• A medida que Semantic Kernel construye abstracciones para funciones avanzadas de búsqueda como la búsqueda híbrida, el Elasticsearch Connect permitirá a los desarrolladores .NET implementarlas fácilmente usando Semantic Kernel.

En esta publicación analizaremos formas de proteger la Información Personal Identificable (PII) y los datos sensibles al emplear LLMs públicos en un flujo RAG (Generación Aumentada por Recuperación). Exploraremos el enmascaramiento de la PII y datos sensibles empleando librerías de código abierto y expresiones regulares, así como el uso de LLMs locales para enmascarar los datos antes de invocar un LLM público.

Antes de empezar, repasemos algunos términos que usamos en esta publicación.

Terminología

LlamaIndex es un marco de datos líder para construir aplicaciones LLM (Grandes Modelos de Lenguaje). LlamaIndex proporciona abstracciones para las distintas etapas de la construcción de una aplicación RAG (Generación Aumentada por Recuperación). Frameworks como LlamaIndex y LangChain proporcionan abstracciones para que las aplicaciones no se acoplen estrechamente a las APIs de ningún LLM específico.

Elasticsearch es ofrecido por Elastic. Elastic es líder en el sector detrás de Elasticsearch, un almacén de datos escalable y base de datos vectoriales que soporta búsqueda de texto completo para mayor precisión, búsqueda vectorial para comprensión semántica y búsqueda híbrida para lo mejor de ambos mundos. Elasticsearch es un motor de búsqueda y análisis distribuido y RESTful, almacén de datos escalable y base de datos vectorial. Las capacidades de Elasticsearch que empleamos en este blog están disponibles en la versión Gratis y Abierta de Elasticsearch.

La Generación Aumentada por Recuperación (RAG) es una técnica/patrón de IA en la que los LLMs reciben conocimientos externos para generar respuestas a las consultas de los usuarios. Esto permite adaptar las respuestas de los LLM a un contexto específico y ser menos genéricas.

Las incrustaciones son representaciones numéricas del significado de texto/medios. Son representaciones de información de alta dimensión en dimensiones inferiores.

RAG y Protección de Datos

Generalmente, los Grandes Modelos de Lenguaje (LLMs) son buenos generando respuestas basadas en la información disponible en el modelo que puede capacitar con datos de Internet. Sin embargo, para aquellas consultas donde la información no está disponible en el modelo, los LLMs deben proporcionar con conocimientos externos o detalles específicos que no estén contenidos en el modelo. Dicha información puede estar en tu base de datos o en tu sistema de conocimiento interno. La Generación Aumentada por Recuperación (RAG) es una técnica en la que, para una consulta de usuario dada, primero recuperas el contexto/información relevante de sistemas externos (a los LLMs) (por ejemplo, tu base de datos) y envías ese contexto junto con la consulta de usuario a un LLM para generar una respuesta más específica y relevante.

Esto hace que la técnica RAG sea muy eficaz para aplicaciones en respuesta a preguntas, creación de contenido y en cualquier lugar, un conocimiento profundo del contexto y el detalle es beneficioso.

Como resultado, en una cadena RAG corres el riesgo de exponer información interna como PII (Información Personal Identificable) e información sensible (por ejemplo, nombres, fechas de nacimiento, números de cuenta, etc.) a los LLMs públicos.

Aunque tus datos son seguros cuando usas una base de datos vectorial como Elasticsearch (a través de varias palancas como Control de Acceso basado en Roles, Seguridad a Nivel de Documentos , etc.), hay que tener cuidado al enviar datos fuera a un LLM público.

Proteger la Información Personalmente Identificable (PII) y los datos sensibles es crucial al emplear grandes modelos de lenguaje (LLMs) por varias razones:

• Cumplimiento de la privacidad: Muchas regiones tienen regulaciones estrictas, como el Reglamento General de Protección de Datos (RGPD) en Europa o la Ley de Privacidad del Consumidor de California (CCPA) en Estados Unidos, que exigen la protección de los datos personales. El cumplimiento de estas leyes es necesario para evitar consecuencias legales y multas.

• Confianza del usuario: Garantizar la confidencialidad e integridad de la información sensible genera confianza en los usuarios. Los usuarios tienen más probabilidades de emplear e interactuar con sistemas que creen que protegerán su privacidad.

• Seguridad de los datos: La protección frente a brechas de datos es esencial. Los datos sensibles expuestos a los LLMs sin las salvaguardas adecuadas pueden ser susceptibles a robo o mal uso, lo que puede provocar daños como el robo de identidad o el fraude financiero.

• Consideraciones éticas: Éticamente, es importante respetar la privacidad de los usuarios y manejar sus datos de forma responsable. Un mal manejo de la PII puede provocar discriminación, estigmatización u otros impactos sociales negativos.

• Reputación empresarial: Las compañías que no protegen datos sensibles pueden sufrir daños en su reputación, lo que puede tener efectos negativos a largo plazo en su negocio, incluyendo la pérdida de clientes e ingresos.

• Reducción de los riesgos de abuso: El manejo seguro de datos sensibles ayuda a prevenir el uso malicioso de los datos o del modelo, como capacitar los modelos con datos sesgados o usar los datos para manipular o dañar a individuos.

En general, es necesaria una protección robusta de las PII y datos sensibles para garantizar el cumplimiento legal, mantener la confianza de los usuarios, garantizar la seguridad de los datos, mantener estándares éticos, proteger la reputación empresarial y reducir el riesgo de abuso.

Resumen rápido

En la publicación anterior hablamos de cómo implementar la experiencia de preguntas frecuentes empleando una técnica RAG con Elasticsearch como base de datos vectorial, empleando LlamaIndex y un LLM Mistral que se ejecuta localmente. Aquí vamos a construir sobre eso.

Leer la publicación anterior es opcional, ya que ahora vamos a hablar o resumir rápidamente lo que hicimos en la publicación anterior.

Teníamos un conjunto de datos de ejemplo de conversaciones en centros de llamadas entre agentes y clientes de una compañía de seguros de hogar ficticia. Construimos una aplicación RAG sencilla que respondía a preguntas como "¿Por qué tipo de problemas relacionados con el agua presentan reclamaciones los clientes?".

A grandes rasgos, así es como se veía el flujo.

Durante la fase de Indexación, cargamos e indexamos documentos usando la canalización LlamaIndex. Los documentos se agrupaban en fragmentos y se almacenaban en la base de datos vectorial Elasticsearch junto con sus incrustaciones.

Durante la fase de consulta, cuando el usuario hacía una pregunta, LlamaIndex recuperaba documentos similares en top-K que eran relevantes para la consulta. Estos documentos relevantes para el top-K junto con la consulta se enviaban al LLM Mistral que se ejecutaba localmente, que luego generaba la respuesta para ser enviada de vuelta al usuario. No dudes en leer la publicación anterior o explorar el código.

En la publicación anterior teníamos el LLM funcionando localmente. Sin embargo, en producción puede que quieras usar un LLM externo proporcionado por varias compañías como OpenAI, Mistral, Anthropic , etc. Puede ser porque tu caso de uso necesita un modelo fundamental más amplio o porque ejecutar localmente no es una opción debido a necesidades de producción empresarial como escalabilidad, disponibilidad, rendimiento, etc.

Introducir un LLM externo en tu pipeline RAG te expone al riesgo de filtrar inadvertidamente información sensible y PII a los LLMs. En esta publicación exploraremos opciones sobre cómo enmascarar la información de PII como parte de tu pipeline RAG antes de enviar documentos a un LLM externo.

RAG con un LLM público

Antes de hablar sobre cómo proteger tu PII e información sensible en una cadena RAG, primero construiremos una aplicación RAG sencilla empleando LlamaIndex, la base de datos Elasticsearch Vector y OpenAI LLM.

Prerrequisitos

Necesitaremos lo siguiente.

• Elasticsearch está en funcionamiento como base de datos vectorial para almacenar los embeddings. Sigue las instrucciones de la publicación anterior sobre cómo instalar Elasticsearch.

• Abre las claves API de IA.

Aplicación sencilla de RAG

Para referencia, el código completo se puede encontrar en este Repositorio de Github(branch:protecting-pii). Clonar el repositorio es opcional, ya que repasaremos el código a continuación.

En tu IDE favorito, crea una nueva aplicación en Python con los siguientes 3 archivos.

• index.py donde va el código relacionado con la indexación de datos.

• query.py donde va el código relacionado con la consulta y la interacción con LLM.

• .env donde van propiedades de configuración como las claves de API.

Necesitamos instalar algunos paquetes. Comenzamos creando un nuevo entorno virtual de Python en la carpeta raíz de tu aplicación.

Activa el entorno virtual e instala los paquetes requeridos a continuación.

Configura las propiedades de conexión de OpenAI y Elasticsearch en el archivo .env archivo.

Datos de indexación

Descarga el archivo conversations.json que contiene conversaciones entre clientes y agentes del centro de llamadas de nuestra ficticia compañía de seguros de hogar. Coloca el archivo en el directorio raíz de la aplicación junto a los 2 archivos python y el archivo .env Archivo que creaste antes. A continuación se muestra un ejemplo del contenido del archivo.

Más allá del código de abajo en index.py que se encarga de indexar los datos.

Ejecutar el código anterior para ver crea un índice en Elasticsearch, almacena los embeddings en el índice de Elasticsearch llamado convo_index.

Si necesitas explicación sobre LlamaIndex IngestionPipeline, consulta la publicación anterior en la sección Crear Pipeline.

Consulta

En la publicación anterior usamos un LLM local para hacer consultas.

En esta publicación usamos un LLM público, OpenAI, como se muestra a continuación.

El código anterior muestra la respuesta de OpenAI como se indica a continuación.

Los clientes presentaron diversas reclamaciones relacionadas con el agua, incluyendo problemas como daños por agua en sótanos, tuberías rotas, daños por granizo en los tejados y denegación de reclamaciones por motivos como falta de notificación a tiempo, problemas de mantenimiento, desgaste gradual y daños preexistentes. En cada caso, los clientes expresaron frustración por las denegaciones de reclamaciones y buscaron evaluaciones y decisiones justas respecto a sus reclamaciones.

Ocultar la PII en RAG

Lo que cubrimos hasta ahora implica enviar documentos tal cual a OpenAI junto con la consulta del usuario.

En la tubería RAG, tras recuperar el contexto relevante de un almacén vectorial, tenemos la oportunidad de enmascarar la información personal personal y sensible antes de enviar la consulta y el contexto al LLM.

Hay varias formas de enmascarar la información de la PII antes de enviarla a un LLM externo, cada una con su propio mérito. A continuación analizamos algunas de las opciones

1. Empleando bibliotecas de PLN como spacy.io o Presidio (biblioteca de código abierto mantenida por Microsoft).

2. Uso de LlamaIndex desde el primer momento NERPIINodePostprocessor.

3. Uso de LLMs locales mediante PIINodePostprocessor

Una vez que implementes la lógica de enmascaramiento usando cualquiera de las formas anteriores, podrías configurar el LlamaIndex IngestionPipeline con un PostProcesador (tu propio personalizado o cualquiera de los PostProcessors listos para usar de LlamaIndex).

Uso de bibliotecas de PLN

Como parte de la cadena RAG podríamos enmascarar datos sensibles usando bibliotecas de PLN. Usaremos el paquete spacy.io en esta demo.

Crea un nuevo query_masking_nlp.py de archivo y agrega el código que aparece a continuación.

La respuesta del LLM se muestra a continuación.

En el código anterior, al crear el Llama Index QueryEngine, suministramos un CustomPostProcessor.

La lógica que invoca el QueryEngine en está definida en el método _postprocess_nodes de CustomPostProcessor. Estamos usando la biblioteca SpaCy.io para detectar Entidades Nombradas en nuestro y luego usamos algunas expresiones regulares para reemplazar esos nombres, así como información sensible, antes de enviar los documentos al LLM.

Como ejemplo a continuación, se presentan partes de conversaciones originales y la conversación enmascarada creada por el CustomPostProcessor.

Texto original:

Texto enmascarado por el CustomPostProcessor.

Nota:

Identificar y enmascarar la información personal personal y la información sensible no es una tarea sencilla. Cubrir diversos formatos y semánticas de información sensible requiere un buen conocimiento de tu dominio y datos. Aunque el código presentado arriba puede funcionar para algunos casos de uso, puede que tengas que modificar según tus necesidades y pruebas.

Usando el LlamaIndex de fábrica NERPIINodePostprocessor

LlamaIndex facilitó la protección de la información de PII en una cadena RAG al introducir NERPIINodePostprocessor.

La respuesta es la siguiente que se muestra

Uso de LLMs locales mediante PIINodePostprocessor

También podríamos aprovechar un LLM que funcione localmente o en tu red privada para hacer el trabajo de enmascaramiento antes de enviar los datos a un LLM público.

Usaremos Mistral funcionando en Ollama en tu máquina local para hacer el enmascaramiento.

Ejecutar Mistral localmente

Descarga e instala Ollama. Luego de instalar Ollama, ejecuta este comando para descargar y ejecutar mistral

Puede que tardes unos minutos en descargar y ejecutar el modelo localmente por primera vez. Verifica si el mistral está funcionando haciendo una pregunta como la siguiente: "Escribe un poema sobre nubes" y verifica si el poema te gusta. Mantén a Ollama funcionando, ya que tendremos que interactuar con el modelo mistral más adelante mediante código.

Crea un archivo nuevo llamado query_masking_local_LLM.py y agrega el código de abajo.

La respuesta es algo parecido a la que se muestra a continuación

Conclusión

En esta publicación mostramos cómo se puede proteger la PII y los datos sensibles al usar LLMs públicos en un flujo RAG. Demostramos múltiples formas de lograrlo. Se recomienda encarecidamente probar estos enfoques según tu caso de uso y necesidades antes de adoptarlos.

Antes de empezar, veremos algo de terminología.

Terminología

LlamaIndex es un marco de datos líder para construir aplicaciones LLM (Grandes Modelos de Lenguaje). LlamaIndex proporciona abstracciones para las distintas etapas de la construcción de una aplicación RAG (Generación Aumentada por Recuperación). Frameworks como LlamaIndex y LangChain proporcionan abstracciones para que las aplicaciones no se acoplen estrechamente a las APIs de ningún LLM específico.

Elasticsearch es ofrecido por Elastic. Elastic es líder en el sector detrás de Elasticsearch, un motor de búsqueda y análisis que soporta búsqueda en texto completo para mayor precisión, búsqueda vectorial para comprensión semántica y búsqueda híbrida para lo mejor de ambos mundos. Elasticsearch es un almacén de datos escalable y una base de datos vectorial. Las capacidades de elasticsearch que empleamos en este blog están disponibles en la versión gratis y abierta de Elasticsearch.

La Generación de Aumentos por Recuperación (RAG) es una técnica/patrón de IA en la que los LLMs reciben conocimientos externos para generar respuestas a las consultas de los usuarios. Esto permite adaptar las respuestas de los LLM a un contexto específico y que las respuestas sean más específicas.

Mistral ofrece tanto modelos LLM de código abierto como optimizados de nivel empresarial. En este tutorial, usaremos su modelo de código abierto mistral-7b que funciona en tu portátil. Si no quieres ejecutar el modelo en tu portátil, alternativamente podrías usar su versión en la nube, en cuyo caso tendrás que modificar el código de este blog para usar las claves y paquetes de API adecuados.

Ollama ayuda a ejecutar LLMs localmente en tu portátil. Usaremos Ollama para ejecutar localmente el modelo de código abierto Mistral-7b.

Las incrustaciones son representaciones numéricas del significado de texto/medios. Son representaciones de información de alta dimensión en dimensiones inferiores.

Construcción de una aplicación RAG con LlamaIndex, Elasticsearch y Mistral: Resumen del escenario

Escenario:

Disponemos de un conjunto de datos de ejemplo (como archivo JSON) de conversaciones en centros de llamadas entre agentes y clientes de una compañía de seguros de hogar ficticia. Construiremos una aplicación RAG sencilla que podrá responder preguntas como

Give me summary of water related issues.

Caudal de alto nivel

Tenemos Mistral LLM funcionando localmente usando Ollama.

A continuación, cargamos las conversaciones del archivo JSON como Documents en ElasticsearchStore (que es un VectorStore respaldado por Elasticsearch). Al cargar los documentos creamos incrustaciones usando el modelo Mistral que se ejecuta localmente. Almacenamos estos embeddings junto con las conversaciones en LlamaIndex Elasticsearch vector Store (ElasticsearchStore).

Configuramos un LlamaIndex IngestionPipeline y lo suministramos con el LLM local que usamos, en este caso Mistral que funciona a través de Ollama.

Cuando hacemos una pregunta como "Dame un resumen de los problemas relacionados con el agua.", Elasticsearch realiza una búsqueda semántica y devuelve conversaciones relacionadas con problemas relacionados con el agua. Estas conversaciones , junto con la pregunta original, se envían al LLM que se ejecuta localmente para generar una respuesta.

Pasos para construir la aplicación RAG

Ejecutar Mistral localmente

Descarga e instala Ollama. Luego de instalar Ollama, ejecuta este comando para descargar y ejecutar mistral

Puede que tardes unos minutos en descargar y ejecutar el modelo localmente por primera vez. Verifica si el mistral está funcionando haciendo una pregunta como la siguiente: "Escribe un poema sobre nubes" y verifica si el poema te gusta. Mantén a Ollama funcionando, ya que tendremos que interactuar con el modelo mistral más adelante mediante código.

Instalar Elasticsearch

Pon en marcha Elasticsearch ya sea creando un despliegue en la nube (instrucciones aquí) o ejecutándolo en docker (instrucciones aquí). También puedes crear un despliegue autoalojado de Elasticsearch de calidad producción empezando por aquí.

Suponiendo que usas el despliegue en la nube, descarga la clave API y el ID de la nube para el despliegue tal y como se indica en las instrucciones. Los usaremos más tarde.

Aplicación RAG

Como referencia, se puede encontrar el código completo en este repositorio de Github. Clonar el repositorio es opcional, ya que repasaremos el código a continuación.

En tu IDE favorito, crea una nueva aplicación en Python con los siguientes 3 archivos.

• index.py donde va el código relacionado con la indexación de datos.

• query.py donde va el código relacionado con la consulta y la interacción con LLM.

• .env donde van propiedades de configuración como las claves de API.

Necesitamos instalar algunos paquetes. Comenzamos creando un nuevo entorno virtual de Python en la carpeta raíz de tu aplicación.

Activa el entorno virtual e instala los paquetes requeridos a continuación.

Datos de indexación

Descarga el archivo conversations.json que contiene conversaciones entre clientes y agentes de centros de llamadas de nuestra compañía de seguros de hogar ficticia. Coloca el archivo en el directorio raíz de la aplicación junto a los 2 archivos python y el archivo .env Archivo que creaste antes. A continuación se muestra un ejemplo del contenido del archivo.

Definimos una función llamada get_documents_from_file en index.py que lee el archivo json y crea una lista de Documentos. Los objetos documento son la unidad básica de información con la que trabaja LlamaIndex.

Create IngestPipeline

En primer lugar, agrega las claves de CloudID y API de Elasticsearch que obtuviste en la sección Install Elasticsearch al archivo .env . Tu archivo .env debería parecer a lo siguiente (con valores reales).

LlamaIndex IngestionPipeline te permite componer una tubería usando múltiples componentes. Agrega el código de abajo al archivo index.py .

Como se mencionó anteriormente, el LlamaIndex IngestPipeline puede estar compuesto por múltiples componentes. Estamos agregando 3 componentes a la tubería en la línea pipeline = IngestionPipeline(....

• Fragmentador de Sentences: Como se puede ver en la definición de get_documents_from_file(), cada documento tiene un campo de texto que contiene la conversación encontrada en el archivo json. Este campo de texto es un texto largo. Para que la búsqueda semántica funcione bien, debe dividir en fragmentos de textos más pequeños. La clase SentenceSplitter hace esto por nosotros. Estos bloques se denominan nodos en la terminología de LlamaIndex. Hay metadatos en los nodos que apuntan al documento al que pertenecen. Alternativamente, podrías usar Elasticsearch Ingestpipeline para el chunking, como se muestra en este blog.

• OllamaEmbedding: Los modelos de incrustación convierten un fragmento de texto en números (también llamados vectores). Tener representación numérica nos permite realizar búsquedas semánticas donde los resultados coinciden con el significado de la palabra en lugar de simplemente hacer una búsqueda de texto. Suministramos a IngestionPipeline OllamaEmbedding("mistral"). Los chunks que dividimos usando SentenceSplitter se envían al modelo Mistral que se ejecuta en tu máquina local mediante Ollama, luego Mistral crea embeddings para los chunks.

• ElasticsearchStore: El almacén vectorial LlamaIndex ElasticsearchStore respalda las incrustaciones que se están creando en un Índice Elasticsearch. ElasticsearchStore se encarga de crear y poblar el contenido del índice Elasticsearch especificado. Al crear el ElasticsearchStore (referenciado por es_vector_store) proporcionamos el nombre del índice Elasticsearch que queremos crear (calls en nuestro caso), el campo en el índice donde queremos almacenar las incrustaciones (conversation_vector en nuestro caso) y el campo donde queremos almacenar el texto (conversation en nuestro caso). En resumen, basar en nuestra configuración ElasticsearchStore crea un nuevo índice en Elasticsearch con conversation_vector y conversation como campos (entre otros campos creados automáticamente).

Para unirlo todo, gestionamos la tubería llamando a pipeline.run(documents=documents).

Ejecuta el script index.py para ejecutar la tubería de ingest:

Una vez completada la ejecución de la pipeline, deberíamos ver un nuevo índice en Elasticsearch llamado calls. Ejecutando una consulta sencilla de elasticsearch usando la Dev Console deberías poder ver los datos cargados junto con las incrustaciones.

Para resumir lo que hicimos hasta ahora, creamos Documents a partir de un archivo JSON, los dividimos en bloques, creamos incrustaciones para esos fragmentos y almacenamos las incrustaciones (y la conversación de texto) en un almacén vectorial (ElasticsearchStore).

Consulta

El llamaIndex VectorStoreIndex te permite recuperar documentos relevantes y datos de consulta. Por defecto, VectorStoreIndex almacena incrustaciones en memoria en un SimpleVectorStore. Sin embargo, se pueden usar almacenes vectoriales externos (como ElasticsearchStore) para hacer que las incrustaciones sean persistentes.

Abre el query.py y pega el código de abajo

Definimos un LLM local (local_llm) para apuntar al modelo Mistral que se ejecuta en Ollama. A continuación, creamos un VectorStoreIndex (index) a partir de la tienda vectorial ElasticssearchStore que creamos antes y luego obtenemos un motor de consulta desde el índice. Al crear el motor de consultas, hacemos referencia al LLM local que debe usar para responder, también proporcionamos (similarity_top_k=10) para configurar el número de documentos que deben recuperar del almacén vectorial y enviar al LLM para obtener una respuesta.

Ejecuta el script query.py para ejecutar el flujo RAG:

Enviamos el Give me summary of water related issues de consulta (no dudes en personalizar el query) y la respuesta del LLM, que se proporciona con los documentos relacionados, debería ser algo así como el siguiente.

Algunas advertencias:

Esta entrada de blog es una introducción para principiantes a la técnica RAG con Elasticsearch y, por tanto, omite la configuración de las características que te permitirán llevar este punto de partida a producción. Al construir para casos de uso en producción, querrás considerar aspectos más sofisticados como poder proteger tus datos con Seguridad a Nivel de Documento, fragmentar tus datos como parte de una pipeline de Ingest de Elasticsearch o incluso ejecutar otros trabajos de ML con los mismos datos que se usan para casos de uso de GenAI/Chat/Q&A.

También podrías considerar buscar datos y crear incrustaciones desde diversas fuentes externas (por ejemplo, Azure Blob Storage, Dropbox, Gmail, etc.) usando Elastic Connectors.

Elastic hace posible todo lo anterior y más posible, y ofrece una solución integral de nivel empresarial para casos de uso de GenAI y más allá.

¿Qué sigue?

• Quizá notaste que estamos enviando 10 conversaciones relacionadas junto con la pregunta del usuario al LLM para formular una respuesta. Estas conversaciones pueden contener información personal identificable (PII) como nombre, fecha de nacimiento, dirección, etc. En nuestro caso, el LLM es local, así que la fuga de datos no es un problema. Sin embargo, cuando quieres usar un LLM que se ejecuta en la nube (por ejemplo, OpenAI) no es deseable enviar textos que contengan información de PII. En un blog de seguimiento veremos cómo lograr información de PII de Enmascaramiento antes de enviarla a LLMs externos en el flujo RAG.

• En esta publicación empleamos un LLM local; en la próxima publicación sobre Enmascarar datos de PII en RAG, veremos cómo podemos cambiar fácilmente de un LLM local a uno público.