Vercel Knowledge Agent : Construire un Agent IA Fiable Sans Embeddings ni RAG

Vercel vient de publier un template open source qui remet en question une bonne partie de ce que l'industrie considère comme acquis sur la construction d'agents IA : son Knowledge Agent Template n'utilise ni embeddings, ni base de données vectorielle, ni pipeline RAG. À la place, il s'appuie sur des commandes Unix classiques (grep, find, cat) exécutées dans un sandbox isolé pour chercher et extraire l'information.

L'annonce, publiée en mars 2026 par Ben Sabic sur le blog de Vercel, s'accompagne d'un chiffre qui retient l'attention : le coût par appel d'un agent commercial est passé de 1,00 dollar à 0,25 dollar, soit une réduction de 75 %. Le tout avec une amélioration de la qualité des réponses.

Le repository est public sur GitHub (vercel-labs/knowledge-agent-template), le déploiement se fait en un clic sur Vercel, et le template est construit avec le AI SDK et Nuxt. C'est une approche radicalement différente du RAG traditionnel, et elle mérite une analyse en profondeur pour comprendre quand elle fonctionne, quand elle ne fonctionne pas, et pour qui elle est faite.

Pour comprendre l'intérêt de l'approche de Vercel, il faut d'abord comprendre pourquoi le RAG (Retrieval-Augmented Generation) est devenu un problème autant qu'une solution.

Le pipeline RAG classique fonctionne ainsi : vous découpez vos documents en chunks, vous les transformez en vecteurs via un modèle d'embedding, vous les stockez dans une base vectorielle (Pinecone, Weaviate, Chroma, etc.), et à chaque requête, vous faites une recherche sémantique pour trouver les chunks les plus pertinents, que vous injectez dans le prompt du LLM.

En théorie, c'est élégant. En pratique, les problèmes s'accumulent. Le chunking est un art plus qu'une science : découpez trop petit et vous perdez le contexte, trop grand et les résultats sont bruités. Le choix du modèle d'embedding impacte fortement la qualité de la recherche sémantique. La base vectorielle ajoute une couche d'infrastructure à maintenir, monitorer et payer. Et le pire : quand le RAG donne une mauvaise réponse, le debugging est opaque. Quel chunk a été sélectionné ? Pourquoi cet embedding était-il considéré comme pertinent ? Comment améliorer les résultats ?

Les "échecs silencieux" du RAG sont particulièrement insidieux. L'agent retourne une réponse qui semble plausible mais qui est basée sur un chunk mal découpé ou un embedding mal aligné. Sans traçabilité claire, vous ne savez pas si votre agent est fiable ou non.

Le "tuning hell" est un autre problème courant. Améliorer la qualité d'un pipeline RAG signifie souvent ajuster simultanément le chunking, le modèle d'embedding, les paramètres de recherche, les seuils de similarité, et parfois la structure même des documents sources. Chaque ajustement peut avoir des effets de bord imprévisibles.

L'approche de Vercel est presque déconcertante de simplicité. Au lieu de construire un pipeline d'embeddings, le Knowledge Agent Template stocke les sources comme des fichiers dans un système de fichiers classique, et utilise les commandes bash standard pour les explorer.

Le workflow technique est le suivant : les sources sont ajoutées via une interface d'administration, stockées dans Postgres, puis synchronisées vers un repository snapshot via Vercel Workflow. Quand un utilisateur pose une question, l'agent charge le snapshot dans un Vercel Sandbox isolé et utilise des outils bash (grep -r, find, cat) pour chercher l'information.

Pourquoi ça fonctionne ? La clé est que les LLM modernes ont été massivement entraînés sur du code et des workflows de développement. Ils "savent" déjà utiliser grep, find et cat de manière efficace. Quand vous donnez à un LLM un système de fichiers et des commandes bash, il adopte naturellement une stratégie de recherche structurée : chercher un terme dans tous les fichiers, affiner la recherche, lire le fichier pertinent, extraire l'information.

L'avantage majeur de cette approche est la traçabilité déterministe. Chaque action de l'agent est une commande bash visible et reproductible. Si l'agent donne une mauvaise réponse, vous pouvez tracer exactement quels fichiers il a consultés, quelles commandes il a exécutées, et quels résultats il a obtenus. Pour corriger, vous modifiez le fichier source ou ajustez la stratégie de recherche, pas un paramètre d'embedding opaque.

Le complexity router est un autre composant intéressant. Il classifie les requêtes entrantes et les route vers le modèle optimal via AI Gateway. Les questions simples vont vers un modèle moins cher, les questions complexes vers un modèle plus puissant. C'est cette optimisation qui contribue à la réduction de coût de 75 %.

