AMELIORATIONS.md

# 🚀 Pistes d'amélioration — RAG Number_one

Objectif du hackathon : **JUSTE** (accuracy) · **PAS CHER** (tokens) · **SOBRE** (CO₂).
On avance **dans l'ordre**, une piste à la fois, en mesurant l'effet avant de passer à la suivante.

> État de base actuel : 152 mémoires, 84 840 chunks, `text-embedding-3-small`, LLM `gpt-5.1`,
> recherche cosinus top-3, `temperature=0.7`. Pipeline = `rag_query()` dans `app.py`.

---

## 1. ✍️ Améliorer le pré-prompt  `[ À FAIRE ]`

**Objectif :** de meilleures réponses (plus justes, moins d'hallucinations, format respecté) sans rien changer au code.

**Où :** `prompts/rag_prompt.txt` (chargé tel quel par `build_rag_prompt()` dans `app.py`).

**Comment :**
- Rendre les consignes plus strictes : répondre **uniquement** à partir du contexte, dire explicitement « information insuffisante » sinon (anti-hallucination).
- Soigner le format JSON exigé (`answer`, `explanation`) — un écart = parsing raté.
- Ajouter éventuellement : style concis, citer les sources, raisonner étape par étape avant de répondre.
- Spécialiser le ton « expert actuariat » (vocabulaire métier).

**Impact attendu :** ↗️ accuracy · coût/CO₂ ≈ neutres (prompt un peu plus long).
**Risque :** faible. **Effort :** très faible. → **Meilleur rapport gain/effort, on commence par là.**

---

## 2. 🎯 Réduire le `k` (top-3 → top-2 ?)  `[ À FAIRE ]`

**Objectif :** moins de tokens injectés dans le prompt → **moins cher + moins de CO₂**, si 2 passages suffisent à répondre.

**Où :** `app.py` → `TOP_K_RESULTS = 3` (≈ ligne 60). Aussi le défaut de `/query`.

**Comment :**
- Tester `k=2` et comparer l'accuracy vs `k=3` sur quelques questions types.
- Chaque chunk ≈ 130 tokens → passer de 3 à 2 économise ~1 chunk de contexte par requête, à chaque appel.

**Impact attendu :** ↘️ coût · ↘️ CO₂ · accuracy = à surveiller (risque de perdre le bon passage).
**Risque :** moyen (si le bon contexte était le 3ᵉ). **Effort :** très faible (1 ligne).
**Note :** à tester APRÈS le prompt, pour mesurer proprement.

---

## 3. 🌡️ Régler la température du LLM  `[ À FAIRE ]`

**Objectif :** réponses plus **déterministes et factuelles** (moins de variabilité/invention).

**Où :** `config.json` → `llm.temperature` (actuellement `0.7`), lu par `app.py`.

**Comment :**
- Pour du factuel/RAG, une température **basse** (ex. `0.0`–`0.3`) est généralement préférable.
- Tester `0.2` puis `0.0`, comparer la justesse et la stabilité des réponses.

**Impact attendu :** ↗️ accuracy (moins d'hallucinations) · coût/CO₂ ≈ neutres.
**Risque :** faible. **Effort :** très faible (1 valeur).

---

## 4. 🔁 Cross-encoder (reranker)  `[ À FAIRE ]`

**Objectif :** récupérer les **bons** passages → c'est *« la qualité du retrieval qui fait le score »*.

**Principe :**
```
question → recherche cosinus large (top-20)   ← rappel
        → cross-encoder reclasse les 20 (lit question+passage ENSEMBLE)
        → garde les top-2/3 meilleurs → LLM    ← précision
```

**Où :** `retrieve_relevant_context()` dans `app.py` (élargir le `n_results`, ajouter une étape de rerank avant de renvoyer).

**Comment :**
- Modèle type `BAAI/bge-reranker-v2-m3` via `sentence-transformers`, **en local sur le GPU**.
- Bien plus précis que le cosinus (qui compare 2 vecteurs figés).

**Impact attendu :** ↗️↗️ accuracy (souvent le plus gros levier) · coût ≈ neutre (rerank local, pas d'appel payant) · CO₂ : un peu de calcul GPU local.
**Risque :** moyen (latence + dépendance). **Effort :** moyen. **⚡ Le GPU sert enfin ici.**

---

## 5. 🧭 Routing petit/gros modèle via le cross-encoder  `[ À FAIRE ]`

**Objectif :** envoyer les questions **simples** sur **GPT-5-mini** (petit, pas cher, sobre) et garder **GPT-5.1** pour les **difficiles** → c'est l'*« arbitrage intelligent »* explicitement récompensé par le jury.

**Principe :**
```
question + passages → score de confiance (issu du cross-encoder / du retrieval)
   ├─ confiance haute (question simple, contexte net) → GPT-5-mini   (€/CO₂ ↓↓)
   └─ confiance basse (ambigu, technique)             → GPT-5.1
```

**Où :** dans `rag_query()` (`app.py`), choisir dynamiquement le modèle/endpoint avant l'appel LLM. Nécessite d'ajouter la config du **mini** dans `config.json` (2ᵉ endpoint/modèle).

**Comment :**
- Réutiliser le **score du reranker** (piste 4) comme signal de difficulté/confiance : score élevé sur le top-1 ⇒ question bien couverte ⇒ mini suffit.
- Seuil à calibrer sur des exemples.

**Impact attendu :** ↘️↘️ coût · ↘️↘️ CO₂ · accuracy ≈ maintenue si le seuil est bien réglé.
**Risque :** moyen-élevé (calibrer le seuil sans perdre en accuracy). **Effort :** moyen-élevé.
**Dépend de :** la piste 4 (le cross-encoder fournit le signal de confiance).

---

## Ordre de travail recommandé
1 → 2 → 3 (gains rapides, faible risque) puis 4 (gros levier accuracy) puis 5 (gros levier coût/CO₂, s'appuie sur 4).

⚠️ **À chaque changement** : tester quelques questions, vérifier que le **format JSON de `/query` reste intact** (sinon score = 0), puis re-déployer (push + restart Space).