Evaluation engineer (ingénieur évaluation des modèles IA)

L’evaluation engineer, ou ingénieur évaluation des modèles IA, conçoit les méthodes, jeux de tests et pipelines qui mesurent les capacités des modèles de langage sur des usages définis. Ses résultats aident les équipes produit et recherche à comparer des modèles, repérer leurs limites et préparer les décisions de mise en service. Il transforme une attente utilisateur en critères explicites, puis construit un dispositif permettant de refaire la mesure.

Son travail produit des livrables concrets : tâches à exécuter, données de test, règles de notation, code d’évaluation et conclusions sur les résultats. Il ne suffit pas de publier un score. Il faut expliquer ce que celui-ci mesure, les conditions dans lesquelles il a été obtenu et les usages qu’il ne couvre pas. La reproductibilité conserve des conditions de comparaison maîtrisées, sans promettre des réponses identiques à chaque exécution d’un modèle stochastique.

Les postes de Mistral AI et d’Anthropic font apparaître plusieurs priorités : benchmarks liés aux usages clients, infrastructure partagée d’évaluation ou mesure pendant le post-entraînement. Un poste peut privilégier l’une de ces responsabilités. Les réunir toutes dans une annonce créerait une exigence plus large que chacune des spécialités observées. Le rattachement doit donc préciser les interlocuteurs produit et recherche, ainsi que les responsables de la décision finale de lancement. Les sources ne définissent pas un rattachement hiérarchique unique.

Evaluation engineer, AI engineer et auditeur indépendant : qui fait quoi ?

• L’Evaluation engineer construit les mesures, analyse les erreurs et explique les limites des résultats. Il contribue aux critères d’acceptation sans disposer nécessairement du pouvoir de lancer le modèle.
• L’AI engineer représente ici le besoin voisin de construction de fonctionnalités IA. Cette réalisation applicative sort du cœur de la fiche.
• L’auditeur indépendant répond à un besoin distinct d’audit. Une suite de tests interne ne constitue pas une certification indépendante.

L’assurance qualité logicielle générale reste également hors de ce périmètre : l’objet principal est la mesure des capacités des modèles dans leurs conditions d’usage.

Le recrutement engage d’abord la qualité des décisions prises à partir des évaluations. Une amélioration apparente peut venir d’un changement du jeu de tests, d’un correcteur défectueux ou d’un environnement différent. Si ces causes restent confondues, les équipes peuvent choisir un modèle sur un résultat qui ne traduit pas une amélioration utile. L’Evaluation engineer doit rendre ces différences compréhensibles avant qu’elles orientent le produit ou la recherche.

La définition de la réussite est une autre décision structurante. Un score global ne dit pas toujours si les exigences importantes pour les utilisateurs sont satisfaites. La documentation méthodologique d’Anthropic distingue notamment fidélité à la tâche, cohérence, confidentialité, latence et coût. Ces dimensions se choisissent selon l’usage. Elles ne forment pas une liste obligatoire, et aucun seuil universel ne permet de déclarer un modèle prêt pour la production.

Exemple fictif : une équipe compare deux modèles pour répondre à des demandes clients. Le nouveau modèle réussit mieux en moyenne, mais échoue sur certains cas limites jugés essentiels. L’ingénieur doit rendre ce désaccord visible et expliquer les critères utilisés. Les responsables du lancement peuvent alors discuter l’acceptation de ces échecs au lieu de décider sur la seule moyenne.

Une mauvaise adéquation entre le candidat et le poste peut aussi laisser une partie du besoin sans réponse. Savoir construire une infrastructure de calcul ne prouve pas la capacité à traduire une attente métier en test. Inversement, savoir définir un benchmark ne suffit pas à maintenir un dispositif partagé à grande échelle. Le recrutement doit identifier la responsabilité prioritaire avant de comparer les profils.

Enfin, les évaluations ne couvrent pas à elles seules tout ce qui se produit après le lancement. Suivi en production, retours utilisateurs et examen humain complètent les tests. Une restitution utile présente les limites connues et les questions restantes, sans convertir un résultat favorable en garantie d’absence d’erreurs.

• Traduire les usages visés en critères d’acceptation et en règles de notation explicites.
• Constituer des jeux de tests reflétant les tâches réelles et leurs cas limites.
• Contrôler les consignes et les correcteurs pour distinguer une erreur du modèle d’un défaut du test.
• Automatiser l’exécution des essais, la notation des réponses et la consultation des résultats.
• Maintenir des comparaisons reproductibles lorsque les modèles, benchmarks et codes évoluent.
• Analyser les régressions et les variations de mesure avant de recommander une action.
• Présenter aux équipes produit et recherche les résultats, leurs limites et leurs conséquences pour les décisions de déploiement.

