Fondamentaux de l'IA générative

Trois ingrédients se sont rencontrés :

1. L’architecture Transformer (Google, 2017) et son mécanisme d’attention : chaque token « regarde » tous les autres pour construire sa représentation. Contrairement aux RNN, tout se calcule en parallèle — parfait pour les GPU.
2. Le passage à l’échelle : plus de paramètres, plus de données, plus de calcul donnent des modèles de plus en plus capables, de façon assez prévisible (scaling laws).
3. L’alignement par feedback humain (InstructGPT, 2022) : un modèle de langage brut complète du texte ; après post-entraînement (SFT puis RLHF), il suit des instructions. C’est ce qui a transformé un autocompléteur en assistant — et donné ChatGPT en novembre 2022.

Le critère « erreur peu coûteuse + vérification facile » se combine avec les quatre traits d’un bon candidat. En pratique, on peut le dérouler ainsi avant d’écrire une ligne de code :

Deux réflexes de terrain : chiffrer la baseline avant le projet (sinon impossible de prouver le gain), et préférer les cas où l’IA propose et l’humain dispose — c’est le design le plus robuste face à l’hallucination.

Le cours illustre le pré-entraînement par un texte à trous. Pour les LLM génératifs (GPT, Claude, Llama, Qwen…), le trou est toujours à la fin : l’objectif est de prédire le token suivant à partir de tous les précédents (modèle causal ou autorégressif). Le « vrai » texte à trous au milieu de la phrase (masked language modeling) est l’objectif de BERT, un modèle qui comprend mais ne génère pas — on le retrouve dans les modèles d’embedding de la session 2.

Le post-entraînement se fait en général en deux temps : SFT (supervised fine-tuning sur des paires rédigées) puis une optimisation par préférences (RLHF, DPO…) où l’on apprend au modèle à préférer la meilleure de deux réponses.

Une requête d’inférence se déroule en deux phases :

• Prefill : tous les tokens d’entrée passent ensemble dans le réseau, en une seule passe massivement parallèle. Le GPU est utilisé à plein, c’est efficace.
• Decode : chaque token de sortie exige une passe complète du modèle, et dépend du précédent. On ne peut pas paralléliser dans le temps ; le GPU attend surtout la mémoire.

Pour ne pas tout recalculer à chaque token, le serveur garde les représentations intermédiaires des tokens déjà vus : le KV cache. Il coûte de la mémoire GPU proportionnelle à la longueur du contexte — c’est l’une des raisons pour lesquelles les très longs contextes sont chers.

Conséquence d’architecture : beaucoup de fournisseurs proposent du prompt caching — si le début de ton prompt (règles, documents) est identique d’un appel à l’autre, il est facturé beaucoup moins cher. On place donc le contenu stable en tête du prompt et la partie variable à la fin.

Côté découpage, la plupart des tokenizers utilisent une variante de BPE (Byte Pair Encoding) : on part des octets, on fusionne itérativement les paires les plus fréquentes du corpus. Les mots fréquents deviennent un seul token ; les mots rares, une suite de fragments.

Les autres réglages d’échantillonnage. La température n’est pas seule : top-k ne garde que les k tokens les plus probables, top-p (nucleus) garde le plus petit ensemble dont les probabilités cumulées dépassent p. On règle en général l’un ou l’autre, pas tout à la fois.

Température 0 ≠ déterministe. Même à 0, deux appels identiques peuvent différer : les calculs en virgule flottante ne sont pas associatifs, et le serveur regroupe ta requête avec celles d’autres clients (batching) — la taille du lot change l’ordre des opérations, donc parfois le token gagnant. S’y ajoutent les mises à jour silencieuses du modèle côté fournisseur. Conséquence : on teste sur des distributions (un jeu d’évaluation), jamais sur une seule exécution.

Les leviers contre l’hallucination, du plus au moins efficace :

1. Ancrer la réponse dans des sources fournies dans le contexte (RAG, session 2) et exiger des citations vérifiables.
2. Donner au modèle le droit de ne pas savoir : une valeur explicite comme "Unknown", plutôt que le forcer à remplir.
3. Contraindre la forme : sortie structurée (JSON validé par un schéma), valeurs autorisées énumérées.
4. Vérifier en aval : validation par code, second modèle juge, ou humain sur les actions à risque.
5. Mesurer le taux d’erreur sur un jeu d’évaluation (session 5).

