Cómo crear un conjunto de evaluación RAG con documentos de empresa

Un asistente interno con IA no debería evaluarse con cinco preguntas improvisadas durante una demo. Si las preguntas cambian después de cada respuesta, el equipo no puede saber si mejoró la recuperación, si el prompt solo resulta más convincente o si un documento restringido influyó en el resultado. Un conjunto pequeño y versionado de evaluación RAG convierte esas impresiones en evidencia repetible.

Esta guía está dirigida a responsables de operaciones, TI y conocimiento. Explica cómo crear un conjunto de pruebas con documentos sintéticos o aprobados, registrar la evidencia esperada, incluir casos de fallo y repetir las mismas preguntas después de cambiar una fuente o una configuración. Complementa la lista de 15 preguntas para evaluar la búsqueda interna con IA: aquella página ayuda a comparar herramientas; esta construye el activo de evaluación que permite compararlas.

Qué debe incluir un conjunto de evaluación RAG

Un registro útil contiene más que una pregunta y una respuesta del modelo. Como mínimo, anota:

• un identificador estable del caso;
• la persona o el rol que pregunta;
• la pregunta en lenguaje natural;
• la fuente autoritativa que debería responder;
• los hechos obligatorios;
• los hechos o fuentes que no deben aparecer;
• el resultado esperado: responder, pedir precisión o no responder;
• el perfil de acceso usado en la prueba;
• la persona responsable que aprobó la referencia;
• la versión del conjunto y la fecha de revisión.

La guía de evaluación RAG de Microsoft define el conjunto de evaluación como consultas seleccionadas —idealmente con salidas esperadas— que representan el uso previsto y se mantienen exigentes, diversas y actualizadas. Google Cloud recomienda preguntas de calidad que cubran los datos, distintas formulaciones y una complejidad realista, junto con un conjunto de referencia. La documentación de Amazon Bedrock hace explícita la función de la verdad de referencia: los textos recuperados y las respuestas esperadas permiten comparar el sistema con lo que debería haber ocurrido.

«Golden» no significa perfecto para siempre. Significa suficientemente revisado para ser la referencia vigente de una prueba concreta. Cuando cambia una política, la respuesta esperada debe cambiar mediante una revisión visible del conjunto.

Paso 1: define las decisiones que debe respaldar el asistente

No empieces tomando páginas al azar. Enumera las decisiones o interrupciones frecuentes que el asistente pretende reducir: aprobar un gasto, explicar un permiso laboral, encontrar una cláusula contractual, preparar una propuesta, resolver una avería o localizar el paso vigente de onboarding.

Elige dos o tres perfiles y pide a las personas expertas ejemplos de preguntas recientes. Elimina datos de clientes, empleados y cualquier información confidencial salvo que exista autorización explícita. Para evaluar proveedores suele ser más seguro usar un conjunto sintético, porque permite controlar todos los hechos y permisos.

Empieza con entre 20 y 40 casos si bastan para cubrir el primer flujo. La cobertura importa más que una cifra redonda. Cien preguntas casi idénticas pueden ocultar una prueba ausente de permisos o vigencia.

Paso 2: congela un pequeño conjunto de fuentes

Selecciona documentos controlados y registra su versión. Incluye los formatos que usa el equipo: una política, un procedimiento, una tabla, una FAQ breve y un manual más largo. Asigna a cada fuente una persona responsable y una fecha de aprobación.

Introduce dificultades deliberadas:

• una política vigente y un borrador obsoleto;
• dos documentos con títulos parecidos;
• un hecho repartido entre dos fuentes;
• un documento restringido;
• una pregunta ambigua que exige aclaración;
• una pregunta plausible cuya respuesta no existe.

El caso sin respuesta es esencial. Una invención fluida no es un éxito parcial. El resultado esperado debe ser una limitación clara seguida de un siguiente paso útil. El glosario sobre fundamentación explica por qué una cita relacionada no respalda automáticamente una afirmación.

Paso 3: escribe las preguntas antes de mirar la salida

Formula las preguntas como habla la plantilla, no copiando los encabezados del documento. Incluye paráfrasis, abreviaturas, errores ortográficos, identificadores exactos y solicitudes con varias partes. Conserva el texto original aunque sea imperfecto: normalizarlo puede borrar la dificultad que querías probar.

Para cada pregunta, identifica el fragmento autoritativo mínimo que respalda la respuesta. Después, redacta los hechos obligatorios como afirmaciones breves que puedan comprobarse de forma independiente. Evita un único párrafo de referencia muy pulido que premie una comparación superficial de texto.

Un buen registro podría ser:

Paso 4: cubre doce clases de prueba

Usa esta matriz como punto de partida y sustituye los ejemplos por preguntas aprobadas de tu empresa.

