Machine Learning |

Faire un RAG (La génération augmentée par récupération) sur une documentation

Sun, 10 May 2026 00:00:00 +0000

🔍 RAG Personnel — Moteur de Recherche Documentaire Local

Projet perso réalisé pendant une période creuse au travail, par curiosité et envie d’explorer le stack NLP/LLM de bout en bout.

Objectif

Construire un système de Retrieval-Augmented Generation (RAG) from scratch, capable de répondre à des questions en langage naturel à partir d’un document PDF et cela sans dépendre d’une API externe comme OpenAI.

Architecture

PDF uploadé
 │
 ▼
Chunking (RecursiveCharacterTextSplitter)
 │ - chunk_size : 512 tokens (tokenizer HuggingFace)
 │ - chunk_overlap : 10%
 │ - déduplication automatique des chunks
 ▼
Embeddings (intfloat/multilingual-e5-small)
 │ - modèle multilingue, léger, adapté FR/EN
 │ - normalisation cosine
 ▼
Vector Store FAISS
 │ - similarité cosine
 │ - top-30 docs récupérés
 ▼
Reranking (FlashRank — ms-marco-MiniLM-L-12-v2)
 │ - reclassement des 30 docs → top-5 pertinents
 ▼
Génération (Mistral-7B-Instruct-v0.3)
 │ - quantisation 4-bit (BitsAndBytes nf4)
 │ - prompt structuré avec template chat
 ▼
Réponse en français, sourcée par document

Stack technique

Composant	Outil
Chargement PDF	`LangChain PyPDFLoader`
Chunking	`RecursiveCharacterTextSplitter` (HuggingFace tokenizer)
Embeddings	`intfloat/multilingual-e5-small` (SentenceTransformers)
Vector Store	`FAISS` (Meta)
Reranking	`FlashRank` — ms-marco-MiniLM-L-12-v2
LLM	`Mistral-7B-Instruct-v0.3` (quantisé 4-bit, BitsAndBytes)
Orchestration	`LangChain`
Visualisation embeddings	`PaCMAP` + `Plotly`
Environnement	Google Colab (GPU T4)

Points techniques notables

Chunking token-aware : taille des chunks calculée avec le vrai tokenizer du modèle d’embedding (pas juste en caractères), pour coller exactement à la fenêtre contextuelle du modèle.
Pipeline retriever + reranker : deux étapes de sélection — récupération large (top-30) puis reranking croisé (top-5) pour maximiser la pertinence sans sacrifier le recall.
Quantisation 4-bit : Mistral 7B tourne en mémoire GPU limitée grâce à BitsAndBytesConfig (nf4 + double quant + bfloat16).
Prompt engineering en français : template structuré avec instruction système explicite pour obtenir des réponses sourcées et concises.
Visualisation de l’espace d’embedding : projection 2D via PaCMAP pour observer la distribution des chunks et la position de la requête utilisateur dans l’espace vectoriel.

Ce que j’ai appris

Le chunking est critique : un mauvais découpage casse la pertinence du retrieval bien plus que le choix du LLM.
Le reranker change vraiment la donne sur des corpus avec du bruit : passer de top-30 brut à top-5 rerankés améliore nettement la qualité des réponses.
La quantisation 4-bit rend les LLMs 7B accessibles sur GPU modeste (Colab T4) avec une perte de qualité négligeable en usage Q&A.
RAG ≠ magie : la qualité de la réponse finale est bornée par la qualité du document source et la pertinence des chunks récupérés.

Limites & pistes d’amélioration

Pas de gestion de l’historique conversationnel (pas de mémoire entre les questions)
Interface en console uniquement — une UI FastAPI/VueJS serait le next step logique
Pas de persistance du vector store entre les sessions Colab
Évaluation de la qualité des réponses non formalisée (pas de métriques RAGAS)
Modèle d’embedding monolithique — tester des modèles plus grands (multilingual-e5-large) ou spécialisés métier

Résultats

Voici un exemple de prompt effectuée sur la documentation de notre SIRH, question à propos des affectations et le RAG est capable de générer une réponse juste.

