Agentic RAG en local : quand ça vaut la peine

#L'agentic RAG en bref

Un RAG classique suit un chemin fixe : la question déclenche une recherche, les passages trouvés vont dans le prompt, le modèle répond. L'agentic RAG remplace ce chemin par une boucle. Le modèle dispose d'outils de recherche et choisit lui-même s'il les appelle, avec quelle requête et combien de fois, jusqu'à estimer qu'il peut répondre ou qu'il doit renoncer.

Le cours AI Agents for Beginners de Microsoft le décrit comme un fonctionnement où le modèle planifie ses prochaines étapes tout en allant chercher de l'information dans des sources externes, avec une boucle de type « maker-checker » : produire, vérifier, corriger. Ce même cours rappelle la limite de cette autonomie : elle s'exerce à l'intérieur de la tâche et des outils que vous avez fournis.

La conclusion pratique tient en une phrase. Si votre RAG échoue parce qu'une seule recherche ne peut pas rassembler toute la réponse, une boucle peut aider. S'il échoue parce que l'ingestion ou le découpage sont mauvais, elle ne fera que répéter le problème, plus lentement.

#Agentic RAG ou RAG en un passage : la différence

Les briques de base restent les mêmes : embeddings, base vectorielle, modèle de génération. Si elles ne vous sont pas familières, commencez par l'introduction au RAG local. Ce qui change, c'est celui qui décide de l'enchaînement. Dans un RAG classique, c'est votre code ; dans un RAG agentique, c'est le modèle, dans les limites que le code lui impose.

Requête

RAG classique : la question de l'utilisateur, parfois réécrite une fois. Agentique : le modèle formule ses propres requêtes et peut décomposer une question en plusieurs.

Nombre de recherches

RAG classique : une, connue d'avance. Agentique : variable d'une question à l'autre, bornée par une limite que vous fixez.

Sources

RAG classique : en général un seul index. Agentique : plusieurs outils possibles (index vectoriel, recherche par mots-clés, base SQL), entre lesquels le modèle choisit.

Contrôle du résultat

RAG classique : aucun, le modèle rédige avec ce qu'il a reçu. Agentique : le modèle peut juger les passages insuffisants et relancer, ce qui n'est pas une garantie : il peut aussi se tromper dans ce jugement.

Exigence sur le modèle

RAG classique : tout modèle capable de rédiger à partir d'extraits. Agentique : un modèle qui gère correctement l'appel d'outils.

Prévisibilité

RAG classique : temps de réponse assez régulier. Agentique : temps variable et chemin à contrôler dans les traces.

Trois mécanismes composent la boucle. La planification : décomposer la question en sous-questions. L'usage d'outils : traduire chaque sous-question en un appel. La relance : lire le résultat et décider s'il faut reformuler ou conclure. Pour l'architecture générale d'un agent (mémoire, garde-fous, supervision), reportez-vous au guide dédié : ici, seule la boucle de recherche nous intéresse.

Il existe aussi un intermédiaire que l'on oublie souvent : le pipeline à étapes fixes. Une réécriture de requête, une recherche hybride, puis un reranker s'exécutent toujours dans le même ordre, sans décision du modèle. Ce n'est pas de l'agentique, et c'est souvent la première chose à essayer.

#Quand l'agentic RAG vaut la peine

Le bon critère porte sur la forme de vos questions, pas sur le niveau de sophistication souhaité. Regardez les échecs réels de votre RAG actuel, puis classez-les.

Questions à plusieurs sauts

La réponse à une première recherche détermine la seconde : retrouver le fournisseur d'un contrat, puis la clause qui s'applique à ce fournisseur.

Comparaisons entre documents

« Compare le préavis des contrats A et B » demande deux recherches distinctes. Une seule requête peut ramener cinq passages du même contrat.

Plusieurs sources de nature différente

Un chiffre en base SQL et une explication dans des PDF. Le modèle choisit l'outil selon la question, comme le décrit le cours de Microsoft pour les interactions complexes avec une base.

Tolérance à l'attente

Recherche documentaire, préparation d'un dossier, traitement en arrière-plan : quelques dizaines de secondes de plus ne gênent personne si le résultat est relu.

Correction prioritaire sur la vitesse

Quand une réponse incomplète coûte cher, une étape de vérification se défend, à condition de garder une relecture humaine sur les décisions engageantes.

