Agents IA sans embeddings : Vercel remplace le RAG par grep, find et cat

Le RAG est-il devenu trop complexe ? Vercel fait le pari que oui

Depuis deux ans, le Retrieval-Augmented Generation (RAG) s'est imposé comme l'architecture standard pour construire des agents IA capables de répondre à des questions sur des données propriétaires. Le principe est élégant : transformer vos documents en embeddings vectoriels, les stocker dans une base de données vectorielle, puis utiliser la similarité sémantique pour récupérer les passages pertinents avant de les injecter dans le prompt du LLM.

En pratique, les équipes qui déploient le RAG en production découvrent une réalité moins séduisante. Les embeddings échouent silencieusement. Le tuning est un processus sans fin d'ajustement de la taille des chunks, du chevauchement, des modèles d'embedding et des seuils de similarité. Le debugging est opaque : quand l'agent donne une mauvaise réponse, identifier si le problème vient de l'embedding, du retrieval ou de la génération est un combat perdu d'avance.

Vercel Labs a publié le Knowledge Agent Template en mars 2026, une approche radicalement différente. Au lieu d'embeddings et de bases vectorielles, l'agent utilise des commandes unix (grep, find, cat) dans un sandbox isolé pour chercher dans les fichiers sources. C'est un retour aux fondamentaux qui mérite une analyse stratégique approfondie.

Chez Bridgers, nous voyons dans cette approche non pas la « mort du RAG », mais l'émergence d'une alternative crédible pour une catégorie spécifique de cas d'usage. Voici pourquoi, et pour qui cela fait sens.

Comment fonctionne l'approche anti-RAG de Vercel

L'architecture du Knowledge Agent Template repose sur un principe simple : les LLM actuels savent déjà naviguer dans des systèmes de fichiers. Les modèles de langage ont été entraînés sur des quantités massives de code et de documentation technique. Ils savent comment utiliser grep pour chercher une expression régulière, find pour localiser un fichier et cat pour en afficher le contenu.

Plutôt que de construire une infrastructure de retrieval complexe, pourquoi ne pas exploiter cette compétence native ?

Le workflow est le suivant. Les sources de données (dépôts GitHub, transcriptions YouTube, documentation) sont ajoutées via une interface d'administration et stockées dans une base Postgres. Un Vercel Workflow synchronise ces sources vers un snapshot repository. Quand un utilisateur pose une question, l'agent charge ce snapshot dans un Vercel Sandbox isolé et utilise des outils bash (grep -r, find, cat) pour naviguer dans les fichiers et trouver les informations pertinentes.

Les traces d'exécution sont déterministes. Chaque commande bash exécutée par l'agent est enregistrée, ce qui signifie que vous pouvez voir exactement quels fichiers ont été consultés et quelles recherches ont été effectuées pour arriver à une réponse. Comparez cela avec un pipeline RAG où le processus d'embedding et de similarité vectorielle est essentiellement une boîte noire : la différence de debuggabilité est considérable.

Un complexity router classifie les requêtes entrantes pour les orienter vers le modèle optimal via un AI Gateway. Les requêtes simples peuvent être traitées par un modèle léger et rapide, tandis que les questions complexes sont routées vers des modèles plus puissants. Cette optimisation réduit les coûts sans compromettre la qualité sur les cas difficiles.

L'interface d'administration intègre des statistiques d'utilisation, des logs et un agent administrateur IA capable d'exécuter des requêtes SQL pour analyser les patterns d'utilisation. Les adaptateurs Chat SDK permettent un déploiement multi-plateforme : web, GitHub, Discord, Slack.

Les chiffres qui comptent : coût et performance

Vercel a partagé un cas d'usage de référence : un agent de support pour les appels commerciaux. Le coût par appel est passé de 1,00 dollar à 0,25 dollar, soit une réduction de 75 %, avec une amélioration de la qualité des réponses.

Cette réduction de coût s'explique par plusieurs facteurs :

• L'élimination de la base de données vectorielle

  supprime un poste de coût fixe (hébergement, maintenance, indexation).

• Le routage de complexité

  évite de solliciter des modèles coûteux pour des requêtes simples.

• L'absence d'embedding

  signifie qu'il n'y a pas de coût de vectorisation initiale ni de re-vectorisation quand les sources changent.

