Siete arquitecturas RAG más allá del enfoque ingenuo y cuándo resultan adecuadas cada una.

El primer pipeline RAG que construyen la mayoría de las personas es sencillo: se dividen los documentos en fragmentos, se generan embeddings, se obtienen las pocas coincidencias principales, se incluyen en el prompt y se deja que el LLM responda. La demostración funciona y las respuestas suenan convincentes. Pero luego llegan las preguntas reales: vuelve el fragmento incorrecto, aparece el documento correcto pero no el pasaje necesario. A veces la información está en la base de datos, pero el modelo nunca llega a verla.

Lo extraño es que ningún componente está defectuoso. La cadena de procesamiento hace exactamente lo para lo que fue diseñada. Los tutoriales rara vez enfatizan la lección real: llenar una base de datos vectorial es fácil, mientras que poner la información adecuada frente al modelo es el problema difícil. Ese primer diseño es un RAG ingenuo. Tiene usos, al ser el punto de partida natural, pero cuando los documentos se vuelven complicados, las preguntas más difíciles o la fiabilidad es importante, un ciclo de recuperación y respuesta alcanza sus límites. Le siguen siete arquitecturas más avanzadas, cada una con el problema que resuelve, sus posibles puntos de fallo y una forma de determinar si un sistema dado lo necesita.

Por qué existe RAG

Un LLM solo conoce lo que aprendió durante su entrenamiento. Si se le pregunta sobre documentos internos de la empresa o eventos recientes, o bien admite su ignorancia o, peor aún, inventa una respuesta segura. RAG soluciona este problema de manera similar a permitir que un estudiante lleve notas al examen. El sistema primero encuentra el material relevante y lo utiliza como referencia, de modo que el modelo no necesita responder únicamente con base en su memoria.

El flujo básico es el siguiente.

Cuando un usuario hace una pregunta, el sistema sigue cuatro pasos:

1. Buscar en la base de conocimientos externa material relevante
2. Recuperar los fragmentos que mejor se ajusten
3. Añadir esos fragmentos al mensaje junto a la pregunta
4. Enviar todo al LLM, que redacta la respuesta a partir de ese contexto

En resumen: pregunta, búsqueda, recuperación, adición de contexto, LLM, respuesta. Esto funciona bien para conjuntos de documentos pequeños y ordenados. Los datos reales rara vez se comportan así, y suelen surgir cinco debilidades:

• Los fragmentos pierden el contexto. Un extracto que indica que los ingresos aumentaron un 3% no revela qué empresa o trimestre se refiere.
• Se pierde información. Las tablas, gráficos y páginas escaneadas a menudo no sobreviven a la recuperación basada en texto.
• La primera búsqueda puede ser incorrecta, y el RAG básico no se detiene para intentar otra.
• Las conversaciones anteriores desaparecen. Al no tener memoria, cada sesión comienza desde cero.
• Los hechos permanecen desconectados. Cuando la información está distribuida en varios documentos, puede ser necesario vincularla antes de que una respuesta tenga sentido.

Estos no son cinco problemas aleatorios. Explican por qué existen arquitecturas diferentes, y cada uno de ellos aborda un fallo específico en el proceso básico.

1. Notas de los fragmentos contextuales

Antes de almacenar un fragmento, se adjunta una breve nota que indica de qué trata, para que siga teniendo sentido incluso después de salir de su documento original. Imagina arrancar un párrafo de un libro y entregárselo a un desconocido sin título ni número de capítulo: no podrán saber a qué se refiere. Ahora, adjunta primero una nota que indique que proviene del Capítulo 4, sobre los resultados financieros del segundo trimestre de la empresa. Esa es toda la idea.

El fragmento en bruto indica que los ingresos aumentaron un 3% respecto al trimestre anterior, sin especificar la empresa ni el año. Con una nota adjunta, queda claro que proviene del informe del segundo trimestre de 2023 de ACME Corp, seguido de la misma oración.

Raw chunk:        "revenue grew 3% over the previous quarter"
                   -> which company? which year? unclear

With a note attached:  "From ACME Corp's Q2 2023 filing.
                        Revenue grew 3% over the previous quarter."
                   -> now it makes sense on its own

La ventaja es que los fragmentos recuperados tienen sentido por sí solos, y el método de búsqueda en sí permanece intacto, ya que solo cambia lo que se almacena. La desventaja es el costo: una nota por fragmento requiere tiempo y dinero incluso antes de que pueda comenzar la búsqueda, y una nota mal redactada puede dirigir la búsqueda por el camino equivocado con la misma facilidad que una bien redactada la dirige correctamente.