Statut

Projet de curiosité / exploration — non industrialisé, non mis en production.
Objectif : comprendre les briques fondamentales du stack RAG avant d’utiliser des abstractions haut niveau.

Prédire le résultat des élections présidentielles

Sun, 10 May 2026 00:00:00 +0000

présentation du projet

Pour une de nos MSPR (Mise en situation professionelle) nous avons été chargés de prédire les résultats des élections présidentielles. La première étape a consisté à collecter les données nécessaires pour entraîner notre modèle. Cette tâche a impliqué une recherche approfondie sur des sites comme Data.gouv et l’INSEE.

Une fois les données récupérées, nous les avons transformées pour les intégrer dans une base de données. Nous avons utilisé Talend, un outil ETL (Extraction, Transformation, Chargement), pour cette tâche. La mise en place de cette étape a été complexe et chronophage, mais ma contribution principale a été la réalisation des prédictions en Python.

Réalisation de la tâche

Nous avons commencé par extraire les données des différentes tables dans notre base de données :

# Example of code highlighting
input_string_var = input("Enter some data: ")
with engine.begin() as conn:
 querypres = text("SELECT * FROM mspr2_presidentielles")
 df_pres = pd.read_sql_query(querypres, conn)

 querychom = text("SELECT * FROM mspr2_chomeurs")
 df_chom = pd.read_sql_query(querychom, conn)

 queryinfla = text("SELECT * FROM mspr2_inflation")
 df_infla = pd.read_sql_query(queryinfla, conn)

 querypop = text("SELECT * FROM mspr2_population")
 df_pop = pd.read_sql_query(querypop, conn)

 queryinfraction_departement = text("SELECT * FROM mspr2_infraction_departement")
 df_infraction_departement = pd.read_sql_query(queryinfraction_departement, conn)

 queryimpots = text("SELECT * FROM mspr2_impots")
 df_impots = pd.read_csv(io.BytesIO(uploaded['impots_formatted_2022.csv']))

 querySmic = text("Select * from mspr2_smic")
 df_smic = pd.read_sql_query(querySmic, conn)

 querydicparti = text("select * from mspr2_bord_parti")
 df_parti = pd.read_sql_query(querydicparti, conn)

Nous avons ensuite fusionné les différents DataFrames pour en créer un seul contenant tous les indicateurs nécessaires :

df_indicateur = df_chom.merge(df_infla, on='annee', how='outer')
df_indicateur = df_indicateur.merge(df_pop, on=['annee', 'code_dep'], how='outer')
df_indicateur = df_indicateur.merge(df_infraction_departement, on=['annee', 'code_dep'], how='outer')
df_indicateur = df_indicateur.merge(df_impots, on=['annee', 'code_dep'], how='outer')
df_indicateur = df_indicateur.merge(df_smic, on=['annee'], how='outer')

Nous avons remplacé le nom du parti par le bord politique pour mieux cibler notre prédiction. Ensuite, nous avons utilisé la méthode groupby pour regrouper les données par année, code département, tour, et bord politique :

#remplacement du nom des parti par leurs bord
df_pres['parti'] = df_pres['parti'].map(df_parti.set_index('parti')['bord'])
df_pres = df_pres.rename(columns={'parti': 'bord'})

aggregation_functions = {
 'voix': 'sum',
 'inscrits': lambda x: x.iloc[0],
 'votants': lambda x: x.iloc[0],
 'exprime': lambda x: x.iloc[0],
 'blanc_nul' : lambda x: x.iloc[0],
}
df_grouped = df_pres.groupby(['annee', 'code_dep', 'tour', 'bord']).agg(aggregation_functions).reset_index()

Voici un aperçu simplifié du DataFrame après traitement :

Nous avons également créé des boxplots pour mieux visualiser nos données et obtenir une vue plus claire des distributions :

Pour entraîner notre modèle, nous avons utilisé une Random Forest, qui s’est révélée être l’algorithme le plus performant pour notre cas. Voici un extrait du code d’entraînement :


