La scientifique des données

Beaucoup de personnes qui postulent à des postes en ingénierie de l’IA sont des scientifiques des données. Elles entraînent des modèles et conçoivent des expériences depuis des années. Beaucoup utilisent aussi des grands modèles de langage (LLM) au travail, souvent pour classer du texte. En lisant « contribuer à définir notre stratégie d’évaluation », elles pensent, avec raison : « Je sais faire ça. »

Ce profil est solide là où beaucoup d’ingénieurs ont des lacunes : définir ce qui est « bon » et le mesurer honnêtement. La lacune habituelle se trouve de l’autre côté. Souvent, une scientifique des données remet le modèle à un ingénieur, qui le fait fonctionner. Elle a donc rarement été responsable d’un service ou assuré la garde. L’entrevue de Mariana montre les deux côtés.

MC

La personne candidate

Mariana Costa

Scientifique des données, 5 ans d'expérience, en transition vers l'ingénierie de l'IA

• 5 ans comme scientifique des données
• Python, SQL, statistiques
• Maîtrise en statistiques
• Toronto

• Scientifique des données, Basketry (épicerie en ligne, environ 900 personnes), de 2021 à aujourd’hui
• Création de modèles de départ des clients et de demande hebdomadaire (gradient boosting, amplification par gradient) pour les équipes marketing et approvisionnement
• Conception et analyse de plus de 40 tests A/B; rédaction du guide de l’équipe sur la taille des échantillons et les règles d’arrêt
• Direction d’un projet de classification des plaintes clients par LLM en 14 catégories : 1 200 plaintes étiquetées, comparaison de 3 requêtes × 2 modèles, macro-F1 de 0,84 (modèle précédent : 0,71)
• Création et déploiement en production sous forme de traitement par lots chaque nuit, qui achemine environ 6 000 plaintes par jour
• Python (pandas, scikit-learn), SQL, Jupyter, dbt, Git, quelques connaissances de Docker

Ce que Nadia voit avant l’appel

Nadia lit le CV à côté de l’offre d’emploi. Le projet de plaintes contient des éléments qu’elle voit rarement dans ces CV. Il présente un jeu de données étiquetées de taille précisée, une comparaison d’options et une référence de base. Si ces éléments sont réels, Mariana peut combler la lacune la plus urgente de l’équipe : l’absence de cadre d’évaluation.

« Création et déploiement » la rend prudente. C’est une affirmation forte de quelqu’un dont les autres outils sont des carnets (notebooks) Jupyter et dbt. Nadia ne suppose pas que c’est faux. Mais le poste exige la responsabilité des fonctionnalités « du début à la fin ». Elle veut donc savoir exactement qui a fait quoi.

Sa courte liste pour l’appel :

• Les étiquettes sont-elles bonnes, et le test est-il honnête?
• De quoi était-elle responsable une fois le modèle prêt?
• Que fait-elle quand quelque chose tombe en panne en production?
• Peut-elle appliquer cette approche aux résumés de demandes d’indemnisation, qui sont du texte libre plutôt que 14 catégories?

L’offre mentionne le réglage fin, mais l’équipe n’en a jamais fait. Nadia ne l’évalue pas.

Termes utilisés dans cette page

• TF-IDF et régression logistique : un classificateur de texte simple et plus ancien. Il compte les mots présents, puis apprend un poids pour chacun.
• Macro-F1 : la moyenne des scores F1 de chaque catégorie. Une petite catégorie compte donc autant qu’une grande. Consultez Les métriques de classification.
• Kappa de Cohen : la fréquence à laquelle deux personnes s’entendent sur une étiquette, après avoir retiré l’accord attendu par hasard.
• dbt et Airflow : des outils utilisés par les équipes de données pour transformer les données dans une base de données (dbt) et exécuter des tâches selon un horaire (Airflow).
• Sortie structurée : le modèle doit répondre dans un format fixe, comme du JSON conforme à un schéma. Le code peut ainsi lire la réponse de façon sûre.
• Jeu de référence (golden set, jeu d’évaluation) : un ensemble fixe d’exemples avec les bonnes réponses fournies par des experts, utilisé pour mesurer chaque nouvelle version.
• Hallucination (affirmation non appuyée) : quelque chose que le modèle écrit, mais que la source ne dit pas.
• LLM comme juge (LLM-as-judge) : un modèle de langage qui note la sortie d’un autre modèle. Il fait ses propres erreurs. Vous vérifiez donc d’abord ses notes auprès de personnes.
• Récupération : trouver les parties pertinentes d’un long document et ne donner que celles-ci au modèle. La fenêtre de contexte est la quantité maximale de texte que le modèle peut lire en une fois.
• File d’attente et nouvelles tentatives avec délai d’attente croissant exponentiel et gigue : une file d’attente garde les tâches jusqu’à ce qu’un processus soit libre. Chaque nouvelle tentative attend plus longtemps que la précédente, par exemple 2, 4, puis 8 secondes. Un petit délai aléatoire supplémentaire empêche les appels échoués de tous réessayer en même temps.
• Mode fantôme (shadow mode) : le nouveau système traite des données réelles, mais aucun utilisateur ne voit sa sortie.

