HarmonyFidelisHarmonyFidelis
Connexion
Fondamentaux IAFonctionnement des LLMCompétences LLMÉvaluationGlossaireConfigurateur
Académie Aura

Section 3 · Construction

Les compétences essentielles pour les applications LLM

La fiabilité vient de l’architecture, des frontières et de l’évaluation. Chaque technique traite une famille de pannes différente ; les cumuler sans diagnostic ajoute coût et surface d’attaque.

Intermédiaire30 minutes

À la fin, vous saurez

  • Choisir entre prompting, recherche, appel d’outil et adaptation du modèle.
  • Expliquer RAG, function calling, MCP et boucles agentiques.
  • Concevoir un workflow borné avec validation et solution de repli.

Cinq capacités d’ingénierie

01

Contrats de prompt et sorties structurées

Précisez tâche, contexte utile, contraintes et critères de réussite. Un schéma rend la sortie lisible par machine, mais doit être validé et ne prouve pas les faits.

02

Génération augmentée par recherche

Le RAG retrouve des passages externes et les ajoute au contexte. Fraîcheur et traçabilité s’améliorent seulement si indexation, recherche et usage des preuves sont bons.

03

Outils et MCP

Le function calling fait proposer au modèle des arguments structurés. L’hôte valide, autorise et exécute. MCP standardise l’exposition de ressources, prompts et outils.

04

Agents et orchestration

Une boucle agentique observe, planifie, appelle des outils et met à jour son état. Bornez étapes, coût, permissions et effets ; gardez les invariants dans du code déterministe.

05

Adaptation et déploiement

Fine-tuning ou LoRA peuvent façonner un comportement répétitif ; la quantification réduit les ressources. Aucun ne remplace connaissances, permissions, évaluation ou données solides.

Choisir la plus petite intervention efficace

  1. 01

    Clarifier le prompt

  2. 02

    Ajouter le contexte

  3. 03

    Appeler un outil fiable

  4. 04

    Adapter si répétitif

  5. 05

    Optimiser ensuite

Prompting pour une consigne floue, RAG pour une connaissance accessible, outils pour agir ou calculer exactement, fine-tuning pour des comportements stables et répétés.

Confusions fréquentes

  • Le RAG ne supprime pas les hallucinations : la recherche peut échouer et le modèle ignorer ou déformer la preuve.
  • Le modèle propose un appel d’outil, mais l’application doit toujours l’autoriser et le valider.
  • Une architecture multi-agents peut multiplier latence, coût et propagation d’erreurs sans gain.

Exercice : concevoir un assistant ancré

Esquissez un assistant support répondant depuis une base contrôlée.

  • Définir entrées de recherche, métadonnées des sources et abstention si la preuve est faible.
  • Définir un outil en lecture seule avec schéma strict et autorisation serveur.
  • Tracer prompt, modèle, passages, résultat d’outil et évaluation sans journaliser de secrets.

Vérification rapide

Quand le RAG est-il préférable au fine-tuning ?

Quand il faut fournir à la demande une connaissance actuelle, privée ou traçable.

Qui doit autoriser un appel d’outil ?

L’application hôte valide arguments, permissions utilisateur et politique avant exécution.

Un JSON valide garantit-il une réponse correcte ?

Non. Il garantit seulement syntaxe ou schéma ; faits et règles métier doivent encore être contrôlés.

Mots-clés à connaître

  • prompt
  • schéma
  • ancrage
  • RAG
  • recherche vectorielle
  • function calling
  • MCP
  • agent
  • LoRA
  • quantification

Spécifications et recherche primaire

Retrieval-Augmented GenerationArticle primaire combinant génération paramétrique et mémoire externe recherchée.Guide OpenAI du function callingDocumentation actuelle pour définir des outils et traiter les appels structurés.Spécification Model Context ProtocolSpécification normative pour connecter contexte et outils IA de manière interopérable.ReActArticle primaire sur l’alternance de traces orientées raisonnement et d’actions.LoRAArticle primaire sur l’adaptation de faible rang pour un fine-tuning efficace.
Précédent: Fonctionnement des LLMSuivant: Évaluation et sécurité