L'ingénieur backend

Beaucoup de candidats aux postes d’ingénieur en IA viennent de l’ingénierie backend (côté serveur). Ils ont exploité des services en production pendant des années. Puis leur entreprise leur a demandé une fonctionnalité avec un LLM (un grand modèle de langage, qui lit et écrit du texte). Ils ont aimé ce travail.

Ce profil est solide là où beaucoup de candidats en IA sont faibles : la production. La lacune habituelle concerne l’autre moitié du travail : comment savoir si la sortie est correcte? Un LLM peut écrire un texte fluide et faux à la fois.

Daniel est ce candidat. Marcus Chen, le gestionnaire responsable de l’embauche, participe aussi à l’appel. Nous observons comment Nadia trouve les limites des connaissances de Daniel. Nous observons aussi sa réaction quand une personne haut placée affirme quelque chose de faux avec assurance.

DM

La personne candidate

Daniel Mensah

Ingénieur backend, 7 ans d'expérience, en transition vers l'IA

• 7 ans en backend
• Python et Go
• De garde depuis 6 ans
• Toronto

• Ingénieur logiciel principal, Ledgerline (paiements, 600 personnes), de 2019 à aujourd’hui
• A créé et exploité un outil de résumé de longs billets de soutien, basé sur un LLM; 120 agents l’utilisent; temps moyen de traitement réduit d’environ 20 %
• A conçu la limitation du débit, les nouvelles tentatives, la mise en cache et un tableau de bord des coûts pour tous les appels LLM; satisfaction des agents de 85 %
• Responsable des services de rapprochement des versements en Go; de garde depuis 2020; a dirigé plus de 30 analyses d’incidents
• Projet personnel : réponses aux questions (RAG) sur les données ouvertes du transport en commun de Toronto, sur GitHub
• Python, Go, FastAPI, PostgreSQL, Kafka, Kubernetes, AWS

Ce que Nadia voit avant l’appel

Nadia lit le CV à côté de l’offre d’emploi. Les preuves de ses compétences en ingénierie de production sont solides. Daniel a environ un an d’expérience avec des LLM en production, pas les « 2 ans ou plus » de l’offre. Mais un an avec de vrais utilisateurs peut enseigner plus que deux ans de démonstrations.

Elle relève une ligne dans ses notes : « satisfaction des agents de 85 % ». La satisfaction ne garantit pas l’exactitude. L’évaluation est la partie la plus urgente du poste. Elle prévoit donc de l’explorer en profondeur.

Elle veut savoir :

• Daniel a-t-il conçu lui-même les mécanismes de fiabilité, et sait-il pourquoi chaque partie fonctionne?
• Comment savait-il que les résumés étaient corrects, et pas seulement appréciés?
• Comment envisage-t-il un résumé de demande d’indemnisation aux volumes de Quillfield?

Termes utilisés sur cette page

• RAG (génération augmentée par récupération) : le système trouve les parties pertinentes de vos documents et donne seulement ces parties au modèle.
• Jeton (token) : un petit morceau de texte, souvent une partie d’un mot. Les fournisseurs facturent par jeton.
• Fenêtre de contexte : la quantité maximale de texte, en jetons, qu’un modèle peut lire dans une seule requête.
• Latence p95 : 95 % des requêtes se terminent plus vite que ce délai.
• Jeu d’évaluation (ou jeu de référence) : un ensemble fixe d’exemples dont les réponses ont été vérifiées par des personnes. Chaque nouvelle version est testée avec cet ensemble.
• LLM comme juge : un deuxième modèle qui note la sortie du premier modèle.
• Limite de débit (et 429) : le fournisseur autorise un nombre limité de requêtes ou de jetons par minute. Au-delà, il renvoie l’erreur 429, « trop de requêtes ».
• Délai d’attente croissant exponentiel : après un appel échoué, attendez avant de réessayer, et doublez l’attente chaque fois.
• ROC (reconnaissance optique de caractères) : logiciel qui transforme une page numérisée en texte, avec quelques erreurs.
• Mise en cache des requêtes (prompts) : le fournisseur conserve le début répété d’une requête. Les appels suivants avec le même début coûtent donc moins cher.

L’entrevue

Minutes 0 à 5 : l'ouverture

Nadia(intervieweur) :

