Quelles bibliothèques Python LLM pour un ingénieur ?

Hugging Face, LangChain, Pydantic AI, LlamaIndex et Unsloth couvrent l’essentiel : accès aux modèles, orchestration d’applications, validation typée, RAG et fine‑tuning — des ressources comme le Hugging Face LLM Course et les docs LangChain confirment leur centralité.

Comment utiliser Hugging Face Transformers

Hugging Face Transformers permet de charger, tokeniser et effectuer de l’inférence sur des milliers de modèles préentraînés via le Hub.

Les cas d’usage principaux sont simples et souvent complémentaires.

• Prototypage : Permet de tester très vite des modèles pour valider une idée ou un prompt.
• Inférence locale : Permet d’exécuter des modèles sur votre machine ou vos serveurs pour la latence et la confidentialité.
• Export / Serving : Permet d’exporter ou de convertir des poids pour des serveurs de production (TorchScript, ONNX, TF SavedModel).
• Compatibilité PyTorch/TensorFlow : Offre des wrappers pour utiliser soit PyTorch (AutoModel…) soit TensorFlow (TFAutoModel…).

Installation pas à pas.

• Installer la bibliothèque principale et un runtime ML : pip install transformers torch.
• Ajouter TensorFlow seulement si nécessaire : pip install tensorflow.
• Vérifier la version avec python -c « import transformers; print(transformers.__version__) ».

Exemple 1 : inférence rapide avec facebook/opt-125m.

from transformers import AutoTokenizer, AutoModelForCausalLM
tokenizer = AutoTokenizer.from_pretrained("facebook/opt-125m")
model = AutoModelForCausalLM.from_pretrained("facebook/opt-125m")
inputs = tokenizer("Bonjour, comment ça va ?", return_tensors="pt")
outputs = model.generate(**inputs, max_length=50)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Exemple 2 : basculer entre PyTorch et TensorFlow.

from transformers import AutoTokenizer, TFAutoModelForCausalLM
tokenizer = AutoTokenizer.from_pretrained("facebook/opt-125m")
model = TFAutoModelForCausalLM.from_pretrained("facebook/opt-125m", from_pt=True)
inputs = tokenizer("Salut", return_tensors="tf")
outputs = model.generate(**inputs, max_length=30)
print(tokenizer.decode(outputs[0].numpy()[0], skip_special_tokens=True))

Conseils production.

• Choix du modèle : Privilégier la taille minimale qui atteint vos KPI pour réduire coûts et latence.
• Quantization : Utile pour réduire mémoire et coût d’inférence ; choisir une méthode et une librairie éprouvées (ex. quantization post-training), mais tester la dégradation qualitative.
• Cache du Hub : Exploiter le cache local (~/.cache/huggingface) pour éviter des téléchargements répétés en production.
• Vigilance mémoire : Surveiller VRAM/RAM, prévoir batch sizes et attention aux séquences longues qui explosent la mémoire.

Transformer fournit les modèles (les poids et tokenizers) que des outils comme LangChain vont orchestrer pour construire des workflows, chainer des prompts et gérer le routage entre backends.

Prototypage	Chargement instantané de milliers de modèles pour tester des idées.
Inférence locale	Contrôle, confidentialité et latence réduite grâce à l’exécution locale.
Export / Serving	Compatibilité et conversions vers formats de serving (TorchScript/ONNX/TF).

Comment construire des applications LLM avec LangChain

LangChain fournit des briques modulaires (chains, agents, memory, connectors) pour composer des applications LLM complexes.

LangChain rassemble les composants centraux suivants pour orchestrer des flux LLM robustes.

Chains	Orchestrent des étapes séquentielles (prétraitement, retrieval, LLM, post‑traitement).
Agents	Décident dynamiquement quelle action exécuter (appel d’outil, question au modèle), utile pour workflows multi‑étapes.
Memory	Garde le contexte conversationnel entre requêtes (ex. ConversationBufferMemory).
Tools	Connecteurs vers APIs externes (web, calcul, bases de données) que l’agent peut invoquer.
Retrievers	Interface d’accès aux stores vectoriels (Chroma, FAISS, Pinecone) pour la RAG (Retrieval‑Augmented Generation).

