Accueil › Glossaire › Needle in a Haystack

Needle in a Haystack (Test LLM)

Le test « Needle in a Haystack » (NIAH) est un protocole d’évaluation qui mesure la capacité d’un grand modèle de langage (LLM) à retrouver une information précise (la « needle », l’aiguille) enfouie dans un contexte textuel volumineux (le « haystack », la botte de foin).

Origine du test Needle in a Haystack

En novembre 2023, Greg Kamradt publie sur X (ex-Twitter) un thread qui deviendra l’un des benchmarks les plus cités dans l’écosystème LLM. Son constat est simple : les fournisseurs annoncent des fenêtres de contexte toujours plus grandes (128K, 200K, 1M de tokens), mais personne ne vérifie si le modèle exploite réellement toute cette capacité. Le test NIAH comble ce manque avec un protocole reproductible et visuel.

Le principe s’inspire du concept bien connu de « chercher une aiguille dans une botte de foin ». On insère une phrase cible (par exemple : « The best thing to do in San Francisco is eat a sandwich and sit in Dolores Park on a sunny day ») à un endroit précis d’un long document, puis on demande au modèle de restituer cette information. Si le modèle répond correctement, il a « trouvé l’aiguille ». Sinon, il l’a perdue.

Protocole détaillé

Construction du haystack

Le haystack est constitué de textes neutres, généralement des essais de Paul Graham dans l’implémentation originale. Ces textes n’ont aucun rapport sémantique avec l’aiguille, ce qui empêche le modèle de la localiser par simple pertinence thématique. Le volume de texte est ajusté pour couvrir différentes longueurs de contexte : 1K, 2K, 4K, 8K, 16K, 32K, 64K, 128K tokens, et au-delà selon la capacité du modèle.

Insertion de la needle

L’aiguille est placée à une profondeur variable, exprimée en pourcentage : 0 % signifie tout en haut du document, 50 % au milieu, 100 % tout en bas. On teste typiquement des incréments de 10 % (0 %, 10 %, 20 %… 100 %), ce qui donne 11 positions par longueur de contexte.

Requête au modèle

Le prompt demande au modèle de répondre en utilisant uniquement le contexte fourni. Exemple : « Based on the context provided, what is the best thing to do in San Francisco? ». Le modèle ne doit pas inventer une réponse à partir de ses connaissances entraînées.

Évaluation de la réponse

La réponse est évaluée automatiquement, souvent par un second LLM (GPT-4 dans l’implémentation originale) qui note la correspondance entre la réponse et l’aiguille attendue. Le résultat est binaire ou gradué (hit / partial / miss).

Visualisation en heatmap

Les résultats sont agrégés dans une heatmap bidimensionnelle. L’axe X représente la longueur du contexte, l’axe Y la profondeur d’insertion. Les cellules vertes indiquent une récupération correcte, les rouges un échec. Cette visualisation permet d’identifier immédiatement les zones problématiques d’un modèle.

Résultats historiques marquants

Les premiers tests de Kamradt comparaient GPT-4 Turbo (128K) et Claude 2.1 (200K). GPT-4 Turbo affichait un rappel quasi parfait sur toute sa fenêtre. Claude 2.1, en revanche, présentait des zones d’échec significatives, notamment lorsque l’aiguille se trouvait en milieu de contexte. Anthropic a ensuite démontré qu’un simple ajout de 10 mots au prompt (une instruction de rappel) réduisait considérablement les échecs de Claude, passant de 165 manques à 74 dans les tests d’Arize AI.

Depuis, les résultats se sont améliorés sur toute la ligne. Gemini 1.5 Pro (2024) a été le premier modèle à revendiquer un rappel supérieur à 99,7 % sur 1 million de tokens en single-needle, d’après la recherche publiée par Google DeepMind. Les modèles actuels de la génération GPT-5.4 (OpenAI), Claude Opus 4.6 (Anthropic) et Gemini 3.1 Pro (Google) atteignent généralement un recall parfait ou quasi parfait sur le test NIAH standard en single-needle, ce qui a poussé la communauté à développer des variantes plus exigeantes.

