RAG para empresas: cuándo conviene y cuándo no
RAG para empresas (Retrieval-Augmented Generation, o generación aumentada por recuperación) es una arquitectura que conecta un modelo de IA con los documentos reales de tu empresa: antes de responder, el sistema busca los fragmentos relevantes en tu información y el modelo genera la respuesta basándose en eso, citando la fuente en vez de inventar. Hasta ahí llegan casi todas las guías. Ninguna te ayuda a decidir si TU caso lo necesita. En Duotach construimos RAG en producción y también resolvimos casos donde hubiera sido gastar de más: este artículo es el framework de decisión que usamos nosotros.
Qué es RAG, en corto (lo único que necesitás saber del pipeline)
El pipeline de un sistema RAG tiene cuatro pasos. Es la técnica detrás de la mayoría de las bases de conocimiento con IA para empresas:
Ingestión
Tus documentos (políticas, manuales, contratos, procesos) se dividen en fragmentos.
Indexado
Cada fragmento se convierte en un embedding (una representación numérica de su significado) y se guarda en un índice consultable.
Recuperación
Cuando alguien pregunta, el sistema busca los fragmentos más relevantes para esa consulta, no todo el corpus.
Generación
El modelo de IA recibe la pregunta más los fragmentos recuperados y redacta la respuesta apoyándose en ellos, con referencia a la fuente.
Si querés la explicación larga del mecanismo, la guía de AWS sobre RAG es la referencia canónica. Pero entender el pipeline no es tomar la decisión. La decisión son los cinco criterios que siguen.
Los 5 criterios para decidir si tu empresa necesita RAG
Estos son los criterios que revisamos antes de proponerle RAG a un cliente. Ninguno alcanza solo; la decisión sale de mirar los cinco juntos.
1. Volumen de documentos
Los modelos actuales aceptan mucho contexto directo: los modelos de Anthropic llegan hasta 1 millón de tokens por consulta, según su documentación oficial. Un manual de procedimientos completo, o varios, entran en una sola conversación. Pero esa misma documentación advierte el límite: a medida que crece el contexto, la precisión y la memoria del modelo se degradan (el fenómeno se conoce como context rot). Regla práctica: si tu corpus son decenas de documentos, el contexto directo compite; si son miles de documentos o crece sin techo, la recuperación selectiva deja de ser opcional.
2. Frecuencia de actualización
Un corpus estable (el manual de onboarding que cambia dos veces al año) se puede cargar a mano cada vez que cambia. Un corpus vivo (precios, stock, políticas que se corrigen todas las semanas, actas de reuniones nuevas) necesita un pipeline de ingestión que indexe lo nuevo de forma automática. RAG está diseñado exactamente para eso: actualizás el índice, no el modelo. Si tu información cambia más rápido de lo que alguien puede copiarla y pegarla, ese es un punto para RAG.
3. Trazabilidad de fuentes
Este criterio pesa más de lo que parece, y es el que las guías educacionales suelen saltear. Si cada respuesta necesita una cita verificable ("esto sale de la política de compras, sección 4"), RAG lo da de forma nativa: la respuesta llega con los fragmentos que la respaldan. Para decisiones operativas, compliance, RRHH o cualquier contexto donde "el sistema me lo dijo" no alcanza como justificación, la trazabilidad sola puede justificar RAG aunque el corpus sea chico.
4. Permisos y multiusuario
Si toda la empresa puede ver todos los documentos, cualquier arquitectura sirve. Si finanzas no puede ver lo de RRHH y un externo no puede ver nada de lo interno, necesitás filtrar qué recupera el sistema según quién pregunta. El contexto directo no filtra por usuario: lo que está en el prompt, está para todos. Un índice con metadata de permisos sí. Empresas de 50 empleados para arriba casi siempre caen de este lado.
5. Costo por consulta
La economía es aritmética simple: las API de modelos de IA cobran por token procesado. Mandar un corpus de 500.000 tokens en cada consulta cuesta más de 100 veces lo que cuesta recuperar los 3.000-5.000 tokens relevantes y mandar solo eso. Con 5 consultas por día la diferencia es anecdótica; con cientos de consultas diarias de todo el equipo, el costo por consulta domina la decisión. RAG existe, en parte, porque nadie quiere pagar el corpus completo en cada pregunta.
Regla de decisión: si tu caso marca dos o más criterios del lado de RAG (corpus grande o creciente, actualización frecuente, citas obligatorias, permisos por rol, volumen alto de consultas), RAG se justifica. Si no marca ninguno, casi seguro hay una alternativa más simple y más barata.
Las alternativas que casi nadie te cuenta
Los artículos escritos por vendors de RAG rara vez mencionan que RAG compite contra opciones más simples. Estas son las tres que evaluamos siempre antes de proponer un build.
Contexto directo: la opción cero
Para un corpus chico y estable (decenas de documentos que casi no cambian), la solución honesta es no construir nada: cargás los documentos en el contexto del modelo (un proyecto de Claude, por ejemplo) y listo. Cero infraestructura, cero mantenimiento, resultado inmediato. La evidencia académica respalda esta opción para corpus acotados: la evaluación Long Context vs RAG de arXiv muestra que con contexto suficiente, darle los documentos directo al modelo compite con la recuperación e incluso la supera en preguntas que requieren leer el documento entero. El límite: sin trazabilidad estructurada, sin permisos por usuario, y con el costo y la degradación creciendo junto con el corpus.
Búsqueda tradicional + un agente con herramientas
Existe una postura contrarian en este debate que vale la pena tomar en serio: webvise sostiene que la mayoría de las bases de conocimiento empresariales no necesitan RAG. Su argumento: para un corpus de texto plano de unos cientos de documentos (ellos ponen el umbral cerca de los 1.000), un índice mantenido a mano más comandos de búsqueda simples es más barato de operar y más preciso que un pipeline RAG típico, y hasta conceden que RAG sigue siendo la elección correcta para corpus multimodales, actualización de alta frecuencia y filtrado estricto por metadata.
Nuestra posición, después de construir ambos escenarios: tienen razón a medias. El patrón "búsqueda full-text + un agente que sabe usar herramientas de búsqueda" funciona muy bien para documentación técnica interna curada. Pero el conteo de documentos es solo uno de los cinco criterios. En una empresa mediana real, la trazabilidad y los permisos suelen pesar más que el tamaño del corpus, y ahí el índice manual se queda corto mucho antes de los 1.000 documentos. Además, "mantenido a mano" presupone que alguien lo mantiene, y ese supuesto es justo el que falla en la mayoría de las empresas que conocemos.
Fine-tuning: por qué casi siempre lo descartamos
El fine-tuning (reentrenar el modelo con tus datos) aparece en todas las comparativas y en la práctica casi nunca es la respuesta para conocimiento empresarial, por tres razones:
- •El conocimiento queda congelado en los pesos del modelo. Cambió la política de precios: hay que reentrenar. Con RAG, actualizás un documento en el índice.
- •No hay cita de fuente. El modelo "sabe" la respuesta pero no puede decirte de qué documento salió, así que perdés la trazabilidad completa.
- •Cuesta más y requiere más expertise que cualquiera de las otras opciones, para un resultado peor en este caso de uso.
El fine-tuning sirve para otra cosa: enseñarle a un modelo un estilo, un formato de salida o un comportamiento específico. Para hechos que cambian, no.
Tabla de decisión
| Criterio | Contexto directo | Búsqueda + agente | RAG |
|---|---|---|---|
| Volumen que soporta | Decenas de docs | Cientos de docs | Miles de docs o más |
| Actualización frecuente | Manual, no escala | Requiere mantenimiento a mano | Ingestión automática |
| Trazabilidad de fuentes | Débil | Parcial (devuelve el archivo) | Nativa (cita el fragmento) |
| Permisos por usuario | No | Limitado | Sí, por metadata |
| Costo por consulta | Alto si el corpus crece | Bajo | Bajo (solo lo relevante) |
| Complejidad del build | Ninguna | Baja | Media |
Los errores comunes al implementar RAG
Cuando RAG sí se justifica, la implementación es donde se pierde o se gana el proyecto. Estos son los errores que más vemos, en orden de daño:
Indexar documentación desactualizada o duplicada
El error número uno no es técnico: es de contenido. Si el índice tiene tres versiones de la misma política, el sistema recupera basura y responde basura con total confianza. La limpieza del corpus va antes que cualquier decisión de arquitectura.
Chunking ciego
Cortar los documentos por cantidad fija de caracteres, ignorando títulos, secciones y tablas, produce fragmentos que no se entienden solos. La recuperación devuelve pedazos sin contexto y la calidad de respuesta se derrumba.
No medir la calidad del retrieval
Casi todos evalúan la respuesta final y nadie mira qué fragmentos recuperó el sistema. Si la recuperación trae los documentos equivocados, el mejor modelo del mundo responde mal. Se mide por separado.
Elegir la vector database antes que el problema
Empezar el proyecto discutiendo qué base vectorial usar es empezar por el final. Primero el corpus, los permisos y las consultas reales; la infraestructura sale de eso.
Nadie es dueño de la base de conocimiento
Sin un responsable y un proceso de actualización definido, el sistema envejece: seis meses después responde con la información de hace seis meses.
Tratarlo como proyecto de una sola vez
Un RAG se ajusta con consultas reales después del deploy: qué preguntas falla, qué documentos faltan, qué fragmentos se recuperan mal. Sin esa fase de ajuste, queda a mitad de camino.
Si querés el proceso completo de construcción paso a paso (fuentes, estructura, deploy, permisos), lo documentamos en cómo crear una base de conocimiento con IA.
Qué pinta tiene un RAG bien hecho en producción
La teoría se verifica con un caso real. En Ecuador construimos una base de conocimiento con IA sobre AWS para Acatha, una empresa con un problema clásico: documentación dispersa entre archivos, mails y personas, y consultas internas que dependían de que alguien supiera dónde estaba la información.
Lo que quedó funcionando, y por qué cada pieza importa para el framework de este artículo:
- Un agente que responde en lenguaje natural citando la fuente interna, en vez de inventar. La trazabilidad (criterio 3) no fue un extra: era el requisito que hacía útil al sistema.
- Todo desplegado sobre AWS, con la información de la empresa en su propia nube. La data no salió a un SaaS de terceros; el sistema corre en la infraestructura del cliente.
- Claude más embeddings y recuperación como stack: el pipeline RAG de manual, sin piezas exóticas.
- Implementación por fases: relevamiento de procesos y documentación, automatización de lo repetitivo, montaje de la base de conocimiento, y ajuste con consultas reales antes del traspaso. Esa última fase es el antídoto del error 6.
- Operado por el equipo del cliente. Documentamos el sistema para que ellos lo mantengan y lo amplíen sin depender de nosotros, que es la respuesta al error 5.
El resultado operativo: consultas internas respondidas 24/7 por el agente y una fuente única de verdad para políticas y procesos, en lugar de perseguir a la persona que sabía dónde estaba el archivo.
De ese proyecto sale nuestro checklist de "RAG bien hecho": respuestas con cita a la fuente, data en la infraestructura del cliente, proceso de actualización definido, y el equipo del cliente operándolo. Si una propuesta de RAG no incluye esas cuatro cosas, falta la mitad del proyecto.
La decisión antes que la arquitectura
El framework completo en tres líneas: RAG se justifica cuando marcás dos o más de los cinco criterios (corpus grande o creciente, actualización frecuente, trazabilidad obligatoria, permisos por rol, volumen alto de consultas). Si no marcás ninguno, contexto directo o búsqueda más agente resuelven lo mismo con menos plata. Y el fine-tuning, para conocimiento empresarial, casi nunca es la respuesta.
¿Estás evaluando esta decisión para tu empresa? La conversación es corta: nos contás qué documentación tenés, quién la consulta y cada cuánto cambia, y te decimos honesto qué arquitectura corresponde, incluso si la respuesta es "no necesitás RAG".
Preguntas Frecuentes
¿Qué es RAG para empresas?+
¿Cuándo NO conviene usar RAG?+
¿RAG elimina las alucinaciones?+
¿Qué diferencia hay entre RAG y fine-tuning?+
¿Cuánto cuesta implementar RAG en una empresa?+
¿Cuánto tarda implementarse un RAG?+
Artículos Relacionados
Base de conocimiento con IA para empresas: qué es y cómo tener la tuya
Qué es una base de conocimiento con IA, cuándo comprar un SaaS y cuándo construirla sobre tu infraestructura. Con un caso real sobre AWS en Ecuador.
Cómo crear una base de conocimiento con IA: proceso real
Cómo crear una base de conocimiento con IA en 6 pasos: fuentes, arquitectura RAG, implementación en tu nube, pruebas y mantenimiento. Con un caso real.
Agentes de IA con Claude Code: qué son y cómo se usan
Cómo funcionan los agentes y subagentes de Claude Code, casos de uso reales y cómo aplicarlos en automatización empresarial.