← Retour au blog Architecture IA

Comment industrialiser un pipeline LLM en production

Retour d'expérience sur 12 mois de déploiements IA chez AXA : orchestration, monitoring, gestion des coûts et points de défaillance.

Le contexte : de l’expérimentation à la production

Depuis début 2024, j’ai travaillé sur l’industrialisation d’un pipeline LLM pour AXA Group Operations, destiné à extraire et modéliser automatiquement des contrats d’assurance complexes. Ce qui a commencé comme une preuve de concept avec quelques appels OpenAI dans un notebook Jupyter s’est rapidement transformé en un système critique traitant des milliers de documents par jour.

Voici ce que j’ai appris en mettant ce pipeline en production — et les erreurs coûteuses que vous pouvez éviter.

Architecture : les fondations d’un système fiable

1. Orchestration avec Airflow

J’ai choisi Apache Airflow pour orchestrer l’ensemble du pipeline. Pas parce que c’est à la mode, mais parce que :

Le DAG principal ressemble à ceci :

ingestion >> validation >> chunking >> llm_extraction >> post_processing >> storage

Chaque étape est idempotente. Si l’extraction LLM plante à 80%, on ne recommence pas à zéro.

2. Stratégie multi-modèle

Ne jamais dépendre d’un seul fournisseur. Notre stack :

Le routeur de modèle décide en fonction de :

3. Gestion des coûts : le vrai problème

En novembre 2024, notre facture OpenAI a atteint $12,000/mois. Voici comment on l’a ramenée à $3,200 :

Caching agressif

# Hash sémantique du contenu + version du prompt
cache_key = f"{"{"}doc_hash}:{"{"}prompt_version}"
if cached := redis.get(cache_key):
    return cached

Prompt engineering rigoureux

Batching intelligent Regrouper plusieurs extractions dans un seul appel quand possible (attention : ça réduit la précision de 2-3%).

Monitoring : ce qui compte vraiment

Les métriques classiques (latence, throughput) ne suffisent pas. Voici ce qu’on surveille :

Métriques métier

Alertes opérationnelles

Points de défaillance et solutions

Problème #1 : Hallucinations structurées

Le LLM invente des clauses qui n’existent pas, mais le JSON est parfaitement valide.

Solution : Validation cross-référencée

# Extraire 2x avec des prompts différents
result_a = extract_with_prompt_v1(doc)
result_b = extract_with_prompt_v2(doc)

# Comparer les outputs
if similarity(result_a, result_b) < 0.85:
    flag_for_human_review()

Problème #2 : Latence imprévisible

Certains documents prenaient 45 secondes, d’autres 3 minutes. Impossible de provisionner correctement.

Solution : Timeouts adaptatifs par taille de document

timeout = base_timeout + (doc_size_kb * timeout_per_kb)

Problème #3 : State management distribué

Avec 20 workers Airflow parallèles, maintenir l’état cohérent était un cauchemar.

Solution : PostgreSQL comme source de vérité unique, Redis pour le caching éphémère uniquement.

Déploiement : l’infrastructure

Stack AWS

CI/CD

Leçons apprises

  1. Commencer petit, scaler prudemment : ne pas paralléliser avant d’avoir résolu la fiabilité sur 1 thread
  2. Les prompts sont du code : versionnés, testés, reviewés
  3. La qualité > la vitesse : un mauvais résultat rapide coûte plus cher qu’un bon résultat lent
  4. Prévoir le budget tokens : comme on prévoit le budget cloud classique
  5. Human feedback loop essentiel : au moins les 3 premiers mois, quelqu’un valide 100% des outputs

Résultats chiffrés

Après 12 mois en production :

Conclusion

Industrialiser un pipeline LLM, ce n’est pas juste “coller GPT-4 sur vos données”. C’est de l’ingénierie distribuée classique, avec en plus la gestion d’un composant externe non-déterministe et coûteux.

Si vous vous lancez : investissez dans le monitoring dès le jour 1, ne sous-estimez pas les coûts, et gardez toujours un humain dans la boucle au début.

Besoin d’aide pour architecturer votre pipeline IA ? Contactez-moi pour un audit ou un accompagnement technique.