L’entrevue

Minutes 0 à 5 : le début

Nadia(intervieweur) :

Bonjour Mariana, merci d’avoir pris le temps. Je suis Nadia, ingénieure principale dans l’équipe Claims Intelligence. J’ai construit la majeure partie de notre extraction à la réception des dossiers. D’abord, j’aimerais entendre parler de quelque chose que vous avez construit. Je poserai beaucoup de questions pour approfondir. C’est normal. Ensuite, un problème que nous avons. Puis vos questions. Et comme l’invitation le disait, aucun assistant d’IA pendant cette étape. Les notes sur papier sont permises. Si je baisse les yeux, je prends simplement mes notes.

Mariana(personne candidate) :

D’accord, bien. Je dois préciser que je suis scientifique des données, pas ingénieure selon mon titre. Alors si j’utilise trop de termes de statistiques, arrêtez-moi.

Minutes 5 à 25 : le projet, puis les détails

Nadia(intervieweur) :

Bien sûr. Et vous pouvez m’arrêter si j’utilise trop de termes d’ingénierie. Choisissez un projet dont vous êtes fière et expliquez-le-moi.

Mariana(personne candidate) :

D’accord. Le classificateur de plaintes. Donc, Basketry reçoit environ 6 000 plaintes par jour, de l’application, par courriel et par clavardage. Avant, des règles par mots-clés les envoyaient aux équipes, et environ 30 % arrivaient à la mauvaise équipe. On le sait grâce aux réaffectations. Quand un agent transmet une plainte à une autre équipe, c’est enregistré. Et à chaque mauvaise affectation, le client attendait environ une journée de plus.

Alors avant toute requête (prompt), j’ai construit un jeu de données étiquetées. 1 200 plaintes, 14 catégories, comme livraison en retard, substitution, salubrité des aliments, facturation. J’en ai gardé 400 pour développer les requêtes et 800 pour le test final.

Nadia(intervieweur) :

Hum-hum. Et qu’avez-vous comparé?

Mariana(personne candidate) :

Trois requêtes sur deux modèles, un grand et un petit, moins cher. Et notre ancien modèle, TF-IDF avec régression logistique, qui avait un score macro-F1 de 0,71. La meilleure configuration a obtenu 0,84. Le petit modèle était presque pareil au grand, la différence était dans le bruit. Et il coûtait environ six fois moins cher. Alors on a choisi le petit.

Nadia(intervieweur) :

Et en production?

Mariana(personne candidate) :

Après six semaines en production, les réaffectations sont passées d’environ 30 % à environ 12 %.

Ce que l’intervieweur vérifie

Nadia entend plusieurs bons signes en quelques minutes. Il y a une référence de base et des données de test gardées à part. Il y a une mesure d’affaires et un choix fondé sur le coût. Elle commence par la base de tout : les étiquettes.

Nadia(intervieweur) :

Commençons par les étiquettes. Qui a étiqueté les 1 200 plaintes, et comment saviez-vous que les étiquettes étaient correctes?

Mariana(personne candidate) :

Moi et Inês, elle est cheffe d’équipe au soutien à la clientèle. D’abord, on a étiqueté les mêmes 300 plaintes, séparément. L’accord était… pas très bon. Un kappa de Cohen de 0,62.

Nadia(intervieweur) :

Sur quoi étiez-vous en désaccord?

Mariana(personne candidate) :

