L'ingénierie des LLM & l'architecture FTI

Savoir invoquer un grand modèle de langage (large language model, LLM) derrière un prompt bien tourné ne fait pas de vous un ingénieur des LLM. L'ingénierie des LLM commence là où s'arrête le notebook : quand il faut collecter et versionner des données, fine-tuner un modèle, l'évaluer, le servir avec une latence acceptable, le monitorer en production et automatiser tout le cycle. Le livre de Paul Iusztin et Maxime Labonne part d'une conviction simple : on apprend les LLM et le ML de production en se salissant les mains, en construisant des systèmes complets plutôt que des démonstrations jetables.

Pour incarner cette philosophie, les auteurs déroulent un projet fil rouge tout au long de l'ouvrage : le « LLM Twin », un jumeau numérique qui apprend à écrire dans votre style. Ce chapitre pose les fondations conceptuelles. D'abord ce qu'est ce LLM Twin et pourquoi le construire. Ensuite — et c'est le cœur technique — l'architecture FTI (feature/training/inference), un patron qui décompose n'importe quel système ML en trois pipelines découplés. Enfin, l'application de ce patron à l'architecture concrète du LLM Twin.

Au-delà du prompt : qu'est-ce que l'ingénierie des LLM ?

Du point de vue de l'ingénieur, entraîner un modèle est souvent l'étape la plus simple. Trouver la bonne architecture et les bons hyperparamètres est un problème de recherche ; mais transformer un modèle entraîné sur un jeu de données statique en un service robuste est un problème d'ingénierie, et c'est là que tout se complique. Iusztin et Labonne énumèrent les questions qu'un ingénieur ML ou MLOps doit trancher :

• Ingérer, nettoyer et valider des données fraîches en continu.
• Distinguer les contextes d'entraînement (training) et d'inférence (inference).
• Calculer et servir les features dans le bon environnement.
• Servir le modèle de façon économe (cost-effective).
• Versionner, tracer et partager jeux de données et modèles.
• Monitorer l'infrastructure et les modèles.
• Déployer sur une infrastructure capable de monter en charge.
• Automatiser les déploiements et les entraînements.

Le piège du proof of concept (POC) est précisément là. Un notebook qui produit un beau résultat sur un jeu de données figé donne l'illusion d'avoir résolu le problème, alors que l'essentiel — la fiabilité, la reproductibilité, l'exploitation — reste à faire. L'ingénierie des LLM consiste à concevoir, dès le départ, l'architecture de production qui rendra ces vingt pièces mouvantes maîtrisables.

Le projet fil rouge : le « LLM Twin »

Un LLM Twin est un personnage d'IA qui incorpore votre style d'écriture, votre voix et votre personnalité dans un LLM. C'est une version numérique de vous-même projetée dans le modèle. Là où un LLM générique est entraîné sur tout l'internet, le LLM Twin est fine-tuné sur vous. Le mot « projeté » est choisi à dessein : comme toute projection, il perd de l'information en chemin. Le jumeau ne sera jamais vous ; il copiera la part de vous que reflètent les données sur lesquelles il a appris.

Le mécanisme repose sur le transfert de style (style transfer) : un modèle reflète ses données d'entraînement. Nourrissez-le de Shakespeare, il écrira comme Shakespeare. Pour le calibrer sur une persona, on combine deux leviers développés plus loin dans le livre : le fine-tuning (chapitre 5) et des techniques avancées de génération augmentée par récupération (retrieval-augmented generation, RAG) (chapitres 4 et 9), qui conditionnent le décodage autorégressif avec des embeddings de vos contenus passés.

Un point d'architecture mérite d'être souligné dès maintenant : le système est agnostique au modèle (model-agnostic). Rien n'interdit d'utiliser l'API d'OpenAI ; le cadre présenté fonctionne avec tout LLM manipulable par programme et exposant une interface de fine-tuning. La clé des produits ML qui réussissent est d'être centré sur la donnée (data-centric) et agnostique au modèle, afin de pouvoir expérimenter rapidement plusieurs modèles sur ses propres données.

Le périmètre retenu pour le produit minimum viable (minimum viable product, MVP) reste volontairement modeste mais complet de bout en bout : collecter des données depuis LinkedIn, Medium, Substack et GitHub ; fine-tuner un LLM open source ; peupler une base de données vectorielle (vector database) pour le RAG ; générer des posts LinkedIn ; et exposer une interface web simple. La discipline du MVP impose de respecter le « V » de viable : un parcours utilisateur entier, sans fonctionnalité à moitié implémentée.