2. Recuperación multimodal

A menudo los documentos no son texto plano en absoluto. Convertir una página PDF a texto y buscar en ella puede dañar tablas y gráficos, por lo que la alternativa es permitir que el sistema vea la página como una imagen. Compare leer la descripción de alguien sobre un gráfico con ver el gráfico en sí. Una descripción puede omitir detalles o dar números incorrectos, mientras que el original no lo hace.

En el flujo tradicional, se extrae una página PDF en texto, se intenta adivinar la estructura de la tabla y luego se busca en ese texto, por lo que los números y la estructura pueden desordenarse durante el proceso. En el flujo multimodal, se busca directamente en la página como si fuera una imagen.

Old way:  PDF page -> extract text -> guess at the table layout -> search the text
          (numbers and structure can get scrambled along the way)

Multimodal way:  PDF page -> search the page as an image directly
                 (the table stays a table, the chart stays a chart)

Esto permite manejar tablas, gráficos y escaneos que distorsionan la extracción de texto, además de eliminar un paso delicado del proceso. Los costos son un cálculo más intensivo que en la búsqueda de texto plano, y el ecosistema es más reciente, con menos herramientas y menor conocimiento comunitario.

3. Búsqueda híbrida

Funcionan juntos dos tipos de búsqueda: una que comprende el significado y otra que busca palabras exactas, y se combinan sus resultados. Imagina a dos bibliotecarios: uno entiende lo que quieres decir incluso cuando tu redacción no es precisa; el otro no tiene sentido del contexto pero siempre localizará el documento que contiene el código específico que escribiste. La idea es contar con ambos.

Toma la consulta “error E0502 borrow checker”. La búsqueda basada en el significado encuentra documentos sobre un concepto relacionado incluso sin la frase exacta, mientras que la búsqueda de palabras exactas localiza la cadena literal “E0502”; el resultado combinado fusiona ambos enfoques.

Query: "error E0502 borrow checker"

Meaning-based search:   finds docs about a similar concept, even without that exact phrase
Exact-word search:      finds the literal string "E0502"
Combined:               merges both into one final list

Una sola búsqueda abarca tanto las preguntas conceptuales generales como los términos técnicos precisos, lo que soluciona un problema común: la búsqueda basada únicamente en el significado suele ser inadecuada con códigos, identificadores y jerga. El costo es tener que operar con dos sistemas de búsqueda, y decidir cuánto peso merecen los resultados de cada uno requiere un ajuste cuidadoso.

4. Búsqueda de estilo gráfico y de mapa

En lugar de almacenar fragmentos aislados, este enfoque muestra cómo se conectan las personas, empresas e ideas dentro de los documentos, agrupa a las relacionadas y prepara de antemano un breve resumen para cada grupo. Cuando una pregunta es demasiado amplia para cualquier fragmento individual, el sistema recurre a esos resúmenes de grupo e incluso puede decidir por sí mismo qué grupos merecen ser analizados.

Digamos que alguien quiere conocer los temas principales de todo lo publicado este año. Ningún artículo individual responde a esa pregunta. Si la organización estuviera dividida en departamentos, cada uno con un resumen de una página sobre su trabajo, leer solo esas páginas permitiría obtener la respuesta rápidamente. Ese es el mapa. Una variante más inteligente funciona como un asistente que primero determina qué departamentos son relevantes para la pregunta, en lugar de leer todos los resúmenes sin discriminación.

El proceso consta de dos pasos. Primero, se crea el mapa una sola vez, con antelación: se determina cómo se conectan las personas y las ideas, se agrupan los elementos relacionados y se escribe un resumen por grupo. Segundo, se responde a una pregunta general a partir de esos resúmenes.

Step 1, build the map (done once, ahead of time):

  Documents -> find how people/ideas connect -> group related ones
            -> write a short summary for each group

Step 2, answer a broad question:

  "What are the big themes here?"
  -> pick the relevant groups (a smart version does this pick automatically)
  -> read just their summaries -> combine into one answer

Ventajas: se responden preguntas temáticas complejas cuando ningún fragmento por sí solo puede hacerlo, se pueden rastrear las conexiones entre muchos documentos al mismo tiempo, y la versión de selección automática omite los resúmenes que no son relevantes. Desventajas: se necesita un proyecto real para crear el mapa, algunas partes deben reconstruirse cada vez que los documentos cambian significativamente, y el paso de selección de grupos es otro lugar donde el sistema podría tomar decisiones erróneas.