Surtout sur deux paires. La principale était « article manquant » contre « substitution ». Par exemple, quelqu’un commande du lait d’avoine, reçoit du lait d’amande et écrit « il manque mon lait d’avoine ». Pour nous, c’est une substitution, et ça va à une autre équipe. Alors on a ajouté une règle au guide : si autre chose est arrivé à sa place, c’est une substitution. Peu importe les mots du client. On a réécrit le guide, étiqueté 150 autres plaintes et obtenu 0,81.

Nadia(intervieweur) :

Et l’autre paire?

Mariana(personne candidate) :

« Remboursement non reçu » et « erreur de facturation ». Celle-là, on ne l’a jamais complètement réglée. Certaines plaintes sont vraiment les deux.

Pourquoi cela fonctionne

Mariana donne un exemple précis, la règle qui en découle et sa raison. Seule la personne qui a fait le travail connaît ces détails. Elle dit aussi ce qu’elle n’a pas résolu.

Nadia(intervieweur) :

Les 14 catégories étaient-elles équilibrées?

Mariana(personne candidate) :

Non, pas du tout. Les livraisons en retard représentaient environ 31 %. La salubrité des aliments, donc les allergènes, les aliments avariés, un objet dans la nourriture, c’était environ 2 %. Autour de 24 plaintes dans tout le jeu de données. Et c’est la catégorie la plus importante, parce que l’équipe qualité doit répondre dans les 24 heures. Alors j’ai présenté le rappel par catégorie, et j’ai lu chaque plainte de salubrité des aliments manquée.

Nadia(intervieweur) :

Ça fait peut-être 16 plaintes dans vos données de test. Quelle confiance pouvez-vous avoir dans le rappel sur 16 plaintes?

Mariana(personne candidate) :

Pas beaucoup. On en a détecté 14 sur 16, donc 88 %, mais l’intervalle à 95 % va environ de 64 à 97 %. Je l’ai mis dans le rapport. Mon gestionnaire n’était pas très content.

Nadia(intervieweur) :

Alors qu’avez-vous fait?

Mariana(personne candidate) :

On a cherché dans les archives avec des mots-clés et trouvé environ 60 autres plaintes probablement liées à la salubrité des aliments. On les a étiquetées et mesuré le rappel dessus. Mais je savais que ça nous faisait paraître meilleurs qu’on était, parce qu’une recherche par mots-clés trouve les cas faciles. Et je ne pouvais pas mesurer la précision du tout, parce que cet échantillon n’est pas aléatoire.

Pourquoi cela fonctionne

Un pourcentage tiré de 16 exemples est un intervalle, pas un seul nombre. Une recherche par mots-clés trouve surtout des plaintes faciles liées à la salubrité des aliments. Le rappel mesuré sur celles-ci paraît donc meilleur qu’il ne l’est. Elles ne montrent pas non plus à quelle fréquence le modèle indique à tort « salubrité des aliments ». Mariana connaît ces deux limites. Quillfield a besoin de cette compétence, car ses experts en sinistres peuvent étiqueter seulement quelques dossiers par semaine. Voir Le compromis entre précision et rappel.

Comment l’intervieweur va plus loin

Après trois niveaux de questions, Nadia n’a toujours pas trouvé la limite des connaissances de Mariana en évaluation. D’autres questions sur ce sujet ne lui apprendront pas grand-chose. Elle passe donc à la partie du CV dont elle est moins certaine.

Nadia(intervieweur) :

Votre CV dit que vous l’avez construit et déployé. Parlez-moi du côté production.

Mariana(personne candidate) :

Oui. Honnêtement, « déployé », c’est trop fort. J’ai écrit le code de classification, la requête et l’analyse des réponses, dans un module Python. Jonas, notre ingénieur en apprentissage automatique, en a fait une tâche Airflow exécutée chaque nuit. Il a aussi configuré la table où elle écrit. J’ai révisé sa demande de tirage (pull request), mais pour la logique, pas l’infrastructure. Je devrais corriger cette ligne.

Où cela tourne mal

« Déployé » sur son CV n’était pas vrai. Mariana le corrige tout de suite, donc cela lui coûte peu. Si elle le défendait, Nadia commencerait aussi à douter de son récit sur l’évaluation. Voir Acquérir de vraies compétences et apprendre à les expliquer.

Nadia(intervieweur) :

Merci d’être claire. Alors, à 2 h, que se passe-t-il quand le modèle renvoie autre chose qu’une de vos 14 catégories? Ou que l’appel échoue?

Mariana(personne candidate) :