1. Hecho directo: una respuesta en una única fuente bien identificada.
2. Paráfrasis: la pregunta evita la terminología del documento.
3. Identificador exacto: número de factura, referencia de producto, código de política o error.
4. Síntesis de varias fuentes: los hechos necesarios aparecen en dos documentos compatibles.
5. Vigente frente a obsoleto: un borrador superado se parece más a la pregunta que la fuente aprobada.
6. Permiso concedido: el perfil autorizado debe recibir la respuesta restringida y su cita.
7. Permiso denegado: un perfil no autorizado no debe ver respuesta, título, fragmento ni cita.
8. Conocimiento ausente: ninguna fuente contiene el dato solicitado.
9. Petición ambigua: una respuesta segura exige una pregunta aclaratoria.
10. Fuentes contradictorias: dos archivos aparentemente aprobados discrepan y el conflicto debe mostrarse.
11. Variación de lenguaje: una errata, sigla o expresión coloquial pone a prueba la recuperación.
12. Instrucción no fiable: un documento contiene texto que no debe desviar al asistente de la tarea de la persona usuaria.

Trata los casos de seguridad como condiciones excluyentes. Una fuga de permisos no debe quedar disimulada por notas altas en preguntas fáciles.

Paso 5: puntúa por separado la recuperación y la respuesta

Un sistema puede recuperar el fragmento correcto y generar una respuesta incompleta. También puede redactar algo plausible después de recuperar una fuente equivocada. Registra ambas capas.

En recuperación, comprueba si apareció la fuente esperada, si apareció una fuente obsoleta o prohibida y si el fragmento citado contiene la evidencia necesaria. En la respuesta, revisa la cobertura de hechos obligatorios, afirmaciones sin respaldo, tratamiento correcto de la información ausente, utilidad y claridad.

No conviertas la primera rúbrica en un falso benchmark universal. Define el aprobado según el riesgo del negocio. Una FAQ de cafetería y una decisión de renovación contractual no merecen el mismo umbral de revisión. El Centro de Recursos de IA de NIST presenta las pruebas, la evaluación, la verificación y la validación como prácticas de ciclo de vida; el hábito importante es documentar la prueba y repetirla cuando cambian el sistema o el uso.

Paso 6: incorpora revisión humana cuando haya juicio

Los evaluadores automáticos ayudan a ejecutar conjuntos grandes con consistencia, pero una persona experta debe aprobar los hechos de referencia y revisar los fallos matizados. Google Cloud recomienda implicar a las partes interesadas y personas usuarias, y combinar la evaluación cuantitativa con el criterio humano.

Aprovecha los desacuerdos. Si RRHH y operaciones no coinciden en la respuesta esperada, el asistente ha revelado un problema de gobierno de fuentes, no un fallo de evaluación. Regístralo como brecha de conocimiento, asigna una persona responsable y corrige el documento autoritativo antes de tocar los prompts.

Paso 7: versiona el conjunto y cambia una sola variable

Guarda la versión del conjunto de fuentes, la versión del dataset, la configuración del sistema, la fecha y el resultado de cada ejecución. Al probar una mejora, cambia una sola variable relevante: la fuente, la estrategia de chunking, el método de recuperación, el prompt o el modelo. Google Cloud recomienda mantener estables las preguntas y respuestas de referencia para atribuir el cambio de puntuación a la modificación probada.

Añade casos procedentes de producción solo después de una revisión de privacidad. Las preguntas sin respuesta y el feedback negativo son buenos candidatos, pero deben limpiarse, aprobarse y asignarse a la fuente correcta antes de entrar en el conjunto de referencia. Retira casos cuando desaparezca el flujo de negocio, sin reescribir silenciosamente su historial.

Cabecera CSV para copiar

Una hoja de cálculo basta para la primera versión:

case_id,persona,question,expected_source,required_facts,forbidden_facts,expected_outcome,access_profile,owner,dataset_version,reviewed_at

Usa una fila por pregunta. Guarda varios hechos obligatorios como lista estructurada o con un separador coherente. Vincula los identificadores de fuente con un manifiesto congelado en vez de pegar fragmentos confidenciales en una hoja sin protección.

Cómo ejecutar el conjunto con Polp

La ayuda pública de Polp recomienda empezar con un pequeño conjunto de documentos revisados, formular una pregunta real y comprobar si las fuentes citadas son correctas. Ese es el alcance adecuado para una primera evaluación.

Sube o conecta únicamente las fuentes sintéticas aprobadas y ejecuta cada caso con el rol especificado. Guarda la respuesta y las citas, marca evidencia ausente o inesperada y lleva los problemas de fuente sin resolver al flujo de calidad del conocimiento. La guía para subir documentos ayuda a preparar archivos claros y vigentes; la guía para preguntar a Polp explica cómo revisar fuentes y tratar una respuesta sin información como algo útil en lugar de fomentar una invención.

Si quieres probar este conjunto con un asistente interno respaldado por fuentes, solicita una demo de Polp y trae el manifiesto de fuentes, los perfiles y las condiciones de aprobado. Un piloto disciplinado debe dejar un activo de calidad reutilizable, no solo una demo memorable.

Regla de decisión

Tu conjunto de evaluación está listo cuando otra persona puede ejecutar los mismos casos contra la misma versión de las fuentes y entender por qué cada resultado aprobó o suspendió. Mantén preguntas realistas, evidencia esperada explícita, casos de permisos estrictos y un historial visible de revisiones. Eso basta para sustituir «las respuestas parecían buenas» por una prueba que el equipo pueda repetir.