RAG estricto vs RAG genérico

El término RAG está roto

RAG significa Retrieval Augmented Generation. La idea es elegante: antes de responder, el modelo consulta una base de conocimiento y usa ese contexto para generar la respuesta. En el papel, suena infalible. En producción, hay dos implementaciones que se llaman igual y se comportan distinto: RAG genérico y RAG estricto.

RAG genérico

La arquitectura por defecto. Se embebe el corpus en un vector store, se hace búsqueda semántica, los top-k chunks entran al prompt, y el modelo responde con esa información como sugerencia. El problema: el modelo se siente libre de complementar con su conocimiento general cuando “cree” que ayuda.

Ese rasgo lo vuelve fascinante para chatbots de marketing y peligroso para operaciones reguladas. Dice cosas verdaderas con la misma cadencia con la que dice cosas inventadas. Cuando un asesor cooperativo cita una tasa o un abogado cita un fallo, la diferencia entre verdad y alucinación deja de ser estética: es legal.

RAG estricto

La arquitectura que usamos cuando la respuesta vive bajo una norma. Tres reglas no negociables:

• Cita obligatoria. Cada afirmación factual debe rastrearse al chunk que la sostuvo. Si no hay fuente, el agente dice “no encontré la información”.
• Sin completar con conocimiento general. El modelo no agrega lo que cree saber. Si el corpus no lo cubre, el caso se escala.
• Trazabilidad exportable. Cada respuesta queda firmada en el audit ledger con la lista de chunks consultados y el hash del documento fuente.

Cuándo cada uno tiene sentido

RAG genérico funciona bien para discovery y soporte de primera línea donde la respuesta correcta es “lo más parecido posible”. Es rápido de implementar y conversacional. La barra: el costo del error es bajo y el usuario tolera que el agente recomiende verificar con un humano.

RAG estricto se vuelve obligatorio en derecho tributario, cumplimiento financiero, producto regulado, salud y cualquier dominio donde el cliente final exige defenderse ante un auditor. No es un upgrade opcional: es un cambio de contrato con el modelo.

Lo que cuesta cambiar

RAG estricto pide más trabajo de chunking, más metadatos en el corpus, evaluaciones continuas y un agente que sepa decir “no sé” con la misma fluidez con la que responde. La inversión se paga el primer caso que pasa por auditoría sin un solo dato no soportado por la fuente.

La regla de campo es directa: si tu cliente algún día puede tener que demostrar de dónde salió una respuesta, elige RAG estricto desde el día cero. Convertir un RAG genérico a estricto en producción cuesta más que diseñarlo bien.