Comment décidez-vous d'utiliser un LLM pré-entraîné directement, de le fine-tuner ou de construire un système RAG ?

La décision repose sur les schémas d'accès aux données, les exigences de latence et la nature des connaissances dont le système a besoin. Si la tâche est générative et que le modèle de base possède déjà la connaissance du domaine, l'ingénierie de prompts avec un modèle hébergé comme GPT-4o ou Claude est généralement la voie la plus rapide vers la valeur. Le fine-tuning est pertinent quand vous disposez d'exemples étiquetés de haute qualité du format de sortie exact souhaité, ou quand la latence et le coût nécessitent un modèle plus petit et spécialisé. Le RAG est le bon choix quand le système doit accéder à des informations récentes, propriétaires ou fréquemment mises à jour. En pratique, beaucoup de systèmes de production combinent les trois approches : un modèle fine-tuné pour le ton et le format, la récupération pour les connaissances en temps réel, et une conception de prompt soignée pour les relier.

Expliquez comment vous concevriez un pipeline RAG pour une application de support client.

Je commencerais par la couche de récupération. Pour un cas d'usage support, la base de connaissances comprend généralement la documentation produit, les tickets résolus et les documents de politique. Je découperais le contenu soigneusement, en visant des morceaux de 300 à 500 tokens avec chevauchement significatif, et j'embarquerais chaque morceau avec text-embedding-3-large d'OpenAI. Je stockerais les embeddings dans une base vectorielle comme Pinecone ou pgvector, avec des filtres de métadonnées par catégorie et langue. Côté génération, j'utiliserais une approche en deux étapes : récupérer les cinq meilleurs morceaux par similarité cosinus, les re-classer avec un cross-encoder, puis passer les trois meilleurs dans le prompt final. J'ajouterais aussi une étape de classification des requêtes pour traiter directement les FAQ évidentes sans récupération, réduisant latence et coût.

Comment évaluez-vous la qualité d'une fonctionnalité propulsée par un LLM ?

L'évaluation des systèmes LLM doit se faire à deux niveaux. Le premier est l'évaluation hors ligne sur un ensemble fixe d'entrées et de sorties attendues, que je construis avant de construire la fonctionnalité. Je crée un ensemble de test d'au moins 50 cas représentatifs couvrant les entrées typiques, les cas limites et les modes d'échec connus. Je note les sorties avec des métriques automatisées comme BLEU ou ROUGE pour les tâches extractives, et LLM-as-judge pour la génération ouverte, plus une revue humaine d'un échantillon aléatoire. Le second niveau est l'évaluation en ligne via les signaux utilisateurs : notations, taux de modification, taux d'escalade et abandon de session. J'instrumente ces signaux dès le premier jour car les évaluations hors ligne ne prédisent jamais parfaitement l'expérience utilisateur.

Comment gérez-vous l'injection de prompts et les entrées adversariales dans les systèmes d'IA en production ?

L'injection de prompts est l'un des risques les plus sérieux dans tout système où les entrées utilisateurs sont incorporées dans un prompt. Mon approche standard est une défense en couches. Au niveau de l'entrée, je valide et assainis les entrées utilisateurs avant qu'elles n'atteignent le prompt, en signalant les chaînes contenant des patterns d'instruction comme 'ignore les instructions précédentes'. Dans le prompt lui-même, j'utilise un cadrage de rôle strict et des délimiteurs XML pour séparer le contenu système de confiance du contenu utilisateur non fiable. Au niveau de la sortie, j'applique une validation pour détecter les réponses déviantes avant qu'elles n'atteignent l'utilisateur. Pour les applications à risque plus élevé, je réalise aussi des exercices de red-teaming périodiques contre le prompt de production pour identifier de nouveaux vecteurs d'injection.

Parlez-moi d'une fois où une fonctionnalité IA que vous avez construite n'a pas fonctionné comme prévu en production.