Le template est conçu pour fonctionner avec des sources structurées et semi-structurées : repos GitHub, transcriptions YouTube, documentation technique, fichiers texte. Tout ce qui peut être stocké comme fichier dans un système de fichiers est une source valide.

L'interface d'administration permet d'ajouter, gérer et synchroniser les sources. Le contenu est stocké dans Postgres pour la persistance, puis exporté vers un snapshot qui est chargé dans le sandbox à chaque session d'agent.

Pour le déploiement multi-plateforme, le template utilise le Chat SDK de Vercel avec des adaptateurs pour différentes interfaces : chat web, bot GitHub, bot Discord, et extensible à Slack et d'autres plateformes. C'est un agent que vous déployez une fois et que vous rendez accessible partout.

Un agent d'administration IA est aussi inclus, avec des outils comme query_stats et run_sql pour analyser les statistiques d'utilisation, les logs, et la performance de l'agent. Vous pouvez littéralement demander à l'IA d'analyser les performances de votre IA.

La limitation principale est claire : cette approche fonctionne mieux avec du contenu structuré et textuel. Pour des documents très longs sans structure claire, ou pour des recherches qui nécessitent une compréhension sémantique profonde (synonymes, concepts liés, associations implicites), le RAG avec embeddings reste supérieur. L'approche filesystem est déterministe et traçable, mais elle est aussi plus littérale dans sa recherche.

Le choix entre l'approche filesystem de Vercel et un pipeline RAG classique dépend de votre cas d'usage, de votre tolérance au debugging, et de vos contraintes de coût.

Choisissez l'approche Vercel si vos sources sont structurées (code, documentation, FAQ, transcriptions), si la traçabilité et le debugging sont critiques pour votre usage, si vous voulez minimiser l'infrastructure (pas de base vectorielle à gérer), et si le coût par requête est un facteur important.

Choisissez le RAG si vos sources sont très hétérogènes ou non structurées, si vous avez besoin de recherche sémantique floue (trouver des concepts similaires même sans termes exacts), si vos documents sont très longs et mal indexables par mots-clés, ou si vous avez déjà l'infrastructure vectorielle en place.

En termes de coût : l'approche Vercel élimine les frais de base vectorielle (Pinecone peut coûter de 70 à 200 dollars par mois pour un usage moyen) et réduit les appels LLM grâce au complexity router. Le chiffre de 75 % de réduction de coût n'est pas un benchmark théorique mais un résultat rapporté sur un cas d'usage réel (agent de vente).

En termes de debuggabilité : l'avantage de l'approche filesystem est massif. Chaque trace est une séquence de commandes bash que n'importe quel développeur peut comprendre et reproduire. Corriger un problème signifie éditer un fichier ou ajuster une commande, pas recalculer des embeddings ou réindexer une base vectorielle.

En termes de qualité de recherche : le RAG a un avantage théorique pour la recherche sémantique, mais cet avantage est souvent annulé en pratique par les problèmes de chunking et d'embedding. Pour du contenu structuré, la recherche par mots-clés avec grep est souvent plus précise et plus fiable qu'une recherche vectorielle.

Le déploiement se fait en un clic depuis le template Vercel (vercel.com/templates/nuxt/chat-sdk-knowledge-agent). Le template crée automatiquement l'application, la base de données Postgres, et le sandbox.

L'étape suivante consiste à ajouter vos sources via l'interface d'administration. Vous pouvez pointer vers un repo GitHub, uploader des fichiers texte, ou connecter des transcriptions YouTube. Le système synchronise automatiquement les sources et crée le snapshot utilisé par l'agent.

La personnalisation se fait à deux niveaux : les prompts de l'agent (comment il interprète les requêtes et formule ses réponses) et la stratégie de recherche (quelles commandes bash il utilise en priorité). Si l'agent donne une mauvaise réponse, vous identifiez le problème via les traces déterministes et vous ajustez soit le contenu source, soit la stratégie de recherche.

Le template est construit avec le AI SDK de Vercel et Nuxt. Les développeurs familiers avec ces technologies peuvent l'étendre facilement : ajouter de nouveaux types de sources, créer des adaptateurs pour de nouvelles plateformes, ou intégrer des outils personnalisés via le @savoir/sdk.

L'approche anti-RAG de Vercel ne remplacera pas le RAG pour tous les cas d'usage. Mais elle offre une alternative concrète, déployable immédiatement, et significativement moins chère pour une large catégorie de projets. Pour les équipes qui construisent des agents de support, de documentation ou de vente sur des sources structurées, c'est peut-être la solution la plus pragmatique disponible aujourd'hui. Le fait qu'elle fonctionne avec des commandes Unix vieilles de 50 ans est, paradoxalement, ce qui la rend si fiable.