On ne renvoit pas les documents bruts, mais une version compressée, filtrée, ou résumée, adaptée à la question.

C’est un pré‑processing intelligent du contexte.

C’est devenu indispensable

Parce que :

• les fenêtres de contexte sont grandes mais pas infinies,
• les chunks bruts sont souvent trop verbeux,
• les embeddings récupèrent parfois trop de documents,
• les modèles hallucinent moins quand le contexte est précis.

La contextual compression permet :

• d’augmenter la précision,
• de réduire le bruit,
• d’améliorer la factualité,
• de diminuer le coût.

Les 3 grandes familles de contextual compression

1. Compression par résumé (LLM summarization)

On récupère les documents pertinents, puis on demandes au LLM :

« Résume uniquement les parties utiles pour répondre à la requête X. »

C’est la version la plus simple et la plus efficace.

Exemple

• Document : 3 pages
• Requête : « Quels sont les effets secondaires du médicament ? »
• Résumé compressé : 4 lignes ciblées

2. Compression par extraction (LLM extraction)

Le LLM ne résume pas : il extrait les passages pertinents.

« Extrait uniquement les phrases qui répondent à la question X. »

C’est plus précis et moins risqué que le résumé.

3. Compression par filtrage sémantique (embedding‑based filtering)

On fait un re‑ranking interne :

1. récupérer les chunks via embeddings.
2. re‑embed de chaque chunk par rapport à la requête.
3. élimination des chunks peu pertinents.

C’est du semantic pruning.

Comment ça s’intègre dans un pipeline RAG ?

Voici le pipeline classique :

User query
→ embedding de la requête
→ retrieval (top‑k documents)
→ contextual compression (résumé / extraction / filtrage)
→ Prompt final = system + historique + requête + contexte compressé
→ LLM

La compression intervient entre le retrieval et le prompt final.

Pourquoi c’est supérieur au RAG naïf ?

Sans compression :

• envoit trop de texte,
• dépasse la fenêtre,
• ajoute du bruit,
• augmente les hallucinations.

Avec compression :

• n’envoie que l’essentiel,
• reste dans la fenêtre,
• augmente la précision,
• réduit le coût.

Le point clé : la compression est contextuelle
Ce n’est pas un résumé générique.
C’est un résumé conditionné par la requête.

Exemple :

• Requête A : « Quels sont les risques ? »
• Requête B : « Quels sont les bénéfices ? »

Le même document donnera deux compressions différentes pour des requêtes différentes.

Notons que, par requête, on peut entendre historique + question. Ainsi, la même question de l’utilisateur, après avoir posé différentes questions et obtenu différentes réponses, une nouvelle question sera traitée en tenant compte des précédentes.

C’est ce qui rend la technique si puissante.

Les erreurs fréquentes

-résumer les documents avant le retrieval
→ tu perds de l’information utile

-compresser sans conditionner sur la requête
→ tu obtiens un résumé générique, inutile

-compresser trop tôt dans le pipeline
→ tu risques de biaiser la recherche

-compresser avec un modèle trop faible
→ tu introduis des erreurs dans le contexte

Comment faire une contextual compression robuste ?

Étape 1 — Retrieval large (top‑20 ou top‑50)

On récupère large pour ne rien rater.

Étape 2 — Re‑ranking (embedding ou cross‑encoder)

On réduit à top‑5 ou top‑10.

Étape 3 — Compression LLM (résumé/extraction)

On produit un contexte propre, court, précis.

Étape 4 — Prompt final

On injecte uniquement la version compressée.

Ce pipeline est beaucoup plus stable que le RAG naïf.