Les données IoT sont surtout des nombres — le cœur de la valeur GenAI est donc souvent autour du flux, là où il y a du texte :

• Assistant de diagnostic : à partir d’une alerte (levée par du ML classique ou un seuil), il lit les manuels et l’historique des interventions sur l’équipement et propose une procédure. Le technicien décide.
• Requêtes en langage naturel sur la télémétrie : « quels capteurs de la zone B ont dépassé 8 °C cette semaine ? » → le modèle génère une requête (SQL, PromQL…) validée puis exécutée par le code, pas par le modèle.
• Triage des tickets de support (comme l’exercice bonus) : extraction structurée, classification, routage.
• Rapport d’incident : transformer les notes brutes d’un technicien en rapport structuré.

Pour chacun, pose les questions de l’arbre de décision plus haut : coût d’une erreur, facilité de vérification, avant/après mesurable.

• Poids ouverts ≠ open source. Beaucoup de modèles « open » publient leurs poids sous une licence qui restreint certains usages ; les données et le code d’entraînement restent fermés. Lis la licence avant de l’embarquer dans un produit.
• Ne choisis pas UN modèle. En production, on route souvent : un petit modèle rapide et bon marché pour les tâches simples (classification, extraction), un grand modèle pour le raisonnement. Mets une couche d’abstraction (une LLM gateway, session 4) entre ton code et les fournisseurs pour pouvoir changer de modèle sans réécrire l’application — c’est aussi ta stratégie de sortie si un fournisseur coupe l’accès.
• Re-évalue régulièrement : un nouveau modèle sort tous les mois. Ton jeu d’évaluation est ce qui rend le changement de modèle sûr et rapide.

• Imposer le format plutôt que le demander. La plupart des API (et Ollama, via le paramètre format) acceptent un JSON Schema : le décodage est contraint, la sortie est forcément valide. Garde quand même une validation côté code (Pydantic, Zod) : le schéma garantit la forme, pas la justesse des valeurs.
• Délimiter les données. Encadre les données utilisateur par des balises (<message_client>…</message_client>) et place-les après les instructions : le modèle distingue mieux ce qu’il doit faire de ce qu’il doit traiter — c’est une défense partielle contre l’injection.
• Versionner le prompt comme du code : il vit dans le dépôt, il a des tests (ton jeu d’évaluation) et un historique. Changer une phrase peut changer les résultats ; on ne le découvre qu’en mesurant.
• Chain of thought et modèles de raisonnement. Les modèles récents dits « de raisonnement » réfléchissent déjà avant de répondre ; leur demander « réfléchis étape par étape » apporte moins. Pour une extraction structurée, la consigne « vérifie avant de répondre, n’affiche pas la vérification » suffit.

Pourquoi 8 milliards de paramètres tiennent dans 5 Go. La mémoire ≈ paramètres × bits par poids ÷ 8. En précision 16 bits, un modèle 8B pèse ~16 Go ; Ollama distribue par défaut des versions quantifiées sur ~4 bits (formats Q4_K_M & co.) : 8 × 4 ÷ 8 ≈ 4 Go, plus les métadonnées et le KV cache. La quantification dégrade légèrement la qualité, beaucoup moins que de passer à un modèle plus petit.

Lire --verbose. prompt eval rate = vitesse du prefill (élevée, parallèle) ; eval rate = vitesse du decode (tokens générés par seconde, bien plus faible). Tu retrouves l’asymétrie qui explique le prix des tokens de sortie.

Ollama est un serveur. Il expose une API sur localhost:11434, dont une route compatible OpenAI — ton code peut passer d’un modèle local à un modèle cloud en changeant une URL :

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3:4b",
  "stream": false,
  "options": { "temperature": 0 },
  "messages": [{ "role": "user", "content": "Donne 3 usages de la GenAI en IoT." }]
}'

Bonus : refais l’exercice de triage en passant le schéma JSON dans le champ format de la requête, et compare la robustesse de la sortie.