Le premier cas, je le connais. On utilisait une sortie structurée stricte, donc la catégorie est toujours une des 14. Les 0,3 % d’échecs étaient des refus et des réponses… comment dire, coupées à la limite de longueur. Ces cas retournent aux anciennes règles par mots-clés.

Nadia(intervieweur) :

Et l’échec de l’appel? Avez-vous déjà reçu une alerte de garde pour ça?

Mariana(personne candidate) :

Pardon, de garde? Ah, vous voulez dire l’alerte, quand on est de garde. Non, jamais. Je crois que Jonas a ajouté des nouvelles tentatives. Mais combien, ou ce qui arrive si toute la nuit échoue, je ne sais pas.

Ce que l’intervieweur vérifie

Recevoir une alerte de garde, c’est recevoir une alerte comme ingénieur de garde. Mariana demande ce que le terme signifie, et c’est tout à fait correct. Votre français n’a pas besoin d’être parfait; la personne qui mène l’entrevue écoute votre raisonnement. Voici le premier signe de sa limite : elle sait comment la sortie peut être erronée, mais pas comment le système peut tomber en panne. Nadia le garde pour plus tard.

Nadia(intervieweur) :

Une dernière question là-dessus. Six mois plus tard, comment savez-vous que ça fonctionne encore?

Mariana(personne candidate) :

Chaque mois, Inês et moi étiquetons 100 plaintes prises au hasard dans le dernier mois. Et je surveille la répartition des catégories par jour. En mars, les substitutions sont passées d’environ 9 % à… 15 %, je pense, en une semaine. Ça pouvait être réel, il y avait une pénurie de produits laitiers. Mais j’ai retraité cette semaine avec l’ancienne version du modèle, et c’était le modèle. Le fournisseur avait mis à jour le modèle derrière le nom qu’on appelait. Depuis, on fixe la version exacte, et on teste avant de changer.

Pourquoi cela fonctionne

C’est une vraie surveillance. Il y a un échantillon étiqueté régulier et un signal peu coûteux qui indique un changement. Ensuite, une vérification montre si le monde a changé ou si le modèle a changé.

Minutes 25 à 48 : le problème de Quillfield

Nadia(intervieweur) :

Voici un vrai problème de notre côté. Un dossier de réclamation arrive : 20 à 60 pages, des formulaires numérisés, les notes de l’expert en sinistres, des courriels, des photos, une estimation d’entrepreneur. Les experts nous disent qu’ils passent environ 40 minutes à lire un dossier avant de pouvoir agir. Nous voulons leur donner une ébauche de résumé d’une page : les faits clés, les questions ouvertes et ce qui manque. Comment aborderiez-vous ça?

Mariana(personne candidate) :

Hmm. Avant les modèles, je veux savoir comment on va l’évaluer. Donc, qui le lit, et quand? Et quelle est la pire erreur? Omettre un fait ou dire quelque chose qui n’est pas dans le dossier? Parce que ça demande des mesures différentes.

Nadia(intervieweur) :

L’expert en sinistres, avant le premier contact avec le client. Les pires erreurs sont un fait erroné, comme la date du sinistre, ou l’omission de dommages antérieurs ou d’une exclusion mentionnée dans le dossier. Et le résumé n’est jamais la seule base d’une décision. L’expert confirme.

Mariana(personne candidate) :

D’accord. Alors je n’évaluerais pas le résumé comme un seul texte. Je le diviserais en faits, avec trois types d’erreurs. Un fait clé manque, un fait est erroné ou une affirmation n’est appuyée par aucune page.

Nadia(intervieweur) :

Hum-hum. Et la partie « ce qui manque »?

Mariana(personne candidate) :

Celle-là, je l’évaluerais comme un classificateur. A-t-il indiqué ce qui manque vraiment, et seulement ça? C’est plus facile à vérifier qu’un texte libre. Et chaque phrase devrait renvoyer à sa page. Alors « est-ce appuyé » devient une question sur une page, pas 60. Mais les bonnes réponses doivent venir de vos experts en sinistres. Combien de temps ont-ils, vraiment?

Nadia(intervieweur) :

Honnêtement? Environ quatre heures par semaine à eux deux, au total. Et la majeure partie sert à l’échantillon hebdomadaire de dossiers reçus.

Ce que l’intervieweur vérifie