L'architecture FTI : trois pipelines pour tout système ML

Avant de concevoir le LLM Twin, il faut un patron d'architecture. Les auteurs s'appuient sur l'architecture FTI (feature/training/inference), popularisée par Jim Dowling de Hopsworks. Pour en saisir l'intérêt, regardons d'abord ce qu'elle remplace.

Le problème des approches antérieures

L'architecture la plus courante des applications ML est un monolithe batch qui couple création des features, entraînement et inférence dans le même composant. Cette approche résout d'emblée un problème réel, le décalage entraînement/service (training-serving skew) — situation où les features passées au modèle sont calculées différemment à l'entraînement et à l'inférence. Puisque le même code produit les features dans les deux cas, le décalage disparaît par construction. Le monolithe fonctionne bien sur de petites données traitées en batch sur une planification régulière.

Mais il accumule les défauts :

• Les features ne sont pas réutilisables par d'autres systèmes.
• Si la donnée croît, il faut réécrire tout le code pour passer à PySpark ou Ray.
• Difficile de réécrire le module de prédiction dans un langage plus performant (C++, Java, Rust).
• Difficile de répartir le travail entre plusieurs équipes.
• Impossible de basculer vers du streaming pour de l'entraînement temps réel.

L'autre extrême, l'architecture temps réel sans état (stateless), déplace le problème : pour prédire, le client doit transmettre tout l'état dans sa requête. Pour recommander un film, il ne suffit plus d'envoyer un identifiant utilisateur : il faut transmettre son nom, son âge, son historique… Le client se retrouve couplé au service de modèle et doit savoir accéder à cet état. C'est un anti-patron. Même chose pour un LLM avec RAG : sans base vectorielle pour stocker les documents, le client devrait les récupérer et les passer lui-même, ce qui n'est pas viable.

MONOLITHE BATCH (couplage)
  [ features + training + inference dans UN composant ]
  + pas de decalage entrainement/service (meme code)
  - features non reutilisables, scaling global, equipes bloquees