À l'inverse, restez sur un RAG simple dans ces situations :

FAQ et questions à une seule source

La réponse se trouve dans un passage : une recherche suffit, une boucle n'ajoute que de l'attente.

Assistant conversationnel sur petit matériel

L'utilisateur attend une réponse rapide et le modèle tourne déjà près de ses limites.

Recherche qui rate les bons passages

Corrigez d'abord le découpage, les embeddings et la recherche hybride. Relancer une recherche mal réglée donne d'autres mauvais résultats.

Calcul exact sur données structurées

Une requête SQL écrite et testée est plus fiable qu'un agent qui en improvise une.

Liens multiples entre entités sur tout le corpus

Si le besoin est de parcourir des relations à grande échelle, une approche par graphe répond à un autre problème : voir le guide GraphRAG.

#Le coût en latence et en modèle

Dans le cloud, chaque tour de boucle se voit sur la facture. En local, il se voit à l'horloge et dans la mémoire. Trois postes comptent.

#La latence se multiplie

Pour N recherches, le modèle génère N + 1 fois : une fois avant chaque recherche, une dernière pour la réponse. Un RAG en un passage ne génère qu'une fois. Comme le prompt s'allonge à chaque tour, chaque génération relit davantage de texte, sauf ce que le cache de contexte du runtime permet de réutiliser. Le temps total dépend du modèle, de la quantification et de la machine ; mesurez-le chez vous plutôt que de vous fier à un chiffre général.

#Le contexte se remplit vite

Calcul illustratif : 4 passages de 1 200 caractères représentent environ 1 400 tokens, à raison de 3 à 4 caractères par token. Cinq recherches ajoutent donc environ 7 000 tokens, sans compter la question, les consignes et les réflexions du modèle. Avec num_ctx à 8192, la marge a presque disparu. Ollama tronque alors le contexte, et les premiers résultats, parfois les consignes, peuvent sortir de la fenêtre sans que l'application le signale clairement.

Augmenter num_ctx consomme davantage de mémoire et ralentit les tours suivants. Il vaut souvent mieux renvoyer moins de passages, ou en résumer le contenu avant de le réinjecter.

#Le modèle doit tenir la boucle

Le modèle doit produire des appels d'outils bien formés, puis juger si ce qu'il a lu suffit. Vérifiez la prise en charge avec ollama show : la section Capabilities doit mentionner tools. Cette vérification dit que le format est géré, pas que le modèle prend de bonnes décisions.

RTX 3060 12 Go ou RTX 4070 12 Go

Un modèle de 7 à 9B en Q4_K_M (repère site : 7B ≈ 5 Go) laisse de la place pour le contexte et l'embedding. C'est le point de départ de l'exemple ci-dessous, avec qwen3.5:9b.

RTX 4080 16 Go

Un 14B en Q4_K_M (≈ 9 Go) tient avec une marge plus confortable pour un contexte élargi.

RTX 4090 24 Go ou M4 Pro 24 à 48 Go

Un modèle plus grand devient envisageable, comme qwen3.8:27b (environ 18 Go). Sur 24 Go, surveillez ce qu'il reste une fois le contexte élargi.

#Choisir un orchestrateur

L'orchestrateur exécute la boucle : il transmet les appels d'outils, renvoie les résultats au modèle et applique les limites. Trois voies existent, toutes compatibles avec un modèle local.

Boucle écrite à la main

Une vingtaine de lignes autour de l'API de chat d'Ollama et de son paramètre tools. Convient pour comprendre le mécanisme ou pour un cas très simple. Vous écrirez vous-même les limites et les traces.

LangGraph

La boucle est un graphe explicite de nœuds et d'arêtes, avec état, limite de récursion et streaming des étapes. Bon choix si vous voulez contrôler chaque transition. C'est celui de notre exemple.

LlamaIndex

Intéressant si votre ingestion et vos index y sont déjà : ses agents réutilisent vos moteurs de requête comme outils.

Ne choisissez pas sur la popularité. Si votre pipeline tourne déjà avec un framework, restez-y. Dans tous les cas, épinglez vos versions : ces bibliothèques évoluent vite et leurs fonctions préconstruites changent. Notre exemple écrit donc le graphe explicitement, ce qui rend aussi la boucle lisible.