Mariana conçoit le jeu de référence avant toute requête. Elle demande aussi combien de temps les experts ont, ce que l’offre ne mentionne pas.

Mariana(personne candidate) :

Quatre heures. D’accord, donc chaque dossier étiqueté est très précieux. Personne ne devrait écrire de résumés idéaux, c’est lent et difficile à comparer. Je demanderais une liste de vérification par dossier. Les 10 ou 15 faits qu’un expert doit voir, plus ce qui manque. Peut-être 15 minutes par dossier, une fois qu’ils ont l’habitude. Si j’obtiens deux de ces heures, ça donne environ 8 dossiers par semaine. Et les 32 champs d’extraction que vous étiquetez déjà sont des faits sans travail supplémentaire. Alors je commencerais avec ces dossiers.

Nadia(intervieweur) :

Quels dossiers choisiriez-vous?

Mariana(personne candidate) :

Pas au hasard. Un échantillon stratifié. Habitation et automobile, blessures et dommages matériels seulement, courts et longs, bonnes et mauvaises numérisations, plusieurs assureurs. Je prendrais plus de réclamations avec blessures et de mauvaises numérisations, là où je prévois des erreurs. Puis je corrigerais la pondération pour tout résultat global. Environ un dossier sur cinq va aux deux experts, pour savoir à quel point ils sont d’accord. Ah, et les dossiers avec blessures contiennent des renseignements de santé. Alors je vérifierais qui peut les voir pour l’étiquetage, et où le jeu de données est stocké.

Pourquoi cela fonctionne

Mariana adapte son plan aux quelques heures des experts et réutilise les étiquettes existantes. Elle choisit davantage de réclamations avec blessures et de mauvaises numérisations, car les erreurs y sont probables. Ensuite, elle corrige le score global pour que ces dossiers difficiles supplémentaires ne le fassent pas paraître pire qu’il est. Elle soulève aussi la question des renseignements de santé sans qu’on le lui demande.

Nadia(intervieweur) :

Huit dossiers par semaine, c’est très peu. Vous changerez la requête plus souvent que ça. Comment vérifiez-vous le reste?

Mariana(personne candidate) :

Un LLM juge, pour une partie. « Cette phrase est-elle appuyée par la page qu’elle cite », c’est une question précise. Je pense qu’un juge peut bien le faire. Mais je le mesurerais d’abord contre les étiquettes des experts, comme je l’ai fait pour Inês et moi. Et par type de réclamation, parce qu’il est peut-être bon pour l’automobile et mauvais pour les blessures.

Nadia(intervieweur) :

Et pour les faits manquants?

Mariana(personne candidate) :

Là, je fais moins confiance à un juge. Pour savoir ce qui manque, il faut savoir ce qui compte pour un expert en sinistres. Ça reste avec la liste de vérification des experts.

Les prochaines minutes, en bref

Elles discutent du choix entre donner tout le dossier au modèle et en récupérer certaines parties. Mariana dit qu’elle n’a pas construit de système de récupération. Elle propose de tester les deux sur le jeu de référence. Elle veut aussi vérifier si les faits omis se trouvent plus souvent au milieu des longs dossiers. Nadia confirme que l’équipe déciderait de cette façon. Puis elle change de direction.

Nadia(intervieweur) :

Je passe maintenant à un autre sujet. Disons que le jeu de référence donne de bons résultats et que vous êtes en production. Les résumés sont générés à la réception, pour environ 9 000 dossiers par jour. Au pic du matin, environ 3 % des appels au modèle dépassent le délai d’attente. Que se passe-t-il, et que faites-vous?

Mariana(personne candidate) :

On les réessaie. Mais… si le délai expire parce que le fournisseur est occupé au pic, réessayer immédiatement ajoute de la charge au pire moment. Alors attendre un peu avant? Honnêtement, je ne suis pas sûre de la méthode habituelle.

Nadia(intervieweur) :

Et les dossiers où les nouvelles tentatives échouent aussi?

Mariana(personne candidate) :

Alors l’expert ouvre la réclamation et il n’y a pas de résumé. Je voudrais qu’il voie « résumé non disponible », pas un demi-résumé. Ensuite, il lit le dossier comme aujourd’hui. Après ça… je n’ai jamais conçu cette partie. Chez Basketry, Jonas l’aurait fait.

Nadia(intervieweur) :

Une nouvelle tentative peut-elle causer son propre problème?

