Construire un dataset
Vingt bonnes questions valent mieux que deux cents médiocres. Voici comment les choisir.
Un dataset est un ensemble de cas portant un nom, et les vérifications qu'on leur applique. Un agent peut en avoir plusieurs : un pour les questions de tous les jours, un pour les questions délicates, un pour ce qu'il devrait refuser.
Nouveau dataset, donnez-lui un nom et une ligne indiquant quand le lancer, puis commencez à ajouter des cas.
Ce qui fait un bon cas
Entrée, la question, exactement comme une vraie personne la taperait. Tapez la version brouillonne, pas la version soignée, parce que la version brouillonne est celle que vos collègues enverront.
Sortie attendue (facultatif), une réponse de référence. Certaines vérifications en ont besoin, la plupart non. Écrivez-la quand il existe une réponse indiscutablement juste, et laissez-la vide sinon.
Métadonnées (facultatif), vos propres étiquettes comme {"difficulty": "hard"}, utiles pour donner du sens aux résultats plus tard.
Surcharges d'évaluateurs (facultatif), des vérifications pour ce cas uniquement, sinon il hérite de celles du dataset.
Choisir vos vingt questions
C'est cette partie qui décide si tout l'exercice sert à quelque chose, et l'instinct (écrire vingt questions ordinaires) produit un dataset qui passe pour toujours et ne vous apprend rien.
Un bon assortiment :
Quelques questions vraiment ordinaires. Le pain quotidien. Si celles-là échouent un jour, c'est que quelque chose va très mal.
Les questions délicates. Ambiguës, mal précisées, ou avec une hypothèse cachée dedans. « J'ai droit à combien de jours ? » quand la réponse dépend du pays.
Celles qu'il devrait refuser ou nuancer. Hors de son périmètre, ou dont la réponse honnête est « les documents ne le disent pas ». C'est le groupe que les gens oublient, et c'est là que les agents échouent le plus souvent : répondre avec assurance à une question qu'ils auraient dû décliner.
Celles qui vous ont mordu. Chaque fois que l'agent se trompe en usage réel, ajoutez-la comme cas. Au bout de deux mois, c'est la partie la plus précieuse du dataset, parce que c'est la liste des erreurs qu'il ne pourra plus refaire en silence.
Une ou deux avec un piège. Une question qui part d'une fausse prémisse. « Pourquoi avons-nous arrêté l'offre Pro ? » alors que vous ne l'avez pas fait. Vous corrige-t-il, ou invente-t-il une raison ?
Vingt cas choisis comme ça vous en disent plus que deux cents variantes de « quelle est notre politique de remboursement ».
Générer des cas
Si c'est la page blanche qui vous bloque, Générer vous en rédige quelques-uns : décrivez le domaine, dites combien vous en voulez, donnez éventuellement deux ou trois exemples pour le ton.
Vous relisez ensuite chaque brouillon, en modifiant, supprimant ou régénérant l'un après l'autre avant d'accepter. Rien n'est enregistré tant que vous n'avez pas accepté.
Les cas générés sont un point de départ, pas un dataset. Ils ont tendance à se regrouper autour de l'évidence, c'est-à-dire exactement le groupe qui vous apprend le moins.
Servez-vous-en pour les questions ordinaires, puis ajoutez à la main les questions délicates, les refus et les pièges. Ce sont ceux qui viennent de la connaissance du métier, et aucun générateur ne connaît votre métier.
Partir d'un modèle
Partir d'un modèle copie un dataset publié par quelqu'un de votre organisation, ou un modèle intégré fourni par Asteria Labs.
Vous obtenez votre propre copie. Les modifications ultérieures de l'original ne l'atteignent jamais, et vos modifications ne touchent jamais les leurs.
Publiez le vôtre avec Publier au catalogue, et toute votre organisation pourra lire et copier chaque cas de test qu'il contient. Le retirer ensuite n'affecte pas les copies déjà faites.
Banques de questions partagées
Quand plusieurs agents dupliquent le même modèle, la vue Banques de questions partagées les regroupe et les classe par leur dernier taux de réussite. Utile pour un standard que tout le monde est censé atteindre : un agent nettement en dessous des autres se voit.
Lisez ce classement avec la réserve que la vue elle-même indique : la duplication copie les questions à cet instant précis. Une copie modifiée depuis ne pose peut-être plus les mêmes questions, donc un score plus bas peut signaler un dataset plus dur plutôt qu'un agent moins bon.
Garder un dataset honnête
Ajoutez les vrais échecs. L'habitude la plus rentable de toutes. Les vraies erreurs valent mieux que les erreurs imaginées.
Ne modifiez pas un cas pour le faire passer. C'est tentant, et ça détruit tout l'intérêt. Si un cas est réellement injuste, corrigez-le. S'il est juste et qu'il échoue, c'est le dataset qui fait son travail.
Élaguez ceux qui n'échouent jamais. Un cas qui a passé quarante exécutions d'affilée coûte de l'argent et ne vous apprend rien. Gardez-en quelques-uns comme témoins et retirez le reste.
N'y touchez pas pendant une comparaison. Changer les cas et l'agent en même temps, c'est ne plus pouvoir dire ce qui a fait bouger le score.