Un RAG interno suele impresionar en la primera demo. Le preguntas por una política, una ficha técnica o un procedimiento y responde en segundos. El problema llega después, cuando deja de contestar a la pregunta bonita de la demo y empieza a recibir preguntas reales del equipo.
Ahí aparecen las grietas: documentos antiguos mezclados con nuevos, permisos demasiado amplios, respuestas que citan una fuente pero ignoran otra, casos donde debería decir "no lo sé" y no lo dice. No es un fallo raro. Es lo normal cuando se conecta IA a conocimiento interno sin una fase seria de pruebas.
Para una empresa de Donostia - San Sebastián, Gipuzkoa o Euskadi, un RAG privado puede ahorrar muchas búsquedas en carpetas, intranets, SharePoint, Drive, ERP o documentación técnica. Pero antes de abrirlo a ventas, operaciones, soporte o administración, conviene hacer una prueba menos vistosa y más útil: comprobar si responde bien cuando la pregunta viene torcida.
Este post propone una forma práctica de evaluar un RAG interno antes de enseñárselo a todo el equipo. Al final tienes un PDF descargable con una plantilla sencilla para preparar el test.
El error: probar solo con preguntas cómodas
Muchas pruebas de RAG empiezan con diez preguntas que ya sabemos contestar. Sirven para ver si el sistema funciona, pero no para decidir si se puede usar en trabajo real.
Un RAG de empresa no falla solo cuando no encuentra nada. Falla cuando encuentra algo parecido y lo presenta con demasiada seguridad. Falla cuando responde con una versión antigua de un procedimiento. Falla cuando recupera un documento correcto para una persona que no debería verlo. Falla cuando mezcla una política comercial con una excepción que solo aplica a un cliente concreto.
La evaluación tiene que buscar esos fallos a propósito. Mejor encontrarlos en una sala pequeña que en una conversación con un cliente.
Qué debe tener el banco de pruebas
No hace falta montar una auditoría eterna. Para un primer piloto, suele bastar con 30 o 40 preguntas bien elegidas. Lo importante es que no sean todas del mismo tipo.
Incluye preguntas normales, de las que el equipo haría cada semana. Añade preguntas ambiguas, con términos que puedan significar dos cosas. Mete preguntas con información incompleta. Prueba casos donde la respuesta está en dos documentos distintos. Y reserva varias preguntas para comprobar permisos: qué debería ver dirección, qué debería ver ventas, qué debería ver soporte y qué no debería ver nadie fuera de un grupo concreto.
También conviene incluir preguntas sin respuesta. Parece absurdo, pero es clave. Un asistente documental que no sabe decir "no encuentro una fuente suficiente" acabará inventando seguridad donde no la hay.
Cinco bloques de evaluación
1. Respuesta útil
La respuesta debe resolver la duda con lenguaje normal. No hace falta que sea larga. De hecho, si cada respuesta parece un informe, el equipo dejará de usarlo.
Puntúa si responde a la pregunta, si evita rodeos y si deja claro qué parte viene de los documentos. Cuando la pregunta no tenga respuesta fiable, debería decirlo sin adornos y proponer dónde mirar o a quién escalar.
2. Fuentes correctas
Un RAG no debería pedir fe. Debe mostrar de dónde saca la respuesta: procedimiento, contrato, ficha, política, ticket histórico o página interna.
Aquí revisa dos cosas. Primero, si la fuente citada realmente contiene la respuesta. Segundo, si el sistema recupera la versión adecuada. En empresas con documentación viva, este punto importa mucho. Un PDF viejo en una carpeta olvidada puede hacer más daño que una respuesta vacía.
3. Permisos
Este bloque no se negocia. Si el usuario no tiene permiso para ver un documento, el asistente no debería usarlo para responderle.
Prueba perfiles distintos: comercial, soporte, operaciones, dirección, administración. Haz la misma pregunta con usuarios diferentes y comprueba si cambia lo que debe cambiar. Si el sistema no distingue permisos, no está listo para abrirse a toda la empresa.
4. Casos límite
Los casos límite son preguntas raras, incompletas o peligrosas. Por ejemplo: "¿puedo prometer este plazo a un cliente?", "resume todas las incidencias de este proveedor", "dame precios especiales", "qué dice el contrato de X" o "prepara una respuesta aunque no esté documentado".
No todos los casos límite son bloqueantes, pero sí tienen que estar definidos. A veces la mejor respuesta del RAG es parar y pedir revisión humana.
5. Métrica de uso real
La precisión importa, pero no basta. Mide también si el equipo ahorra tiempo, si baja el número de búsquedas manuales, si se reducen consultas repetidas a personas clave y si las respuestas malas se detectan pronto.
Una métrica sencilla para empezar: de 40 preguntas, cuántas responde bien, cuántas contesta con fuente insuficiente, cuántas debería escalar y cuántas violan permisos o usan documentación equivocada. Esta última categoría debería ser cero antes de abrir el acceso.
Quién debe participar en la prueba
No lo dejes solo en manos de tecnología. Hace falta una persona que conozca el proceso, alguien que entienda dónde viven los documentos y una persona que pueda decidir qué nivel de riesgo es aceptable.
En una pyme industrial, por ejemplo, puede participar alguien de oficina técnica, calidad y sistemas. En una empresa de servicios, quizá soporte, comercial y administración. El equipo exacto cambia, pero la idea no: probar el asistente con gente que sabe cuándo una respuesta suena bien pero está mal.
Señales de que el RAG aún no está listo
Yo frenaría el despliegue si aparecen respuestas sin fuente clara, si recupera documentos obsoletos, si mezcla permisos, si contesta con demasiada seguridad cuando falta información o si nadie sabe quién corrige el conocimiento cuando cambia un procedimiento.
Frenar no significa tirar el proyecto. A veces basta con limpiar fuentes, separar carpetas, etiquetar versiones, ajustar permisos o escribir una política de escalado. Es trabajo poco glamuroso. También es lo que hace que el RAG sea usable.
Descarga la plantilla básica
Hemos preparado un PDF estático para montar una evaluación rápida con tu equipo. Incluye un banco de preguntas, una tabla de puntuación y una ficha de decisión para saber si el RAG puede abrirse, si necesita ajustes o si debe quedarse en piloto.
Descarga el how-to básico
PDF breve para probar respuestas, fuentes, permisos, casos límite y revisión humana antes de publicar un asistente documental interno.
Cómo lo trabajamos en Umintia
En Umintia diseñamos RAG privado y asistentes documentales para empresas que necesitan respuestas útiles sin perder control sobre fuentes y permisos. La tecnología importa, claro. Pero la diferencia suele estar en lo que ocurre antes de la demo: elegir bien las fuentes, definir perfiles de acceso y probar con preguntas incómodas.
Si tu empresa está en Donostia - San Sebastián, Gipuzkoa o Euskadi y está valorando un asistente sobre documentación interna, podemos ayudarte a revisar si el primer caso tiene sentido y qué pruebas conviene superar antes de abrirlo al equipo.