Questions d'entretien Ingénieur IA

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.