En mi última publicación, explico cómo se puede utilizar la búsqueda híbrida para mejorar significativamente la efectividad de una canalización RAG. RAG, en su versión básica, que utiliza solo búsqueda semántica en incrustaciones, puede ser muy efectivo, permitiéndonos utilizar el poder de la IA en nuestros propios documentos. Sin embargo, la búsqueda semántica, por poderosa que sea, cuando se utiliza en grandes bases de conocimiento, a veces puede perder coincidencias exactas de la consulta del usuario, incluso si existen en los documentos. Esta debilidad del RAG tradicional se puede solucionar agregando un componente de búsqueda de palabras clave en el proceso, como BM25. De esta manera, la búsqueda híbrida, que combina la búsqueda semántica y de palabras clave, genera resultados mucho más completos y mejora significativamente el rendimiento de un sistema RAG.
Sea como sea, incluso cuando utilizamos RAG con búsqueda híbrida, a veces podemos perdernos información importante que se encuentra dispersa en diferentes partes del documento. Esto puede suceder porque cuando un documento se divide en fragmentos de texto, a veces se pierde el contexto (es decir, el texto circundante al fragmento que forma parte de su significado). Esto puede suceder especialmente con textos complejos, con significados interconectados y dispersos en varias páginas, e inevitablemente no pueden incluirse por completo en un solo fragmento. Piense, por ejemplo, en hacer referencia a una tabla o una imagen en varias secciones de texto diferentes sin definir explícitamente a qué tabla nos referimos (por ejemplo, “como se muestra en la tabla, las ganancias aumentaron un 6%”, ¿a qué tabla?). Como resultado, cuando se recuperan los fragmentos de texto, se les quita su contexto, lo que a veces resulta en la recuperación de fragmentos irrelevantes y la generación de respuestas irrelevantes.
Esta pérdida de contexto fue un problema importante para los sistemas RAG durante algún tiempo, y se han explorado varias soluciones no tan exitosas para mejorarlo. Un intento obvio de mejorar esto es aumentar el tamaño del fragmento, pero esto a menudo también altera el significado semántico de cada fragmento y termina haciendo que la recuperación sea menos precisa. Otro enfoque es aumentar la superposición de fragmentos. Si bien esto ayuda a aumentar la preservación del contexto, también aumenta los costos de almacenamiento y computación. Lo más importante es que no resuelve completamente el problema: aún podemos tener interconexiones importantes con los límites de los fragmentos. Los enfoques más avanzados que intentan resolver este desafío incluyen las incrustaciones de documentos hipotéticos (HyDE) o el índice de resumen de documentos. Sin embargo, estos todavía no logran proporcionar mejoras sustanciales.
En última instancia, un enfoque que resuelve esto de manera efectiva y mejora significativamente los resultados de un sistema RAG es la recuperación contextual, introducida originalmente por Anthropic en 2024. La recuperación contextual tiene como objetivo resolver la pérdida de contexto preservando el contexto de los fragmentos y, por lo tanto, mejorando la precisión del paso de recuperación del proceso RAG.
. . .
¿Qué pasa con el contexto?
Antes de decir algo sobre la recuperación contextual, demos un paso atrás y hablemos un poco sobre qué es el contexto. Claro, todos hemos oído hablar del contexto de los LLM o de las ventanas contextuales, pero ¿de qué se tratan realmente?
Para ser muy preciso, el contexto se refiere a todos los tokens que están disponibles para el LLM y en función de los cuales predice la siguiente palabra; recuerde, los LLM funcionan generando texto prediciendo una palabra a la vez. Por lo tanto, serán las indicaciones del usuario, las indicaciones del sistema, las instrucciones, las habilidades o cualquier otra directriz que influya en cómo el modelo produce una respuesta. Es importante destacar que la parte de la respuesta final que el modelo ha producido hasta ahora también es parte del contexto, ya que cada nuevo token se genera en función de todo lo anterior.
Aparentemente, diferentes contextos conducen a resultados de modelos muy diferentes. Por ejemplo:
“Fui a un restaurante y pedí una pizza”. “Fui a la farmacia y compré un medicamento”.
Una limitación fundamental de los LLM es su ventana de contexto. La ventana de contexto de un LLM es la cantidad máxima de tokens que se pueden pasar a la vez como entrada al modelo y tener en cuenta para producir una respuesta única. Hay LLM con ventanas de contexto más grandes o más pequeñas. Los modelos de frontera modernos pueden manejar cientos de miles de tokens en una sola solicitud, mientras que los modelos anteriores a menudo tenían ventanas de contexto tan pequeñas como 8k tokens.
En un mundo perfecto, querríamos simplemente pasar toda la información que el LLM necesita saber en el contexto, y lo más probable es que obtengamos muy buenas respuestas. Y esto es cierto hasta cierto punto: un modelo de frontera como Opus 4.6 con una ventana de contexto de 200.000 tokens corresponde a unas 500-600 páginas de texto. Si toda la información que necesitamos proporcionar se ajusta a este límite de tamaño, podemos incluir todo tal como está, como entrada para el LLM y obtener una excelente respuesta.
El problema es que para la mayoría de los casos de uso de la IA en el mundo real, necesitamos utilizar algún tipo de base de conocimiento con un tamaño que esté mucho más allá de este umbral; piense, por ejemplo, en bibliotecas jurídicas o manuales de equipos técnicos. Dado que los modelos tienen estas limitaciones de la ventana de contexto, desafortunadamente no podemos simplemente pasar todo al LLM y dejar que responda mágicamente; de alguna manera tenemos que elegir cuál es la información más importante que debe incluirse en nuestra ventana de contexto limitada. Y de eso se trata esencialmente la metodología RAG: seleccionar la información adecuada de una gran base de conocimientos para responder eficazmente a la consulta de un usuario. En última instancia, esto surge como un problema de optimización/ingeniería (ingeniería de contexto) que identifica la información apropiada para incluirla en una ventana de contexto limitada, a fin de producir las mejores respuestas posibles.
Esta es la parte más crucial de un sistema RAG: asegurarse de que se recupere la información adecuada y se transmita como entrada al LLM. Esto se puede hacer con la búsqueda semántica y la búsqueda de palabras clave, como ya se explicó. Sin embargo, incluso cuando se reúnen todos los fragmentos semánticamente relevantes y todas las coincidencias exactas, todavía existe una buena posibilidad de que quede información importante.
¿Pero qué tipo de información sería ésta? Ya que hemos cubierto el significado con la búsqueda semántica y las coincidencias exactas con la búsqueda de palabras clave, ¿qué otro tipo de información hay que considerar?
Diferentes documentos con significados inherentemente diferentes pueden incluir partes similares o incluso idénticas. Imagine un libro de recetas y un manual de procesamiento químico que indiquen al lector que “caliente la mezcla lentamente”. El significado semántico de dicho fragmento de texto y las palabras reales son muy similares, idénticos. En este ejemplo, lo que forma el significado del texto y nos permite separar entre cocina e ingeniería química es a lo que nos referimos como contexto.
Por lo tanto, este es el tipo de información adicional que pretendemos preservar. Y esto es exactamente lo que hace la recuperación contextual: preserva el contexto (el significado circundante) de cada fragmento de texto.
. . .
¿Qué pasa con la recuperación contextual?
Entonces, la recuperación contextual es una metodología aplicada en RAG con el objetivo de preservar el contexto de cada fragmento. De esta manera, cuando se recupera un fragmento y se pasa al LLM como entrada, podemos preservar la mayor cantidad posible de su significado inicial (la semántica, las palabras clave, el contexto), todo.
Para lograr esto, la recuperación contextual sugiere que primero generemos un texto auxiliar para cada fragmento (es decir, el texto contextual) que nos permita situar el fragmento de texto en el documento original del que proviene. En la práctica, le pedimos a un LLM que genere este texto contextual para cada fragmento. Para hacer esto, proporcionamos el documento, junto con el fragmento real, en una sola solicitud a un LLM y le solicitamos que “proporcione el contexto para situar el fragmento específico en el documento”. Un mensaje para generar el texto contextual de nuestro fragmento del libro de cocina italiano se vería así:
el documento completo Documento del libro de cocina italiano del que proviene el fragmento Aquí está el fragmento que queremos colocar dentro del contexto del documento completo. el fragmento real Proporcione un contexto breve que ubique este fragmento dentro del documento general para mejorar la recuperación de búsqueda. Responda sólo con el contexto conciso y nada más.
El LLM devuelve el texto contextual que combinamos con nuestro fragmento de texto inicial. De esta manera, para cada fragmento de nuestro texto inicial, generamos un texto contextual que describe cómo se coloca este fragmento específico en su documento principal. Para nuestro ejemplo, esto sería algo como:
Contexto: Paso de la receta para cocinar a fuego lento salsa de pasta con tomate casera. Trozo: Calienta la mezcla lentamente y revuelve ocasionalmente para evitar que se pegue.
¡Lo cual es, de hecho, mucho más informativo y específico! Ahora ya no hay duda de qué es esta misteriosa mezcla, porque en el mismo trozo se incluye convenientemente toda la información necesaria para identificar si estamos hablando de salsa de tomate o de soluciones de almidón de laboratorio.
A partir de este momento, trataremos el texto fragmentado inicial y el texto contextual como un par inseparable. Luego, el resto de los pasos de RAG con búsqueda híbrida se realizan esencialmente de la misma manera. Es decir, creamos incrustaciones que se almacenan en una búsqueda vectorial y el índice BM25 para cada fragmento de texto, antepuesto con su texto contextual.
Este enfoque, por simple que sea, da como resultado mejoras sorprendentes en el rendimiento de recuperación de las tuberías RAG. Según Anthropic, Contextual Retrieval mejora la precisión de la recuperación en un impresionante 35%.
. . .
Reducción de costos con almacenamiento en caché rápido
Te escucho preguntar: “¿Pero esto no va a costar una fortuna?”. Sorprendentemente, no.
Intuitivamente, entendemos que esta configuración aumentará significativamente el costo de ingesta de una tubería RAG; esencialmente el doble, si no más. Después de todo, ahora agregamos un montón de llamadas adicionales al LLM, ¿no? Esto es cierto hasta cierto punto; de hecho, ahora, para cada fragmento, hacemos una llamada adicional al LLM para ubicarlo dentro de su documento fuente y obtener el texto contextual.
Sin embargo, este es un costo que solo pagamos una vez, en la etapa de ingesta del documento. A diferencia de las técnicas alternativas que intentan preservar el contexto en tiempo de ejecución, como las incrustaciones de documentos hipotéticos (HyDE), la recuperación contextual realiza el trabajo pesado durante la etapa de ingesta de documentos. En los enfoques de tiempo de ejecución, se requieren llamadas LLM adicionales para cada consulta de usuario, lo que puede escalar rápidamente la latencia y los costos operativos. Por el contrario, la recuperación contextual cambia el cálculo a la fase de ingesta, lo que significa que la calidad de recuperación mejorada no conlleva gastos adicionales durante el tiempo de ejecución. Además de esto, se pueden utilizar técnicas adicionales para reducir aún más el costo de recuperación contextual. Más precisamente, el almacenamiento en caché se puede utilizar para generar el resumen del documento sólo una vez y luego situar cada fragmento frente al resumen del documento producido.
. . .
en mi mente
La recuperación contextual representa una mejora simple pero poderosa de los sistemas RAG tradicionales. Al enriquecer cada fragmento con texto contextual, señalando su posición semántica dentro de su documento fuente, reducimos drásticamente la ambigüedad de cada fragmento y, por lo tanto, mejoramos la calidad de la información transmitida al LLM. Combinada con la búsqueda híbrida, esta técnica nos permite preservar la semántica, las palabras clave y el contexto simultáneamente.
¿Te encantó esta publicación? ¡Seamos amigos! Únase a mí en:
📰Substack 💌 Medio 💼LinkedIn ☕¡Cómprame un café!
Todas las imágenes del autor, salvo que se indique lo contrario.