Muchas empresas empiezan un proyecto RAG con la pregunta equivocada: “¿Qué modelo usamos?” o “¿En qué herramienta lo montamos?”. La pregunta correcta es mucho menos glamourosa: ¿qué conocimiento interno merece ser recuperable y con qué nivel de riesgo?
Si el conocimiento de la empresa no está bien gobernado, un RAG no lo ordena: solo le da una interfaz más convincente.
Un RAG útil no convierte la documentación en inteligencia mágica. Lo que hace es reducir el tiempo entre una duda operativa y una respuesta que pueda usarse de forma segura. Para eso, no basta con indexar documentos. Hay que decidir qué entra, qué sale y qué se hace cuando el sistema no sabe.
El caso real: respuestas rápidas, decisiones lentas
Pensemos en una empresa mediana con ventas, operaciones y soporte repartidos entre ERP, SharePoint, correos y tickets. Cada área guarda información en su propio formato. Cuando alguien pregunta “¿cómo gestionamos una devolución fuera de plazo?” o “¿qué pasa si un cliente premium abre un ticket crítico?”, la respuesta existe, pero está dispersa.
El primer impulso suele ser juntar todo y montar un chatbot. El resultado habitual es peor de lo esperado: el sistema responde con seguridad aparente, mezcla versiones antiguas con las actuales y da respuestas útiles solo en una parte de los casos. El problema no es el modelo. El problema es que el conocimiento no tiene jerarquía.
Un RAG bien planteado debe ayudar en escenarios concretos, por ejemplo:
- consultas repetitivas de soporte interno,
- reglas de operación que cambian con frecuencia,
- acceso rápido a políticas y procedimientos vigentes,
- búsqueda de evidencias en tickets y documentación técnica.
Si el caso de uso no tiene un volumen repetido o un coste de error claro, el proyecto suele convertirse en una demo cara.
Qué fuentes sí y cuáles no
Aquí está la primera decisión seria: no todas las fuentes deben entrar en el índice. La mayoría de fallos de RAG vienen de querer meterlo todo.
Fuentes que suelen funcionar bien:
- manuales internos versionados,
- procedimientos aprobados,
- base de conocimiento de soporte,
- documentación técnica controlada,
- FAQs validadas por negocio.
Fuentes que hay que tratar con mucho cuidado:
- correos,
- chats informales,
- notas personales,
- documentos sin propietario,
- archivos desactualizados sin control de versión.
No significa que sean inútiles. Significa que su valor es contextual, no normativo. Un error frecuente es permitir que el sistema cite un correo como si fuera una política. Eso genera una ilusión de precisión que luego se paga en operación.
Un criterio práctico: si una fuente puede cambiar una decisión de cliente, cumplimiento o dinero, debe tener propietario, fecha de vigencia y revisión explícita. Si no, no debería responder sola.
Mini-caso: cuando el asistente sabía demasiado
Una empresa de servicios con varias unidades quería reducir el tiempo que el equipo de operaciones dedicaba a buscar respuestas en documentación interna. Se cargaron manuales, tickets históricos y notas de proyectos en un RAG piloto.
En las pruebas iniciales, el sistema parecía útil. Pero al revisar casos reales, aparecieron tres problemas:
- devolvía procedimientos ya retirados,
- mezclaba criterios de dos equipos distintos,
- contestaba incluso cuando la documentación era ambigua.
La corrección no fue “afinar el prompt”. Fue reordenar el proyecto: se limitó el corpus a documentos vigentes, se separaron fuentes por dominio, se añadieron etiquetas de confianza y se obligó al sistema a responder con “no encontrado” si la evidencia no era suficiente.
El valor real apareció después: menos tiempo perdido buscando, menos escalados innecesarios y menos respuestas inventadas. No porque la IA fuera más “inteligente”, sino porque se le permitió ser menos temeraria.
El error incómodo: querer que responda a todo
Aquí está la parte que muchos equipos no quieren oír: un buen RAG debe negarse a responder con frecuencia.
Eso incomoda porque parece una mala experiencia de usuario. En realidad, es una buena señal de control. Si el sistema responde a todo, normalmente está extrapolando. Y en operaciones, extrapolar es otra forma de inventar.
La decisión más útil suele ser establecer tres comportamientos:
- responder con cita y fuente cuando la evidencia es fuerte,
- pedir aclaración cuando falta contexto,
- escalar a una persona cuando el riesgo es alto o la respuesta no es unívoca.
También conviene aceptar que no todo problema necesita generación. A veces basta con una búsqueda mejorada y filtrada. El RAG no debe convertirse en un sustituto de la gobernanza documental.
Señales de que el proyecto está bien planteado
Antes de escalar, hay señales que importan más que la demo:
- las respuestas se basan en fuentes vigentes y visibles,
- el sistema muestra cuándo no tiene suficiente evidencia,
- los usuarios dejan de preguntar por canales humanos para temas repetitivos,
- las áreas dueñas de contenido revisan y corrigen el corpus,
- las respuestas erróneas se pueden rastrear hasta una fuente concreta.
Si no puedes auditar una respuesta, no tienes un asistente de conocimiento; tienes una caja negra con interfaz amable.
Conclusión
Un RAG para conocimiento interno no se gana por usar el modelo más nuevo, sino por definir bien el perímetro, la calidad documental y el comportamiento ante la duda. La diferencia entre una prueba interesante y una herramienta operativa está en la disciplina de contenido, no en el brillo de la IA. En Codefuente solemos empezar por ese mapa de decisiones antes de construir nada, porque en conocimiento interno el orden importa más que la ambición.