Cas d’usage concrets : question‑réponse sur corpus d’entreprise, résumé contextuel de documents, agent conversationnel multi‑step (pattern ReAct : Reason+Act), et orchestration d’APIs pour accomplir des tâches complexes.

Exemple minimal : chaîne question→retrieval→LLM (Hugging Face ou cloud)

from langchain.huggingface_hub import HuggingFaceHub
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA

# Connexion au modèle Hugging Face
llm = HuggingFaceHub(repo_id="google/flan-t5-large", model_kwargs={"temperature":0})

# Création du store vectoriel et du retriever
vectordb = Chroma(persist_directory="db")
retriever = vectordb.as_retriever()

# Chaîne RAG
chain = RetrievalQA.from_chain_type(llm=llm, chain_type="stuff", retriever=retriever)
resp = chain.run("Quelle est la procédure pour X ?")
print(resp)

Exemple d’agent simple avec outil externe et mémoire

from langchain.agents import initialize_agent, Tool, AgentType
from langchain.memory import ConversationBufferMemory
import requests

# Outil qui appelle une API externe
def get_weather(city: str) -> str:
    r = requests.get(f"https://api.meteo.example/{city}")
    return r.text

tool = Tool(name="weather", func=get_weather, description="Obtenir la météo pour une ville")

memory = ConversationBufferMemory(memory_key="chat_history")
agent = initialize_agent([tool], llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, memory=memory)
print(agent.run("Quel temps fera à Paris demain ?"))

Conseils d’architecture : tester chaque chaîne avec entrées mockées, prévoir retries et backoffs pour les appels LLM, monitorer coûts (ex. coûts par token), et définir quotas/guards pour éviter boucles d’agent.

LangChain complète LlamaIndex en déléguant l’ingestion et l’indexation (embeddings, chunking) à LlamaIndex, tandis que LangChain orchestre les flows et agents. Pydantic AI sert à valider/saniter les schémas de données et à limiter les surfaces d’attaque des agents.

Rendu attendu : HTML valide.

• Choisir LangChain si vous voulez modularité, intégrations prêtes et agents dynamiques.
• Préférer une implémentation maison si vous avez besoins ultra‑spécifiques et contraintes légales fortes (coût de maintenance élevé).
• Combiner LangChain + LlamaIndex pour ingestion/indexation et réutilisabilité.
• Penser Pydantic AI pour validation stricte des entrées/sorties des agents.

Pourquoi utiliser Pydantic AI pour des agents typés

Pydantic AI apporte typage strict, validation et observabilité aux agents Python pour réduire les erreurs et améliorer la sécurité.

J’utilise Pydantic AI pour imposer des contrats de données clairs entre les composants d’un agent et pour capter les anomalies dès l’entrée et à la sortie des modèles. Les bénéfices concrets sont la validation des entrées/sorties, la prévention des exceptions silencieuses, une meilleure traçabilité des causes d’erreur et une réaction automatisable aux violations de contrat.

• Validation des entrées/sorties : Permet d’empêcher l’exécution avec des données malformées et de produire des erreurs explicites et traçables.
• Contrats de données : Facilite le design de RPC internes entre outils d’agent, pipelines et UI en garantissant des schémas immuables.
• Traçabilité et réactivité : Rend possible le logging structuré des violations et le déclenchement d’alertes ou de fallbacks programmatiques.

Scénarios d’utilisation typiques incluent des agents manipulant des données sensibles (PII), des pipelines multi‑fournisseurs où chaque étape doit respecter un schéma, des systèmes d’event streaming UI où la cohérence d’un événement est critique, et l’exécution durable où les tâches asynchrones doivent être rejouables avec des contrats stables.

Exemple de code (validation et gestion d’erreur) :

from pydantic import BaseModel, ValidationError
import logging

logger = logging.getLogger(« agent »)
logger.setLevel(logging.INFO)

class ToolInput(BaseModel):
user_id: int
action: str
payload: dict

