- RAG usado en IA basada en conocimiento empresarial puede perder contexto como el nombre de la empresa o el momento temporal al dividir documentos en pequeños chunks, y por eso omitir información relevante
- Contextual Retrieval de Anthropic adjunta una breve explicación basada en el documento completo antes de cada chunk y luego crea embeddings e índices BM25 para reducir la tasa de fallos en la recuperación
- En los experimentos, Contextual Embeddings redujo la tasa de fallos de recuperación de chunks top-20 de 5.7% a 3.7%, un 35%, y la combinación de Contextual Embeddings con Contextual BM25 la bajó a 2.9%, un 49%
- Si además se suma reranking (reordenamiento), se vuelven a puntuar los 150 candidatos top para enviar solo los 20 mejores al modelo, y la tasa de fallos de recuperación baja de 5.7% a 1.9%, un 67%
- Si la base de conocimiento tiene 200,000 tokens o menos, también es posible meterla completa en el prompt, pero en bases más grandes conviene evaluar la combinación de Contextual Retrieval y reranking según cada caso de uso
El contexto documental que RAG pierde
- Para que un modelo de IA sea útil en una tarea específica, necesita acceso a conocimiento de contexto
- Un chatbot de soporte al cliente necesita el conocimiento de ese negocio
- Un bot de análisis legal necesita conocimiento de jurisprudencia previa
- Los desarrolladores normalmente refuerzan el conocimiento del modelo con Retrieval-Augmented Generation (RAG)
- Buscan información relevante en una base de conocimiento
- Añaden esa información recuperada al prompt del usuario para mejorar la respuesta del modelo
- En RAG tradicional, el proceso de dividir documentos en chunks puede eliminar el contexto, haciendo que no se encuentre información relevante
- Contextual Retrieval es una forma de mejorar la etapa de recuperación en RAG, y puede usar juntas dos subtécnicas
- Contextual Embeddings: genera embeddings con chunks a los que se les añadió contexto
- Contextual BM25: crea un índice BM25 con chunks a los que se les añadió contexto
- Esta combinación reduce la cantidad de fallos de recuperación en 49%, y al combinarse con reranking llega hasta 67%
- Hay un cookbook disponible para implementar Contextual Retrieval con Claude
En bases de conocimiento pequeñas también sirven los prompts largos
- Si la base de conocimiento tiene 200,000 tokens o menos, es decir, menos de unas 500 páginas, se puede meter la base completa en el prompt sin usar RAG
- El prompt caching de Claude hace este enfoque más rápido y más eficiente en costos
- Permite guardar en caché prompts usados con frecuencia entre llamadas a la API
- Puede reducir la latencia en más de 2x
- Puede reducir el costo hasta en 90%
- Se puede ver cómo funciona en el prompt caching cookbook
- Cuando la base de conocimiento crece, se necesita un método de recuperación más escalable, y ahí entra Contextual Retrieval
El papel de RAG tradicional y BM25
- Cuando una base de conocimiento grande no cabe en la ventana de contexto, la solución típica es RAG
- El flujo de preprocesamiento de RAG es el siguiente
- El corpus documental se divide normalmente en pequeños chunks de texto de unos cientos de tokens o menos
- Un modelo de embeddings convierte esos chunks en embeddings vectoriales que capturan significado
- Los embeddings se guardan en una base de datos vectorial que permite búsqueda por similitud semántica
- En tiempo de ejecución, se buscan en la base vectorial los chunks semánticamente más parecidos a la consulta del usuario, y esos chunks relevantes se agregan al prompt del modelo generativo
- Los modelos de embeddings capturan bien relaciones semánticas, pero pueden pasar por alto coincidencias exactas de cadenas
- BM25 (Best Matching 25) es una función de ranking basada en coincidencia léxica, especialmente efectiva para consultas con identificadores únicos o términos técnicos
- BM25 se basa en el concepto de TF-IDF
- TF-IDF mide qué tan importante es una palabra específica dentro de un documento en una colección
- BM25 considera la longitud del documento y aplica una función de saturación a la frecuencia de términos para evitar que palabras comunes dominen los resultados
- Por ejemplo, al buscar
"Error code TS-999" en una base de datos de soporte técnico, un modelo de embeddings podría encontrar documentos generales sobre códigos de error, pero pasar por alto la coincidencia exacta con "TS-999"
- BM25 encuentra directamente esa cadena e identifica los documentos relevantes
RAG que usa embeddings y BM25 juntos
- RAG puede combinar embeddings y BM25 para recuperar chunks con mayor precisión
- Divide la base de conocimiento en pequeños chunks
- Genera para cada chunk una codificación TF-IDF y un embedding semántico
- Usa BM25 para encontrar los chunks principales basados en coincidencias exactas
- Usa embeddings para encontrar los chunks principales basados en similitud semántica
- Combina resultados con técnicas de rank fusion y elimina duplicados
- Mete los K chunks principales en el prompt para generar la respuesta
- Este enfoque equilibra la coincidencia exacta de términos con una comprensión semántica más amplia
- Puede escalar de forma rentable hasta bases de conocimiento enormes que no caben en un solo prompt
- Pero los sistemas RAG tradicionales tienen la limitación de que destruyen el contexto al dividir documentos en chunks
- Un caso representativo es preguntar
"What was the revenue growth for ACME Corp in Q2 2023?" en una base de conocimiento basada en reportes de la SEC
- El chunk relevante podría contener solo
"The company's revenue grew by 3% over the previous quarter."
- Solo con ese chunk no se sabe de qué empresa ni de qué periodo se habla
- Esto dificulta usar la información correcta tanto al recuperar como al usar el contenido
Cómo funciona Contextual Retrieval
- Contextual Retrieval añade un contexto descriptivo por chunk antes de hacer embeddings y construir el índice BM25
- Cuando se aplica a embeddings, se llama Contextual Embeddings
- Cuando se aplica al índice BM25, se llama Contextual BM25
- En el ejemplo del reporte de la SEC, el chunk original es el siguiente
The company's revenue grew by 3% over the previous quarter.
- El chunk contextualizado queda así
This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter.
- Antes ya se habían propuesto métodos para usar contexto con el fin de mejorar la recuperación
- Estos métodos son distintos del enfoque de Contextual Retrieval, que añade contexto específico por chunk
Generar contexto de chunk con Claude
- No es realista que personas anoten manualmente miles o millones de chunks
- Anthropic redactó un prompt para que Claude genere un contexto breve y específico por chunk basándose en el contexto del documento completo
- El prompt usado con Claude 3 Haiku fue el siguiente
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.
- El texto de contexto generado suele tener 50 a 100 tokens y se antepone al chunk antes de usarlo para embeddings y para crear el índice BM25
- Si se usa prompt caching, no hace falta volver a enviar el documento de referencia para cada chunk
- El documento se sube una vez a la caché y luego se hace referencia al contenido ya cacheado
- Suponiendo chunks de 800 tokens, documentos de 8k tokens, una instrucción de contexto de 50 tokens y 100 tokens de contexto por chunk, el costo único de generar chunks contextualizados es de 1.02 dólares por cada millón de tokens de documentos
Método experimental y rendimiento de recuperación
- Los experimentos se realizaron en varios dominios de conocimiento, modelos de embeddings, estrategias de recuperación y métricas de evaluación
- Bases de código
- Novelas
- Papers de ArXiv
- Artículos científicos
- Los ejemplos de preguntas y respuestas de cada dominio están incluidos en el Appendix II
- Las gráficas muestran el rendimiento promedio en todos los dominios de conocimiento, usando la configuración de embeddings de mayor desempeño, Gemini Text 004, y recuperación de chunks top-20
- La métrica de evaluación es 1 - recall@20
- Mide la proporción de veces en que un documento relevante no fue recuperado dentro de los 20 chunks principales
- En los resultados globales, todas las combinaciones embedding-source evaluadas mejoraron su rendimiento al aplicar contextualización
- Los resultados de mejora de rendimiento fueron los siguientes
- Contextual Embeddings: redujo la tasa de fallos de recuperación top-20 de 5.7% → 3.7%, es decir, 35%
- Contextual Embeddings + Contextual BM25: redujo la tasa de fallos de recuperación de 5.7% → 2.9%, es decir, 49%
Puntos a considerar al implementar
- Los límites de los chunks pueden afectar el rendimiento de recuperación
- Tamaño del chunk
- Límites del chunk
- Solapamiento entre chunks
- Contextual Retrieval mejoró el rendimiento en todos los modelos de embeddings probados, pero el nivel de mejora puede variar según el modelo
- Los embeddings de Gemini y de Voyage fueron especialmente efectivos
- El prompt general proporcionado funciona bien, pero se pueden obtener mejores resultados con un prompt de contextualización personalizado para el dominio o el caso de uso
- Ejemplo: incluir un glosario de términos clave que solo se definen en otros documentos de la base de conocimiento
- Meter más chunks en la ventana de contexto aumenta la probabilidad de incluir información relevante
- Pero a mayor cantidad de información, el modelo puede distraerse más, así que hay límites
- Al probar con 5, 10 y 20 chunks, 20 dio el mejor rendimiento
- En casos de uso reales, hace falta experimentar
- Para generar la respuesta, puede mejorar pasar chunks contextualizados y distinguir qué parte es contexto y cuál es el chunk original
- Siempre hay que ejecutar una evaluación
Mejorar aún más con reranking
- Reranking es una técnica de filtrado que, en bases de conocimiento grandes, envía al modelo solo los chunks más relevantes entre los candidatos recuperados inicialmente
- Esta etapa puede afectar la calidad de la respuesta, el costo y la latencia al reducir la cantidad de información que procesa el modelo
- El procedimiento es el siguiente
- Una recuperación inicial trae los chunks principales potencialmente relevantes
- En el experimento se usó el top 150
- Los N chunks principales y la consulta del usuario se envían al modelo de reranking
- El modelo de reranking asigna a cada chunk una puntuación de relevancia e importancia
- Se seleccionan los K chunks principales
- En el experimento se usó el top 20
- Los chunks elegidos se añaden como contexto del modelo para generar el resultado final
- El experimento se realizó con el reranker de Cohere
- También existe el reranker de Voyage, pero no hubo tiempo para probarlo
- Añadir una etapa de reranking optimiza aún más la recuperación en distintos dominios
- Reranked Contextual Embedding + Contextual BM25 redujo la tasa de fallos de recuperación de chunks top-20 de 5.7% → 1.9%, es decir, 67%
Equilibrio entre costo y latencia
- El reranking introduce una etapa adicional en tiempo de ejecución, por lo que inevitablemente añade algo de latencia
- Incluso si el modelo de reranking puntúa todos los chunks en paralelo, hay que considerar el impacto en latencia y costo
- Rerankear más chunks puede mejorar el rendimiento, pero aumenta el costo y la latencia
- Rerankear menos chunks reduce costo y latencia, pero puede disminuir la mejora de rendimiento
- El equilibrio adecuado debe encontrarse experimentando con varias configuraciones en cada caso de uso específico
Resultado al combinar todo
- Se compararon combinaciones de tipo de dataset, modelo de embeddings, uso o no de BM25, uso o no de Contextual Retrieval, uso o no de reranking y cantidad top-K de recuperación
- El resumen de resultados es el siguiente
- Embeddings + BM25 funciona mejor que usar solo embeddings
- Entre los embeddings probados, Voyage y Gemini fueron los mejores
- Pasar top-20 chunks al modelo fue más efectivo que top-10 o top-5
- Añadir contexto a los chunks mejora significativamente la precisión de recuperación
- Reranking funciona mejor que no usar reranking
- Para maximizar la mejora de rendimiento, se puede combinar Contextual Embeddings basados en Voyage o Gemini, Contextual BM25, una etapa de reranking y agregar 20 chunks al prompt
- Los desarrolladores pueden experimentar este enfoque con el Contextual Retrieval cookbook
1 comentarios
Opiniones de Hacker News
Estoy construyendo RAG empresarial para una agencia gubernamental. Hicimos pruebas A/B experimentales con métricas de RAGAS y, con base en preguntas de evaluación sintéticas, no hubo un gran cambio al agregar reordenamiento basado en LLM después de una búsqueda híbrida (búsqueda semántica + vectorial), y HyDE redujo mucho la calidad de las respuestas y de la recuperación
Aún tenemos que evaluar más con preguntas de expertos y preguntas reales de usuarios usando RAGAS
Así que, aunque no es ninguna novedad decir que la búsqueda híbrida suele ser buena en RAG de producción/empresarial, no hay un método que siempre gane. En nuestro caso, junto a la similitud vectorial, bastó con usar búsqueda semántica de Azure AI Search como segundo método. En otros entornos, BM25 o un pequeño modelo de lenguaje afinado para posprocesamiento de consultas podrían funcionar mejor, así que al final hay que seguir probando según el caso de uso
Lo siguiente que planeamos probar es RAPTOR, SelfRAG, RAG con agentes, mejora de consultas (expansión y subconsultas) y GraphRAG
La lección hasta ahora es que hay que trabajar con una línea base y un grupo experimental, e intentar refutar la hipótesis nula con métricas como RAGAS; además, las preguntas/respuestas de evaluación deberían usar tres tipos: Q&A escritos por expertos, preguntas reales de usuarios obtenidas de logs y Q&A sintéticos generados a partir de los documentos fuente
Lo que más me gusta de este enfoque es que aprovecha muy bien el caché de prompts
Los prompts cacheados suelen costar alrededor de 1/10 de lo normal, así que trucos como procesar todos los chunks junto con el documento original completo antes no tenían sentido por costo, pero ahora sí son viables
Gracias al ahorro que da el caché, creo que se abrirán muchas más técnicas buenas de este tipo
Nota sobre recuperación contextual: https://simonwillison.net/2024/Sep/20/introducing-contextual... y nota sobre caché de prompts: https://simonwillison.net/2024/Aug/14/prompt-caching-with-cl...
Sería un contexto útil para tener una idea de cuánto hay que invertir para mantenerse al día con los modelos y funciones más recientes
Desde la perspectiva de alguien con experiencia en búsqueda tradicional, limitar RAG a modelos de embeddings ya hechos y búsqueda vectorial parece una estrategia bastante ingenua. La búsqueda vectorial por sí sola no es tan buena, y para mejorar el contexto que se le da al LLM hacen falta estrategias adicionales de recuperación de información. En el fondo, eso es justo lo que se está haciendo aquí
Microsoft publicó antes un paper sobre Graph RAG, que combina RAG y búsqueda vectorial sobre un grafo conceptual creado mediante extracción de entidades a partir de los datos indexados. Eso permite traer información contextualmente relacionada con los chunks coincidentes
Tengo la impresión de que se puede llegar bastante lejos incluso sin búsqueda vectorial. También sería mucho más barato. Bastaría con motores de búsqueda tradicionales y consultas bien ajustadas. Claro, la clave está en afinar las consultas, y puede que no sirva para casos generales, pero sí podría funcionar en casos más especializados
Como contexto adicional, este enfoque no es tan nuevo. Una forma común de mejorar resultados de RAG es “expandir” los chunks base con un LLM para aumentar la superficie semántica que puede hacer match
Si corres expansión de consultas con HyDE[1], quizá mejore aún más, pero no siempre sale mejor, así que yo lo uso como ruta alternativa
No tengo claro qué fue exactamente lo nuevo que presentó Anthropic aquí. Incluso viendo el código del cookbook, solo muestra el proceso para generar ese contexto, y la API en realidad no ha cambiado respecto a la “recuperación contextual”
Lo que sí cambió fue el caché de prompts introducido hace un mes, que permite añadir contexto mucho mejor a chunks individuales usando el documento largo completo como contexto y a un costo muy bajo. El caché es una gran función, muy valiosa para exponer a desarrolladores, y eso sí se le reconoce
Pero fuera de eso, parece que todo es simplemente un cookbook que muestra un flujo de trabajo específico de RAG
Dicho eso, Cohere está entre las APIs que más me han gustado de las que he probado. No tengo ninguna afiliación, pero la API de RAG de Cohere me pareció muy buena, a diferencia de otros proveedores. La recomiendo mucho
1: https://arxiv.org/abs/2212.10496
Si tus datos tienen decenas de miles de chunks, hay que hacer eso para todos, así que sale caro. Cachear el documento puede reducir ese costo
No encaja muy bien con mis requisitos de RAG, y supongo que con los de la mayoría tampoco. Una consulta puede ejecutarse el próximo mes o dentro de un año. No parece que esa política haya cambiado, así que me sorprende un poco que se hable de Prompt Caching en relación con RAG
Nosotros también hacemos algo parecido. Primero dividimos los documentos en chunks según los encabezados h1, h2 y h3, y al inicio de cada chunk agregamos el header como contexto
Como ejemplo hipotético, si el chunk original era “La dosis habitual para adultos es de 1 a 2 tabletas o cápsulas de 200 mg, 3 veces al día”, ahora quedaría algo como
# Fever,## Treatment, seguido de una línea divisoria y luego el mismo contenidoParece funcionar bastante bien, y ni siquiera se necesita un LLM al indexar el documento
Esto también podría ser el origen del debate de que “ChatGPT se volvió más lento en diciembre”. Es posible que esos metadatos de “fecha” hayan hecho que esa información fuera menos útil para ChatGPT
Primero resumo cada página, le pongo un título y extraigo una lista de subsecciones. Luego junto todos los resúmenes y le pido al modelo que cree un índice jerárquico. El modelo organiza todo el conjunto como un árbol y, al momento de la consulta, combina la ruta dentro del árbol como contexto adicional
Esta técnica no me convence mucho. Estoy de acuerdo en que el escenario planteado es un problema común, pero la solución propuesta se siente torpe
Los embeddings vectoriales tienen una propiedad parecida a una compresión de bolsa de palabras, y pueden quedar sobreindexados hacia el primer bloque de texto antes del salto de línea. Como resultado, ciertos índices del vector terminan mucho más cerca de 0 que antes. Después de la cuantización, eso puede volverse literalmente 0 y hacer que se pierda bastante precisión en el vector denso. La búsqueda por IDF compensa un poco, pero no lo suficiente
Si se hace un “semantic boost” del embedding para acercarlo más al título, resumen o abstract del documento, se puede obtener la ventaja de recall de este prefijo de “contexto” sin contaminar el vector base. En implementación, es una suma ponderada. En la etapa de augmentación, cuando se inserta en la ventana de contexto, también se puede inyectar el chunk de resumen si el documento hace match. Personalmente, me parece una solución mucho más limpia
Explicación de “semantic boost” en la API de Trieve[1]:
semantic_boost: útil para mover el vector de embedding de un chunk en la dirección de una frase de distancia. Por ejemplo, si un chunk conchunk_htmligual aiphoneusaflagshipcomodistance_phrasey0.25comodistance_factor, se puede empujar para que quede 25% más cerca del término “flagship”. Conceptualmente, esto traza una línea de distancia euclidiana/L2 entre el vector delinnerTextdechunk_htmly el vector dedistance_phrase, y luego mueve el vector dechunk_htmla lo largo de esa línea para acercarlo o alejarlo en una cantidad dedistance_factorL2Distance[1]:https://docs.trieve.ai/api-reference/chunk/create-or-upsert-...
Si es así, ¿eso no significa que una vector DB queda atada a un solo LLM, o incluso a una sola versión como Claude-3.5 Sonnet, y que no se puede migrar ni a 3.5 Haiku ni a Opus, y que para pasar a ChatGPT o Llama habría que reindexar?
La técnica que me parece más útil es implementar una estrategia de lista enlazada donde un chunk tenga múltiples punteros desde elementos que lo referencian. Esto lo hago manualmente, pero aumenta muchísimo la variedad de formas en que se puede referenciar un nodo específico
Visto de otra manera, es como los comentarios. Todos los comentarios debajo de este post pueden verse como punteros al post original. Algunos comentarios están semánticamente cerca del original, y otros se alejan más por la percepción del autor. Pero si a cada comentario se le asigna un
parent_id, aumentan los caminos para llegar al post originalUn ejemplo de esta técnica puede verse aquí [1]. En vez de tratar de adivinar qué consulta hará el usuario final, simplemente se deja que el usuario lo diga y eso se indexa como puntero. Las opciones para representar un objeto dado son finitas, pero algunas representaciones están muy, muy, muy lejos del significado del objeto central
[1] - https://x.com/yourcommonbase/status/1833262865194557505
En datasets pequeños, la idea de que basta con meter 200 mil tokens para obtener la mejor respuesta no coincide con mi experiencia
A medida que el prompt crece, muchas veces veo que baja la consistencia de la salida y también empeora el seguimiento de instrucciones. Incluso me da la impresión de que esto pasa en rangos mucho menores que 25k tokens. Me pregunto si a otras personas también les pasa y si hay métodos conocidos para evitarlo
Interesante. El problema que tengo es buscar con RAG no fragmentos de conocimiento, sino reglas aplicables. Solo deberían inyectarse en el contexto las reglas que puedan aplicarse al contexto dado
Aún no lo he probado, pero creo que podría funcionar entrenar un clasificador pequeño para determinar si una regla específica puede aplicarse. El LLM principal se encarga de decidir si esa regla realmente aplica en el contexto actual
Por ejemplo, supongamos que juegas un juego de mazmorra multiusuario con un LLM. Digamos que antes el personaje tuvo un mal comportamiento relacionado con taxis, y que el juego creó una regla: “cada vez que intente subirse a un taxi, lo echan. ‘Sabemos quién eres y no te aceptaremos como cliente hasta que ofrezcas una disculpa formal al director de la compañía de taxis’”. Si se disculpa, la regla se elimina. El director de la compañía de taxis podría ser otro jugador, o la persona que activó originalmente la regla que su propia flota de taxis NPC hará cumplir
Me pregunto qué tan escalable sería esto según la cantidad de reglas activas, y hasta qué punto podría aplicarse el RAG tradicional. Determinar si una regla aplica parece un problema más abstracto y difícil que determinar si un fragmento de conocimiento es relevante
Lo que lo hace especialmente más difícil es el bucle de dependencia que no existe en la recuperación de conocimiento. Para identificar si una regla aplica, primero hay que recuperar esa regla. ¿Cómo podría resolverse este problema?
Si redactas una consulta de ejemplo con ayuda de LLama 3.1 8B, podrías escribirla con suficiente detalle, como que un ejército de elfos oscuros se acerca, que Grimgold Ironfist está en una situación desesperada, que antes fue un orgulloso miembro de la milicia enana pero ahora tiene 35% de salud, que en su inventario hay un pico desgastado, una cantimplora, pan viejo y 17 monedas de oro, y que, a pesar de su “problemático pasado” con el gremio de taxis, intenta parar un taxi en el camino
Un ejemplo de regla que se recuperaría del almacén vectorial sería una que aparezca por la proximidad vectorial generada por las menciones al nombre/atributos del personaje y a taxi y Taxi Guild
Sería una regla como: “Taxi Guild ha impuesto un castigo severo a Grimgold. Cada vez que intente parar un taxi, será expulsado inmediatamente del vehículo. El edicto del Guild establece: ‘Grimgold Ironfist, el enano barbudo de mala reputación, no puede abordar ningún taxi operado por miembros hasta que ofrezca una disculpa formal a Thorgrim Stonebeard, director de Golden Horse Cab Company. Si no cumple, quedará excluido permanentemente de nuestro servicio’”
Dice “si la base de conocimiento es menor de 200,000 tokens (unas 500 páginas)”, pero ojalá Anthropic simplemente publicara el tokenizador. Así no habría que adivinar
Estoy esperando el día en que toda la industria de IA dé una vuelta completa y termine regresando a TF-IDF