RAG en empresas: cuándo usarlo y cuándo evitarlo
RAG funciona bien cuando la respuesta depende de documentos privados, cambiantes o demasiado extensos para entrar completos en el prompt. No sustituye la gestión documental: la pone a prueba.
Antes de montar embeddings, bases vectoriales y prompts, conviene saber si el problema real es recuperación de información, permisos, versiones duplicadas o expectativas equivocadas.
El problema que RAG si puede resolver
Un RAG empresarial sirve cuando la respuesta depende de informacion privada, cambiante o demasiado extensa para meterla entera en el prompt. El modelo razona y redacta; el sistema de recuperacion decide que evidencias entran en contexto.
La promesa es atractiva: respuestas con fuentes sobre manuales de Confluence, politicas en Google Drive, contratos en SharePoint, tickets de Jira o documentación técnica en GitHub. Pero el sistema solo funciona si la recuperacion es buena.
Señales de que RAG encaja
- Los usuarios ya buscan en documentos internos y pierden tiempo localizando respuestas.
- La informacion cambia con frecuencia y no conviene reentrenar modelos.
- La respuesta debe citar documentos o secciones concretas.
- Existen permisos por equipo, cliente o región que deben respetarse.
- El volumen documental es alto, pero tiene estructura minima.
Cuando RAG suele fallar
- Documentos duplicados con versiones contradictorias.
- PDFs escaneados sin OCR fiable.
- Chunks demasiado grandes o demasiado pequeños.
- Busqueda semantica sin filtros por fecha, producto o permisos.
- Usuarios esperando que el sistema adivine informacion que no existe en la base.
Arquitectura minima viable
Ingestion
Extrae texto, conserva metadatos, versiona documentos y elimina duplicados. Sin esta capa, los embeddings solo indexan ruido.
Retrieval con filtros de negocio
Combina busqueda semantica con filtros estructurados. pgvector, Pinecone, Weaviate o Azure AI Search no compensan metadatos pobres: producto, fecha, cliente, permisos y versión suelen ser tan importantes como el vector.
Respuesta
El prompt debe obligar a citar fuentes y reconocer ausencia de evidencia. La respuesta bonita sin trazabilidad no sirve para decisiones.
Evaluacion
Mide precision de recuperacion, respuestas sin fuente, alucinaciones y satisfaccion del usuario por caso de uso.
Ejemplo real: Confluence, SharePoint y permisos por equipo
Una empresa con manuales en Confluence y contratos en SharePoint no necesita solo embeddings. Necesita conservar permisos, fecha de versión, propietario del documento y producto afectado. Sin esos metadatos, un comercial puede recibir una respuesta basada en una política antigua o en un documento que no deberia ver.
Que deberia quedar decidido antes de mover presupuesto
Despues de revisar esta guía, el siguiente paso no es adoptar la opcion más visible, sino escribir una decisión operativa: alcance, responsable, metrica, riesgo aceptable y fecha de revision. Esa disciplina separa una mejora real de otra iniciativa dificil de mantener.
Prueba mínima antes de invertir en plataforma
Un piloto RAG serio puede empezar con un conjunto pequeño: 200 documentos útiles, permisos claros y 30 preguntas frecuentes que hoy consumen tiempo al equipo. Si el sistema no recupera bien en ese escenario, añadir más documentos solo amplifica el ruido.
También hay que probar preguntas sin respuesta. Un buen RAG debe decir que no encuentra evidencia suficiente antes que fabricar una contestación convincente.
- Separa documentos vigentes de borradores o versiones antiguas.
- Conserva fuente, fecha, propietario y permisos en cada fragmento indexado.
- Evalúa la recuperación antes de evaluar la redacción final del modelo.
Criterios de decisión antes de construir un RAG
La decisión no debería empezar por Pinecone, Weaviate, Azure AI Search, pgvector o cualquier base vectorial. Empieza por tres preguntas: qué usuarios preguntan, qué documentos contienen la respuesta y qué riesgo tiene una respuesta incorrecta. Si esas tres piezas no están claras, el proyecto puede consumir semanas en infraestructura sin mejorar la búsqueda interna.
Un RAG empresarial merece inversión cuando hay conocimiento disperso pero recuperable: políticas internas, documentación de producto, contratos tipo, manuales de soporte, tickets cerrados o procedimientos operativos. Si el contenido está duplicado, sin propietario o mezclado con borradores, el primer trabajo es documental. El modelo no arregla una intranet desordenada; la hace más visible.
| Criterio | Señal favorable | Señal de riesgo |
| --- | --- | --- |
| Documentos | Hay fuentes vigentes, propietarios y fechas | PDFs escaneados, duplicados y versiones contradictorias |
| Permisos | Se puede filtrar por equipo, cliente o rol | Todo el índice queda visible para cualquiera |
| Preguntas | Existen consultas repetidas y medibles | El caso de uso es genérico o no tiene usuarios claros |
| Evaluación | Hay respuestas esperadas y fuentes correctas | Se valida solo con impresiones subjetivas |
| Operación | Alguien mantiene ingestion, logs y permisos | El sistema queda como una demo sin responsable |
Ejemplo concreto: soporte técnico con Confluence y Zendesk
Imagina un equipo SaaS con documentación en Confluence, tickets históricos en Zendesk y runbooks en GitHub. El objetivo no es que el asistente “sepa de todo”, sino que ayude a soporte de nivel 1 a responder incidencias repetidas: errores de facturación, límites de API, configuración de SSO y problemas de importación.
El piloto debería empezar con un conjunto pequeño: páginas vigentes de Confluence, tickets resueltos de los últimos seis meses y runbooks aprobados. Cada fragmento indexado necesita metadatos: producto, versión, fecha, propietario, visibilidad y fuente. Sin esos filtros, una respuesta sobre SSO de una versión antigua puede parecer correcta y ser peligrosa.
La evaluación puede hacerse con 40 preguntas reales. No basta con medir si la respuesta “suena bien”. Hay que comprobar si recupera la fuente correcta, si cita la versión adecuada, si reconoce ausencia de información y si evita mezclar clientes o permisos. En un entorno con datos sensibles, una respuesta sin control de permisos es un fallo de seguridad, no un simple error de búsqueda.
Errores comunes al implantar RAG
El primer error es indexarlo todo. Meter miles de documentos sin limpieza produce respuestas con fuentes pobres y contradicciones. Es mejor empezar con una colección pequeña y fiable que con una base enorme llena de ruido.
El segundo error es confundir embeddings con búsqueda completa. La búsqueda semántica ayuda con intención y lenguaje natural, pero no sustituye filtros por fecha, producto, idioma, cliente o permisos. En muchos casos, una combinación híbrida de búsqueda semántica, palabras clave y metadatos funciona mejor que vectores solos.
El tercero es no medir la recuperación por separado. Si el sistema recupera mal, el modelo redactará mal aunque sea potente. Conviene evaluar top 3 o top 5 documentos recuperados antes de mirar la respuesta final.
El cuarto es no diseñar respuestas negativas. Un buen RAG debe decir “no encuentro evidencia suficiente” cuando el índice no contiene la respuesta. En empresas, esa frase vale más que una alucinación elegante.
Métricas que separan un piloto serio de una demo
Las métricas útiles son concretas: porcentaje de preguntas con fuente correcta, respuestas sin evidencia, tiempo ahorrado por agente, tickets escalados correctamente, latencia media, coste por consulta y tasa de corrección humana. También interesa revisar qué documentos se recuperan demasiado y cuáles nunca aparecen.
Para tomar una decisión de continuidad, el piloto debería demostrar mejora en un flujo real. Por ejemplo: reducir escalados repetitivos en soporte, acelerar búsqueda de políticas internas o mejorar onboarding técnico. Si solo genera una interfaz bonita sobre documentos internos, todavía no hay producto.
Cuándo evitarlo
Conviene evitar RAG si el contenido cambia cada día sin control, si los permisos no están resueltos, si no hay preguntas repetidas o si la organización espera respuestas normativas sin revisión humana. También es mala señal usarlo para decisiones de alto riesgo sin auditoría: legal, salud, crédito, seguridad o cumplimiento requieren controles adicionales.
En esos casos, puede ser mejor empezar por ordenar documentación, mejorar el buscador existente, crear una base de conocimiento mantenida o automatizar clasificación de consultas antes de construir una capa generativa.
