Un modèle de langage ne connaît que ce qu'il a vu à l'entraînement, et il l'a appris sous forme de statistiques, pas de faits vérifiables. Tout ce module tourne autour de la même question pratique : comment lui fournir la bonne information au bon moment, et comment l'adapter à un usage précis sans le réentraîner entièrement.

1. Ce qu'est un LLM, mécaniquement

Un grand modèle de langage est un transformer décodeur (module 16) entraîné à une seule tâche : prédire le jeton suivant. Tout le reste — répondre, résumer, traduire, coder — émerge de cette tâche unique appliquée à une quantité colossale de texte.

Le texte est d'abord découpé en jetons par un tokeniseur (BPE ou SentencePiece), qui fusionne itérativement les paires de caractères les plus fréquentes du corpus. Résultat : les mots courants deviennent un jeton unique, les mots rares se décomposent en morceaux.

"maintenance préventive"  →  ["maintenance", " prév", "entive"]     3 jetons
"P-204"                   →  ["P", "-", "204"]                      3 jetons
"anticonstitutionnel"     →  ["anti", "constitu", "tionnel"]        3 jetons

Ordre de grandeur : ~4 caractères par jeton en anglais, ~3 en français.
Conséquence pratique : compter les lettres d'un mot ou faire de l'arithmétique
sur des chiffres est DIFFICILE pour un modèle qui ne voit pas les caractères
mais des blocs — ce n'est pas un défaut de raisonnement, c'est la représentation.

À chaque étape, le modèle produit une distribution de probabilité sur tout le vocabulaire, dont on tire le jeton suivant. Les paramètres d'échantillonnage pilotent ce tirage :

distribution brute :  "pompe" 0,50   "vanne" 0,30   "moteur" 0,15   "chat" 0,05

température = 0     → toujours "pompe" (déterministe) : extraction, classification
température = 0,7   → distribution légèrement piquée : rédaction équilibrée
température = 1,5   → distribution aplatie, "chat" devient possible : créativité
                      (et incohérence)
top-p = 0,9         → on ne garde que les jetons cumulant 90 % de la masse,
                      puis on tire dedans : coupe la traîne absurde

Trois conséquences pratiques de cette mécanique. Le modèle n'a pas de mémoire entre deux appels : l'historique complet est renvoyé à chaque fois, et la « conversation » est une illusion entretenue par le contexte. Il ne sait pas ce qu'il ignore : produire un texte plausible est son objectif, ce qui rend les hallucinations structurelles et non accidentelles. Et son coût est proportionnel au contexte : l'attention est quadratique en longueur (module 16), et la mémoire du cache KV croît linéairement avec le nombre de jetons.

2. Embeddings et similarité sémantique

Un embedding projette un texte dans \(\mathbb{R}^d\) (typiquement \(d\) de 384 à 3072) de sorte que la proximité géométrique traduise la proximité de sens. « fuite au presse-étoupe » et « suintement au niveau du joint » sont éloignés lexicalement — aucun mot commun — mais proches sémantiquement, donc voisins dans cet espace.

La mesure usuelle est le cosinus :

On compare des directions, pas des amplitudes — c'est ce qu'on veut, car la norme d'un embedding dépend surtout de la longueur du texte. Si les vecteurs sont normalisés, cosinus et produit scalaire coïncident, et maximiser le cosinus revient à minimiser la distance euclidienne : d'où les optimisations des bases vectorielles, qui normalisent systématiquement à l'indexation.

Ces représentations sont apprises de façon contrastive (module 13) : on rapproche les paires de textes liés — une question et son passage de réponse — et l'on éloigne les paires non liées. C'est la raison pour laquelle un modèle d'embedding conçu pour la recherche est entraîné différemment d'un modèle de similarité entre phrases, et pourquoi le choix du modèle doit correspondre à l'usage. Le classement MTEB les compare tâche par tâche ; en pratique, un modèle multilingue de taille moyenne suffit largement pour un corpus francophone, et il tourne sur processeur.