def call_tool(data: dict):
try:
validated = ToolInput(**data)
logger.info(« Appel outil validé: %s », validated.json())
return {« status »: « ok »}
except ValidationError as e:
logger.error(« Validation échouée: %s », e.json())
return {« status »: « error », « reason »: « invalid_input » }

# Simulation d’un appel non conforme
resp = call_tool({« user_id »: « abc », « action »: « delete »})

Observabilité et évaluation : Surveiller la latence des validations, le nombre d’erreurs de validation, le taux de fallback (retours vers une logique alternative) et les violations de schéma. Outils recommandés : Prometheus + Grafana pour métriques, OpenTelemetry pour traces distribuées et Sentry pour erreurs applicatives.

Liaison avec LangChain, Transformers et LlamaIndex : Pydantic AI stabilise les interfaces entre prompts, parsers et indexeurs, réduisant les fallbacks dus à des formats inattendus et améliorant la fiabilité des chaînes (chains) et des pipelines multi‑modèles.

	Sans Pydantic AI	Avec Pydantic AI
Fiabilité	Faible, erreurs silencieuses fréquentes	Élevée, contrôles stricts en entrée/sortie
Sécurité	Risque de fuite ou manipulation de données	Réduction des surfaces d’attaque par validation
Temps de débogage	Long, causes peu explicites	Court, erreurs explicites et traçables

Comment connecter LLMs aux données avec LlamaIndex

LlamaIndex sert d’interface entre documents/stockage et LLMs, automatisant chunking, indexation vectorielle et métadonnées pour des architectures RAG.
LlamaIndex joue le rôle de pipeline entre vos sources de données et le modèle de langage, en transformant documents hétérogènes en vecteurs recherchables et en gérant la récupération contextuelle.
LlamaIndex prend en charge le chunking (découpage), la création d’embeddings via des modèles (OpenAI, Hugging Face, etc.), l’indexation vectorielle et l’attachement de métadonnées pour filtrage et reranking.

• Connecteurs disponibles : PDF, fichiers Office, bases de données SQL/NoSQL, APIs REST, stockage cloud (S3, GCS), sources web (scraping) et systèmes de fichiers.
• Stratégies d’indexation : Utilisation d’embeddings pour similarité sémantique, Chunking par taille/overlap pour contrôler la granularité, Index hybride (moteur vectoriel + filtres exacts sur métadonnées).

Cas d’usage typiques : Recherche documentaire améliorée pour analystes, Agent question‑réponse sur un corpus d’entreprise, Pipeline RAG pour support client avec récupération de passages pertinents puis génération contextuelle.

Exemple de code : ingestion d’un dossier de PDF, création d’index vectoriel (embeddings OpenAI) puis requête augmentée.

# Installer : pip install llama-index openai
from llama_index import SimpleDirectoryReader, GPTVectorStoreIndex, LLMPredictor, ServiceContext
from openai import OpenAI
# Lecture des PDF depuis ./pdfs
documents = SimpleDirectoryReader('./pdfs').load_data()
# Créer embeddings via OpenAI
service_context = ServiceContext.from_defaults(embed_model=OpenAI())
index = GPTVectorStoreIndex.from_documents(documents, service_context=service_context)
# Requête
query = "Quels sont les risques identifiés dans le rapport X ?"
response = index.query(query)
print(response)

Intégration avec LangChain : utiliser l’index comme retriever dans une chaîne.

# Exemple d'utilisation comme retriever
retriever = index.as_retriever()
# Puis dans LangChain, fournir retriever à un LLMChain ou ConversationalRetrievalChain

• Bonnes pratiques : Nettoyer le texte (OCR, suppression boilerplate) avant ingestion pour améliorer qualité.
• Bonnes pratiques : Ajuster la granularité du chunking selon la tâche (exemple 200–500 tokens avec 20% overlap comme point de départ).
• Bonnes pratiques : Surveiller les coûts d’API d’embeddings et batcher les appels lorsque possible.
• Bonnes pratiques : Arbitrer pertinence vs latence en choisissant moteur vectoriel (FAISS, Milvus, Pinecone) et taille de top_k.