Mariana(personne candidate) :

Vous voulez dire que ça coûte plus cher?

Nadia(intervieweur) :

Pardon, je n’étais pas claire. Je veux dire, est-ce que la nouvelle tentative peut changer ce qui finit par être stocké?

Mariana(personne candidate) :

Ah. Hmm. Peut-être que le premier appel a terminé, mais en retard, et maintenant il y a deux résumés pour un dossier? Donnez-moi une seconde.

Pause.

Non, je ne sais pas ce que vous feriez pour ça. Je regarderais comment l’extraction à la réception gère ce cas, parce qu’elle traite déjà les mêmes dossiers.

La limite

Voilà la limite. Mariana la gère bien. Elle n’invente pas de méthode et indique le système qui résout déjà le problème. Mais « Jonas l’aurait fait » représente un risque, car ici l’ingénieur en IA est responsable de la fonctionnalité en production. Nadia écrit un mot : « responsabilité ».

Une meilleure réponse

Mariana en savait plus qu’elle ne l’a montré. Elle avait dépendu de tâches par lots pendant des années. Une réponse plus forte part de cette expérience et dit clairement où elle s’arrête :

« Je n’en ai pas eu la responsabilité, alors laissez-moi raisonner à partir de la tâche par lots que je connais. Chez Basketry, les résultats étaient écrits par identifiant de plainte. Si la tâche s’exécutait à nouveau, elle remplaçait les lignes, elle n’en ajoutait pas. Je voudrais la même chose ici. Une tâche de résumé par dossier, avec l’identifiant du dossier et la version de la requête comme clé. Comme ça, l’exécuter deux fois donne un résultat, pas deux. Je pense que les ingénieurs appellent ça idempotent : le faire deux fois revient à le faire une seule fois. Et un délai expiré de mon côté ne veut pas dire que le fournisseur a arrêté. On peut payer les deux appels, et celui en retard peut encore écrire un résultat. C’est pourquoi l’écriture doit utiliser une clé.

À la réception, personne n’attend. L’expert ouvre la réclamation des heures plus tard. Alors je ne lutterais pas contre le pic. Je mettrais les tâches dans une file d’attente et limiterais le nombre d’appels simultanés. Je réessaierais un appel échoué après une attente qui augmente chaque fois. Avec un peu de hasard, pour qu’ils ne reviennent pas tous ensemble. Après trois ou quatre tentatives, il va dans une liste d’échecs, et l’expert voit “résumé non disponible”. Quelqu’un reçoit une alerte si cette liste dépasse un niveau convenu. Ensuite, je mesurerais le taux d’échec par heure et le temps d’attente des dossiers. Je suis sûre qu’il me manque des détails, alors je demanderais comment l’extraction à la réception fait ça. »

Cette réponse ne prétend pas venir d’une experte. Elle utilise son propre travail comme preuve.

Nadia(intervieweur) :

D’accord, arrêtons là sur ce sujet. Encore une question : comment le mettriez-vous à la disposition des experts en sinistres?

Mariana(personne candidate) :

Ah, ça, j’aime. D’abord, en mode fantôme. Générer des résumés pour de vrais dossiers, ne les montrer à personne et évaluer un échantillon avec les experts. Ensuite, un assureur pour le projet pilote.

Nadia(intervieweur) :

Et comment savez-vous que ça économise les 40 minutes?

Mariana(personne candidate) :

Je ferais une répartition aléatoire par expert, pas par réclamation. Si un expert reçoit des résumés pour certaines réclamations seulement, il commence à lire toutes les réclamations différemment. Alors la différence ne veut plus rien dire. Je mesurerais le temps de lecture, mais aussi la fréquence des corrections de faits, avec un bouton dans l’interface. Et une règle d’arrêt. Si les corrections de faits erronés dépassent un taux convenu, on fait une pause.

Retour à son point fort

Choisir l’expert en sinistres comme unité de l’expérience évite un vrai piège. C’est aussi un plan de mise en production, donc cela répond en partie à la question précédente. Pour le côté ingénierie, voir Mise en production progressive.

Minutes 48 à 57 : les questions de Mariana

Mariana(personne candidate) :

L’échantillon hebdomadaire de 200 dossiers pour l’extraction. Comment est-il choisi? Et l’exactitude a-t-elle changé pendant les 14 mois?

Nadia(intervieweur) :