#Prérequis

Ollama

Installé et à l'écoute sur http://localhost:11434.

Python

Un environnement virtuel récent. Vérifiez la version exigée par les paquets au moment de l'installation.

Documents

Quelques fichiers Markdown ou texte dans un dossier mes_documents. Pour des PDF, reprenez l'ingestion du tutoriel ChromaDB.

Mémoire

Environ 6 Go libres pour un modèle de 9B et son contexte, davantage si vous élargissez num_ctx.

#Exemple d'agentic RAG avec LangGraph et Ollama

L'exemple construit un agent qui dispose d'un seul outil de recherche, posé sur un index ChromaDB local. Il reste volontairement minimal pour que la boucle soit visible.

#Étape 1 : installer les modèles et les paquets

ollama pull qwen3.5:9b
ollama pull nomic-embed-text
ollama show qwen3.5:9b

python -m venv .venv
source .venv/bin/activate
pip install langgraph langchain-ollama chromadb ollama
pip freeze > requirements.txt

#Étape 2 : indexer les documents

Le découpage par caractères sert uniquement à garder l'exemple court. Sur un vrai corpus, utilisez un découpage qui respecte la structure, et un modèle d'embedding validé sur vos textes en français.

from pathlib import Path

import chromadb
import ollama

EMBED_MODEL = "nomic-embed-text"

client = chromadb.PersistentClient(path="./chroma_db")
collection = client.get_or_create_collection(
    "docs", metadata={"hnsw:space": "cosine"}
)


def decouper(texte, taille=1200, recouvrement=150):
    pas = taille - recouvrement
    return [texte[i:i + taille] for i in range(0, len(texte), pas)]


for fichier in Path("mes_documents").glob("*.md"):
    morceaux = decouper(fichier.read_text(encoding="utf-8"))
    if not morceaux:
        continue
    vecteurs = ollama.embed(model=EMBED_MODEL, input=morceaux)["embeddings"]
    collection.upsert(
        ids=[f"{fichier.name}-{i}" for i in range(len(morceaux))],
        documents=morceaux,
        embeddings=vecteurs,
        metadatas=[{"source": fichier.name} for _ in morceaux],
    )

print(collection.count(), "passages indexés")

#Étape 3 : écrire l'outil et la boucle

La description de l'outil compte : c'est elle que le modèle lit pour décider de l'appeler. La consigne système impose de chercher avant de répondre, de séparer les sous-questions, et d'admettre l'absence d'information.

import chromadb
import ollama
from langchain_core.messages import HumanMessage, SystemMessage
from langchain_core.tools import tool
from langchain_ollama import ChatOllama
from langgraph.graph import START, MessagesState, StateGraph
from langgraph.prebuilt import ToolNode, tools_condition

EMBED_MODEL = "nomic-embed-text"
collection = chromadb.PersistentClient(path="./chroma_db").get_collection("docs")


@tool
def chercher_documents(requete: str) -> str:
    """Cherche dans les documents internes. Utiliser une requête courte
    portant sur un seul sujet. Renvoie des passages précédés de leur source."""
    vecteur = ollama.embed(model=EMBED_MODEL, input=requete)["embeddings"][0]
    res = collection.query(query_embeddings=[vecteur], n_results=4)
    passages = zip(res["documents"][0], res["metadatas"][0])
    return "\n\n".join(f"[{m['source']}] {d}" for d, m in passages) or "Aucun passage."


outils = [chercher_documents]
llm = ChatOllama(model="qwen3.5:9b", temperature=0, num_ctx=8192).bind_tools(outils)

CONSIGNE = SystemMessage(content=(
    "Tu réponds uniquement à partir des résultats de chercher_documents. "
    "Si la question porte sur plusieurs sujets, fais une recherche par sujet. "
    "Si les passages ne suffisent pas, reformule une fois puis dis clairement "
    "ce que tu n'as pas trouvé. Cite la source entre crochets."
))


def agent(state: MessagesState):
    return {"messages": [llm.invoke([CONSIGNE] + state["messages"])]}


graphe = StateGraph(MessagesState)
graphe.add_node("agent", agent)
graphe.add_node("tools", ToolNode(outils))
graphe.add_edge(START, "agent")
graphe.add_conditional_edges("agent", tools_condition)
graphe.add_edge("tools", "agent")
app = graphe.compile()

