Pouvez-vous décrire, à l’exécution, les trois étapes principales d’un système de Retrieval-Augmented Generation (RAG) ?
Réponse : (1) Récupérer les K passages les plus pertinents pour la requête (retrieval), (2) construire un prompt contenant le contexte récupéré et la question, (3) générer la réponse avec le LLM.
Pouvez-vous citer deux raisons pour lesquelles un LLM seul peut poser problème en production pour répondre à des questions sur des documents internes ?
Réponse : Par exemple : connaissances figées (cutoff) donc obsolescence, hallucinations (réponses plausibles mais fausses), difficulté à dire « je ne sais pas », absence de justification par des sources.
Quelles propriétés sont recherchées en production pour un système de question/réponse assisté par LLM sur une base documentaire ?
Réponse : Traçabilité (savoir d’où vient l’information), mise à jour des documents sans réentraîner le modèle, contrôle pour limiter les réponses non supportées par des preuves, observabilité (logs, métriques, débogage retrieval vs génération).
Comment expliquez-vous l’idée de séparer « raisonner » et « savoir » dans un système RAG ?
Réponse : Le LLM sert à générer/raisonner, tandis que la base documentaire sert de source de connaissances ; le pipeline injecte l’information pertinente au moment de la requête.
Parmi les propositions suivantes, laquelle correspond au pipeline OFFLINE typique d’un système RAG (de l’ingestion à l’index) ?
A) Embedding de requête → retrieval top-k → assemblage de contexte → prompting → génération → post-traitement
B) Ingestion → nettoyage/normalisation → chunking → embeddings → stockage (vector store + métadonnées) → persistance/versioning d’index
C) Entraînement du LLM sur tous les documents internes à chaque mise à jour
D) Conversation multi-tours avec mémoire pour accumuler les preuves dans le chat
Réponse : B) Ingestion → nettoyage/normalisation → chunking → embeddings → stockage (vector store + métadonnées) → persistance/versioning d’index.
Dans un RAG, que risque-t-il de se passer si le retriever récupère principalement du bruit ?
Réponse : Le LLM risque de produire une réponse non fiable car elle s’appuie sur un contexte bruité ou non pertinent.
Pouvez-vous expliquer les effets typiques d’un chunking « trop petit » versus « trop grand » ?
Réponse : Trop petit : contexte incomplet, réponses fragmentaires, besoin d’augmenter top-k. Trop grand : dilution/bruit, prompt plus long (coût/latence), risque de dépasser la fenêtre de contexte.
Parmi les propositions suivantes, laquelle liste correctement les sections séparées dans un prompt structuré orienté production ?
A) INSTRUCTIONS / TÂCHE / FORMAT / DONNÉES (ou CONTEXTE)
B) SALUTATIONS / STYLE / TEMPÉRATURE / LONGUEUR
C) OBJECTIFS / RÉCOMPENSES / PÉNALITÉS / RÉFLEXION INTERNE
Réponse : A) INSTRUCTIONS / TÂCHE / FORMAT / DONNÉES (ou CONTEXTE).
Comment définissez-vous un « prompt » et quels éléments peut-il contenir pour piloter la sortie d’un LLM ?
Réponse : Une entrée textuelle (souvent structurée) qui peut inclure l’objectif (tâche), le contexte (données), des contraintes (règles) et le format de sortie attendu, éventuellement des exemples (few-shot).
Qu’est-ce qu’une « abstention contrôlée » et quel comportement utile doit-elle préciser ?
Réponse : Un comportement explicite de non-réponse quand l’information manque : indiquer « information insuffisante », préciser ce qui manque et proposer une action utile (questions de clarification, par exemple).
Dans un retrieval en MMR (Maximal Marginal Relevance), quel paramètre sert à régler le compromis entre pertinence et diversité ?
A) chunk_overlap
B) lambda_mult
C) persist_directory
D) doc_version
Réponse : B) lambda_mult.
Pourquoi faut-il utiliser le même modèle d’embedding pour l’index et pour les requêtes, et que se passe-t-il si vous changez de modèle ?
Réponse : Parce que requêtes et chunks doivent être comparables dans le même espace vectoriel ; si le modèle d’embedding change, l’index devient incohérent et doit être reconstruit.
Dans quel cas la recherche lexicale (type BM25/TF-IDF) est-elle particulièrement utile par rapport à la recherche dense par embeddings ?
Réponse : Pour des correspondances exactes (identifiants, codes, noms, numéros), que la recherche dense peut manquer.
En défense contre l’injection de prompt via les documents, quel ordre de priorité des informations doit être appliqué ?
A) CONTEXTE > QUESTION > INSTRUCTIONS
B) QUESTION > INSTRUCTIONS > CONTEXTE
C) INSTRUCTIONS > QUESTION > CONTEXTE
D) INSTRUCTIONS > CONTEXTE > QUESTION
Réponse : C) INSTRUCTIONS > QUESTION > CONTEXTE.
Pouvez-vous définir le principe d’un retrieval hybride ?
Réponse : Combiner une recherche dense (embeddings) et une recherche lexicale, par exemple en fusionnant les candidats ou en pondérant les scores avant tri.
Pouvez-vous décrire le reranking en deux étapes et son objectif ?
Réponse : D’abord un retrieval rapide pour obtenir un ensemble de candidats (fetch_k), puis un reranker plus coûteux pour trier finement et ne garder que les k meilleurs à injecter dans le prompt.
Dans un prompt RAG, que signifie la règle « Answer only from context » et quel mécanisme de repli faut-il expliciter ?
Réponse : Répondre uniquement à partir du contexte fourni ; sinon s’abstenir (par exemple « information insuffisante ») et préciser ce qui manque, éventuellement avec des questions de clarification.
Pour rendre un système RAG observable, quelles informations clés devez-vous logger à chaque requête ?
Réponse : Question, version d’index et de prompt, ids des chunks top-k et leurs scores, taille du contexte (tokens), réponse (avec statut abstention/ok), et latences retrieval et LLM.
Que mesure le Recall@k pour évaluer le retrieval d’un RAG ?
A) Le pourcentage de questions confirmées par un humain
B) Le pourcentage de bonnes sources présentes dans les k chunks retournés
C) La longueur moyenne du prompt en tokens
D) Le temps moyen de génération du LLM
Réponse : B) Le pourcentage de bonnes sources présentes dans les k chunks retournés.
Quelles sont les trois catégories d’analyse d’erreurs pour diagnostiquer un RAG, et que signifient-elles ?
Réponse : (1) Retrieval miss : la preuve correcte n’est pas dans le top-k. (2) Context noise : la preuve est présente mais noyée dans du bruit. (3) Generation drift : la preuve est présente mais la réponse générée est incorrecte ou non supportée.
Dans une architecture d’agent modélisée comme une machine à états (par exemple via un graphe), qu’est-ce qui correspond le mieux à l’orchestration ? A. La liste des extraits retrouvés (snippets) et leurs scores B. Les fonctions d’accès aux données et d’action (RAG, SQL, tagging, ticketing) C. Les transitions conditionnelles, les cycles autorisés et les conditions d’arrêt D. Le schéma de validation des arguments de tools
Réponse : C.
Donnez deux limites d’un pipeline RAG « une requête, une réponse » lorsqu’on doit traiter un flux (par exemple des emails).
Réponse : Absence de gestion d’exception explicite et d’actions ; absence de boucle contrôlée, donc pas d’itération/clarification structurée.
Quelles sont les quatre étapes de la boucle décision–action d’un agent (dans l’ordre) ?
Réponse : Observer → Décider → Agir → Vérifier.
Donnez deux raisons pour lesquelles le tool calling est fragile en pratique.
Réponse : Parsing/schémas non conformes et erreurs/timeout côté tools ; difficulté d’idempotence (risque de double action).
Citez trois éléments typiques qu’un state d’agent doit stocker pour assurer audit et robustesse.
Quelle différence faites-vous entre mémoire de travail (state) et mémoire long-terme persistée ?
Réponse : Le state est la mémoire structurée de travail pendant l’exécution ; la mémoire long-terme est persistée au-delà d’un run (profil, règles, historiques résumés).
Donnez deux propriétés attendues d’un tool bien conçu pour un agent orchestré.
Réponse : Schéma d’entrées/sorties explicite avec validation ; gestion d’erreurs et timeouts claire ; idempotence (ou gestion « already done ») et outputs stables en erreur.
Pourquoi privilégier des outputs structurés (JSON + schéma strict) plutôt que du texte libre ?
Réponse : Pour réduire la variance et éviter un parsing fragile ; pour permettre une validation « fail-fast » et des fallbacks/repairs fiables pour le routing et le tooling.
Citez deux décisions qui doivent être verrouillées par le code (et non laissées au LLM) dans un agent orchestré.
Réponse : Stop conditions (max_steps/max_tool_calls/timeout) et budgets ; allow-list de tools et politiques non négociables (sécurité/compliance) ou règles d’escalade.
Parmi les éléments suivants, lequel doit être décidé par le code dans un agent orchestré ? A. La formulation exacte du texte de réponse B. La stop condition (max steps / timeout) C. La proposition d’une route (reply / ask_clarification / escalate / ignore) D. La génération d’une requête de retrieval
Réponse : B.
Citez deux bénéfices du routing dans un agent qui traite des emails.
Réponse : Réduire le coût (éviter retrieval/rédaction inutiles) et améliorer la sécurité (interdire certains tools selon la route) ou améliorer l’UX (réponses plus ciblées).
Donnez une mitigation concrète pour limiter les erreurs de format et les catégories inventées dans un routing LLM-based.
Réponse : Forcer un output JSON validé avec un ensemble de labels fermé ; si échec de parsing ou champs hors domaine, appliquer un repair prompt ou une re-demande contrainte avec fallback (ask_clarification/escalate).
Dans un pattern « writer + reviewer » séparé, quel est le rôle attendu du reviewer ? A. Réécrire directement la réponse finale B. Produire un diagnostic structuré (problèmes, sévérité, suggestions) sans réécriture C. Exécuter les tools à effets de bord D. Remplacer systématiquement la route choisie par le router
Réponse : B.
Quelle règle de stop est recommandée pour éviter une boucle infinie en reflection ?
Réponse : Limiter à une critique puis une révision (max 1–2 itérations), puis utiliser un fallback/safe mode si nécessaire.
Dans une parallélisation de type fan-out/reduce, quelle étape est indispensable avant de continuer le flow ? A. Une étape de join/agrégation pour fusionner les résultats des branches B. Un rerank obligatoire dans chaque branche C. La suppression du state pour éviter les conflits D. Le retrait de toute politique d’arbitrage pour garder la flexibilité
Réponse : A.
Donnez deux contraintes recommandées sur un plan (planning) pour éviter les plans vagues ou dangereux.
Réponse : Étapes courtes, typées et actionnables (pas d’étapes vagues) ; validation par schéma et allow-list de tools, avec limite stricte du nombre d’étapes (max_steps).
Citez trois invariants typiques vérifiés par des checkpoints dans un agent.
Réponse : intent dans un ensemble fermé (reply/ask_clarification/escalate/ignore) ; steps_used ≤ max_steps (budget respecté) ; aucun tool non autorisé par la route (ou evidence non vide si needs_retrieval=True, sinon fallback).
Quel couple « type d’erreur → stratégie » est correct ? A. Erreur permanente (permission/tool absent) → retry avec backoff B. Erreur de format (JSON invalide) → repair prompt / re-ask contraint C. Erreur transitoire (timeout/rate limit) → escalade immédiate sans tentative D. Erreur de données (champs manquants) → inventer les champs pour continuer
Réponse : B.
Citez trois menaces typiques contre lesquelles des guardrails doivent protéger un agent outillé.
Réponse : Prompt injection via contenus entrants (emails/documents) ; exfiltration de données ; misuse des tools (appels hors périmètre/paramètres dangereux) ou actions hallucinées (prétendre une action non exécutée).
En évaluation d’agents, que désigne la « trajectoire » ? A. Uniquement le texte de réponse final B. La suite des nodes/décisions/tool calls/erreurs/retries pendant l’exécution C. La taille moyenne de la fenêtre de contexte D. Le score moyen de reranking sur les chunks