Bonjour Daniel, merci d’avoir pris le temps. Je suis Nadia, ingénieure experte dans l’équipe Claims Intelligence. J’ai construit la majeure partie de notre extraction à la réception. Et vous connaissez Marcus depuis la semaine dernière.

Marcus(intervieweur) :

Bonjour Daniel. Aujourd’hui, je fais seulement écouter. Parlez simplement à Nadia.

Nadia(intervieweur) :

Alors, voici le plan. D’abord, j’aimerais entendre parler d’un projet que vous avez construit. Je poserai beaucoup de questions pour approfondir. C’est normal. Ensuite, un problème que nous avons. Puis vos questions. Ah, et comme l’invitation le disait, pas d’assistants d’IA pour cette entrevue. Les notes sur papier sont permises.

Daniel(personne candidate) :

D’accord, ça me va. Juste pour vous prévenir, je vais probablement poser une question sur les gardes à la fin.

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

Nadia(intervieweur) :

Choisissez un projet dont vous êtes fier et expliquez-moi comment vous l’avez réalisé.

Daniel(personne candidate) :

Bien sûr. Alors, chez Ledgerline, le soutien aux commerçants traite les versements échoués, les litiges, les vérifications de compte. Les billets de soutien difficiles deviennent longs, comme 50, 100 messages. Le commerçant, quelques agents, des notes internes, des robots. Quand un nouvel agent prenait un billet, il passait environ huit minutes juste à comprendre la situation. Donc, l’année dernière, j’ai construit un outil de résumé. Il place un court résumé en haut du billet : ce que le commerçant veut, nos actions, les points encore ouverts.

Nadia(intervieweur) :

Hum-hum. Et comment fonctionne-t-il?

Daniel(personne candidate) :

Un service Python, FastAPI, une file d’attente et quelques processus, et il appelle un LLM hébergé. Honnêtement, mon travail portait surtout sur ce qui entoure l’appel, pas sur la requête (prompt). Limitation du débit, nouvelles tentatives, cache, tableau de bord des coûts.

Nadia(intervieweur) :

Combien de personnes l’utilisent?

Daniel(personne candidate) :

Environ 120 agents. Je pense qu’on produit environ 4 000 résumés par jour, ça varie. Et le résultat : les opérations de soutien l’ont donné à trois de leurs six équipes pendant six semaines. Le temps de traitement a baissé d’environ 20 % dans ces équipes. Dans les autres équipes, environ 2 %, donc presque rien.

Ce que l’intervieweur vérifie

Nadia repère les décisions dans le récit. Chaque décision mène à sa prochaine question. Le résultat de Daniel comprend un groupe de comparaison. Il est donc plus crédible qu’un chiffre avant-après. Nadia pourrait quand même demander comment les opérations de soutien ont choisi les trois équipes.

Nadia(intervieweur) :

D’accord, merci. Commençons par le moment de la génération. Le résumé est-il généré quand l’agent ouvre le billet?

Daniel(personne candidate) :

Dans la première version, oui. Et c’était lent. Le p95 était… environ six secondes, je pense. Les agents détestaient ça.

Nadia(intervieweur) :

Alors, qu’avez-vous changé?

Daniel(personne candidate) :

Maintenant, un nouveau message place un événement dans une file d’attente. On attend deux minutes, parce que les messages arrivent par groupes, puis on génère le résumé. Quand l’agent ouvre le billet, il reçoit le résumé enregistré. S’il manque, on en crée un à la demande. Maintenant, environ 90 % des ouvertures affichent un résumé en moins d’une seconde.

Nadia(intervieweur) :

Et quand le fournisseur est lent, ou qu’il limite votre débit?

Daniel(personne candidate) :

Hmm. D’accord, il y a quelques éléments. Un seau à jetons, dimensionné selon notre limite de jetons (tokens) par minute. Il a deux voies. Si un agent attend, sa requête passe en premier. Le travail en arrière-plan utilise ce qui reste.

Nadia(intervieweur) :

Hum-hum. Et les nouvelles tentatives?

Daniel(personne candidate) :

Un délai d’attente croissant exponentiel avec gigue. Trois nouvelles tentatives au maximum, je pense, oui, trois. Sur une réponse 429, on respecte l’en-tête Retry-After. Ah, et il y a un disjoncteur. Si trop d’appels échouent, on arrête les appels pendant trente secondes. La page affiche le dernier résumé avec « may be out of date » (peut ne plus être à jour).

