Recherche vectorielle vs grep+lecture dans un wiki markdown personnel
Situation
La recherche vectorielle hybride est la fonctionnalité vedette de la plupart des gists « v2 » qui prolongent le pattern LLM Wiki de Karpathy, dont LLM Wiki v2 (rohitg00), qui la détaille comme une combinaison de BM25 (mots-clés), de recherche vectorielle (embeddings) et de parcours de graphe de connaissances, fusionnés par reciprocal rank fusion. Eugeniu Ghelbur rapporte l'avoir testée puis retirée de son implémentation, obsidian-second-brain, après plusieurs mois d'usage quotidien.
Critères
Le choix entre les deux approches dépend de la taille du corpus : un wiki curé, de l'ordre de 50 000 à 100 000 tokens, ne pose pas le même problème de récupération qu'un corpus de centaines de milliers de documents. À cette échelle réduite, l'infrastructure requise, la prévisibilité du résultat et le coût d'exploitation pèsent davantage que le gain de rappel qu'apporterait une recherche sémantique.
Options
| Critère | Grep + lecture | Recherche vectorielle hybride |
|---|---|---|
| Taille de corpus visée | Wiki curé, de l'ordre de 50 000 à 100 000 tokens | Centaines de milliers de documents |
| Infrastructure requise | Aucune | Base de données vectorielle à héberger, index à maintenir à jour |
| Prévisibilité | Résultat directement traçable au texte recherché | Résultat parfois difficile à expliquer |
| Coût d'exploitation | Nul au-delà du wiki lui-même | Hébergement et maintenance de l'index |
| Constat après plusieurs mois d'usage quotidien | Trouve la bonne note plus vite et plus prévisiblement, à l'échelle testée | Retirée de l'implémentation : jugée superflue à cette échelle |
Le même raisonnement est étendu à deux autres propositions de la même catégorie — infrastructure de récupération — également retirées : la mémoire à niveaux (tiered memory) et les moteurs élaborés de score de qualité, présentées comme des réponses à des problèmes d'échelle qui ne se posent pas encore pour un wiki personnel ou d'équipe de cette taille.
Arbitrage
Pour un wiki curé de l'ordre de 50 000 à 100 000 tokens, grep suivi d'une lecture l'emporte : pas de base vectorielle à héberger, pas d'index à maintenir, un résultat directement traçable au texte recherché. La recherche vectorielle hybride ne devient pertinente qu'à l'échelle de centaines de milliers de documents — adopter cette combinaison par anticipation d'une croissance du wiki qui n'a pas encore eu lieu revient à payer un coût d'infrastructure avant d'en avoir besoin. Le seuil de bascule avancé est une estimation de l'auteur, sans méthode de mesure précisée ni benchmark chiffré indépendant comparant les deux approches à différentes tailles de corpus. Une implémentation distincte, llm-wiki (nvk), recoupe ce même seuil sans le contredire : elle recommande un moteur de recherche local dédié (qmd, cité dans ses remerciements) au-delà d'une centaine d'articles environ, plutôt que de conserver une recherche par grep seule à cette échelle — un palier intermédiaire entre le grep simple et la recherche vectorielle hybride complète, non mentionné par les autres sources traitées.