Variantes et extensions du test

Multi-Needle Retrieval

Au lieu d’une seule aiguille, on en insère plusieurs (5, 10, voire 100) à des profondeurs différentes. Le modèle doit toutes les retrouver. C’est nettement plus difficile. Dans les tests de Google DeepMind, Gemini 1.5 Pro maintenait environ 60 % de recall avec 100 aiguilles à 1M tokens, un score encore loin de la perfection.

Multi-Needle Reasoning

Développé par le benchmark NeedleBench (OpenCompass), ce protocole exige non seulement de retrouver plusieurs faits dispersés, mais aussi de les combiner pour répondre à une question de raisonnement. Cela teste la capacité d’intégration d’informations, pas seulement le rappel brut.

Ancestral Trace Challenge (ATC)

Toujours dans NeedleBench, l’ATC propose des chaînes de raisonnement logique multi-niveaux (traçage de liens de parenté, par exemple) où chaque élément du texte est pertinent. Ici, pas de « foin » inutile : tout le contexte compte, et le modèle doit raisonner sur l’ensemble.

BABILong

BABILong (NeurIPS 2024) étend l’approche NIAH à des tâches de raisonnement complexes (suivi d’états, inférence causale, comptage) dans des contextes allant jusqu’à 10 millions de tokens. Les résultats montrent que même les meilleurs LLM peinent au-delà de quelques centaines de milliers de tokens sur ces tâches combinées.

Relation avec le problème « Lost in the Middle »

Le test NIAH a mis en lumière un phénomène documenté de manière systématique par Liu et al. (Stanford, 2023) dans leur article « Lost in the Middle ». Les LLM présentent une courbe de performance en U : ils retrouvent mieux l’information lorsqu’elle est située au début ou à la fin du contexte, et la perdent lorsqu’elle est enfouie au milieu. Ce biais positionnel affecte directement les systèmes RAG qui concatènent plusieurs documents dans le prompt.

Les stratégies d’atténuation incluent le re-ranking des documents (placer les plus pertinents en début et fin de prompt), l’utilisation de techniques comme Multi-scale Positional Encoding (Ms-PoE), et la réduction du nombre de documents injectés dans le contexte.

Lien avec les Retrieval Heads

Les travaux de Wu et al. (2024) sur les retrieval heads ont apporté une explication mécaniste au NIAH. Ils ont découvert que seule une petite fraction (moins de 5 %) des têtes d’attention dans un Transformer est responsable de la récupération d’information dans le contexte long. Ces « retrieval heads » fonctionnent comme un algorithme de copier-coller conditionnel : elles identifient les tokens pertinents dans l’entrée et les redirigent vers la sortie.

Lorsqu’on désactive ces retrieval heads, le modèle échoue au test NIAH et commence à halluciner. Désactiver d’autres têtes (non-retrieval) n’affecte pas les performances. Cette découverte a des implications directes pour l’optimisation du KV cache : les frameworks comme DuoAttention (MIT, ICLR 2025) exploitent cette distinction pour ne maintenir un cache complet que sur les retrieval heads, réduisant la consommation mémoire jusqu’à 2,55× sans perte de précision sur le NIAH.

Implications pratiques

Pour les développeurs et intégrateurs

Si vous construisez un système qui injecte de longs documents dans le prompt d’un LLM (RAG, analyse de contrats, synthèse de rapports), le test NIAH devrait faire partie de votre suite d’évaluation. Mais ne vous arrêtez pas là : complétez avec des tests multi-needle, des questions de raisonnement, et des benchmarks comme LongBench ou BABILong pour vérifier que votre modèle ne se contente pas de « trouver l’aiguille » mais comprend réellement le contexte.

Pour le choix de modèle

En mars 2026, la plupart des modèles frontier (GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro) réussissent le NIAH standard sans difficulté. Le critère de différenciation est désormais le multi-needle, le raisonnement long contexte et le coût. À noter : Anthropic est le seul fournisseur à proposer un tarif unique sur toute la fenêtre de 1M tokens pour Claude Opus 4.6 et Sonnet 4.6, sans surcoût au-delà de 200K tokens. GPT-5.4 et Gemini 3.1 Pro appliquent toujours un surcoût sur les contextes longs (au-delà de 272K et ~200K tokens respectivement).