Nadia(intervieweur) :

Pourquoi le disjoncteur?

Daniel(personne candidate) :

À cause d’un incident, en fait. Au début, on appelait le modèle pendant le chargement de la page. Le fournisseur a ralenti, et toute la page du billet est restée bloquée. Ma faute. Donc maintenant, la page du billet n’attend jamais le résumé.

Pourquoi cela fonctionne

Daniel donne des détails. Il parle aussi d’une défaillance qu’il a causée et corrigée. Un disjoncteur arrête brièvement les appels à un service défaillant, pour empêcher la défaillance de se propager. La gigue ajoute un petit délai aléatoire à chaque nouvelle tentative. Ainsi, les clients ne réessaient pas tous au même moment.

Nadia(intervieweur) :

Les billets longs, avec cent messages. Envoyez-vous toute la conversation chaque fois?

Daniel(personne candidate) :

Non, pour réduire les coûts. On envoie le résumé précédent et les nouveaux messages, et le modèle le met à jour. Sur les longues conversations, ça coûte beaucoup moins cher.

Nadia(intervieweur) :

Que se passe-t-il si le résumé précédent contient une erreur?

Daniel(personne candidate) :

Oui. Elle se propage. On a eu un cas : un agent a signalé un remboursement de 1 200 dollars, mais c’était vraiment 120. L’erreur est restée pendant, je pense, six mises à jour. Alors maintenant, on reconstruit le résumé à partir de toute la conversation toutes les dix mises à jour. Et quand un billet est rouvert.

Nadia(intervieweur) :

Pourquoi dix?

Daniel(personne candidate) :

Honnêtement? Ça semblait raisonnable. Ça coûtait environ 15 % de plus. Je n’ai pas mesuré le taux d’erreur avant et après.

Comment l’intervieweur va plus loin

Chaque question découle de la dernière réponse. Daniel a économisé de l’argent au prix d’une certaine fiabilité. Mais il n’a pas mesuré cette perte de fiabilité. C’est ainsi que Nadia arrive à l’évaluation.

Nadia(intervieweur) :

Restons là-dessus. Comment saviez-vous que les résumés étaient bons?

Daniel(personne candidate) :

Chaque résumé a un pouce vers le haut et un pouce vers le bas. On avait environ 85 % de pouces vers le haut. Et le temps de traitement a baissé de 20 %, donc… ils étaient utiles.

Où cela tourne mal

Les pouces et le temps de traitement montrent que les agents aiment les résumés et les utilisent. Ils ne montrent pas que les résumés sont corrects. Un résumé rapide mais erroné fait aussi gagner du temps, jusqu’à ce qu’il entraîne un mauvais remboursement.

Nadia(intervieweur) :

Combien de résumés ont reçu un vote, au total?

Daniel(personne candidate) :

Hm. Au début, peut-être un sur cinq? Plus tard, moins. Les gens votent les premières semaines, puis ils arrêtent.

Nadia(intervieweur) :

Et les pouces vers le bas, qu’est-ce qu’ils signalaient?

Daniel(personne candidate) :

J’en ai lu peut-être trente. Surtout du contexte manquant, quelque chose d’important pour l’agent qui n’était pas là. Quelques montants erronés. Et un dont je me souviens bien. Il disait que le commerçant avait reçu le remboursement, mais l’agent avait seulement promis un remboursement.

Nadia(intervieweur) :

Ce dernier cas. Promis plutôt qu’effectué. Ça arrive combien de fois dans les résumés avec un pouce vers le haut, ou sans vote?

Daniel(personne candidate) :

Je… donnez-moi une seconde.

Non. Je ne sais pas. On n’a jamais lu ceux avec un pouce vers le haut. Et si un agent fait confiance au résumé, il ne voit jamais l’erreur, donc il ne vote jamais contre. Les pouces ne peuvent pas me dire ça. C’est… oui, c’est une vraie lacune.

La limite de ses connaissances

Daniel atteint ici la limite de ses connaissances. Il demande un moment, dit « je ne sais pas » et explique pourquoi sa mesure ne peut pas répondre. Il ne défend pas les 85 %.

Nadia(intervieweur) :