data_train = data_train.drop(data_train[data_train.annee == 2022].index)
X_train = data_train.drop('voix', axis=1)
y_train = data_train['voix']

data_train_2022 = datas_Train.copy()

data_train_2022 = data_train_2022.drop(data_train_2022[data_train_2022.annee != 2022].index)
X_Test_2022 = data_train_2022.drop('voix', axis=1)
Y_Test_2022 = data_train_2022['voix']
rf = RandomForestRegressor(n_estimators=100, max_depth=18, random_state=115)
rf.fit(X_train, y_train)
y_pred_2022 = rf.predict(X_Test_2022)
X_train.head()

La Random Forest, étant un ensemble d’arbres de décision, a montré une précision de 80% dans nos prédictions. Nous avons également analysé l’impact des différents paramètres sur le nombre de voix

Il ressort que, pour ces prédictions, le bord politique de droite tend à perdre des voix, tandis que l’extrême droite tend à en gagner. Les paramètres ayant le plus d’impact, en dehors des bords politiques eux-mêmes, sont le revenu fiscal moyen et les contraventions.

Enfin, nous avons modélisé la différence entre les données réelles et les résultats prédits :

Les résultats de notre expérience sont plutôt concluants. Pour des raisons pédagogiques et de simplicité, nous avons réalisé nos prédictions sur une année où les élections étaient déjà passées. Une prochaine étape pourrait être de prédire les résultats d’une élection à venir en intégrant également des prévisions pour les autres indicateurs.

Prédire les résultats au foot

Sun, 10 May 2026 00:00:00 +0000

Présentation du projet

L’idée m’est venue après un premier projet de prédiction des élections : pourquoi ne pas appliquer les mêmes techniques au football ? Sport que je suis de près, le foot présente une richesse de données (tactiques, joueurs, forme récente, historique des confrontations) qui en fait un terrain d’expérimentation idéal pour le Machine Learning.

L’objectif initial : prédire le score d’un match retour à partir des résultats des matchs aller, avec un modèle fonctionnel déployé en production. Ce projet a évolué au fil du temps vers une architecture bien plus aboutie, intégrant progressivement des pratiques MLOps professionnelles.

V1 — Proof of Concept

Stratégie

Pour aller vite sur un premier résultat exploitable, j’ai volontairement simplifié le scope :

Données d’entrée : uniquement les résultats des matchs passés (pas de composition d’équipe, pas de blessés)
Contrainte budgétaire : utiliser une API football gratuite
Objectif : valider que la prédiction de score est faisable avec peu de features

Collecte de données

J’ai utilisé , qui propose un tier gratuit suffisant pour constituer un dataset exploitable sur plusieurs saisons de Ligue 1 et autres compétitions européennes.

Persistance des données

Pour stocker et rafraîchir les données automatiquement, j’ai développé une application Java Spring Boot qui interroge l’API quotidiennement et persiste les résultats dans une base MySQL.

public void updateMatchList() throws IOException {
 MatchApi matchApi = new MatchApi();
 LocalDate yesterday = LocalDate.now().minusDays(1);
 LocalDate today = LocalDate.now();
 List<Match> refreshedMatchList = matchApi.getMatchList(yesterday, today);

 for (Match match : refreshedMatchList) {
 Optional<Match> matchInBase = matchRepository.findObjbyLegacyid(match.getId());
 Team homeTeam = getOrCreateTeam(match.getHomeTeam().getId(), match.getHomeTeam());
 Team awayTeam = getOrCreateTeam(match.getAwayTeam().getId(), match.getAwayTeam());

 match.setHomeTeam(homeTeam);
 match.setAwayTeam(awayTeam);
 LocalDate now = LocalDate.now();

 matchInBase.ifPresentOrElse(matchinbase -> {
 if (!"FINISHED".equals(matchinbase.getStatus())) {
 match.setDate_fetched(now);
 matchRepository.delete(matchinbase);
 matchRepository.save(match);
 }
 }, () -> {
 log.info("match pas en base %d", match.getId());
 matchRepository.save(match);
 });
 }
}