Au hasard, par jour. L’exactitude par champ est autour de 94 %, et assez stable. Mais elle baisse sur les formulaires manuscrits, et un échantillon aléatoire en contient peu. Honnêtement, après ce que vous avez dit plus tôt, je pense qu’on devrait le stratifier.

Mariana(personne candidate) :

Qui décide quand le résumé est assez bon pour être mis en production? Y a-t-il un chiffre convenu avec l’équipe produit?

Nadia(intervieweur) :

Non. Personne n’a décidé ça. Nous n’avons pas de cadre d’évaluation commun. Chaque fonctionnalité était mesurée à sa façon. C’est une grande partie de la raison pour laquelle nous embauchons.

Pourquoi cela fonctionne

Ces questions amènent Nadia à dire deux choses vraies que l’offre ne dit pas. L’échantillon a un angle mort, et le cadre d’évaluation n’existe pas. Voir Une entrevue est une conversation dans les deux sens.

Mariana(personne candidate) :

Si quelque chose que j’ai construit tombe en panne la nuit, qui reçoit l’appel? Est-ce que ce serait moi? Parce que je n’ai jamais été de garde.

Nadia(intervieweur) :

Oui, après un certain temps. Une semaine sur six, surtout pour le pipeline d’extraction et le projet pilote d’assistant aux polices d’assurance. Les nouvelles personnes accompagnent d’abord quelqu’un pendant deux rotations. La plupart des semaines sont calmes. Certaines ne le sont pas.

Mariana(personne candidate) :

D’accord, merci. Et comment est la culture de l’équipe?

Nadia(intervieweur) :

Amicale, assez directe. Nous débattons des conceptions davantage dans des documents qu’en réunion.

Où cela tourne mal

La dernière question est trop générale pour obtenir une vraie réponse. Une question précise fonctionne mieux : « Parlez-moi du dernier désaccord de l’équipe sur une conception. Comment ça s’est terminé? »

Minutes 57 à 60 : la conclusion

Nadia(intervieweur) :

Merci, Mariana. J’ai apprécié la discussion, surtout le récit sur l’étiquetage. Hannah vous contactera cette semaine pour les prochaines étapes. La prochaine étape serait la conception de systèmes avec Owen.

Mariana(personne candidate) :

Merci. Et je vais corriger la ligne « déployé » avant que quelqu’un d’autre la lise.

Après l’appel : les notes de Nadia

Candidate : Mariana Costa. Entrevue technique approfondie, 60 minutes.

Preuves solides

• Stratégie d’évaluation. La meilleure que j’ai entendue pour ce poste. Types d’erreurs par fait, échantillonnage stratifié, accord entre experts, LLM évaluateur vérifié auprès des experts. Planifiée selon quatre heures de travail d’expert par semaine.
• Conception d’expériences. Données de test réservées, intervalles honnêtes pour les petites classes. Répartir aléatoirement par expert en sinistres : un piège dans lequel nous aurions pu tomber.
• Honnêteté. A corrigé son propre CV (« déployé » décrivait le travail de l’ingénieur en apprentissage automatique) dès la première question.

Quelques preuves

• Python. A écrit le classificateur sous forme de module, fixe les versions des modèles. Aucun test mentionné, aucun service à elle.
• Récupération dans de longs documents. N’en a pas construit. A transformé la question en une expérience rigoureuse.

Aucune preuve

• API, FastAPI, Azure, CI/CD (intégration et déploiement continus). Non abordés; « un peu de Docker » sur le CV.

Préoccupation

• Responsabilité en production. A atteint ses limites sur les délais d’expiration, les nouvelles tentatives et les exécutions en double. Honnête, n’a pas fait semblant de savoir. Mais elle n’a jamais été responsable d’un service en fonctionnement. Ce poste comprend cette responsabilité, y compris les gardes.

Recommandation : passer à la conception de systèmes. Forte sur la partie la plus difficile de ce poste (l’évaluation), faible sur la responsabilité en production. Owen : consacrez surtout le temps à un pipeline traitant 9 000 dossiers par jour, aux défaillances et à ce que voit alors l’expert en sinistres. Si elle peut raisonner là-dessus avec un peu d’aide, je l’embaucherais au niveau intermédiaire avec un plan de mentorat.

La suite