Métriques et scoring

L’évaluation d’un test NIAH peut se faire de plusieurs façons, selon la granularité souhaitée :

Le scoring binaire est le plus courant. La réponse est correcte (hit) ou incorrecte (miss). C’est l’approche de l’implémentation originale de Kamradt. Un évaluateur LLM (typiquement GPT-4) compare la réponse du modèle testé avec la needle attendue et attribue un score de 1 ou 0.

Le scoring gradué (1 à 10) permet de capturer les cas partiels : le modèle a trouvé l’idée générale mais pas les détails exacts, ou il a mélangé l’aiguille avec d’autres informations du contexte. Ce scoring est utile pour les variantes multi-needle où un modèle peut retrouver 7 aiguilles sur 10.

Le recall@k est utilisé dans les variantes multi-needle. Si vous insérez 100 aiguilles et que le modèle en retrouve 60, le recall est de 60 %. C’est la métrique que Google DeepMind a utilisée pour les tests multi-needle de Gemini 1.5 Pro.

Quelle que soit la méthode, l’agrégation des résultats se fait dans la heatmap bidimensionnelle qui reste l’outil de visualisation de référence. Chaque cellule représente une combinaison longueur × profondeur, ce qui permet d’identifier visuellement les « trous » dans la capacité de rappel du modèle.

Impact du prompting sur les résultats

Un aspect souvent sous-estimé du NIAH est sa sensibilité au prompt engineering. Les recherches d’Arize AI ont montré qu’ajouter une instruction de rappel de 10 mots à la fin du prompt pouvait diviser par deux le nombre d’échecs de Claude 2.1. Ce résultat illustre un point fondamental : les performances NIAH ne mesurent pas uniquement la capacité intrinsèque du modèle, mais aussi la qualité de l’instruction.

Pour obtenir des résultats fiables et comparables entre modèles, il convient de standardiser le prompt autant que possible, d’éviter les instructions ambiguës qui laissent le modèle « inventer » une réponse, d’inclure une contrainte explicite du type « répondez uniquement à partir du contexte fourni », et de tester plusieurs formulations pour vérifier la robustesse des résultats.

Ce constat est particulièrement pertinent pour les systèmes RAG en production : la façon dont vous formulez la requête au modèle est presque aussi importante que le modèle lui-même pour la fiabilité du rappel en long contexte.

Évolution vers des benchmarks plus exigeants

La saturation du NIAH standard a poussé la communauté à développer des évaluations plus complexes. Voici les principaux successeurs :

L’idée commune à tous ces benchmarks est de dépasser la simple récupération factuelle pour évaluer des capacités de compréhension, d’intégration et de raisonnement sur de longs contextes. Si vous évaluez un modèle pour un usage professionnel en long contexte, commencez par le NIAH (pour éliminer les candidats incapables de rappel basique), puis passez à ces benchmarks plus exigeants.

Comment lancer un test NIAH

L’implémentation de référence de Kamradt est disponible sur GitHub. Voici les étapes principales :

Pour des protocoles plus avancés (multi-needle reasoning, ATC), utilisez NeedleBench via le framework OpenCompass, qui prend en charge les déploiements vLLM et les évaluations sur cluster Slurm.

Limites du test

Le NIAH présente plusieurs limites qu’il faut garder en tête :

Verdict

Le test Needle in a Haystack est le « Hello World » de l’évaluation long contexte. Il a joué un rôle crucial en exposant les faiblesses réelles des LLM malgré leurs fenêtres de contexte impressionnantes. Aujourd’hui, il reste un pré-requis indispensable (un modèle qui échoue au NIAH est inutilisable en long contexte), mais il ne suffit plus à valider une capacité long contexte pour un usage de production. Complétez-le systématiquement avec des tests multi-needle, de raisonnement, et des évaluations sur vos propres données métier.