Quand la RAG montre ses limites (cohérence, besoin de comportement propriétaire), envisager le fine‑tuning ou des outils d’adaptation comme Unsloth pour entraîner ou spécialiser un modèle plutôt que d’empiler des prompts.

Connecteur	Avantages	Limites
PDF	Extraction riche de documents officiels	Qualité dépend de l’OCR, formats variés
Bases de données	Accès structuré, métadonnées fiables	Nécessite ETL pour normaliser les champs
APIs	Flux temps réel, données fraîches	Latence et limites de rate
Stockage cloud	Scalable, centralisé	Coût de stockage et transfert

Comment optimiser et fine tuning avec Unsloth

Unsloth accélère et réduit la mémoire nécessaire pour le fine‑tuning de LLMs, permettant d’affiner des modèles plus grands sur matériel grand public (rapports d’amélioration 2–5× pour la vitesse et baisse mémoire significative).
Je détaille quand et comment l’utiliser, avec bénéfices pratiques, procédure d’entraînement type et points d’attention.

Résumé des bénéfices pratiques : gains de vitesse d’entraînement observés entre 2–5× selon la documentation initiale, empreinte mémoire réduite permettant des batchs plus grands ou l’utilisation de GPUs 12–16 GB, compatibilité avec flux d’entraînement standard (optimise la mémoire par recomputation / sharding / optimisations systémiques selon l’implémentation).

Cas d’usage recommandés :

• Adapter un modèle à un domaine spécifique : Amélioration des performances sur vocabulaire et style métier.
• Corriger dérives ou biais : Ajuster sorties problématiques via datasets ciblés.
• Entraîner des prompts continus : Affiner comportement multi‑turn et instructions spécifiques.

– Étapes de préparation des données (format JSONL) : chaque ligne un objet { « prompt »: « … », « completion »: « … » }. – Split train/val : 90/10 ou 80/20 selon taille. – Paramètres d’entraînement de base : epochs 1–5 pour petits datasets, learning rate 1e‑5–5e‑5 pour LLMs préentraînés, scheduler linéaire ou cosine. – Sauvegarder checkpoints fréquents et conserver métriques sur validation.

# Commande d'entraînement type (format général)
python train.py --model MODEL --data path/to/data.jsonl --epochs 3 --batch-size 8 --lr 2e-5 --output-dir out/
# Flags courants : --gradient_accumulation_steps N, --fp16, --save_steps X, --eval_steps Y, --warmup_steps Z

Alternatives et complémentarités : LoRA / adapters restent des options économes en paramètres pour fine‑tuning rapide. Je recommande d’essayer d’abord la RAG via LlamaIndex (Retrieval-Augmented Generation) pour améliorer la précision sans réentraîner, puis passer au fine‑tuning si nécessaire.

Points d’attention : valider systématiquement sur un jeu séparé pour éviter le sur‑apprentissage, mesurer coût GPU réel (heures × prix), planifier sauvegardes et stratégie de rollback des checkpoints.

Merci de renvoyer le rendu en HTML valide.

Critère	RAG via LlamaIndex	Fine‑tuning avec Unsloth
Coût	Faible à moyen (stockage + retrieval infra)	Moyen à élevé (GPU pour entraînement)
Latence	Ajout de latence retrieval (réponse + recherche)	Latence native du modèle (généralement plus faible en inference)
Qualité des réponses	Très bonne pour faits/contenu documentaire	Meilleure pour comportement et style spécifiques
Besoins en données	Peu (documents + indexation)	Significatif (exemples annotés pour fine‑tuning)

Prêt à combiner ces bibliothèques pour votre prochain projet LLM ?

Hugging Face, LangChain, Pydantic AI, LlamaIndex et Unsloth couvrent les étapes clés : accès aux modèles, orchestration d’applications, validation typée, connexion aux données et fine‑tuning efficace. En les combinant vous réduisez le temps de prototypage, augmentez la fiabilité et contrôlez les coûts. Le bénéfice direct : livrer des applications LLM plus robustes et maintenables, plus vite.

FAQ

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert & formateur en tracking server‑side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme Formations Analytics, j’ai accompagné des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor. Disponible pour aider votre équipe à implémenter et industrialiser des workflows LLM — contactez‑moi.