Construire un ensemble de données d'évaluation LLM qui reflète un travail réel

Des travaux récents font de la structure des ensembles de données un choix de conception

HieraRAG, une prépublication de juin 2026, étudie la granularité des questions synthétiques dans les benchmarks RAG. Il définit la granularité comme quelque chose à évaluer dans une configuration de récupération spécifique. Cela permet de se demander quelles distinctions un ensemble de données expose plutôt que de supposer que davantage de questions créent automatiquement une meilleure référence.

Preuve : Dans quelle mesure un indice de référence RAG doit-il être précis ? Un cadre hiérarchique pour la génération de questions synthétiques [1]

Les données d'évaluation et les données de formation servent à des décisions différentes

Les exemples de formation aident à changer le comportement d’un modèle. Un ensemble de données d'évaluation teste un comportement défini par rapport à des preuves de référence ou à des critères de notation. Rubrex recommande de conserver les cas utilisés pour régler les invites ou les modèles séparés d'un ensemble de décisions retenu. Si l'équipe étudie un test échoué et modifie le système pour le réussir, conservez ce cas comme contrôle de régression, mais utilisez de nouveaux cas retenus pour évaluer si le changement se généralise.

Des exemples synthétiques peuvent aider à couvrir les entrées inhabituelles, les preuves manquantes ou les limites d'autorisation. Vérifiez chaque question et le résultat attendu par rapport au matériel source avant de l'accepter. Enregistrez comment l'exemple a été créé et quel échec il représente. Un vaste corpus de formation ou une collection de paires questions-réponses générées automatiquement ne constitue pas, en soi, un ensemble d’évaluation validé.

Définir l'enregistrement avant de collecter des exemples

Rubrex recommande un enregistrement de cas avec un identifiant immuable, une entrée, un contexte autorisé, un comportement attendu, une catégorie source, une date de collecte et un statut de réviseur. Pour un flux de travail utilisant un outil, incluez l’état initial et l’état final autorisé. Pour une écriture ouverte, utilisez une rubrique ancrée au lieu d'exiger une phrase exacte.

Enregistrez si le cas provient de la production, d'une escalade de support, d'un spécialiste du domaine ou d'une génération synthétique. Conservez une description publiquement sécurisée de son origine même lorsque l’interaction brute ne peut pas être conservée. Un ensemble de données ne doit pas acquérir discrètement des informations sensibles simplement parce qu’une exportation de journaux est pratique.

Construisez délibérément une couverture

Mappez le produit en tranches significatives avant d'écrire des invites. Les exemples incluent le type de tâche, l’âge du document, la longueur de la saisie, la disponibilité des preuves, la langue et l’autorisation de l’utilisateur. Évitez le produit cartésien complet lorsqu'il produit des combinaisons qui ne peuvent pas se produire. Privilégiez les combinaisons avec une exposition réelle ou une hypothèse de défaillance précise.

Pour les cas synthétiques, spécifiez le comportement souligné et demandez à une étape de révision distincte de vérifier que l'entrée est plausible et que la référence est prise en charge. Un modèle peut générer à la fois une question erronée et une réponse erronée correspondante. L'accord entre ces deux artefacts ne constitue pas une validation indépendante.

Exemple illustratif : questions politiques versionnées

Un assistant aux avantages sociaux reçoit des questions sur une politique actuelle et une politique archivée. Créez des cas distincts pour les questions actuelles, les questions explicitement historiques et les questions sans date. Le comportement attendu diffère : utilisez la règle actuelle, répondez historiquement ou clarifiez la date applicable. Changer simplement les noms dans un exemple simple manquerait cette distinction.

Gardez ces cas liés aux versions de stratégie afin qu’une véritable mise à jour de stratégie ne semble pas être une régression de modèle. Supprimez les attentes non valides en les examinant, avec une explication, plutôt que de supprimer les cas difficiles de l'ensemble de données.

Traitez l'ensemble de données comme un artefact de produit maintenu

Séparez un ensemble de développement d’un ensemble de décision et enregistrez l’accès à chacun. Ajoutez de nouveaux cas d’échec via une file d’attente de révision légère. Lorsque vous rapportez un score, identifiez la version de l’ensemble de données et expliquez les changements importants. Comparer le résultat du mois dernier sur une combinaison de tâches avec le résultat de ce mois-ci sur une autre peut confondre les changements de trafic avec l'amélioration du modèle.

Questions courantes