Modélisation

Sur un notebook Python, j’entraîne un modèle de régression pour prédire séparément le nombre de buts à domicile et à l’extérieur.

Définition des features et targets :

from sklearn.model_selection import train_test_split

X = data_encoded.drop(['nbr_goal_full_away', 'nbr_goal_full_home'], axis=1)
y_away = data_encoded['nbr_goal_full_away']
y_home = data_encoded['nbr_goal_full_home']

X_train, X_test, y_away_train, y_away_test, y_home_train, y_home_test = train_test_split(
 X, y_away, y_home, test_size=0.2, random_state=42
)

Optimisation des hyperparamètres avec RandomizedSearchCV :

from sklearn.ensemble import RandomForestRegressor
from sklearn.model_selection import RandomizedSearchCV

param_grid = {
 'n_estimators': [50, 100, 200, 500],
 'max_depth': [None, 10, 20, 30],
 'min_samples_split': [2, 5, 10],
 'min_samples_leaf': [1, 2, 4],
 'max_features': ['auto', 'sqrt', 'log2']
}

rf = RandomForestRegressor(random_state=42)
rf_random_away = RandomizedSearchCV(rf, param_grid, n_iter=100, cv=3,
 verbose=2, random_state=42, n_jobs=-1)
rf_random_home = RandomizedSearchCV(rf, param_grid, n_iter=100, cv=3,
 verbose=2, random_state=42, n_jobs=-1)

rf_random_away.fit(X_train, y_away_train)
rf_random_home.fit(X_train, y_home_train)

J’ai opté pour la Random Forest après comparaison avec d’autres algorithmes (LinearRegression, GradientBoosting) — elle donnait les meilleurs résultats sur ce dataset avec peu de preprocessing.

Déploiement V1

Le modèle entraîné est sérialisé (joblib.dump) en fichier .pkl, récupéré automatiquement via le système d’artefacts GitLab CI/CD, puis copié sur un VPS. Une API consomme ce fichier pour exposer les prédictions, et un frontend Vue.js permettait à l’utilisateur de taper deux équipes et d’obtenir un score prédit.

L’application a été mise hors ligne suite à de nouveaux impératifs professionnels — mais ce premier cycle complet ingestion → entraînement → déploiement → exposition a validé le concept.

V2 — Refonte complète vers une architecture MLOps pro

La V1 avait des limites claires : modèle basique, peu de features, pas de monitoring, pas de versioning des données ni des modèles. La V2 est une réécriture complète, Python-first, pensée pour être industrialisable.

Objectifs de la refonte

Stack 100% Python : suppression du service Java Spring, plus léger et plus cohérent avec l’écosystème data/ML
Feature engineering enrichi : intégrer des données contextuelles (blessures, forme récente, confrontations directes)
Pratiques MLOps réelles : versioning des données, tracking des expérimentations, automatisation complète

Nouvelle architecture

API Football
 │
 ▼
Ingestion Python (scheduled)
 │
 ▼
Base MySQL — données brutes
 │
 ▼
Feature Engineering (calcul automatique)
 │ ├── Forme récente (5 derniers matchs)
 │ ├── Moyenne buts marqués / encaissés
 │ ├── Confrontations directes historiques
 │ └── Impact blessures (note joueur × importance)
 ▼
Dataset enrichi
 │
 ▼
Entraînement + Tracking MLflow
 │
 ▼
Modèle versionné (DVC)
 │
 ▼
API FastAPI
 │
 ▼
Frontend Vue.js

Feature Engineering avancé

Contrairement à la V1 qui se basait uniquement sur les scores bruts, la V2 calcule automatiquement un ensemble de features à partir des données historiques en base :

Forme récente : moyenne de points sur les N derniers matchs pour chaque équipe
Efficacité offensive/défensive : buts marqués et encaissés en moyenne sur la saison
Historique des confrontations directes (head-to-head) : taux de victoire, moyenne de buts sur les duels passés entre les deux équipes
Avantage domicile : modélisé comme feature à part entière car statistiquement significatif

Intégration des blessures

