Una respuesta convincente puede ser peor que una respuesta vacía. En una empresa, el problema de un sistema RAG no es solo que se equivoque: es que se equivoque con tono seguro delante de alguien que tiene que actuar hoy.
La prueba importante no es si responde rápido, sino si sabe callarse a tiempo.
Ese es el criterio que deberíamos aplicar antes de confiar en un RAG empresarial: no medirlo por lo “inteligente” que suena, sino por cómo se comporta cuando la documentación está incompleta, cuando hay conflicto entre fuentes y cuando la pregunta no merece una respuesta automática. Eso cambia mucho más la operación que una demo pulida.
El error típico: evaluar el RAG como si fuera un buscador
La trampa más común es probar el sistema con preguntas amables. “¿Cuál es el procedimiento de devoluciones?”, “¿Cómo se solicita una baja?”, “¿Dónde está la política de gastos?”. Con eso parece que funciona, pero todavía no sabes si sirve para trabajar.
Un RAG, Retrieval-Augmented Generation o generación aumentada por recuperación, mezcla búsqueda y redacción. Eso significa que su riesgo no está solo en lo que redacta, sino en qué documentos recupera, cuáles ignora y qué hace cuando recupera material débil o contradictorio. Si evalúas solo la frase final, estás mirando el escaparate y no la trastienda.
La pregunta útil es más incómoda: ¿puede el sistema demostrar de dónde sale cada respuesta y qué hace cuando no lo sabe? Si no puedes contestar eso, no tienes un asistente confiable; tienes una máquina de parecer segura.
Las cinco preguntas que sí separan ayuda de humo
Antes de aprobar un RAG, conviene hacerle cinco preguntas muy concretas:
- ¿Qué fuentes espera usar y cuáles están fuera de alcance?
- ¿Cita el origen de la respuesta de forma verificable?
- ¿Se abstiene cuando la evidencia es insuficiente?
- ¿Pide aclaración cuando la pregunta es ambigua?
- ¿Escala a una persona cuando hay riesgo operativo o legal?
No hace falta un laboratorio para ver esto. Hace falta una pequeña batería de casos reales: una política antigua, un documento duplicado, una orden con excepciones, una pregunta mal formulada y una consulta cuya respuesta correcta es “no lo sé”.
La documentación de evaluaciones de OpenAI insiste precisamente en diseñar criterios de prueba, usar fuentes de datos bien definidas y ejecutar evals para comprobar el comportamiento del sistema con datos de prueba, no solo con intuición. También encaja con su enfoque de graders, que permiten medir resultados frente a criterios concretos en lugar de confiar en impresiones sueltas. (platform.openai.com)
Mini-caso: cuando el problema no era la IA, sino la evidencia
Pensemos en una empresa mediana con soporte interno y un RAG sobre procedimientos. Al principio todo parece bien: el equipo hace preguntas frecuentes y recibe respuestas rápidas. Pero a las pocas semanas aparece el patrón real.
Cuando el departamento técnico cambia un proceso y el PDF antiguo sigue indexado, el sistema mezcla ambas versiones. Cuando una pregunta tiene una excepción por cliente o por país, responde como si fuera una regla universal. Y cuando no encuentra apoyo suficiente, rellena los huecos con una frase elegante.
En ese escenario, el fallo no está solo en el modelo. Está en la mezcla de fuentes sin jerarquía, en la ausencia de una fecha de vigencia visible y en no definir qué preguntas deben terminar en revisión humana. La lección es dura pero útil: un RAG no corrige un desorden documental; lo amplifica.
La decisión incómoda: menos automatización, más control
Aquí aparece la parte menos popular. Un buen RAG empresarial no responde todo. De hecho, cuanto más importante es la decisión, más veces debería abstenerse.
Eso incomoda porque parece “menos útil”. Pero en operación real suele ser más valioso un sistema que diga “necesito revisión” que uno que entregue una respuesta inventada con formato profesional. En soporte, compras, RR. HH. o compliance, una respuesta incorrecta consume más tiempo del que ahorra.
Por eso conviene separar tres niveles:
- preguntas de consulta general, donde puede responder con margen;
- preguntas operativas, donde debe citar y verificar;
- preguntas sensibles, donde debe detenerse y escalar.
Ese diseño no frena el proyecto; evita que el primer éxito aparente se convierta en un problema de confianza.
Cómo revisarlo sin montar una burocracia
La evaluación no tiene por qué ser pesada. Puede empezar con una tabla simple: pregunta, fuente esperada, respuesta correcta, nivel de confianza, acción si no hay evidencia. Lo importante es repetirla con casos reales, no con ejemplos inventados.
Tres señales valen más que una presentación bonita: respuestas con cita clara, abstención cuando falta evidencia y revisiones humanas que realmente corrigen la base documental. Si no aparece ninguna de las tres, el sistema todavía está en demo, aunque ya lo usen en producción.
La propia lógica de evals de OpenAI apunta a ese enfoque: definir datos de prueba, medir criterios concretos y revisar resultados de forma sistemática, no confiar en una primera impresión. (platform.openai.com)
Lo que deberías pedir esta semana
Si estás valorando un RAG, esta semana puedes avanzar con tres preguntas muy prácticas:
- ¿Qué tres respuestas incorrectas nos harían perder confianza de verdad?
- ¿Qué documentos deben mandar sobre los demás y cómo se ve eso en la práctica?
- ¿Quién revisa las respuestas dudosas y con qué criterio se corrige la base?
Si un sistema va a influir en decisiones reales, el estándar no debería ser que parezca listo, sino que sepa cuándo no debe hablar. En Codefuente solemos empezar por esa frontera: menos promesa, más prueba y más control operativo.