Ça va. Disons que vous avez deux semaines pour le découvrir. Que feriez-vous?

Daniel(personne candidate) :

D’accord, je vais réfléchir à voix haute. Un échantillon, peut-être 200 résumés, de conversations courtes et longues. Un agent expérimenté lit toute la conversation et vérifie le résumé ligne par ligne. Chaque affirmation est-elle dans la conversation, ou est-elle fausse? Et ensuite, séparément, qu’est-ce qui manque?

Nadia(intervieweur) :

D’accord. Et ensuite?

Daniel(personne candidate) :

Ensuite, j’ai des nombres. Les faits erronés, les faits manquants. Et « promis plutôt qu’effectué » dans son propre groupe, parce que ça coûte de l’argent. Je garderais les mêmes 200 et testerais chaque changement de requête ou de modèle sur eux. Actuellement, on regarde simplement une vingtaine de billets à la main. C’est à peu près comme ça que les gens font?

Nadia(intervieweur) :

C’est proche de ce qu’on fait à la réception. Un niveau de plus. Deux agents expérimentés lisent la même conversation. L’un dit que le résumé omet quelque chose d’important, l’autre dit qu’il est correct. Que faites-vous?

Daniel(personne candidate) :

Hmm. Leur donner les mêmes cinquante, et voir à quelle fréquence ils sont d’accord? S’ils sont souvent en désaccord, le problème est le sens du mot « important », pas le modèle. Il existe une statistique pour ça, pour l’accord… Je ne l’ai jamais utilisée.

Nadia(intervieweur) :

Le kappa de Cohen, pour deux personnes. Mais vous avez l’essentiel. Si les gens ne s’entendent pas, vous ne pouvez pas mesurer le modèle. D’accord, passons à un de nos problèmes.

Une meilleure réponse

Daniel arrive à une bonne réponse, mais seulement après plusieurs questions. Avec un peu de préparation, il peut la donner dès la première question :

« Honnêtement, seulement en partie. Les pouces montrent que les agents l’aimaient, et le temps de traitement montre qu’ils l’utilisaient. Aucun des deux ne m’indique à quelle fréquence un résumé est faux. Dans ceux avec un pouce vers le bas, j’ai trouvé du contexte manquant, des montants erronés et un remboursement promis présenté comme effectué. Ce dernier type m’inquiète le plus, parce qu’un agent qui fait confiance au résumé ne le voit jamais. Si je le reconstruisais, je commencerais avec 200 conversations étiquetées par deux agents expérimentés. À chaque changement, je compterais les affirmations erronées, manquantes et sans appui dans la conversation. »

Cette réponse ne prétend pas qu’il a fait un travail qu’il n’a pas fait.

Minutes 25 à 48 : le problème de Quillfield

Nadia(intervieweur) :

Voici un vrai problème chez nous. 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, l’estimation d’un entrepreneur. Les experts en sinistres disent passer environ 40 minutes à lire un dossier avant de pouvoir agir. Nous voulons leur donner une ébauche de résumé d’une page : les faits essentiels, les questions ouvertes et les éléments manquants. Comment aborderiez-vous ça?

Daniel(personne candidate) :

D’accord. Avant de concevoir quoi que ce soit, quelques questions. Qui le lit, et quand? Juste après la réception, ou quand l’expert prend la réclamation en charge?

Nadia(intervieweur) :

Les experts en sinistres, généralement dans la journée suivant la réception.

Daniel(personne candidate) :

Et « fait essentiel ». Il y a une liste quelque part, ou c’est dans la tête des experts? Et à quoi ressemble une erreur grave?

Nadia(intervieweur) :

Les spécialistes des réclamations ont une liste de vérification informelle pour chaque type de réclamation. Une erreur grave, c’est un résumé qui omet une exclusion de la police ou une échéance. Ou qui présente quelque chose comme un fait, alors que le dossier ne le dit pas. Le résumé ne décide jamais rien; l’expert confirme.

Daniel(personne candidate) :

D’accord. Dernière question : est-ce que la réception vous fournit déjà du texte par page?

Nadia(intervieweur) :

Oui. La réception applique la reconnaissance optique de caractères (OCR) à chaque page et conserve le texte avec les numéros de page. Chacun des 32 champs a aussi sa page.

Daniel(personne candidate) :