Les données de blessures sont ingérées en brut dans la base, puis le module de feature engineering les affecte automatiquement au match correspondant. Cela permet de conserver la donnée brute tout en produisant une feature agrégée exploitable par le modèle.

La prochaine étape est de scraper les notes des joueurs blessés (style Sofascore / WhoScored) afin de pondérer l’impact d’une blessure par l’importance du joueur dans son équipe — un défenseur central titulaire indisponible n’a pas le même poids qu’un remplaçant.

Analyse des comportements de parieurs (Polymarket)

Une piste exploratoire en cours : analyser les cotes et positions des meilleurs parieurs sur Polymarket pour en extraire un signal de marché. L’hypothèse est que les marchés de prédiction agrègent une information collective parfois plus précise que les features techniques seules — une forme de wisdom of the crowd quantifiable.

Vers une stack MLOps professionnelle

C’est la partie qui me tient le plus à cœur, car c’est exactement ce qu’on attend d’un MLOps Engineer en production.

Versioning des données et des modèles avec DVC

En V1, le modèle .pkl était un artefact GitLab non tracé. En V2, j’intègre DVC (Data Version Control) pour :

Versionner les datasets d’entraînement (couplé à Git)
Reproduire n’importe quel run d’entraînement à partir d’un commit
Stocker les artefacts sur un remote (S3 ou VPS)

dvc init
dvc add data/matches.csv
dvc run -n train \
 -d data/matches.csv -d src/train.py \
 -o models/rf_home.pkl -o models/rf_away.pkl \
 python src/train.py

Tracking des expérimentations avec MLflow

Chaque run d’entraînement est loggué dans MLflow Tracking : hyperparamètres, métriques (MAE, RMSE), artefacts. Cela permet de comparer les expérimentations et de promouvoir le meilleur modèle en production de manière traçable.

import mlflow
import mlflow.sklearn

with mlflow.start_run():
 mlflow.log_params(best_params)
 mlflow.log_metric("mae_home", mae_home)
 mlflow.log_metric("mae_away", mae_away)
 mlflow.sklearn.log_model(rf_home, "rf_home")
 mlflow.sklearn.log_model(rf_away, "rf_away")

CI/CD GitLab — pipeline d’entraînement automatisé

stages:
 - data
 - train
 - evaluate
 - deploy

fetch_data:
 stage: data
 script:
 - python src/ingestion.py
 only:
 - schedules

train_model:
 stage: train
 script:
 - python src/train.py
 artifacts:
 paths:
 - models/

evaluate:
 stage: evaluate
 script:
 - python src/evaluate.py
 artifacts:
 reports:
 metrics:
 - metrics.json

deploy:
 stage: deploy
 script:
 - scp models/*.pkl user@vps:/app/models/
 - ssh user@vps "systemctl restart football-api"
 only:
 - main

Monitoring du modèle en production

Un point souvent négligé mais critique en MLOps : détecter le drift. Le comportement des équipes évolue (mercato, changement d’entraîneur, blessures longue durée), ce qui dégrade progressivement les performances du modèle. Je prévois d’intégrer un monitoring basique :

Data drift : comparer la distribution des features en production vs le dataset d’entraînement (avec evidently)
Performance drift : comparer les prédictions aux résultats réels au fil des journées, et déclencher un réentraînement automatique si le MAE dépasse un seuil défini

Bilan et prochaines étapes

Aspect	V1	V2 (en cours)
Langage principal	Java + Python	Python uniquement
Features	Scores bruts	Forme, H2H, blessures, marché
Versioning modèle	Artefact GitLab non tracé	DVC + MLflow
Tracking expés	Aucun	MLflow
Monitoring prod	Aucun	Evidently (prévu)
Déploiement	Manuel	CI/CD automatisé

Ce projet est pour moi un laboratoire concret pour pratiquer les patterns MLOps que je vise en production professionnelle : reproductibilité, observabilité, automatisation. La prochaine milestone est de déployer la V2 avec MLflow et DVC opérationnels, puis d’intégrer le monitoring de drift en production.