Arquitecturas RAG en producción: del prototipo al sistema confiable

Un RAG básico se monta en una tarde: embeddings, una base vectorial, un prompt y listo. La parte difícil empieza cuando alguien pregunta algo que no está en los documentos, cuando el corpus cambia todas las semanas o cuando el costo por respuesta se duplica.

Este artículo resume el modelo mental que uso para llevar un sistema RAG de demo a producción. No es una receta única, pero sí una lista de decisiones que no conviene improvisar.

El prototipo es la parte fácil

Un flujo mínimo tiene cuatro piezas:

Documentos → Chunking → Embeddings → Vector DB
                                      ↓
Pregunta → Embedding → Retrieval → Prompt → LLM → Respuesta

En producción aparecen preguntas adicionales: ¿quién puede ver cada documento? ¿qué versión del corpus respondió? ¿cómo sé que la respuesta no alucina? ¿cuánto cuesta cada consulta? ¿qué pasa si el proveedor del modelo falla?

1. Ingesta y chunking: basura entra, basura sale

El chunking no es un detalle de implementación; define la calidad de la recuperación. Un chunk demasiado pequeño pierde contexto. Uno demasiado grande diluye la señal y gasta tokens.

En salud, por ejemplo, prefiero chunks por sección con metadatos de documento, versión, vigencia y nivel de acceso. El texto solo no basta: la procedencia es parte del dato.

2. Recuperación híbrida: vectores, pero también palabras

La búsqueda vectorial entiende similitud semántica, pero puede fallar con códigos, nombres propios o términos exactos. La búsqueda léxica sigue siendo valiosa.

SELECT id, contenido,
       1 - (embedding <=> :query_embedding) AS similitud
FROM documentos
WHERE vigente = true
  AND acceso_permitido(:usuario_id)
ORDER BY embedding <=> :query_embedding
LIMIT 20;

Una arquitectura común es recuperar candidatos con ambos métodos, fusionar resultados y aplicar un reranker. No siempre necesitas un modelo de reranking; a veces alcanza con reglas de negocio y filtros de metadata.

3. Generación con contexto controlado

El prompt debe hacer tres cosas: responder solo con el contexto recuperado, citar las fuentes y admitir cuando no hay información suficiente.

Eres un asistente técnico. Responde únicamente con la información
de los fragmentos proporcionados. Si la respuesta no está en el
contexto, dilo explícitamente. Incluye el identificador de cada
fragmento usado como cita.

Una respuesta que dice «no tengo información suficiente» es un resultado exitoso, no un fracaso. El objetivo no es impresionar; es ser confiable.

4. Evaluación: el testing de la era LLM

Sin evaluación, cada cambio de prompt es una apuesta. Necesitas un conjunto dorado de preguntas y respuestas, y métricas que se puedan ejecutar en CI.

• Retrieval recall: ¿el documento correcto aparece entre los candidatos?
• Faithfulness: ¿la respuesta se sostiene con el contexto?
• Answer relevance: ¿responde lo que se preguntó?
• Abstención: ¿dice «no sé» cuando debe?
• Costo y latencia: ¿sigue siendo viable?

5. Observabilidad y costos

Cada respuesta debería dejar un rastro: pregunta, chunks recuperados, versión del modelo, tokens de entrada y salida, latencia, costo y feedback del usuario. Sin eso, no puedes explicar una regresión ni justificar una factura.

Algunas prácticas que han funcionado:

• Cachear embeddings de documentos y consultas frecuentes.
• Limitar el número de chunks y el tamaño del contexto.
• Usar modelos pequeños para clasificación o extracción y reservar el modelo grande para la respuesta final.
• Separar el costo de ingesta del costo de consulta.
• Medir costo por respuesta resuelta, no solo por token.

Checklist para producción

1. Metadata y control de acceso en cada chunk.
2. Estrategia de chunking documentada y versionada.
3. Recuperación híbrida con filtros de negocio.
4. Prompt con citas y abstención explícita.
5. Set dorado de evaluación en CI.
6. Trazas por consulta y costo por respuesta.
7. Plan de actualización del corpus y de rollback del modelo.

RAG no es un producto que se instala; es un sistema que se cultiva. La calidad vive en los detalles aburridos: datos, permisos, evaluación y observabilidad.