Ah, bien. Alors je ne partirais pas du dossier brut. Donc, une première ébauche. Une tâche qui s’exécute juste après l’extraction à la réception. L’entrée, c’est les 32 champs avec leurs pages, plus le texte des pages. La sortie est structurée, pas du texte libre. Les faits, chacun avec sa page. Les questions ouvertes. Une liste des éléments manquants.

Nadia(intervieweur) :

Hum-hum.

Daniel(personne candidate) :

La liste des éléments manquants, je la ferais surtout en code. Comparer la liste de vérification de ce type de réclamation aux 32 champs. Le modèle peut y ajouter des éléments, mais la base est du code classique, facile à tester. Et avant d’enregistrer quoi que ce soit, on vérifie chaque citation. La page existe-t-elle, et le texte cité s’y trouve-t-il? Sinon, on retire le fait ou on le signale.

Nadia(intervieweur) :

« Le texte cité s’y trouve-t-il. » Une correspondance exacte, sur du texte OCR?

Daniel(personne candidate) :

Non, non, ça échouerait tout le temps. Approximative, je pense. Normaliser les espaces et la casse, puis calculer un score de similarité sur une partie de la page. Avec un seuil qu’on ajuste. Mais honnêtement, je connais mal l’OCR. Je voudrais d’abord regarder une centaine de vos pires numérisations.

Pourquoi cela fonctionne

Daniel demande qui lit le résumé et ce que coûte une erreur avant de concevoir la solution. Il réutilise ce que l’équipe possède déjà et confie la liste des éléments manquants à du code classique. Vérifier chaque citation est une habitude du développement backend (côté serveur) : vérifier les données avant de leur faire confiance. Quand Nadia examine le détail, il indique où ses connaissances s’arrêtent.

Nadia(intervieweur) :

Pourquoi à la réception, plutôt que quand l’expert ouvre la réclamation?

Daniel(personne candidate) :

La même leçon que pour les billets. Personne ne veut attendre trente secondes, et généralement, on dispose de plusieurs heures. 9 000 par jour, c’est… environ six par minute, en moyenne. Mais j’imagine que vous avez des pointes?

Nadia(intervieweur) :

Après une grosse tempête, oui. Un épisode de grêle l’année dernière a quadruplé notre volume normal pendant dix jours. Et combien ça coûte, approximativement?

Daniel(personne candidate) :

Pour les pointes, une file d’attente avec des priorités. On dimensionne les processus selon la limite de débit du contrat, pas selon la pointe. Pendant une tempête, les résumés arrivent plus tard, mais rien ne casse. Quand de nouveaux documents arrivent, on régénère, avec une clé basée sur le hachage du dossier et la version de la requête, donc… désolé, j’ai oublié la deuxième partie de votre question.

Nadia(intervieweur) :

Le coût. Approximativement.

Daniel(personne candidate) :

Oui, le coût. Je vais réfléchir à voix haute. Quarante pages, peut-être 500 à 700 jetons par page après l’OCR. Donc, disons 25 000 jetons en entrée, et un ou deux mille en sortie. Multiplié par 9 000… environ 225 millions de jetons d’entrée par jour. Je ne connais pas votre prix par jeton, mais je partirais de ce nombre.

Nadia(intervieweur) :

D’accord.

Daniel(personne candidate) :

Ah, et personne n’attend le travail de nuit ni le traitement du retard après une tempête. Donc, je regarderais l’API par lots du fournisseur. C’est souvent environ la moitié du prix, mais les résultats peuvent prendre jusqu’à une journée. Et je confirmerais que le traitement par lots garde les données canadiennes au Canada. Certaines offres par lots fonctionnent seulement dans des régions mondiales.

Marcus(intervieweur) :

Je peux ajouter quelque chose? J’écoute, et honnêtement, je pense que la conception devient trop compliquée. Avec des fenêtres de contexte d’un million de jetons, la récupération est pratiquement morte. On va simplement mettre le dossier entier et la police complète dans la requête.

Daniel(personne candidate) :

Hm. Pour le dossier, je suis plutôt d’accord. 25 000 jetons entrent facilement, c’est ce que je supposais. Là où je vois les choses autrement, c’est « la récupération est morte », et la partie sur la police. Quelques raisons… voyons si je peux les mettre en ordre.