Le template est open source et le déploiement se fait en un clic sur Vercel. Les coûts sous-jacents dépendent de l'utilisation des Vercel Sandboxes et de l'AI SDK, qui sont facturés à l'usage. Pour les projets à volume modéré, le coût total peut être significativement inférieur à une architecture RAG traditionnelle avec Pinecone, Weaviate ou Chroma.

Pourquoi cette approche fonctionne (et quand elle ne fonctionne pas)

Pour comprendre les forces et les faiblesses de l'approche filesystem, il faut identifier les cas où le RAG classique est en difficulté.

Le RAG excelle quand les données sont massives (millions de documents), non structurées et quand la pertinence sémantique est le critère principal de retrieval. Si un utilisateur pose une question sur un concept et que la réponse se trouve dans un paragraphe qui utilise une terminologie différente, la similarité vectorielle identifiera le passage pertinent là où une recherche textuelle échouerait.

En revanche, le RAG est excessif pour les cas d'usage suivants :

• Les bases de connaissances structurées

  (documentation technique, FAQ, wikis d'entreprise) où l'information est organisée en fichiers avec des titres et des sections clairs.

• Les dépôts de code

  où la structure du projet et les noms de fichiers portent une grande partie du contexte.

• Les corpus de taille modérée

  (quelques milliers de documents) où l'agent peut raisonnablement naviguer dans l'arborescence.

L'approche de Vercel est particulièrement puissante pour ces cas d'usage car elle exploite la structure existante des données plutôt que de la détruire en la réduisant à des vecteurs. Quand un développeur demande comment fonctionne une fonction spécifique, grep trouve le fichier source, cat affiche le contexte, et l'agent comprend la réponse en lisant le code comme le ferait un humain.

La limite fondamentale est le passage à l'échelle. Quand le volume de données dépasse ce qu'un agent peut raisonnablement explorer par navigation séquentielle (disons au-delà de 100 000 documents), le temps de recherche augmente linéairement avec le volume. Les bases vectorielles, en revanche, offrent une recherche en temps quasi constant grâce à l'indexation. Pour les corpus massifs, le RAG reste indispensable.

Le debugging comme avantage concurrentiel

L'un des aspects les plus sous-estimés de l'approche de Vercel est la facilité de correction des erreurs.

Dans un pipeline RAG, quand l'agent donne une mauvaise réponse, le processus de diagnostic est complexe :

• Est-ce que le bon passage a été indexé ?

• Est-ce que l'embedding capture bien la sémantique ?

• Est-ce que le seuil de similarité est trop restrictif ou trop lâche ?

• Est-ce que le contexte injecté était pertinent mais insuffisant ?

Avec l'approche filesystem, le diagnostic est direct. L'agent a exécuté « grep -r "terme" . » et n'a pas trouvé le fichier pertinent ? La solution est d'ajouter le fichier ou de modifier la stratégie de recherche de l'agent. L'agent a trouvé le bon fichier mais a mal interprété le contenu ? Le problème est dans le prompt ou le modèle, pas dans l'infrastructure de retrieval.

Vercel formule cela de manière percutante : vous corrigez les mauvaises réponses en éditant des fichiers et en ajustant la stratégie de recherche, pas en tuning des embeddings. Cette différence paraît anodine mais change radicalement le profil de compétences nécessaire pour maintenir le système. Un développeur junior peut diagnostiquer et corriger la plupart des problèmes sans expertise en machine learning.

Pour les équipes qui construisent des agents de support client, de documentation interne ou de knowledge management, cette réduction de la barrière de maintenance est un argument décisif.

Architecture détaillée : ce qui se passe sous le capot

Examinons l'architecture technique plus en profondeur pour les équipes qui envisagent d'adopter cette approche.

Le cycle de vie des données commence par l'ajout de sources via l'interface d'administration. Les sources sont persistées dans Postgres, ce qui fournit la durabilité et la transactionnalité classiques d'une base relationnelle. Un Vercel Workflow synchronise périodiquement les sources vers un snapshot repository, créant une image cohérente de l'ensemble des données à un instant T.

Quand une requête arrive, l'agent instancie un Vercel Sandbox isolé et y charge le snapshot. Le sandbox est un environnement d'exécution complet avec accès au filesystem et aux outils bash. L'agent dispose de deux outils principaux : bash et bash_batch. Le premier exécute une commande unique, le second permet d'exécuter plusieurs commandes en parallèle pour accélérer la recherche.

Le fonctionnement est séquentiel et observable. L'agent peut d'abord exécuter « find . -name "*.md" » pour lister les fichiers markdown, puis « grep -r "terme recherché" . » pour localiser les mentions pertinentes, puis « cat chemin/vers/fichier.md » pour lire le contenu complet. Chaque étape est enregistrée dans une trace déterministe.

Le Chat SDK de Vercel fournit des adaptateurs multi-plateformes qui permettent de déployer le même agent comme chatbot web, bot GitHub, bot Discord ou bot Slack sans réécriture. La bibliothèque @savoir/sdk gère l'interface avec les outils.

Comparaison coût-bénéfice avec les architectures RAG classiques

Pour aider les équipes à prendre une décision éclairée, voici une comparaison structurée des deux approches.

Coût initial. L'approche RAG nécessite le choix et le déploiement d'une base vectorielle (Pinecone, Weaviate, Chroma, Qdrant), la sélection d'un modèle d'embedding, le développement du pipeline d'ingestion (chunking, embedding, indexation) et les tests de qualité de retrieval. L'approche filesystem nécessite uniquement la configuration des sources dans l'interface d'administration et le déploiement en un clic sur Vercel.

Coût récurrent. Le RAG implique l'hébergement de la base vectorielle, la re-vectorisation lors des mises à jour, les appels au modèle d'embedding et les appels au LLM de génération. L'approche filesystem implique uniquement le stockage Postgres, les Vercel Sandboxes et les appels au LLM.

Maintenance. Le RAG demande une expertise en machine learning pour le tuning des embeddings et des paramètres de retrieval. L'approche filesystem demande une compréhension basique des outils unix et de la structure de fichiers.

Debuggabilité. Le RAG offre une visibilité limitée sur le processus de similarité vectorielle. L'approche filesystem offre des traces déterministes complètes de chaque commande exécutée.

Passage à l'échelle. Le RAG gère efficacement les corpus de millions de documents grâce à l'indexation vectorielle. L'approche filesystem est limitée par la navigation séquentielle et devient lente au-delà de dizaines de milliers de documents.

Implications pour la construction d'agents en entreprise

L'approche de Vercel ne tuera pas le RAG. Mais elle valide un principe important : la solution la plus simple qui fonctionne est souvent la meilleure.

Pour les équipes qui construisent leurs premiers agents de knowledge management, le Knowledge Agent Template offre un point de départ considérablement plus simple qu'un pipeline RAG complet. Vous pouvez avoir un prototype fonctionnel en quelques heures plutôt qu'en quelques semaines, et itérer rapidement sur la qualité des réponses sans plonger dans les subtilités des embeddings.

Pour les équipes qui ont déjà un pipeline RAG en production, l'approche de Vercel pose une question inconfortable : avez-vous réellement besoin de cette complexité ? Si votre corpus est de taille modérée et bien structuré, un agent filesystem pourrait donner des résultats équivalents ou supérieurs avec une fraction de l'effort de maintenance.

Pour les architectes de systèmes, la leçon est plus large. Le fait que les LLM sachent naviguer dans des systèmes de fichiers comme des développeurs humains ouvre des possibilités au-delà du knowledge management. Audit de code, analyse de configuration, vérification de conformité : tous ces cas d'usage peuvent bénéficier d'agents qui interagissent directement avec les artefacts plutôt qu'avec des représentations vectorielles intermédiaires.

Conclusion : la simplicité comme stratégie technique

Le Knowledge Agent Template de Vercel est un rappel salutaire que l'innovation n'est pas toujours synonyme de complexité. En remplaçant les embeddings par des commandes bash, Vercel ne propose pas une régression technologique mais un recadrage pragmatique : utiliser le bon outil pour le bon problème.

Chez Bridgers, nous recommandons aux équipes de considérer l'approche filesystem comme option par défaut pour les nouveaux projets de knowledge management avec des corpus de taille modérée. Commencez simple, mesurez les résultats, et n'ajoutez la complexité du RAG que si les données montrent que c'est nécessaire.

C'est un principe d'ingénierie classique, mais dans la course à la sophistication technique de l'IA, il est étonnamment facile de l'oublier.

Le vrai test sera l'adoption en production à grande échelle. Si les entreprises confirment les gains de coût et de maintenabilité annoncés par Vercel, nous pourrions assister à un mouvement de retour vers des architectures plus simples dans l'écosystème des agents IA. Et dans un domaine où la complexité croissante est souvent acceptée sans questionnement, ce serait une évolution bienvenue.