Un asistente que responde bien durante una demostración todavía puede fallar cuando una pregunta exige cruzar documentos, distinguir versiones o reconocer que falta información. Para decidir si está preparado, necesitas una evaluación que represente el trabajo que hará y los errores que el negocio puede tolerar.
En un sistema RAG, la generación se apoya en información recuperada de una colección de documentos. La evaluación debe separar dos preguntas: si se ha encontrado la evidencia adecuada y si la respuesta utiliza esa evidencia correctamente. Medir solo lo convincente que resulta el texto oculta fallos de recuperación.
Define primero qué tareas están permitidas
«Responder preguntas internas» es un alcance demasiado abierto para construir una prueba útil. Concreta quién consulta, qué documentos puede utilizar y qué decisiones quedan fuera del asistente.
Un ejemplo ficticio: un equipo de soporte necesita consultar procedimientos de instalación de distintos productos. El asistente puede localizar pasos, explicar requisitos y enlazar el documento correspondiente. Si faltan la versión del producto o el contexto necesario, debe pedirlos. No debe completar un procedimiento con instrucciones inventadas.
Con ese alcance puedes definir errores específicos: citar un manual obsoleto, mezclar productos, omitir una condición previa o responder con información a la que el usuario no tiene acceso.
Construye un conjunto de preguntas con evidencia esperada
Recoge situaciones de trabajo y revísalas con quienes conocen la documentación. Cada caso debe permitir determinar qué información era accesible y qué respuesta sería aceptable. No necesitas redactar una única frase de referencia si varias respuestas pueden ser correctas.
| Campo del caso | Para qué sirve |
|---|---|
| Pregunta y contexto del usuario | Reproducir la necesidad y su ambigüedad |
| Identidad o perfil de permisos de prueba | Determinar qué documentos puede consultar |
| Documento y versión de referencia | Fijar la evidencia válida |
| Afirmaciones que deben aparecer | Evaluar si la respuesta resuelve la tarea |
| Afirmaciones que no están respaldadas | Detectar invenciones o extrapolaciones |
| Conducta esperada si falta información | Comprobar aclaraciones y abstenciones |
Incluye preguntas con nombres exactos, abreviaturas, errores de escritura y expresiones equivalentes. Añade también casos sin respuesta, documentos contradictorios y versiones antiguas que se parezcan mucho a las vigentes.
Reserva una parte del conjunto para aceptación. Si ajustas continuamente el sistema mirando todas las respuestas de evaluación, puedes acabar optimizando para esos ejemplos y perder una medida independiente de su funcionamiento.
Evalúa la recuperación antes de cambiar el prompt
Guarda qué fragmentos se recuperan para cada consulta y revisa si contienen la información necesaria. Cuando el contexto no incluye la respuesta, modificar las instrucciones de redacción puede disimular el síntoma sin solucionar el problema.
Para un conjunto con documentos relevantes identificados, la cobertura de recuperación permite observar cuánta evidencia esperada aparece entre los resultados. La precisión describe qué parte de lo recuperado es pertinente. Estas medidas necesitan referencias suficientemente completas; si el inventario de documentos relevantes está incompleto, la interpretación también lo estará.
La documentación de evaluadores RAG de Microsoft diferencia la calidad de recuperación de dimensiones de respuesta como fundamentación, relevancia y completitud. Esa separación ayuda a localizar dónde falla el sistema.
Puntúa la respuesta con una rúbrica verificable
No reduzcas la evaluación a «me gusta» o «parece correcta». Una rúbrica operativa puede distinguir:
- Resolución: la respuesta aborda la tarea que el usuario planteó.
- Respaldo: cada afirmación sustantiva se sostiene en la evidencia disponible.
- Cobertura: aparecen las condiciones necesarias para actuar correctamente.
- Citas: los enlaces permiten comprobar las afirmaciones a las que acompañan.
- Límites: el sistema pide aclaraciones o reconoce que no puede responder cuando corresponde.
Una respuesta puede estar bien respaldada y seguir siendo incorrecta para el trabajo: por ejemplo, si reproduce fielmente un procedimiento cuya versión ya no está vigente. Por eso hay que evaluar la validez de la fuente, además de la correspondencia entre el texto generado y el fragmento recuperado.
Si utilizas otro modelo para puntuar, compara sus valoraciones con revisiones humanas sobre casos variados. Revisa desacuerdos y fija la rúbrica antes de comparar versiones. El juicio automático ayuda a ampliar la evaluación, pero no debe convertirse en una aprobación que nadie puede explicar.
Prueba los permisos como una condición independiente
Prepara documentos de prueba accesibles para un perfil y restringidos para otro. Ejecuta consultas equivalentes con ambas identidades. Verifica también el comportamiento después de revocar un permiso y cuando una respuesta queda almacenada en caché.
La comprobación debe abarcar recuperación, herramientas, referencias y resultados reutilizados. Un texto final que omite un dato sensible no demuestra por sí solo que ese dato nunca llegó al contexto del modelo.
Incluye documentos de prueba con instrucciones ajenas a la tarea, como una petición de ignorar las reglas del asistente. El resultado esperado es que el contenido se trate como información no confiable y no cambie las autorizaciones del usuario. Estas pruebas complementan los controles de acceso; no los sustituyen.
Convierte los resultados en una decisión de despliegue
Evita una media global que mezcle fallos de poca importancia con exposiciones de información o instrucciones peligrosamente incompletas. Segmenta por tarea, tipo de documento, idioma si aplica y perfil de acceso.
Acuerda con el responsable del proceso qué errores bloquean la salida y qué deficiencias permiten un piloto limitado con supervisión. Los umbrales dependen del uso y del coste del error: no existe un porcentaje universal que certifique que cualquier RAG es seguro o útil.
Registra junto al resultado las versiones del corpus, índice, modelo, instrucciones y configuración de recuperación. Para evaluar un cambio de fragmentación, mantén estables los demás elementos cuando sea posible. Si cambian todos a la vez, será difícil atribuir la mejora o el deterioro.
Mide también el esfuerzo que queda para el usuario
Un asistente puede producir respuestas correctas y aun así requerir demasiadas aclaraciones, esperas o verificaciones manuales. Observa el tiempo hasta una respuesta utilizable, los reintentos, las consultas que pasan a una persona y el coste de resolver la tarea completa.
El paso posterior al lanzamiento es mantener un conjunto de regresión y convertir incidencias reales en nuevos casos revisados, con la información sensible minimizada. Cada actualización del corpus o del sistema debe poder compararse con una referencia conocida.
Si estás valorando una solución de IA y analítica aplicada, empieza por definir tareas y evidencia antes de elegir el modelo. Para plantear el caso a Nexeus Big Data, prepara ejemplos de consultas, documentos representativos y las decisiones que deberían seguir bajo responsabilidad humana.