Le coût, d’abord. Si la police et ses avenants font cent pages de plus, chacun des 9 000 appels quotidiens les paie.

Marcus(intervieweur) :

Le cache rend pourtant la police peu coûteuse, non?

Daniel(personne candidate) :

Pour le texte de base, oui. Cette partie se répète, donc le cache des requêtes aide. Mais les avenants diffèrent pour chaque titulaire de police, tout comme la version applicable à la date du sinistre. Cette partie ne se répète pas, donc on la paie chaque fois. Et c’est justement mon prochain point.

Marcus(intervieweur) :

Continuez.

Daniel(personne candidate) :

La semaine dernière, vous m’avez dit que l’assistant pour les polices omet parfois un avenant. Je ne pense pas que ce soit un problème de taille. Le problème, c’est de savoir quelle version et quels avenants s’appliquaient à la date du sinistre. C’est une recherche dans la base de données, pas une requête au modèle.

Ensuite, la qualité. Les modèles n’utilisent pas aussi bien toutes les parties d’une entrée très longue. C’est bien mieux qu’avant, mais ça dépend du modèle et de la tâche. Donc, je le testerais sur nos documents. Et la protection des renseignements personnels. On ne devrait pas envoyer au modèle plus de renseignements personnels que la tâche n’en exige.

Donc, je ne dis pas non plus « toujours récupérer ». Pour la police, je proposerais une recherche de version, puis la récupération. Mais c’est une hypothèse. On pourrait vérifier en une semaine. Prendre 50 dossiers que les spécialistes connaissent bien, essayer les deux méthodes et comparer les faits manquants, les faits erronés, le coût et le temps.

Bien exprimer un désaccord

Marcus est le responsable du recrutement, et il croit ce qu’il dit; ce n’est pas un test. Daniel commence par approuver la partie juste. Il dit « je vois les choses autrement », pas « vous avez tort ». Quand Marcus objecte, Daniel répond avec un fait concernant les documents de cette équipe. Il termine par une expérience. Ainsi, les données décident, pas la personne au titre le plus élevé. Un avenant modifie une police standard, par exemple pour ajouter une protection pour un sous-sol. Consultez nos conseils pour exprimer un désaccord avec des raisons et sur les affirmations qu’un outil est « mort ».

Nadia(intervieweur) :

J’appuierais ça. On ne l’a jamais mesuré. On a eu la même discussion pour la réception, et on a décidé selon nos opinions. Marcus, je peux organiser ça.

Marcus(intervieweur) :

D’accord. Mesurez-le.

Nadia(intervieweur) :

Revenons à la qualité, parce que c’est là qu’on s’est arrêtés sur votre projet de billets. Comment sauriez-vous que ces résumés sont assez bons pour les mettre en production?

Daniel(personne candidate) :

Cette fois, je le ferais avant, pas après. Un jeu de données étiquetées, où les spécialistes des réclamations notent les faits essentiels. Ensuite, on mesure les faits manquants, les faits erronés et les affirmations sans appui dans les documents. De combien de temps les spécialistes disposent-ils?

Nadia(intervieweur) :

Environ quatre heures par semaine, à eux deux. La majeure partie sert à l’échantillon hebdomadaire de réception.

Daniel(personne candidate) :

Attendez, quatre heures au total? D’accord. Alors leur temps est la ressource la plus rare de toute la conception. Je les utiliserais seulement là où personne d’autre ne peut aider. La liste des éléments manquants et la vérification des citations, c’est du code. Pour « cette affirmation est-elle appuyée par la page citée », un deuxième modèle comme juge. Et les spécialistes étiquettent un plus petit jeu de données, qu’on utilise pour vérifier le juge.

Nadia(intervieweur) :

Comment savez-vous que le juge est assez bon?

Daniel(personne candidate) :

Le comparer aux spécialistes sur les mêmes affirmations. Peut-être une centaine pour commencer. Et regarder où ils sont en désaccord. Surtout quand le juge dit « appuyée » et que le spécialiste dit « non », parce que ce sont les cas dangereux.

Nadia(intervieweur) :

Si seulement 5 des 100 affirmations sont sans appui, qu’apprenez-vous sur ce type d’erreur?

Daniel(personne candidate) :