J'ai construit une fonctionnalité de résumé de documents pour un outil interne de gestion des connaissances. Lors des tests, elle produisait des résumés précis et concis. Après le lancement, les utilisateurs ont signalé que les résumés de longs contrats juridiques manquaient des clauses clés. La cause racine était une stratégie de découpage qui scindait les documents aux limites de tokens fixes plutôt qu'aux limites sémantiques comme les titres de sections. J'ai réécrit le découpage pour respecter la structure du document, en utilisant les titres et listes numérotées pour créer des morceaux logiques. Après la correction, le taux de clauses manquantes est passé d'environ 18 % à moins de 3 % des documents. La leçon : la stratégie de découpage est aussi importante que le choix du modèle dans un système RAG.

Décrivez comment vous avez géré un désaccord avec une équipe produit sur ce qu'un système d'IA devrait ou ne devrait pas faire.

L'équipe produit de mon ancienne entreprise voulait que notre assistant IA réponde aux questions sur les prix des concurrents, en utilisant des informations collectées sur des sites publics. J'avais des préoccupations concernant la précision, car les prix changent fréquemment, et le risque de réputation si l'assistant affirmait avec confiance des chiffres obsolètes. J'ai préparé une courte évaluation des risques couvrant la durée de vie des données, le volume de tickets de support prévisible et le risque juridique dans certains marchés réglementés. L'équipe produit a accepté l'argument de précision mais voulait toujours une sensibilisation aux concurrents. Nous avons convenu d'un compromis : l'assistant reconnaîtrait les questions sur les concurrents et redirigerait vers un humain pour des comparaisons détaillées.

Donnez un exemple de la façon dont vous avez rendu un système d'IA plus rentable sans sacrifier la qualité.

Nous faisions passer toutes les requêtes par GPT-4o et nos dépenses API mensuelles avaient atteint un niveau où l'économie unitaire ne fonctionnait plus au prix cible. J'ai effectué une analyse de classification sur un échantillon de 2 000 requêtes et trouvé qu'environ 60 % étaient des recherches factuelles simples ne nécessitant pas un grand modèle. J'ai introduit une couche de routage qui envoyait les requêtes simples à GPT-4o mini et réservait le modèle complet pour les tâches de raisonnement complexes. J'ai validé le routage contre un ensemble de test étiqueté manuellement avant le déploiement. Le résultat a été une réduction de 54 % des coûts API avec des scores de qualité diminuant de moins de 1 %. La logique de routage est devenue un modèle utilisé dans trois autres fonctionnalités IA du produit.

Comment structurez-vous un pipeline d'inférence ML pour une utilisation en production à faible latence ?

La clé est de séparer le prétraitement, l'inférence et le post-traitement en étapes distinctes et indépendamment évolutives. Pour le prétraitement, je maintiens les transformations sans état pour qu'elles s'exécutent en parallèle. Pour l'inférence, j'utilise un framework optimisé comme vLLM ou TGI pour les LLMs, qui gère le batching continu et la réutilisation du KV-cache pour augmenter considérablement le débit. Je quantise aussi les modèles quand c'est possible : passer de FP16 à INT8 avec GPTQ réduit généralement la mémoire de moitié. Je configure des files de requêtes avec des voies prioritaires pour que les requêtes utilisateurs interactives ne soient pas bloquées par les traitements par lots. Enfin, j'ajoute une mise en cache des réponses pour les requêtes déterministes via une couche de cache sémantique, réduisant latence et coût pour les entrées similaires répétées.

Comment approchez-vous la surveillance un LLM en production ?

La surveillance LLM diffère de la surveillance ML classique car on ne peut pas se fier à une seule métrique numérique. Je suis quatre catégories de signaux. Premièrement, les métriques d'infrastructure : percentiles de latence (p50, p95, p99), taux d'erreur, nombre de tokens par requête et dépenses API. Deuxièmement, les signaux de qualité des sorties : scores LLM-as-judge automatisés sur un échantillon de sorties de production et retours utilisateurs. Troisièmement, les indicateurs de dérive des données : changements dans la distribution des types de requêtes d'entrée. Quatrièmement, les signaux de sécurité : le taux auquel le filtre de sortie ou la modération de contenu se déclenche, segmenté par catégorie d'entrée. J'envoie tout cela dans un tableau de bord Grafana ou Datadog avec des alertes sur les métriques qui ont historiquement précédé les plaintes des utilisateurs.