if __name__ == "__main__":
    question = "Compare la durée de préavis du contrat A et du contrat B."
    entree = {"messages": [HumanMessage(content=question)]}
    for etape in app.stream(entree, {"recursion_limit": 12}, stream_mode="values"):
        etape["messages"][-1].pretty_print()

#Étape 4 : lire la trace

L'intérêt de stream_mode="values" est de montrer chaque message. Lisez la trace avant la réponse finale, en vous aidant de cette grille :

1. 01
   Le modèle appelle-t-il l'outil ?

   S'il répond directement, il ne cherche pas : renforcez la consigne ou changez de modèle.
2. 02
   Les requêtes ont-elles un sens ?

   Pour la comparaison, on attend idéalement une requête par contrat. Une seule requête reprenant toute la question signale que la décomposition ne se fait pas.
3. 03
   Les passages répondent-ils ?

   Si les extraits sont hors sujet, le problème vient de l'index, pas de l'agent.
4. 04
   La réponse s'appuie-t-elle sur les extraits ?

   Vérifiez chaque citation entre crochets dans le passage correspondant.

#Étape 5 : borner la boucle

Chaque recherche consomme deux étapes du graphe (agent puis outil). Une limite de 12 autorise donc cinq recherches, puis la réponse finale. Au-delà, LangGraph lève une erreur GraphRecursionError (module langgraph.errors) : interceptez-la dans votre application et renvoyez un message explicite, plutôt que de laisser l'utilisateur face à une trace d'erreur.

#Pièges et dépannage

Le modèle n'appelle jamais l'outil

Vérifiez tools dans ollama show, reformulez la description de l'outil, et essayez un autre modèle. Ne compensez pas par une consigne de plus en plus longue.

Il répète la même recherche

Le modèle tourne en rond. Abaissez la limite et, dans l'outil, renvoyez un message clair lorsque la requête a déjà été faite.

La réponse oublie les premiers résultats

Signe probable de contexte tronqué. Réduisez n_results, découpez plus finement, ou augmentez num_ctx si la mémoire le permet.

Les réponses deviennent très lentes

Regardez ollama ps : une partie du modèle est peut-être sur le processeur, ou les modèles se relaient en mémoire. Comptez aussi le nombre de tours dans la trace.

Il invente alors qu'il n'a rien trouvé

La boucle n'empêche pas l'invention. Contrôlez les citations par programme : chaque source citée doit figurer dans les résultats d'outil de la conversation.

Un outil trop puissant

Un agent qui lit des documents reçoit aussi leur contenu, éventuellement hostile. Donnez-lui des outils en lecture seule, et une validation humaine pour toute action qui modifie quelque chose.

#Décider sur vos propres questions

Les chiffres publiés ailleurs portent sur d'autres corpus, d'autres modèles et d'autres réglages. Seule une comparaison sur vos données permet de trancher, et elle ne demande pas beaucoup de matériel.

1. 01
   Constituer un jeu de questions

   Prenez des questions réelles dont vous connaissez la réponse et les passages sources, en mélangeant questions simples et questions à plusieurs sauts. Gardez trace du type de chaque question.
2. 02
   Fixer une référence

   Faites-les passer dans votre RAG actuel, sans agent. Notez si le bon passage a été retrouvé, si la réponse est correcte, et le temps total.
3. 03
   Changer une seule chose

   Lancez le même jeu avec l'agent, sur le même index et le même modèle, sur la même machine.
4. 04
   Lire par type de question

   Regardez le résultat séparément pour les questions simples et les questions complexes, et relevez le nombre de recherches par question. Une moyenne globale peut masquer un gain sur les unes et une perte de temps sur les autres.
5. 05
   Garder ce qui se justifie

   Si seules certaines questions en profitent, un routage peut suffire : RAG direct par défaut, boucle pour les questions détectées comme complexes.

Pour automatiser la partie qualité de cette comparaison, le guide consacré à Ragas présente des métriques adaptées. Notez aussi la version des paquets, le modèle, la quantification et num_ctx : sans cela, votre résultat ne sera pas comparable le mois suivant.

#Pour aller plus loin

L'agentic RAG se pose sur un RAG qui fonctionne déjà. Ces guides couvrent le socle à stabiliser d'abord, les approches voisines et l'architecture d'agent.