Pas grand-chose. Cinq cas, le juge en détecte quatre, et… ça ne me dit presque rien. Hm. Donc, il me faut plus de mauvaises affirmations dans l’échantillon que dans la réalité. Choisir celles qui sont probablement sans appui, par exemple quand la vérification de citation a presque échoué. Ou en créer : prendre de bons résumés, changer un montant ou une date, et voir si le juge le détecte. Pour les nombres exacts, je demanderais à quelqu’un qui connaît mieux les statistiques que moi.

Pourquoi cela fonctionne

Daniel applique la leçon de la première moitié et travaille avec une limite réelle. Un modèle juge est utile seulement après une comparaison avec des personnes. Un échantillon aléatoire contient trop peu d’erreurs pour ce test. Il ajoute donc des erreurs, dont certaines volontairement.

Nadia pose ensuite une question sur les renseignements médicaux dans les réclamations pour blessures. Daniel répond à partir de son travail dans les paiements :

• Garder les requêtes complètes hors des journaux (logs) généraux.
• Garder les données canadiennes au Canada, et le tester.
• Inclure les détails médicaux seulement quand l’expert en sinistres en a besoin.

Il dit ne pas connaître assez bien les lois sur la protection des renseignements personnels pour en dire plus. Il s’agit de la LPRPDE, la loi fédérale pour les entreprises privées, et des lois provinciales comme celles du Québec.

Pour la mise en production, Daniel propose d’abord une exécution silencieuse, où les experts ne voient pas la sortie. Ensuite, un projet pilote avec un assureur, avec des motifs de rétroaction (« fait erroné », « fait manquant ») plutôt qu’un pouce vers le haut.

Minutes 48 à 57 : les questions de Daniel

Daniel(personne candidate) :

Alors, les gardes, comme je l’ai dit au début. Qu’est-ce qui réveille les gens la nuit pour une fonctionnalité de LLM ici? Il y a une rotation?

Nadia(intervieweur) :

Oui. Une semaine sur six, après avoir accompagné quelqu’un pendant deux rotations. Ce n’est pas dans l’offre, et ça devrait l’être. C’est surtout le fournisseur : des pointes de latence, des limites de débit pendant les tempêtes. Parfois, un changement de version du modèle casse l’extraction d’un champ.

Daniel(personne candidate) :

Comment remarquez-vous ce dernier cas? Ça ne déclenche pas d’erreur, non?

Nadia(intervieweur) :

Lentement, pour l’instant. L’échantillon hebdomadaire de 200 le détecte. C’est une des raisons pour lesquelles ce poste existe.

Pourquoi cela fonctionne

La question sur les gardes révèle un fait absent de l’offre d’emploi. La question suivante relie les gardes aux défaillances de qualité qui ne déclenchent aucune erreur. La réponse de Nadia montre qu’il n’existe pas encore de cadre d’évaluation commun. Consultez une entrevue est une conversation dans les deux sens.

Daniel(personne candidate) :

Et l’étiquetage. Y a-t-il un plan pour obtenir plus de temps des spécialistes, ou les quatre heures sont-elles fixes?

Nadia(intervieweur) :

Honnêtement, prévoyez quatre heures pour les six premiers mois. Marcus en demande plus, mais il ne peut rien promettre.

Minutes 57 à 60 : la conclusion

Nadia(intervieweur) :

D’accord, notre temps est écoulé. La prochaine étape est généralement la conception de systèmes avec Owen Fraser, notre ingénieur principal. Hannah vous contactera cette semaine.

Daniel(personne candidate) :

Merci. La partie sur l’évaluation était inconfortable, mais utile.

Nadia(intervieweur) :

Bien. C’est la partie que je préparerais pour la suite. Merci, Daniel.

Après l’appel : les notes de Nadia

Nadia rédige ses notes en fonction de l’offre d’emploi :

Ingénierie en production et services Python : preuves solides. Il a conçu et exploité le système. Il a expliqué une défaillance qu’il a causée et corrigée.

LLM en production : quelques preuves. Une fonctionnalité, un an, 120 utilisateurs réels. Une expérience approfondie, mais courte.

RAG et récupération : quelques preuves. Un projet personnel seulement, mais son raisonnement sur le contexte long était solide.