3. Index vectoriels : HNSW et IVF-PQ

Chercher les \(k\) plus proches voisins de façon exacte coûte \(O(nd)\) par requête : 10 millions de vecteurs en dimension 1024 font 40 Go de calcul par question. On utilise donc une recherche approchée (ANN), qui échange quelques points de rappel contre plusieurs ordres de grandeur en latence.

HNSW — un graphe de navigation hiérarchique
  couche 2 (peu de nœuds, liens LONGS)   ●───────────────●      "autoroutes"
  couche 1                               ●────●─────●────●      routes nationales
  couche 0 (tous les nœuds, liens courts)●─●─●─●─●─●─●─●─●      rues locales
  On entre par le haut, on descend en suivant toujours le voisin le plus proche
  de la requête. Quelques dizaines de comparaisons au lieu de dix millions.
  + rappel excellent, latence très faible, insertion dynamique
  - mémoire élevée (le graphe s'ajoute aux vecteurs)
  Paramètres : M (degré), ef_construction (qualité), ef_search (rappel/latence)

IVF-PQ — partition + compression
  1. IVF : on partitionne l'espace en cellules par k-means (module 14) ; à la
     requête, on ne visite que les nprobe cellules les plus proches.
  2. PQ : chaque vecteur est découpé en sous-vecteurs, chacun remplacé par
     le code de son centroïde → mémoire divisée par 10 à 50.
  + adapté aux très grands corpus qui ne tiennent pas en RAM
  - rappel moindre, l'index doit être entraîné au préalable

Le choix de l'outil suit surtout le contexte d'exploitation : pgvector si les données vivent déjà dans PostgreSQL (un seul système à opérer, transactions et filtres SQL gratuits — module 4), FAISS pour un index local sans serveur, Qdrant ou Milvus pour du service dédié avec filtrage par métadonnées et montée en charge. Le filtrage est d'ailleurs le critère discriminant réel : restreindre la recherche à un client ou à une période est trivial en SQL, et demande un support spécifique côté base vectorielle pour rester efficace — filtrer après la recherche approchée peut vider entièrement le résultat.

4. RAG : le pipeline complet

La génération augmentée par récupération répond au problème de fond : au lieu d'espérer que le modèle « sache », on lui fournit les passages pertinents dans le contexte et on lui demande de répondre à partir d'eux. Deux bénéfices immédiats : la connaissance devient à jour et modifiable sans réentraînement, et les réponses deviennent sourçables — donc vérifiables.

INDEXATION (hors ligne)
  1. Extraction        PDF, HTML, Word → texte propre (les tableaux sont le point dur)
  2. Découpage         en passages de 200-500 jetons, avec recouvrement de 10-20 %
  3. Enrichissement    ajouter titre, section, date, source à chaque passage
  4. Embedding         vectoriser chaque passage
  5. Indexation        stocker vecteurs + texte + métadonnées

REQUÊTE (en ligne)
  6. Réécriture        reformuler la question, la désambiguïser avec l'historique
  7. Recherche hybride BM25 (lexical) + vectoriel (sémantique), fusion des rangs
  8. Reranking         un cross-encoder re-note les 50 candidats, on garde les 5 meilleurs
  9. Construction      assembler le prompt : consigne + passages + question
 10. Génération        avec citation obligatoire des sources
 11. Garde-fous        vérifier que la réponse s'appuie sur les passages fournis

Deux étapes font l'essentiel de la différence entre un prototype et un système utilisable.

Le découpage. Trop petit, le passage perd son contexte (« il » ne réfère plus à rien, un chiffre n'a plus son unité) ; trop grand, il dilue le signal et gaspille du contexte payant. Découper sur la structure du document — titres, sections, paragraphes — vaut mieux qu'un découpage à taille fixe qui coupe au milieu d'une phrase. Deux techniques efficaces : la fenêtre glissante avec recouvrement, et le small-to-big, où l'on indexe de petits passages précis (bons pour la recherche) mais où l'on renvoie au modèle le bloc parent complet (bon pour la compréhension).

La recherche hybride et le reranking. La recherche vectorielle seule échoue sur les termes rares — références produit, noms propres, codes — que BM25 trouve immédiatement (module 18) ; inversement BM25 échoue sur les reformulations. Les combiner par fusion de rangs réciproques est robuste et ne demande aucun réglage (module 23). Le reranker (cross-encoder) lit ensemble la question et le passage, au lieu de comparer deux vecteurs calculés séparément : il est nettement plus précis, trop coûteux pour parcourir tout le corpus, mais parfait pour reclasser cinquante candidats. C'est l'amélioration au meilleur rapport gain/effort de tout le pipeline.

from sentence_transformers import SentenceTransformer, CrossEncoder
import numpy as np

encodeur = SentenceTransformer("intfloat/multilingual-e5-base")
reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

# indexation (hors ligne) — noter le préfixe "passage:" exigé par ce modèle
V = encodeur.encode([f"passage: {p}" for p in passages], normalize_embeddings=True)

def repondre(question: str, k_dense: int = 50, k_final: int = 5) -> str:
    q = encodeur.encode(f"query: {question}", normalize_embeddings=True)
    candidats = np.argsort(-(V @ q))[:k_dense]           # cosinus = produit scalaire

    scores = reranker.predict([(question, passages[i]) for i in candidats])
    retenus = [passages[i] for i in candidats[np.argsort(-scores)[:k_final]]]

    contexte = "\n\n".join(f"[{i+1}] {p}" for i, p in enumerate(retenus))
    prompt = (
        "Réponds uniquement à partir des extraits ci-dessous. "
        "Cite tes sources par leur numéro. Si l'information n'y figure pas, "
        "réponds exactement : « Je ne trouve pas cette information ».\n\n"
        f"{contexte}\n\nQuestion : {question}"
    )
    return appeler_llm(prompt, temperature=0)

5. Évaluer un système RAG

Un RAG a deux moitiés, et il faut les évaluer séparément — sinon on ne sait pas laquelle réparer.

• Récupération — rappel@k (le bon passage est-il dans les \(k\) renvoyés ?), MRR et NDCG pour le classement (module 23). Si le rappel@10 est mauvais, aucun travail sur le prompt ne sauvera le système : c'est l'indexation ou la recherche qu'il faut corriger.
• Génération — groundedness (chaque affirmation est-elle appuyée par un passage fourni ?), pertinence de la réponse, exactitude par rapport à une référence. Ces critères s'évaluent avec un LLM juge, calibré au préalable sur quelques dizaines d'exemples annotés à la main — sans quoi on remplace une incertitude par une autre.

La démarche qui marche : constituer un jeu de 50 à 100 questions représentatives avec leurs réponses attendues et les passages qui les contiennent, puis mesurer à chaque modification. Sans ce jeu, toute « amélioration » du prompt est une impression. Des outils comme RAGAS ou promptfoo industrialisent cette boucle.

6. Prompt engineering

Un prompt est une spécification exécutable : il gagne à être structuré comme telle. Ce qui fonctionne de façon reproductible :

• Séparer rôle, consigne, contexte et question, avec des délimiteurs nets. Placer les instructions avant un long contexte, et rappeler la question après — les modèles traitent mieux ce qui encadre.
• Donner des exemples (few-shot) : deux ou trois exemples bien choisis valent mieux qu'un paragraphe d'explications, en particulier pour fixer un format de sortie.
• Demander un raisonnement sur les tâches à étapes, mais dans un champ dédié (raisonnement puis reponse) pour pouvoir l'ignorer à l'affichage.
• Imposer une sortie structurée — JSON contraint par un schéma, validé par Pydantic (module 6). C'est ce qui rend un appel de LLM utilisable dans une chaîne de traitement automatisée.
• Prévoir explicitement l'échappatoire — « si l'information n'est pas disponible, réponds exactement X ». Sans cette porte de sortie, le modèle invente, parce que produire du texte plausible est son objectif.
• Découper les tâches complexes en plusieurs appels spécialisés plutôt qu'un prompt monolithique : chacun devient testable séparément.

Et surtout : évaluer. Un prompt se traite comme du code — un jeu de cas de test, une métrique, un suivi des versions. Itérer « au ressenti » sur trois exemples produit des régressions invisibles sur les autres.

7. Fine-tuning : LoRA, QLoRA, DPO

Réentraîner tous les poids d'un modèle de 7 milliards de paramètres demande des dizaines de gigaoctets de VRAM — poids, gradients et états de l'optimiseur, soit environ 18 octets par paramètre (module 25). L'ajustement à faible rang contourne le problème : on gèle les poids \(W\) et l'on n'apprend qu'une correction de rang faible.

Avec \(r\) de 8 à 64, on entraîne moins de 1 % des paramètres, pour une qualité très proche du fine-tuning complet. C'est exactement l'hypothèse de rang faible du module 8 : l'adaptation à une tâche particulière vit dans un sous-espace de petite dimension. Bénéfice secondaire considérable : les adaptateurs pèsent quelques mégaoctets, donc on peut en stocker des dizaines et les charger à la demande sur un même modèle de base. QLoRA ajoute la quantification du modèle de base en 4 bits, ce qui permet d'ajuster un modèle de 7 milliards de paramètres sur une seule carte grand public.

Besoin                                    Solution           Coût
─────────────────────────────────────────────────────────────────────────────────
Connaissance factuelle, à jour, sourcée   RAG                faible, modifiable à chaud
Format de sortie, ton, style              prompt + few-shot  nul
Tâche répétitive au format très strict    LoRA (SFT)         modéré (heures de GPU)
Vocabulaire ou domaine très spécialisé    LoRA, voire        élevé
                                          pré-entraînement continu
Aligner sur des préférences               DPO                modéré, besoin de préférences
Réduire latence et coût                   distillation vers  élevé, mais amorti
                                          un petit modèle

La règle de décision est simple et souvent ignorée : le fine-tuning enseigne un comportement, le RAG fournit une connaissance. Injecter des faits par fine-tuning fonctionne mal — le modèle les mélange et les oublie —, coûte cher à mettre à jour et empêche toute citation de source. À l'inverse, espérer obtenir un format de sortie très particulier uniquement par prompt finit par saturer : quelques centaines d'exemples et un LoRA règlent le problème définitivement.

Sur l'alignement : le SFT (apprentissage supervisé sur des paires question-réponse) apprend « quoi répondre » ; le DPO apprend à partir de préférences (« cette réponse est meilleure que celle-là ») en optimisant directement une perte de classement, sans passer par un modèle de récompense ni par PPO (module 20). C'est plus simple, plus stable, et devenu le défaut pour aligner un modèle ouvert.

8. Servage, coûts, quantification

La quantification réduit la précision des poids : 16 bits → 8 ou 4 bits. Un modèle de 7 milliards de paramètres passe de 14 Go à environ 4 Go en 4 bits, ce qui le rend exécutable sur une carte modeste. La dégradation en qualité est faible avec les schémas modernes (GPTQ, AWQ, GGUF en k-quants), qui préservent plus finement les poids les plus sensibles — c'est presque toujours le bon compromis pour de l'auto-hébergement, et c'est ce que je fais tourner sur mon NAS avec Ollama.

Pour servir plusieurs utilisateurs, vLLM apporte deux mécanismes décisifs. Le PagedAttention gère le cache KV comme une mémoire paginée : au lieu de réserver le contexte maximal pour chaque séquence, on alloue des blocs à la demande — fini le gaspillage dû aux séquences de longueurs différentes. Le continuous batching insère de nouvelles requêtes dans le lot en cours dès qu'une séquence se termine, au lieu d'attendre la fin du lot entier. Le gain en débit est d'un ordre de grandeur par rapport à une boucle naïve.

Côté coûts, deux ordres de grandeur à garder en tête : le prix d'un appel est dominé par les jetons d'entrée dans un RAG (le contexte est long, la réponse courte), et la latence perçue dépend surtout du premier jeton — d'où l'intérêt du streaming, qui affiche la réponse au fil de la génération. Le cache de prompt, proposé par la plupart des fournisseurs, réduit fortement le coût des préfixes répétés (consignes système, exemples few-shot).

9. Sécurité et limites

• Hallucinations — inhérentes à l'objectif d'entraînement. Le RAG les réduit sans les supprimer ; imposer la citation et vérifier l'ancrage de chaque affirmation reste nécessaire.
• Données personnelles — tout ce qui entre dans un prompt part chez le fournisseur du modèle, et tout ce qui est indexé dans un RAG devient interrogeable par ses utilisateurs. D'où l'anonymisation en amont, le cloisonnement des index par droits d'accès appliqué à la récupération, et parfois l'auto-hébergement.
• Non-déterminisme — même à température 0, le résultat peut varier (parallélisme des noyaux GPU, changements de version côté fournisseur). Il faut versionner les modèles utilisés et rejouer les évaluations à chaque changement.
• Dérive silencieuse — une mise à jour du modèle distant peut dégrader un prompt soigneusement réglé, sans aucun signal. Le suivi d'évaluations dans le temps est la seule protection (module 26).

What this module covers

• How an LLM actually works: tokenisation, next-token sampling, temperature and top-p, and the three practical consequences (no memory, no awareness of ignorance, cost proportional to context).
• Embeddings, cosine similarity, contrastive training, model selection, and the two traps (instruction prefixes, reindexing when the model changes).
• Vector indexes: HNSW vs IVF-PQ, their parameters and trade-offs, and why metadata filtering often decides the tool.
• The full RAG pipeline, with the two stages that matter most: chunking strategy and hybrid search plus cross-encoder reranking.
• Evaluating retrieval and generation separately, with a frozen question set.
• Prompt engineering that survives contact with production: structure, few-shot, structured outputs, explicit escape hatches, and evaluation as code.
• Fine-tuning: LoRA and QLoRA as a low-rank adaptation, SFT vs DPO, and a decision table for prompt vs RAG vs fine-tuning.
• Serving: quantisation, vLLM's PagedAttention and continuous batching, cost and latency drivers.
• Security: prompt injection as a structural vulnerability, hallucinations, personal data, non-determinism and silent drift.

Course outline

1. Modern Python: typing, decorators, iterators and tooling
2. Concurrency in Python: the GIL, threads, processes, asyncio
3. Numerical toolbox: NumPy, pandas, polars, Dask
4. SQL and databases
5. Docker, Compose and Kubernetes
6. Serving a model: FastAPI, Pydantic, Jinja
7. Data engineering: formats, pipelines and streams
8. Math for ML: optimisation, linear algebra, SVD and PCA
9. Inferential statistics: estimate, test, decide
10. Probability, Bayesian inference and uncertainty quantification
11. Causal inference: measuring the effect of an action
12. Data science in practice: from problem to dataset
13. Learning with few labels
14. Classical machine learning
15. Learning theory: why generalisation happens
16. Deep learning
17. Time series, signals and time-to-event data
18. Non-tabular data: text, images, audio, graphs
19. Gaussian processes and Bayesian optimisation
20. Reinforcement learning
21. Machine learning for simulation and engineering
22. LLMs, embeddings, RAG and adaptation
23. Search, ranking and recommendation
24. From scores to decisions
25. Scaling up: GPUs, distributed training, performance
26. MLOps: taking a model to production
27. Fairness, robustness, privacy and security
28. End-to-end project: property listings, from scraping to price prediction