Expliquez comment vous implémenteriez et évalueriez une exécution de fine-tuning pour une tâche spécifique à un domaine.

Je commence par construire soigneusement l'ensemble d'entraînement, car la qualité des données compte plus que la technique de fine-tuning. Je vise au moins 500 exemples de haute qualité dans le format d'instruction que le modèle de base attend, avec une division 90/10 entraînement/évaluation. J'utilise LoRA ou QLoRA pour un fine-tuning efficace en paramètres, ce qui me permet d'affiner un modèle 7B sur un seul A100 sans mises à jour de poids complets. J'exécute le fine-tune avec Axolotl ou le Hugging Face Trainer, en suivant les pertes d'entraînement et d'évaluation par époque pour détecter le sur-apprentissage tôt. Après l'entraînement, j'évalue le checkpoint sur l'ensemble d'évaluation avec des métriques spécifiques à la tâche et compare aux performances du modèle non affiné. Je vérifie aussi que le fine-tuning n'a pas dégradé les refus sur les entrées nuisibles, un effet secondaire courant.

Ingénieur IA

Les entretiens pour un poste d'ingénieur IA évaluent votre capacité à construire des systèmes prêts pour la production qui intègrent des grands modèles de langage, des pipelines de machine learning et une infrastructure de récupération d'informations. Les recruteurs veulent s'assurer que vous maîtrisez l'ensemble de la chaîne, de la sélection du modèle et de l'ingénierie des prompts jusqu'au déploiement, à la surveillance et aux pratiques d'IA responsable. Ce guide couvre les questions les plus fréquentes et les réponses qui montrent que vous pouvez livrer une IA fonctionnelle en production.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Aller plus loin

Réussir l'entretien comportemental (méthode STAR)Comment se préparer à un entretien technique

Questions d'entretien courantes pour Ingénieur IA

Questions comportementales pour les postes Ingénieur IA

Questions techniques pour les candidats Ingénieur IA

Ce que les recruteurs recherchent pour un poste Ingénieur IA

Ce que les recruteurs cherchent vraiment chez les candidats ingénieur IA :

Une expérience en production, pas seulement en recherche. Les projets personnels et les notebooks Kaggle ne remplacent pas le fait d'avoir livré et maintenu une fonctionnalité LLM sous charge réelle.
Une compréhension de la pile complète. Les candidats solides savent comment la récupération, l'inférence et l'évaluation s'articulent, pas seulement une couche isolée.
La conscience des coûts et de la latence. Les systèmes IA qui fonctionnent mais ne sont pas économiquement viables ne survivront pas longtemps dans un produit. Montrez que vous pensez à l'économie unitaire dès le départ.
Une pratique de l'IA responsable. La sécurité, les biais et la surveillance ne sont pas des réflexions après coup. Les entreprises posent de plus en plus de questions là-dessus dès le premier tour d'entretien.
La curiosité pour le paysage des modèles. Le domaine évolue vite. Les candidats qui peuvent nommer les familles de modèles actuelles et leurs compromis montrent qu'ils restent à jour avec la pratique réelle.

Questions à poser à votre interlocuteur

→À quoi ressemble l'infrastructure IA actuelle, et quelles sont les lacunes les plus importantes que vous cherchez à combler avec ce recrutement ?
→Comment gérez-vous la gestion des versions de modèles et les retours arrière quand une nouvelle version dégrade la qualité en production ?
→Quelle est l'approche actuelle de l'équipe pour évaluer la qualité des sorties LLM, et quelle est la maturité des outils d'évaluation ?
→Comment les décisions sont-elles prises sur les cas d'usage IA dans lesquels investir versus déprioritiser ?
→Quelles sont les plus grandes préoccupations en matière d'IA responsable ou de sécurité sur lesquelles l'équipe travaille activement ?

Entrainez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit pour commencer. Sans engagement.

Métiers similaires

Ingénieur logiciel

Tech10 questions

Ingénieur Machine Learning

Tech9 questions

Data scientist

Tech9 questions