Stratégie d’évaluation : point préoccupant. Son projet mesurait la satisfaction, pas l’exactitude des réponses. À la limite de ses connaissances, il a bien raisonné : un jeu étiqueté, des catégories d’erreurs, un modèle juge vérifié par comparaison avec des personnes. Il ne pourrait pas encore diriger seul notre travail d’évaluation.

Protection des renseignements personnels : preuves solides pour les mesures techniques. Il ne connaît pas la loi, et il l’a dit.

Communication : preuves solides. Il a exprimé son désaccord avec Marcus poliment, avec des raisons.

Recommandation : oui, passer à la conception de systèmes. Owen, veuillez consacrer une partie de l’entrevue à l’évaluation. Hannah, veuillez l’en informer.

La suite

Hannah a informé Daniel du sujet à préparer. Il a consacré ses soirées pendant une semaine à ajouter un jeu d’évaluation de 80 questions à son projet personnel sur le transport en commun. Lors de l’entrevue de conception de systèmes avec Owen, son plan d’évaluation était l’un des points forts de sa réponse. Sa discussion sur les valeurs avec Sofia Alvarez s’est aussi bien passée.

Il y avait un seul poste à pourvoir. Lors du bilan, l’équipe a choisi une autre personne finaliste. Elle avait des années d’expérience en réclamations que personne dans l’équipe n’avait. Marcus a appelé Daniel lui-même. Il lui a transmis les commentaires de Nadia et d’Owen. Il lui a aussi demandé s’il pouvait le contacter à l’ouverture du prochain poste de niveau senior. Daniel n’a rien fait de mal. Parfois, une autre personne répond mieux à un besoin précis d’une équipe. Cela fait partie du rôle de la chance dans l’embauche.

Par ailleurs, Marcus a demandé à un ingénieur de mener l’expérience sur le contexte long. Pour les dossiers, le contexte long convenait. Pour les polices, le résultat était mitigé : la recherche de versions a corrigé la plupart des avenants manqués. La récupération a moins aidé que Daniel ne l’avait estimé.

Ce qu’il faut en retenir

• L’expérience en production est une expérience en ingénierie de l’IA. Les nouvelles tentatives, les limites de débit, les files d’attente et les coûts occupaient la moitié de l’entrevue de Daniel.
• « Apprécié » et « utilisé » ne veulent pas dire « correct ». Pour chaque projet avec un LLM, sachez à quelle fréquence il se trompe et de quelle façon. Sinon, dites comment vous le découvririez.
• La limite de vos connaissances compte le plus. Daniel a dit « Je ne sais pas », puis il a raisonné à voix haute. Cela a inspiré plus de confiance qu’une réponse bien rodée.
• Exprimez votre désaccord avec des raisons liées au problème présenté, et proposez un test. Consultez nos conseils pour exprimer un désaccord.
• Vos questions sont aussi des preuves. Les questions de Daniel ont révélé deux faits que l’offre d’emploi ne mentionne pas.

Si votre profil ressemble à celui de Daniel

Votre expérience en production est une longueur d’avance (voir Votre expérience est une longueur d’avance). Comblez vos lacunes en évaluation avant l’entrevue, pas pendant.

1. Ajoutez un jeu d’évaluation à un projet que vous avez déjà. Demandez à une personne qui connaît le travail d’étiqueter 100 à 200 exemples réels. Comptez chaque type d’erreur et relancez l’évaluation sur ce jeu après chaque changement. Apprenez les bases de l’accord entre les personnes qui étiquettent les données. Apprenez aussi à vérifier un modèle juge par comparaison avec des personnes. Les idées de Données d’entraînement, de validation et de test s’appliquent ici aussi.
2. Apprenez à parler des types d’erreurs. « Incorrect », « manquant » et « non étayé » ne signifient pas la même chose, et leurs coûts diffèrent. Les métriques de classification et Le compromis entre précision et rappel vous donnent les mots pour en parler.
3. Exercez-vous à raconter votre projet à voix haute, avec des chiffres et une défaillance que vous avez causée. Notre leçon Expliquer vos décisions montre comment faire.
4. Restez sur votre objectif. L’offre d’emploi mentionne trois frameworks (cadres de développement) d’agents. Personne n’a posé de question à Daniel sur ces outils. Une connaissance approfondie de l’évaluation vous aide davantage. Consultez continuez à apprendre, mais restez sur votre objectif.