Un parcours crédible doit montrer des acquis en programmation, expérimentation et compréhension des modèles de langage. Un diplôme peut documenter une partie de ces acquis, mais ne remplace pas une réalisation permettant de comprendre comment le candidat mesure une capacité et interprète un résultat. Aucun diplôme français obligatoire ni cursus unique propre à cet intitulé n’est établi par les sources retenues.

Les exigences des postes étudiés diffèrent. Mistral AI cite, pour sa plateforme d’évaluation, un master ou un doctorat en informatique, ou une expérience équivalente. Anthropic accepte un bachelor ou une combinaison équivalente d’études, de formation et d’expérience. Ces formulations décrivent des critères d’employeurs distincts. Elles ne justifient ni d’imposer un doctorat à tous les candidats, ni d’assimiler automatiquement ces diplômes à un niveau français.

Une expérience en génie logiciel ou en recherche peut apporter des bases utiles. L’offre Applied AI de Mistral mentionne un code sur lequel d’autres peuvent travailler et une réalisation utilisant des LLM. Dans un dossier de candidature, ces acquis peuvent apparaître dans un dispositif de test réutilisable, des résultats analysés et une explication des choix de notation. L’intérêt de la réalisation tient à la démarche et aux responsabilités réellement exercées.

L’autonomie recherchée doit correspondre au poste : définir un benchmark métier, maintenir l’infrastructure commune ou interpréter des évaluations pendant le post-entraînement. La connaissance de ce dernier domaine ne signifie pas que le titulaire devra entraîner les modèles. Préférez des preuves de maîtrise des tâches confiées à un nombre d’années arbitraire.

Pour évaluer ce profil, appuyez votre décision sur des réalisations explicables et un exercice adapté aux responsabilités du poste.

1. Fixer les critères avant l’entretien

Choisissez la priorité du recrutement : benchmarks métier, plateforme partagée ou mesure liée au post-entraînement. Définissez ensuite les critères observables : pertinence des tests, qualité de la notation, comparabilité des essais et clarté des conclusions.

Distinguez les acquis indispensables des outils que le candidat pourra apprendre. Demandez une autonomie cohérente avec les décisions confiées. Ne confondez pas capacité à influencer un choix et pouvoir hiérarchique de l’imposer.

Un signal favorable est une définition précise des livrables attendus. Une alerte serait d’exiger simultanément toutes les spécialités sans pouvoir expliquer le besoin prioritaire.

2. Examiner une réalisation passée

Demandez au candidat de présenter un dispositif d’évaluation qu’il peut partager sans révéler de données confidentielles. Faites préciser son rôle personnel, l’usage testé, les données disponibles et la règle de réussite.

Examinez comment il a conservé les conditions d’exécution et analysé les écarts. Demandez un résultat surprenant et les vérifications qui ont suivi. Recherchez une explication de la variance, des défauts de tests ou des erreurs du correcteur.

Une démarche solide distingue ce qui a été observé de ce qui reste incertain. Une présentation limitée à un score final, sans conditions de mesure, appelle des questions complémentaires.

3. Proposer un cas pratique proche du poste

Exemple fictif : une équipe veut comparer deux modèles sur des réponses à des demandes clients et dispose de quelques cas anonymes préparés pour l’exercice.

Demandez au candidat de préciser la tâche et les critères d’acceptation. Invitez-le à identifier les cas limites manquants, puis à expliquer comment noter les réponses. Faites discuter les avantages des contrôles programmés, du jugement humain et d’un juge LLM.

S’il retient un juge LLM, demandez comment il le calibrerait contre des experts humains. Présentez un échec contestable et faites examiner les traces. Observez s’il distingue une mauvaise réponse d’une solution valide rejetée par le correcteur.

Adaptez la partie de programmation au poste. Pour une responsabilité de plateforme, demandez comment relancer la comparaison après un changement de modèle ou de code. Faites nommer les conditions et résultats à conserver.

Le signal favorable est une méthode justifiée, avec ses limites. L’alerte est la confiance accordée à un outil ou à un score sans examen de ce qu’il mesure.

4. Apprécier la coopération et la restitution

Demandez une courte recommandation destinée à un responsable produit. Faites expliciter la décision éclairée, les résultats disponibles et les réserves. Introduisez un désaccord entre score automatique et appréciation humaine pour observer la clarification des critères.

Si le poste comporte de la coordination, examinez comment le candidat répartirait les contributions techniques et métier. Évaluez le management hiérarchique seulement s’il figure réellement dans le poste.

Associez un responsable de l’usage à l’échange. Si l’entreprise manque d’expertise, faites examiner la démarche par un spécialiste technique capable de juger les mesures et le code.

5. Recouper les responsabilités exercées

Avec l’accord du candidat, demandez à ses références quelles évaluations il a personnellement conçues ou maintenues. Faites préciser sa réaction à une régression et la façon dont ses conclusions ont été comprises.

Comparez ces éléments aux besoins du poste. Décidez à partir de l’ensemble des observations, en consignant les compétences démontrées et les points qui demanderaient un accompagnement.