Avant l’entrevue de conception de systèmes, Mariana a demandé à Jonas de lui montrer le traitement de nuit chez Basketry. Il lui a montré les nouvelles tentatives, un verrou empêchant deux exécutions simultanées et une alerte que personne n’avait jamais reçue.

Avec Owen, elle a conçu une file de tâches identifiées par l’ID du dossier. Elle a expliqué pourquoi une nouvelle exécution ne doit pas créer un deuxième résumé. Il a dû l’aider à prévoir la capacité nécessaire pour la pointe du matin. Sa note disait « apprend vite; pas encore de niveau sénior ». La discussion sur les valeurs avec Sofia s’est très bien passée.

Pendant le bilan, tout le monde convenait que Mariana améliorerait la qualité de l’évaluation pour toute l’équipe. Elle aurait aussi besoin d’environ six mois de soutien pour assumer seule la responsabilité d’un service. L’équipe avait un seul poste vacant. Il est allé à une autre personne finaliste, dont l’expertise en sinistres était introuvable ailleurs. Marcus a ensuite demandé à son directeur un deuxième poste de niveau intermédiaire, au bas de l’échelle salariale. Ce poste serait axé sur le cadre d’évaluation et les mesures, en collaboration avec la nouvelle recrue sur le résumé. Mariana travaillerait en binôme avec Nadia sur le pipeline et observerait les gardes pendant deux rotations.

Au moment d’écrire ces lignes, le budget pour ce poste n’est pas encore décidé. Hannah l’a dit directement à Mariana et lui a donné une date. Mariana continue de passer des entrevues ailleurs, et c’est la bonne chose à faire.

Cette issue est courante. Une personne peut exceller dans une partie du travail pendant le processus sans obtenir le seul poste offert. La décision dépend maintenant d’un budget, pas de Mariana. Cela fait partie du rôle de la chance dans l’embauche. Mais son entrevue a changé quelque chose : l’équipe veut maintenant un poste qui n’existait pas auparavant.

Ce qu’il faut retenir

• Une expertise approfondie dans un domaine peut vous faire avancer. Mariana ne connaissait pas les nouvelles tentatives. Mais ses réponses sur l’évaluation étaient assez précises pour que Nadia la recommande.
• Corrigez votre propre CV avant la personne qui vous interviewe. Comme elle l’a dit en premier, cela ne lui a presque rien coûté.
• Quand vous atteignez vos limites, partez de votre expérience. Elle dépendait de traitements par lots depuis des années. Une réponse plus forte s’appuie là-dessus, puis précise où cette expérience s’arrête.
• Posez des questions qui révèlent le vrai travail. Ses questions ont montré ses compétences et lui ont appris en quoi consiste le poste.

Si votre profil ressemble à celui de Mariana

Vos compétences en évaluation sont rares en ingénierie de l’IA. Ce qui vous manque, c’est la responsabilité d’un service. Vous pouvez combler vous-même une grande partie de cet écart.

1. Livrez un de vos modèles sous forme de petit service. Rendez-le accessible par une API, écrivez des tests, placez-le dans un conteneur et ajoutez un pipeline qui exécute les tests. Nos cours Créer et déployer votre première API, L’essentiel de Docker et du nuage pour les développeurs en IA et CI/CD, tests et mises en production sûres vous guident à chaque étape.
2. Faites échouer un traitement par lots volontairement. Appelez un modèle pour 1 000 éléments et faites expirer 3 % des appels. Ajoutez ensuite des nouvelles tentatives avec un délai d’attente croissant et des résultats identifiés par l’ID de l’élément. Ainsi, une nouvelle exécution sera sûre. Ajoutez aussi une liste des éléments en échec et un décompte quotidien. Dans le README, décrivez ce qui se passe pour chaque défaillance.
3. Demandez à l’ingénieur qui déploie votre travail de vous montrer comment il fonctionne : ce qui échoue, comment il le sait et qui reçoit l’alerte.
4. Intégrez votre évaluation au processus de mise en production. Un jeu de référence qui bloque une mise en production quand la qualité baisse relie votre force à la production. Consultez Barrière d’évaluation de l’IA.
5. Exercez-vous à raconter votre travail d’évaluation à voix haute, avec les chiffres, les décisions et les limites. Consultez Expliquer vos décisions.
6. Relisez votre CV, verbe par verbe. Pour chaque « construit », « déployé » ou « dirigé », demandez-vous ce que vous avez fait exactement et ce que les autres ont fait.