En esta página

La respuesta corta

Un conjunto de datos de evaluación útil registra la entrada, el contexto relevante, el comportamiento esperado, la procedencia y la categoría de falla para cada caso. Combine ejemplos reales autorizados con casos sintéticos cuidadosamente revisados ​​y conserve un conjunto reservado para decisiones en las que la sintonización no debería influir.

Que llevarse

  • Almacene por qué existe un caso, no solo su mensaje y respuesta.
  • Los ejemplos sintéticos amplían la cobertura pero necesitan una validación independiente.
  • Mantenga los cambios del conjunto de datos versionados y revisables.

Fuentes verificadas . Síntesis de investigaciones y recomendaciones de Rubrex. Se etiquetan ejemplos y experimentos locales; No son resultados de clientes.

Un trabajo reciente hace que la estructura del conjunto de datos sea una opción de diseño

HieraRAG, una preimpresión de junio de 2026, investiga la granularidad de las preguntas sintéticas en los puntos de referencia de RAG. Enmarca la granularidad como algo que se debe evaluar dentro de una configuración de recuperación específica. Esto respalda preguntar qué distinciones expone un conjunto de datos en lugar de suponer que más preguntas crean automáticamente un mejor punto de referencia.

Evidencia: ¿Qué tan detallado debe ser un punto de referencia RAG? Un marco jerárquico para la generación de preguntas sintéticas [1]

Los datos de evaluación y los datos de capacitación sirven para tomar decisiones diferentes

Los ejemplos de capacitación ayudan a cambiar el comportamiento de un modelo. Un conjunto de datos de evaluación prueba un comportamiento definido comparándolo con evidencia de referencia o criterios de puntuación. Rubrex recomienda mantener los casos utilizados para ajustar indicaciones o modelos separados de un conjunto de decisiones retenido. Si el equipo estudia una prueba fallida y cambia el sistema para aprobarla, conserve ese caso como una verificación de regresión, pero utilice casos nuevos retenidos para evaluar si el cambio se generaliza.

Los ejemplos sintéticos pueden ayudar a cubrir entradas inusuales, pruebas faltantes o límites de permisos. Verifique cada pregunta y resultado esperado con el material original antes de aceptarlo. Registre cómo se creó el ejemplo y qué falla representa. Un gran corpus de entrenamiento o una colección de pares de preguntas y respuestas generados automáticamente no es, por sí solo, un conjunto de evaluación validado.

Defina el registro antes de recopilar ejemplos.

Rubrex recomienda un registro de caso con un identificador inmutable, entrada, contexto permitido, comportamiento esperado, categoría de fuente, fecha de recopilación y estado del revisor. Para un flujo de trabajo que utiliza herramientas, incluya el estado inicial y el estado final autorizado. Para escritos abiertos, utilice una rúbrica fija en lugar de exigir una oración exacta.

Registre si el caso provino de producción, una escalada de soporte, un especialista de dominio o una generación sintética. Preservar una descripción segura para el público de su origen incluso cuando no se pueda conservar la interacción cruda. Un conjunto de datos no debería adquirir silenciosamente información confidencial sólo porque sea conveniente exportar un registro.

Construir cobertura deliberadamente

Asigne el producto a porciones significativas antes de escribir indicaciones. Los ejemplos incluyen tipo de tarea, antigüedad del documento, longitud de la entrada, disponibilidad de evidencia, idioma y permiso del usuario. Evite el producto cartesiano completo cuando produce combinaciones que no pueden ocurrir. Priorizar combinaciones con exposición real o una hipótesis de fallo concreta.

Para casos sintéticos, especifique el comportamiento que se destaca y realice un paso de revisión separado para verificar que la entrada sea plausible y que la referencia esté respaldada. Un modelo puede generar tanto una pregunta errónea como una respuesta errónea coincidente. El acuerdo entre esos dos artefactos no es una validación independiente.

Campos de conjunto de datos sugeridos
CampoPropósito
id_casoIdentidad estable en ejecuciones y revisiones
comportamiento_esperadoEl requisito observable, incluida la incertidumbre aceptable.
procedenciaOrigen, permiso de uso y contexto de recopilación.
etiquetas_rebanadasLas condiciones de tarea y falla representadas
estado_revisiónQuién o qué validó la referencia y si persiste la ambigüedad

Ejemplo ilustrativo: preguntas de políticas versionadas

Un asistente de beneficios recibe preguntas sobre una póliza actual y una póliza archivada. Cree casos distintos para preguntas actuales, preguntas explícitamente históricas y preguntas sin fecha. El comportamiento esperado difiere: use la regla actual, responda históricamente o aclare la fecha aplicable. Simplemente cambiar los nombres en un ejemplo sencillo perdería esta distinción.

Mantenga estos casos vinculados a las versiones de la política para que una actualización de la política real no parezca una regresión del modelo. Elimine las expectativas no válidas mediante una revisión, con una explicación, en lugar de eliminar los casos difíciles del conjunto de datos.

Trate el conjunto de datos como un artefacto de producto mantenido

Separe un conjunto de desarrollo de un conjunto de decisiones y registre el acceso a cada uno. Agregue nuevos casos de falla a través de una cola de revisión liviana. Al informar una puntuación, identifique la versión del conjunto de datos y explique los cambios materiales. Comparar el resultado del mes pasado en una combinación de tareas con el resultado de este mes en otra puede confundir los cambios de tráfico con la mejora del modelo.

Límites de la evidencia

Un conjunto de datos es una muestra construida, no un modelo completo de tráfico futuro. Los hallazgos de HieraRAG se refieren a un contexto de investigación particular. El diseño del registro y el ejemplo de política aquí son recomendaciones de Rubrex, no una reproducción de ese estudio.

Preguntas comunes

¿Puede el conjunto de datos ser completamente sintético?

Puede resultar útil durante las primeras etapas del diseño, pero su realismo y cobertura necesitan validación. Mantener explícito su origen sintético y compararlo con el uso real autorizado cuando esté disponible.

¿Las referencias deberían ser respuestas exactas?

Utilice respuestas exactas para tareas exactas. Para resultados abiertos, defina los hechos requeridos, el comportamiento inaceptable y las variaciones aceptables.

Fuentes y lecturas adicionales

Fuentes primarias detrás de este informe. Los hallazgos de una fuente se aplican a sus propias condiciones de estudio; La publicación en arXiv no establece una revisión por pares.

  1. ¿Qué tan detallado debe ser un punto de referencia RAG? Un marco jerárquico para la generación de preguntas sintéticas arXiv · 2026 · PreimpresiónRevisado: registro de resumen y publicación. Accedido 25 sept 2026.

¿Preguntas o correcciones? Escribe a Rubrex. Lea nuestro enfoque editorial.

De la lectura a una evaluación repetible

Ponga un listón de calidad en su caso de uso.

El AI Reliability Sprint cubre un caso de uso, una línea de base, un análisis de fallas y un experimento de mejora en 10 días hábiles.

Explora el Sprint