TEMPS REEL SANS ETAT (couplage cote client)
  client --(tout l'etat: nom, age, historique...)--> [ modele ]
  - le client doit savoir calculer/recuperer les features = anti-patron

FTI (decouplage par stockage partage)
  client --(juste un ID)--> [ inference ] <-- feature store
                                          <-- model registry
  + le service va chercher les features lui-meme

Les trois pipelines

Le patron FTI affirme que tout système ML se ramène à trois pipelines — feature, training, inference — exactement comme une application logicielle classique se ramène à une base de données, une logique métier et une couche d'interface. La puissance de cette abstraction tient à ce qu'elle réduit vingt pièces mouvantes à trois, dont on définit clairement le périmètre et l'interface.

        +---------------------+
 raw -->|  FEATURE pipeline   |--> features/labels
 data   +---------------------+        |
                                       v
                              +-----------------+
                              |  FEATURE STORE  |  (versionne, trace,
                              +-----------------+   partage les features)
                                  |          |
                  features/labels |          | features (online)
                                  v          |
                       +------------------+   |
                       | TRAINING pipeline|   |
                       +------------------+   |
                                  |           |
                            model |           |
                                  v           |
                          +----------------+  |
                          | MODEL REGISTRY |  | (versionne, trace,
                          +----------------+  |  partage les modeles)
                                  |           |
                            model |           |
                                  v           v
                          +------------------------+
                          |   INFERENCE pipeline   |--> predictions
                          +------------------------+

Chaque pipeline est un composant distinct, qui peut tourner sur un autre processus ou un autre matériel, être écrit dans une autre technologie, par une autre équipe, et scalé différemment. Le patron n'est pas une cage : c'est une carte mentale pour structurer l'architecture.

Pipeline	Rôle	Entrées	Sorties
Feature	Transformer la donnée brute en features et labels, les stocker	Données brutes	Features/labels écrits dans le feature store
Training	Entraîner ou fine-tuner un modèle, le publier	Features/labels lus du feature store	Modèle écrit dans le model registry
Inference	Servir des prédictions, en batch ou temps réel	Features (feature store) + modèle (model registry)	Prédictions (stockées ou servies au client)

Détaillons les responsabilités. Le pipeline de features (feature pipeline) prend la donnée brute, la traite, et au lieu de passer directement les features au modèle, les enregistre dans un feature store chargé de les stocker, versionner, tracer et partager. Comme la donnée est versionnée, on garantit que les features d'entraînement et d'inférence correspondent : le décalage entraînement/service est éliminé, mais sans le couplage du monolithe.

Le pipeline d'entraînement (training pipeline) lit features et labels depuis le feature store et produit un modèle stocké dans le registre de modèles (model registry). Ce registre joue pour le modèle le rôle que le feature store joue pour les features : stockage, versionnage, traçage, partage. Les registres modernes embarquent un magasin de métadonnées (metadata store) qui consigne, entre autres, quelles features, labels et versions ont servi à l'entraînement — on sait toujours sur quelles données un modèle a appris.

Le pipeline d'inférence (inference pipeline) lit les features du feature store et le modèle du registre, puis produit des prédictions en batch (stockées en base) ou en temps réel (servies au client). Comme tout est versionné, on met à niveau ou on revient en arrière facilement : on sait que le modèle v1 utilise les features F1, F2, F3 et que la v2 utilise F2, F3, F4, et on recâble les liens en conséquence.

Pourquoi cette abstraction gagne

L'essentiel à retenir, ce sont les interfaces — et elles ne changent jamais, quelle que soit la complexité du système :

# Les trois pipelines partagent un contrat d'interface stable.
# C'est ce contrat, et non leur implementation, qui garantit
# le decouplage du systeme.

def feature_pipeline(raw_data) -> None:
    """Donnee brute -> features/labels ecrits au feature store."""
    features, labels = clean_and_transform(raw_data)
    feature_store.save(features, labels, version="v1")

def training_pipeline() -> None:
    """Feature store -> modele publie au model registry."""
    features, labels = feature_store.get_training_set(version="v1")
    model = fine_tune(features, labels)
    model_registry.push(model, tag="candidate")

def inference_pipeline(query):
    """Feature store + model registry -> prediction."""
    model = model_registry.load(tag="production")
    features = feature_store.get_online(query)  # acces en ligne
    return model.predict(features, query)

Les bénéfices découlent directement de ce contrat :

• Intuitif : trois composants seulement, faciles à comprendre.
• Pile technique adaptable : chaque composant a sa propre stack ; on choisit le meilleur outil pour le big data ou le streaming, pipeline par pipeline.
• Développement parallèle : grâce à l'interface transparente, chaque composant peut être développé par une équipe différente.
• Exploitation indépendante : chaque composant se déploie, se scale et se monitore séparément.

Application au LLM Twin

Le LLM Twin se découpe en quatre composants. Pourquoi quatre et non trois ? Parce qu'il faut ajouter un pipeline de données (data pipeline) aux trois pipelines FTI. Dans une organisation idéale, l'équipe data ingénierie possède le pipeline de données et l'équipe ML possède les pipelines FTI ; mais une petite équipe construisant un MVP doit tout porter — situation typique des start-ups où les ingénieurs cumulent les casquettes.

À ce stade, les auteurs insistent : on raisonne agnostique au langage, au framework, à la plateforme et à l'infrastructure. On ne définit que le périmètre, l'interface et l'interconnexion de chaque composant.

Composant	Patron / rôle	Sortie principale
Collecte de données	ETL : extraire, standardiser, charger les crawls	Base NoSQL (data warehouse)
Feature	Nettoyer, chunker, embedder les 3 types de données	Feature store logique (vector DB + artefacts)
Training	Fine-tuner un LLM sur les instruct datasets	LLM dans le model registry
Inference	RAG + génération via API REST	Réponses + flux de monitoring

Le pipeline de collecte de données

Il crawle vos données personnelles depuis Medium, Substack, LinkedIn et GitHub selon le patron extraire, standardiser, charger (extract, transform, load, ETL), puis les charge dans une base NoSQL faisant office d'entrepôt de données (data warehouse). En pratique, les auteurs décrivent un flux extraire -> standardiser -> charger, proche d'un ELT, où la transformation lourde est repoussée au pipeline de features. Le texte étant non structuré, une base NoSQL comme MongoDB convient parfaitement. Astuce de conception : les données sont rangées par catégorie (articles, posts, code) et non par source. Chaque catégorie se traite différemment — la stratégie de chunking d'un post, d'un article et d'un bout de code diffère — et ce regroupement permet de brancher une nouvelle plateforme (X dans les posts, GitLab dans le code) en ajoutant simplement un ETL, sans toucher au reste.

Le pipeline de features

Il prend les articles, posts et code bruts de l'entrepôt, les traite et les charge dans le feature store via trois étapes : nettoyage (cleaning), découpage (chunking) et vectorisation (embedding). Il crée deux instantanés : un après nettoyage (pour le fine-tuning), un après embedding (pour le RAG). Particularité notable : il utilise un feature store logique (logical feature store) plutôt qu'un feature store spécialisé.

Le pipeline d'entraînement

Il consomme les instruct datasets du feature store, fine-tune un LLM et stocke ses poids dans le model registry. Quand un nouvel instruct dataset apparaît, le pipeline se déclenche. L'équipe data science y mène ses expériences, comparées via un suivi d'expériences (experiment tracker), jusqu'à proposer un candidat de production (production candidate). Un pipeline de test plus strict évalue ensuite ce candidat contre le modèle en production. Même dans un système entièrement automatisé, les auteurs recommandent une étape manuelle d'approbation avant d'accepter un nouveau modèle — le « bouton rouge » qu'un expert presse après lecture d'un rapport. Une fois validé, l'entraînement continu (continuous training, CT) peut s'enchaîner sans friction.

Le pipeline d'inférence

Dernière pièce du puzzle, connecté au model registry et au feature store logique. Il charge le LLM fine-tuné, accède à la base vectorielle pour le RAG, reçoit les requêtes clients via une API REST, et répond en combinant le modèle et la récupération de contexte. Toutes les requêtes, les prompts enrichis et les réponses générées partent vers un système de monitoring des prompts (prompt monitoring) pour analyse, débogage et déclenchement d'alertes. Au niveau de l'interface, ce composant respecte exactement FTI ; en zoomant, il révèle ses spécificités LLM : un client de récupération pour la recherche vectorielle, des gabarits de prompt (prompt templates), et des outils de monitoring dédiés.

Calcul et mise à l'échelle

Le découplage FTI permet d'ajuster les ressources composant par composant, ce qui tombe bien car leurs besoins divergent radicalement :

Composant	Profil de calcul	Mise à l'échelle
Collecte de données	CPU, peu exigeant	Horizontale (CPU/RAM)
Feature	CPU, peu exigeant	Horizontale (CPU/RAM)
Training	GPU puissant (charger et fine-tuner un LLM)	Verticale (plus de GPU)
Inference	Intermédiaire, sensible à la latence	Horizontale (nombre de requêtes)

Cette modularité explique aussi le CT/CI/CD : un orchestrateur ML planifie et déclenche les parties du système — crawler chaque semaine, lancer le pipeline de features quand de nouvelles données arrivent, déclencher l'entraînement quand un nouvel instruct dataset est prêt.

À retenir

• L'ingénierie des LLM dépasse de loin le prompt : c'est la construction de systèmes complets et fiables — données, entraînement, inférence, exploitation — là où le notebook ou le POC ne livre qu'une illusion de solution.
• Le projet fil rouge, le LLM Twin, projette votre style dans un LLM par fine-tuning et RAG ; sa valeur tient à la donnée et au système qui l'entoure, et son architecture reste agnostique au modèle et centrée sur la donnée.
• L'architecture FTI ramène tout système ML à trois pipelines — feature, training, inference — comme le logiciel classique se ramène à base de données, logique métier et interface.
• La communication passe par des artefacts partagés : le feature store (features versionnées) et le model registry (modèles versionnés). C'est ce contrat d'interface, stable quelle que soit la complexité, qui élimine le décalage entraînement/service sans le couplage du monolithe.
• Les bénéfices clés sont la modularité, la scalabilité indépendante, la réutilisation, la testabilité et la séparation des responsabilités — chaque pipeline a sa stack, son équipe, ses ressources et sa stratégie de mise à l'échelle.
• FTI est une carte mentale, pas une cage : un système réel comporte plus de trois pipelines (le LLM Twin en ajoute un de collecte de données) et peut substituer un feature store logique au feature store spécialisé, tant que l'interface est respectée.