Todos los editores y proveedores del modelo de lenguaje grande (LLM) se están centrando en el advenimiento de los agentes de inteligencia artificial (IA) y la IA agente. Estos términos son confusos. Más aún, ya que los jugadores aún no están de acuerdo en cómo desarrollarlos e implementarlos.
Esto es mucho menos cierto para las arquitecturas de generación aumentada de recuperación (RAG) donde, desde 2023, ha habido un consenso generalizado en la industria de TI.
La generación aumentada a través de la recuperación permite que los resultados de un modelo de IA generativo se anclen en la verdad. Si bien no previene las alucinaciones, el método tiene como objetivo obtener respuestas relevantes, basadas en los datos internos de una empresa o en la información de una base de conocimiento verificada.
Podría resumirse como la intersección de la IA generativa y un motor de búsqueda empresarial.
¿Qué es la arquitectura de trapo?
En términos generales, el proceso de un sistema de trapo es simple de entender. Comienza con el usuario enviando un mensaje, una pregunta o solicitud. Este aviso de lenguaje natural y la consulta asociada se comparan con el contenido de la base de conocimiento. Los resultados más cercanos a la solicitud se clasifican en orden de relevancia, y todo el proceso se envía a un LLM para producir la respuesta enviada al usuario.
Las compañías que han tratado de implementar RAG han aprendido los detalles de dicho enfoque, comenzando con el soporte para los diversos componentes que conforman el mecanismo de RAG. Estos componentes están asociados con los pasos necesarios para transformar los datos, desde ingerirlo en un sistema de origen hasta generar una respuesta utilizando un LLM.
Preparación de datos, una necesidad incluso con trapo
El primer paso es reunir los documentos que desea buscar. Si bien es tentador ingerir todos los documentos disponibles, esta es la estrategia incorrecta. Especialmente porque debe decidir si actualizar el sistema en lotes o continuamente.
“Las fallas provienen de la calidad de la entrada. Algunos clientes me dicen: ‘Tengo dos millones de documentos, tienes tres semanas, dame un trapo’. Obviamente, no funciona”, dice Bruno Maillot, director de la IA para la práctica comercial de Sopra Steria Next. “Esta noción de refinamiento a menudo se olvida, a pesar de que se entendió bien en el contexto del aprendizaje automático. La IA generativa no hace chocapic”.
Una LLM no es de facto una herramienta de preparación de datos. Es aconsejable eliminar duplicados y versiones intermedias de documentos y aplicar estrategias para seleccionar elementos actualizados. Esta preselección evita sobrecargar el sistema con información potencialmente inútil y evita problemas de rendimiento.
Una vez que se han seleccionado los documentos, los datos sin procesar (páginas HTML, documentos PDF, imágenes, archivos de documentos, etc.) deben convertirse en un formato utilizable, como el texo y los metadatos asociados, expresados en un archivo JSON, por ejemplo. Estos metadatos no solo pueden documentar la estructura de los datos, sino también sus autores, origen, fecha de creación, etc. Estos datos formateados se transforman en tokens y vectores.
Los editores rápidamente se dieron cuenta de que con grandes volúmenes de documentos y textos largos, era ineficiente vectorizar todo el documento.
Chunking y sus estrategias
De ahí la importancia de implementar una estrategia de “fragmentación”. Esto implica romper un documento en extractos cortos. Un paso crucial, según Mistral AI, que dice, “hace que sea más fácil identificar y recuperar la información más relevante durante el proceso de búsqueda”.
Aquí hay dos consideraciones: el tamaño de los fragmentos y la forma en que se obtienen.
El tamaño de una fragmentación a menudo se expresa como varios caracteres o tokens. Un mayor número de fragmentos mejora la precisión de los resultados, pero la multiplicación de vectores aumenta la cantidad de recursos y el tiempo requeridos para procesarlos.
Hay varias formas de dividir un texto en trozos.
- El primero es cortar según fragmentos de tamaño fijo: caracteres, palabras o tokens. “Este método es simple, lo que lo convierte en una opción popular para las fases iniciales del procesamiento de datos donde necesita explorar los datos rápidamente”, dice Ziliz, un editor de bases de datos vectoriales.
- Un segundo enfoque consiste en un desglose semántico, es decir, basado en un desglose “natural”: por oración, por sección, definida por un encabezado HTML, por ejemplo, sujeto o párrafo. Aunque más complejo de implementar, este método es más preciso. A menudo depende de un enfoque recursivo, ya que implica el uso de separadores lógicos, como espacio, coma, parada completa, encabezado, etc.
- El tercer enfoque es una combinación de los dos anteriores. La fragmentación híbrida combina una descomposición fija inicial con un método semántico cuando se requiere una respuesta muy precisa.
Además de estas técnicas, es posible encadenar los fragmentos juntos, teniendo en cuenta que parte del contenido de los fragmentos puede superponerse.
“La superposición asegura que siempre haya algún margen entre los segmentos, lo que aumenta las posibilidades de capturar información importante incluso si se divide de acuerdo con la estrategia de fragmentación inicial”, según la documentación de LLM Platform Cohere. “La desventaja de este método es que genera redundancia.
La solución más popular parece ser mantener fragmentos fijos de 100 a 200 palabras con una superposición del 20% al 25% del contenido entre fragmentos.
Esta división a menudo se realiza utilizando bibliotecas de Python, como Spacy o NTLK, o con las herramientas de “divisores de texto” en el marco Langchain.
El enfoque correcto generalmente depende de la precisión requerida por los usuarios. Por ejemplo, un desglose semántico parece más apropiado cuando el objetivo es encontrar información específica, como el artículo de un texto legal.
El tamaño de los trozos debe coincidir con las capacidades del modelo de incrustación. Esta es precisamente la razón por la cual el fragmento es necesario en primer lugar. Esto “le permite mantenerse por debajo del límite de token de entrada del modelo de incrustación”, explica Microsoft en su documentación. “Por ejemplo, la longitud máxima del texto de entrada para el modelo Azure OpenAI Embeding-ADA-002 es de 8,191 tokens. Dado que un token corresponde en promedio a alrededor de cuatro caracteres con modelos actuales de OpenAI, este límite máximo es equivalente a alrededor de 6,000 palabras”.
Vectorización e incrustación de modelos
Un modelo de incrustación es responsable de convertir trozos o documentos en vectores. Estos vectores se almacenan en una base de datos.
Aquí nuevamente, hay varios tipos de modelo de incrustación, principalmente modelos densos y escasos. Los modelos densos generalmente producen vectores de tamaño fijo, expresados en x número de dimensiones. Estos últimos generan vectores cuyo tamaño depende de la longitud del texto de entrada. Un tercer enfoque combina los dos para vectorizar extractos cortos o comentarios (Splade, Colbert, IBM Sparse-Embedding-30m).
La elección del número de dimensiones determinará la precisión y la velocidad de los resultados. Un vector con muchas dimensiones captura más contexto y matices, pero puede requerir más recursos para crear y recuperar. Un vector con menos dimensiones será menos rico, pero más rápido para buscar.
La elección del modelo de incrustación también depende de la base de datos en la que se almacenarán los vectores, el modelo de lenguaje grande con el que se asociará y la tarea a realizar. Los puntos de referencia como la clasificación MTEB son invaluables. A veces es posible usar un modelo de incrustación que no provenga de la misma colección LLM, pero es necesario usar el mismo modelo de incrustación para vectorizar la base de documentos y las preguntas del usuario.
Tenga en cuenta que a veces es útil ajustar el modelo de incrustaciones cuando no contiene un conocimiento suficiente del lenguaje relacionado con un dominio específico, por ejemplo, oncología o ingeniería de sistemas.
La base de datos de vector y su algoritmo de recuperación
Las bases de datos de vectores hacen más que simplemente los vectores de almacenamiento: generalmente incorporan un algoritmo de búsqueda semántica basado en la técnica de vecino más cercano para indexar y recuperar información que corresponde a la pregunta. La mayoría de los editores han implementado el algoritmo jerárquico de Werarchical Navigable World (HNSW). Microsoft también influye en Diskann, un algoritmo de código abierto diseñado para obtener una relación de costo de rendimiento ideal con grandes volúmenes de vectores, a expensas de la precisión. Google ha elegido desarrollar un modelo patentado, Scann, también diseñado para grandes volúmenes de datos. El proceso de búsqueda implica atravesar las dimensiones del gráfico vectorial en busca del vecino aproximado más cercano, y se basa en un cálculo de coseno o distancia euclidiana.
La distancia coseno es más efectiva para identificar la similitud semántica, mientras que el método euclidiano es más simple, pero menos exigente en términos de recursos informáticos.
Dado que la mayoría de las bases de datos se basan en una búsqueda aproximada de los vecinos más cercanos, el sistema devolverá varios vectores potencialmente correspondientes a la respuesta. Es posible limitar el número de resultados (corte de Top-K). Esto es incluso necesario, ya que queremos la consulta del usuario y la información utilizada para crear la respuesta para adaptarse a la ventana de contexto LLM. Sin embargo, si la base de datos contiene una gran cantidad de vectores, la precisión puede sufrir o el resultado que estamos buscando puede estar más allá del límite impuesto.
Búsqueda híbrida y rerantos
La combinación de un modelo de búsqueda tradicional como BM25 con un Retriever de tipo HNSW puede ser útil para obtener una buena relación costo-rendimiento, pero también se limitará a un número restringido de resultados. MÁS MÁS, ya que no todas las bases de datos vectoriales admiten la combinación de modelos HNSW con BM25 (también conocido como búsqueda híbrida).
Un modelo de reverencia puede ayudar a encontrar más contenido considerado útil para la respuesta. Esto implica aumentar el límite de los resultados devueltos por el modelo “Retriever”. Luego, como su nombre lo sugiere, el Reranker reordera los trozos de acuerdo con su relevancia para la pregunta. Ejemplos de volviéndose a rerankers incluyen Cohere Rerank, BGE, Janus AI y Elastic Rerank. Por otro lado, dicho sistema puede aumentar la latencia de los resultados devueltos al usuario. También puede ser necesario volver a entrenar este modelo si el vocabulario utilizado en la base de documentos es específico. Sin embargo, algunos lo consideran útil: los puntajes de relevancia son datos útiles para supervisar el rendimiento de un sistema RAG.
Reranker o no, es necesario enviar las respuestas a los LLM. Una vez más, no todos los LLM se crean igual: el tamaño de su ventana de contexto, su velocidad de respuesta y su capacidad de responder de hecho (incluso sin tener acceso a documentos) son criterios que deben evaluarse. A este respecto, Google Deepmind, Openai, Mistral AI, Meta y Anthrope han entrenado sus LLM para respaldar este caso de uso.
Evaluar y observar
Además del Reranker, un LLM puede usarse como juez para evaluar los resultados e identificar posibles problemas con la LLM que se supone que genera la respuesta. Algunas API dependen en su lugar de las reglas para bloquear contenido dañino o solicitudes de acceso a documentos confidenciales para ciertos usuarios. Los marcos de recolección de opinión también se pueden utilizar para refinar la arquitectura de trapo. En este caso, se invita a los usuarios a calificar los resultados para identificar los puntos positivos y negativos del sistema RAG. Finalmente, la observabilidad de cada uno de los bloques de construcción es necesaria para evitar problemas de costo, seguridad y rendimiento.