Essence Du Pattern
Research Agent est un pattern où l'agent mène une recherche contrôlée via un pipeline borné : search, dedupe, policy-check, read, extract notes avec provenance, puis synthesize d'une réponse uniquement à partir de matériaux vérifiés.
Quand l'utiliser : quand il faut collecter et vérifier des faits depuis plusieurs sources, et non répondre sans base de preuve.
Ce n'est pas "juste browse".
Un research-pipeline contient en général :
Search + dedupe URL: retirer les doublons avant lectureRead dans le budget: lire les pages dans les limites de temps et de sourcesExtract facts: produire des notes structuréesVerify claim/citation: vérifier de base les claims clésSynthesize avec références: écrire la réponse finale avec citations
Problème
Imagine que tu demandes :
"Trouve les règles dans la nouvelle loi et explique brièvement."
L'agent a "googlé" et renvoie une conclusion, mais sans traçabilité claire des sources.
Ensuite, les risques classiques apparaissent :
- lecture superficielle (beaucoup ouvert, peu vraiment lu)
- doublons des mêmes matériaux
- mélange de faits et d'interprétation auteur
- citation faible ou fausse
- zéro reproductibilité du résultat
La recherche open-web sans process devient vite chaotique : beaucoup d'étapes, peu de preuve.
C'est le problème central : sans pipeline piloté, il est difficile de prouver que la conclusion est construite sur des sources réelles et vérifiées.
Solution
Research Agent fonctionne via un pipeline borné, pas via "cherche encore un peu".
Analogie : comme une enquête journalistique avec checklist. D'abord tu collectes sources et notes avec liens, puis tu écris les conclusions. Sans cela, on mélange facilement faits et hypothèses.
Principe clé : writer a le droit de synthesis seulement après des notes extraites avec provenance.
Processus contrôlé :
- Recherche (
Search) : trouver un nombre limité de sources - Déduplication (
Dedupe) : normaliser les URL et retirer les doublons - Vérification policy (
Policy Check) : faire passer les sources par policy-gate - Lecture (
Read) : lire uniquement les pages autorisées - Extraction (
Extract) : créer des notes avec provenance (url+quote) - Vérification (
Verify) : vérifier les claims clés - Synthèse (
Synthesize) : écrire la réponse uniquement à partir des notes
Cela permet d'attacher à la réponse :
- quelles pages ont été lues
- quelles citations ont été extraites
- quels claims ont été vérifiés
- pourquoi le pipeline s'est arrêté (
stop reason)
Fonctionne bien si :
- l'étape de recherche (
Search) a des limites claires (max_urls,max_seconds) - l'étape de lecture (
Read) passe par policy-check - l'étape d'extraction (
Extract) contient la provenance complète - l'exécution interdit la synthesis sans notes
Sinon l'agent peut :
- citer des sources non lues
- mélanger des faits non vérifiés
- inventer des citations pour paraître convaincant
C'est pour cela qu'il faut budget caps, dedupe + cache, exécution protégée, et stop-rules contre le search-loop infini.
Comment Ça Fonctionne
Principe critique : writer ne doit pas inventer de sources. Il travaille seulement depuis extracted notes.
Flow complet : Search → Dedupe → Policy Check → Read → Extract → Verify → Synthesize
Recherche (Search)
Une ou deux étapes de search contrôlées avec limites de temps et nombre d'URL.
Dedupe (Dedupe)
Les URL sont normalisées et les doublons retirés avant lecture.
Vérification policy (Policy Check)
Seuls les domains, types de contenu et niveaux de risque autorisés sont traités.
Lecture (Read)
Les pages sont chargées via cache pour éviter de relire le même contenu.
Extraction (Extract)
Les faits sont stockés de façon structurée : url, quote, claims, timestamp.
Vérification (Verify)
Spot-check de base : les claims clés sont-ils appuyés par des citations de page.
Synthèse (Synthesize)
La réponse finale est écrite uniquement depuis les notes avec citations explicites.
En Code, Ça Donne Ça
budget = {"max_urls": 10, "max_seconds": 90}
urls = search_once(goal, k=8)
urls = dedupe_and_normalize(urls)[: budget["max_urls"]]
notes = []
for url in urls:
if budget_exceeded(budget):
break
if not policy_allow(url):
continue # stop/skip reason peut etre loggé
page = fetch_with_cache(url)
note = extract_structured_note(goal, page, url=url)
notes.append(note)
if not notes:
return partial_or_escalate("no_reliable_sources")
verified = spot_check_claims(notes, sample_size=2)
answer = synthesize_from_notes(goal, notes, verified=verified)
return answer
Ici, l'important n'est pas les "beaux prompts", mais l'exécution contrôlée : budget, dedupe, cache, stop reasons.
À L'exécution, Ça Ressemble À Ça
Goal: Quelles restrictions du EU AI Act s'appliquent aux systèmes high-risk ?
Search:
- 12 URL trouvées
- après dedupe : 7 uniques
Read/Extract:
- 5 pages lues avec succès
- 2 rejetées pour faible pertinence
Verify:
- 2 claims clés validés par spot-check
Synthesize:
- résumé court généré
- citations ajoutées depuis 3 sources
Exemple complet d'agent Research
Quand Ça Convient - Et Quand Non
Adapté
| Situation | Pourquoi Research Convient | |
|---|---|---|
| ✅ | Les sources externes sont obligatoires et la citation est nécessaire | Research-agent sait chercher, lire et citer des sources. |
| ✅ | Le sujet est dynamique et la base interne ne suffit pas | La recherche en runtime récupère des données actuelles depuis open-web ou sources externes. |
| ✅ | La provenance des conclusions est nécessaire | On peut montrer explicitement d'où viennent faits et claims clés. |
| ✅ | Contrôle d'exécution présent : budgets et règles d'outils | La recherche bornée contrôle coût et réduit le risque de boucle d'outils. |
Non Adapté
| Situation | Pourquoi Research Ne Convient Pas | |
|---|---|---|
| ❌ | Les données sont déjà dans RAG | La recherche externe est inutile, la recherche interne suffit. |
| ❌ | Latence critique | La recherche et lecture de pages coûtent souvent plus qu'une génération locale. |
| ❌ | Pas de pipeline browse sécurisé par policy | Le contrôle sûr des tools et domains n'est pas assuré. |
Parce que le mode research est presque toujours plus coûteux que la génération locale ou RAG.
Différence Avec RAG
| RAG | Research Agent | |
|---|---|---|
| Sources | Index/base de connaissance interne | Open-web ou sources externes |
| Focus | Réponse ancrée rapide | Recherche, lecture et vérification des faits |
| Contrôle de coût | Relativement stable | Nécessite des budget caps stricts |
| Risque principal | Recherche faible | Boucles d'outils et fausses citations |
RAG travaille sur une knowledge layer préparée. Research Agent récupère la connaissance à l'extérieur en runtime.
Quand Utiliser Research (vs Autres Patterns)
Utilisez Research Agent quand il faut rassembler des faits depuis plusieurs sources et les consolider en preuves structurées.
Test rapide :
- si vous devez "rechercher un sujet sur plusieurs sources et donner une conclusion argumentée" -> Research
- si vous devez "analyser un dataset déjà fourni" -> Data Analysis Agent
Comparaison avec d'autres patterns et exemples
Aide-mémoire rapide :
| Si la tâche ressemble à cela... | Utilisez |
|---|---|
| Après chaque étape, il faut décider quoi faire ensuite | ReAct Agent |
| Il faut d'abord découper un grand objectif en petites tâches exécutables | Task Decomposition Agent |
| Il faut exécuter du code, vérifier les résultats et itérer en sécurité | Code Execution Agent |
| Il faut analyser des données et retourner des conclusions basées sur l'analyse | Data Analysis Agent |
| Il faut une recherche multi-sources avec preuves structurées | Research Agent |
Exemples :
ReAct : "Trouver la cause d'une panne API : vérifier logs -> voir erreurs -> lancer le check suivant selon résultat".
Task Decomposition : "Préparer lancement d'une nouvelle offre : découper en sous-tâches contenu, technique, QA et support".
Code Execution : "Calculer la retention sur 12 mois en Python et valider les formules sur des données réelles".
Data Analysis : "Analyser un CSV de ventes : trouver tendances, outliers, et donner des conclusions courtes".
Research : "Collecter des données sur 5 concurrents depuis plusieurs sources et faire un résumé comparatif".
Comment Combiner Avec D'autres Patterns
- Research + RAG : les découvertes externes vérifiées sont stockées dans la knowledge base interne pour les réponses suivantes.
- Research + Guarded-Policy : les policies limitent tools, domains et types de données autorisés.
- Research + Fallback-Recovery : en cas de search/fetch instable, l'agent retry ou bascule sur des sources de secours.
En Bref
Research Agent:
- exécute une recherche bornée et lecture de sources
- extrait des notes structurées avec provenance
- vérifie les claims clés avant réponse
- renvoie une réponse citée sans boucles infinies de review
Avantages Et Inconvénients
Avantages
rassemble des données de plusieurs sources dans un même flux
ajoute des liens, donc la réponse est plus vérifiable
couvre mieux un sujet qu'une seule source
pratique pour comparer faits et versions
Inconvénients
travaille plus lentement à cause de la recherche et lecture
sans limites, peut consommer trop de ressources
la qualité dépend de la qualité des sources
FAQ
Q: Peut-on chercher "jusqu'à confiance" ?
A: Non. Le niveau de confiance n'est pas une condition d'arrêt. Il faut des limites claires : max_urls, max_seconds et règles stagnation/convergence.
Q: Pourquoi dedupe URL est important ?
A: Sans dedupe, l'agent paie pour relire le même contenu et fausse le nombre effectif de sources.
Q: Suffit-il d'ajouter des citations à la fin ?
A: Non. Les citations doivent venir de extracted notes, pas être générées "pour la forme".
Et Ensuite
Research Agent couvre la recherche et citation open-world.
Maintenant que tu connais les patterns principaux, prochaine question : comment les combiner dans un système réel ? Quand utiliser un workflow déterministe et quand un agent flexible ? Et comment ils travaillent ensemble ?