Cursor : index trigrammes locaux pour recherche regex instantanee dans les agents¶
Resume¶
Article technique de l'equipe Cursor sur l'acceleration des recherches regex pour les agents IA. Probleme : ripgrep scanne tous les fichiers — 15+ secondes sur les gros monorepos. Solution : index inverse local a trigrammes, avec deux optimisations successives (filtres de Bloom type GitHub/Blackbird, puis sparse n-grams type ClickHouse). Resultats : 240s → 90s sur Chromium, 120s → 30s sur le repo Cursor. Stockage minimal via mmap, synchronisation incrementale basee sur les commits Git.
Analyse critique¶
Ce qui est solide :
L'article est un vrai article d'ingenierie — references academiques (Zobel/Moffat 1993, Russ Cox 2012, Nelson Elhage/livegrep 2015), benchmarks reproductibles, compromis techniques documentes. Pas du marketing.
Les trois couches d'optimisation sont bien expliquees :
| Approche | Principe | Compromis |
|---|---|---|
| Trigrammes | Decomposer chaque fichier en sous-chaines de 3 chars, index inverse trigramme → fichiers | Simple, efficace, mais beaucoup de faux positifs |
| Bloom filters (GitHub Blackbird) | Ajouter 2 masques 8-bit par (trigramme, doc) : position modulo 8 + filtre Bloom du char suivant | Quasi-4-gramme sans stocker les quadgrammes, mais saturation avec les mises a jour |
| Sparse n-grams (ClickHouse) | Ne pas extraire tous les trigrammes, seulement les n-grams "epars" determines par hash CRC32 pondere par frequence | N-grams de longueur variable, minimaux en requete, mais extraction plus complexe |
Le detail le plus malin : ponderer le hash CRC32 par la frequence reelle des paires de caracteres dans du code source. Les paires rares (xq, zj) produisent des n-grams plus longs et plus selectifs. Les paires courantes (th, er) sont coupees court. Ca optimise la selectivite sans augmenter le stockage.
Architecture cote client : - 2 fichiers sur disque : index inverse brut + table de consultation triee avec hashes - Seule la table de consultation est en RAM (mmap) - Requete = recherche binaire → offset → lecture directe dans le fichier de postings - Synchronisation : index lie a un commit Git, mises a jour incrementales par-dessus
Ce qui est a nuancer : - L'article est publie par Cursor — c'est aussi un argument de vente pour leur IDE. Mais le contenu technique tient debout independamment. - Les benchmarks sont sur Chromium (enorme) et Cursor (gros). Sur un repo de 425 fichiers comme ProbatioVault-backend, ripgrep est deja instantane. Le gain n'apparait qu'au-dela de ~5000 fichiers. - Pas de code open-source publie — c'est de la documentation technique, pas un outil reutilisable.
Pertinence ProbatioVault¶
Impact modere, a deux niveaux :
1. Workflow multi-agents (step 6b) — chaque agent claude -p fait du search dans son perimetre. Aujourd'hui c'est rapide (425 fichiers backend). Si le repo double ou triple, l'approche trigrammes + sparse n-grams pourrait etre implementee dans les scripts d'orchestration pour pre-filtrer les fichiers avant injection dans le contexte agent. Ca reduirait les tokens consommes (meme probleme que code-review-graph, approche differente).
2. Recherche semantique dans les specs (skills /specs, /contracts, /learnings) — les index FAISS actuels font de la recherche par embeddings (semantique). L'index trigrammes est complementaire pour la recherche exacte (nom de fonction, pattern regex, reference de norme). Les deux approches se combinent : FAISS pour "trouve-moi les specs similaires a X", trigrammes pour "trouve toutes les mentions de SHA3-384 dans les specs".
3. Applicable a ProbatioVault-formal — les 10 normes + modeles TLA+/Alloy/Prolog sont des fichiers texte. Un index trigrammes permettrait de chercher instantanement des predicats, des invariants, ou des references croisees entre normes.
A implementer quand le volume de fichiers justifiera le cout. Pour l'instant, ripgrep suffit.