5. Recuperación iterativa y por agentes

Un mapa responde a las preguntas generales, pero algunas requieren varias búsquedas, por buen que sea el mapa. En este caso, el sistema busca, examina los resultados obtenidos, decide si son suficientes y repite el proceso si es necesario. Compare un motor de búsqueda con un asistente de investigación: el motor devuelve una lista y se detiene, mientras que el asistente lee los resultados, ve que no son suficientes y vuelve a buscar más información, utilizando lo aprendido para realizar búsquedas de manera más eficaz la segunda vez.

El ciclo funciona así: llega una pregunta, se realiza una búsqueda y el sistema verifica si es suficiente. Si no lo es, vuelve a buscar con la información obtenida anteriormente; y si eso tampoco funciona, prueba otro enfoque.

Question comes in
     -> Search once -> "Is this enough to answer?"
     -> No: search again, using what was just learned
     -> No, still not enough: search again, from a different angle
     -> Yes: now answer

Se encarga de las preguntas que realmente requieren múltiples búsquedas y no se detiene tras una búsqueda fallida, a diferencia de un pipeline fijo. El costo consiste en otro viaje de ida y vuelta por cada búsqueda adicional, lo que aumenta los gastos y el tiempo de espera; además, un enfoque mal elegido puede hacer necesarias varias tentativas antes de que se detecte el error.

6. Recuperación con múltiples agentes

Aquí un sistema no planifica, busca, verifica ni escribe todo por sí solo. Esas tareas se dividen entre sistemas más pequeños y especializados, cada uno dedicado a una función específica, bajo la gestión de un coordinador que supervisa todo el proceso. Una sola persona que investigue, escriba y verifique al mismo tiempo tiende a realizar un trabajo mediocre en todos los aspectos. Un equipo pequeño, con una persona encargada de la planificación, otra de la investigación, otra de la verificación y otra de la redacción, suele obtener mejores resultados en cada tarea.

Llega una pregunta, un planificador decide qué se debe buscar, los investigadores van a encontrarlo, a veces desde diferentes fuentes al mismo tiempo, y un revisor verifica los resultados para asegurar su precisión.

Question comes in
  -> Planner decides what needs to be looked up
  -> Searchers go look, sometimes from different sources at the same time
  -> Checker reviews what came back for accuracy
  -> Writer puts together the final answer

Cada parte del trabajo recibe toda la atención necesaria en lugar de que un solo sistema se ocupe de todo, y las búsquedas en paralelo ahorran tiempo. Por otro lado, más sistemas que colaboran aumentan el costo por pregunta, y es necesario un esfuerzo real para rastrear una respuesta final incorrecta a través de varios pasos.

7. Búsqueda basada en memoria

En este diseño, el sistema no solo busca en un conjunto fijo de documentos, sino también en su propia historia con el usuario, tratando las conversaciones anteriores como algo del que se puede echar mano en lugar de olvidarlo una vez terminan. Piense en un médico que lee su historial médico antes de cada consulta, en contraste con uno que le pide que relate toda su historia médica cada vez. La mayor parte de lo que dijo en la última consulta sigue estando en alguna carpeta, y un buen sistema hace lo mismo: mantiene a mano el material importante y lo consulta cuando es relevante.

Permite a un sistema recordar cosas mencionadas días o semanas antes sin tener que cargar todo al mismo tiempo, y ayuda con cualquier asunto personal o continuo, más allá de búsquedas puntuales de documentos. Las desventajas son un sistema de memoria adicional que se superpone a la búsqueda de documentos, lo que implica más componentes en funcionamiento, y el hecho de que los recuerdos antiguos a veces se compriman o resuman para ahorrar espacio, por lo que pueden perderse los detalles.

Elegir

Naive RAG falla de forma silenciosa. Nunca se cae ni genera errores. Los usuarios simplemente reciben respuestas basadas en información incorrecta, y todo parece estar bien hasta que alguien lo verifica.

Cada arquitectura mencionada anteriormente existe porque alguien atribuyó una respuesta incorrecta a una causa específica y corregible. Por lo tanto, la opción más reciente no es automáticamente la que debe elegirse. Elija la que se ajuste a la forma en que falla el proceso de recuperación de información. Analice el flujo actual y pregúntese con sinceridad: cuando da una respuesta errónea, ¿la búsqueda encontró algo incorrecto, algún fragmento perdió su contexto, o el sistema nunca revisó la información una segunda vez? Esa sola pregunta indica cuál es la arquitectura necesaria a continuación.