L’agent de recherche Amazon SageMaker progresse avec le RL multi-tour, mais un benchmark recule

Amazon a indiqué que son agent de recherche Amazon SageMaker avait amélioré la qualité de récupération de 23,7 % sur un benchmark après un seul cycle d’entraînement. L’agent Qwen3.6-27B affiné a également fait passer son taux d’échec sur ce test de 22,89 % à 0,68 %. Il ne s’est toutefois pas amélioré sur toutes les évaluations.

Ce résultat contrasté compte davantage qu’un score parfait. AWS cherche à déterminer si les entreprises peuvent apprendre à un modèle plus petit à naviguer dans leurs outils de recherche, plutôt que de solliciter à répétition un modèle de pointe. En cas de réussite, une partie de la concurrence entre agents se déplacerait de la taille des modèles vers un entraînement spécifique à l’environnement.

L’expérience révèle aussi les limites de cet argument. AWS a comparé le modèle ajusté à son propre modèle de base non ajusté, et non à un modèle de pointe actuel. Ses benchmarks ont mesuré le comportement de récupération dans une configuration contrôlée, plutôt que la précision, la latence et le coût d’exploitation dans un déploiement d’entreprise réel.

AWS a chiffré concrètement l’entraînement d’agents multi-tour

Le changement majeur n’est pas que SageMaker puisse affiner un modèle, mais qu’AWS ait évalué un agent sur des trajectoires de recherche complètes.

AWS a publié l’expérience le 2 octobre 2026, plusieurs mois après le lancement de l’apprentissage par renforcement multi-tour de SageMaker AI. L’entreprise a utilisé le service pour personnaliser un modèle Qwen3.6-27B destiné à la récupération de type entreprise.

L’agent avait accès à deux méthodes de recherche. BM25, une méthode de récupération lexicale, trouve des documents à partir de termes exacts et de schémas de fréquence des mots. La recherche vectorielle convertit les requêtes et les documents en représentations numériques, ce qui aide à rapprocher des concepts formulés différemment.

Le choix entre ces outils ne représente qu’une partie de la tâche. L’agent doit aussi reformuler les requêtes faibles, examiner les contenus récupérés, décider si une autre recherche est utile et s’arrêter avant d’épuiser ses limites. Chaque choix modifie le contexte disponible pour le suivant.

C’est cette dépendance qui explique l’utilisation par AWS de l’apprentissage par renforcement multi-tour, ou MTRL. Cette technique évalue le comportement sur une séquence d’actions au lieu de traiter chaque réponse du modèle comme un événement isolé. La documentation MTRL de SageMaker décrit l’objectif comme la maximisation de la récompense cumulée sur l’ensemble de la séquence.

Pour cette expérience, la récompense était le nDCG@10. Le Normalized Discounted Cumulative Gain au rang 10 mesure si les documents pertinents figurent près du haut des dix premiers résultats. Un score de 1 représente un classement idéal, tandis que zéro signifie que le système n’a récupéré aucun document pertinent.

AWS a appliqué ce score après que l’agent a terminé sa trajectoire de recherche. L’entreprise a aussi attribué une récompense de moins un lorsque l’agent dépassait sa limite de tours ou son budget de jetons par tour. Cette pénalité a fait de l’achèvement efficace une partie de l’objectif d’apprentissage.

L’entreprise a constitué ses données d’entraînement à partir de FRAMES, BRIGHT, Enterprise RAG, ESCI, Musique et MLQA. Ces jeux de données couvrent les questions multi-sauts, la récupération exigeant beaucoup de raisonnement, les documents d’entreprise, la recherche de produits et la compréhension multilingue.

Le benchmark Enterprise RAG comprend plus de 500 000 documents d’entreprise synthétiques et 500 questions. AWS a réservé 5 % de chaque jeu de données d’entraînement pour la validation.

Les tests ont utilisé quatre jeux de données distincts. WixQA couvre des questions de support fondées sur la documentation Wix. Wands évalue la pertinence de la recherche de produits, tandis que FreshStack se concentre sur les questions récentes de développeurs. BrowseComp-Plus teste des requêtes de recherche difficiles sur environ 100 000 documents web vérifiés par des humains.

Cette séparation est importante, car elle réduit le risque que l’évaluation récompense simplement des exemples d’entraînement mémorisés. Elle n’élimine pas toutes les formes de contamination des benchmarks ou de chevauchement des distributions. Néanmoins, des jeux de données mis de côté rendent les gains rapportés plus significatifs que les seuls scores d’entraînement.

AWS n’a modifié que trois paramètres exposés par rapport à leurs valeurs par défaut. L’entreprise a exécuté un cycle, utilisé une taille de lot globale de 128 et autorisé 32 rollouts simultanés. Un rollout correspond à une tentative échantillonnée de l’agent pour accomplir une tâche en plusieurs étapes.

Le service plus large gère la collecte des trajectoires, les points de contrôle et les mises à jour du modèle. Il enregistre aussi les récompenses et les traces au niveau des tours via MLflow géré. Selon l’expérience originale sur l’agent de recherche, les récompenses d’entraînement et de validation ont augmenté avant de se stabiliser vers la fin.

C’est l’événement à l’origine du titre. AWS dispose désormais d’un exemple public dans lequel son service MTRL géré a modifié à la fois le classement de récupération et le comportement d’échec sur des jeux de données non vus. La question plus forte est de savoir ce que ce résultat change dans la stratégie par défaut de construction d’agents.

Le modèle de pointe par défaut est désormais sous pression

AWS remet en cause l’hypothèse selon laquelle la fiabilité doit provenir de l’appel au modèle généraliste le plus performant disponible.

Un modèle de pointe gère souvent mieux des outils inconnus qu’un modèle plus petit, car ses capacités générales de raisonnement et de suivi des instructions sont plus solides. Cet avantage peut en faire le point de départ le plus sûr pour des prototypes. Il peut aussi masquer les faiblesses de la conception de l’environnement de l’agent.

Un modèle plus grand ne comprend toujours pas intrinsèquement les index de recherche, filtres, autorisations, métadonnées ou règles d’arrêt d’une entreprise. Les équipes décrivent généralement ces détails au moyen de prompts et de schémas d’outils. Elles paient ensuite le modèle pour interpréter ces indications à chaque tâche.

AWS propose une autre répartition du travail. L’organisation définit l’environnement et la métrique de réussite, tandis que l’apprentissage par renforcement transforme les interactions répétées en comportement du modèle. Le modèle qui en résulte devient plus spécialisé et moins dépendant d’instructions d’exécution étendues.

Cette approche met sous pression la voie « prompt plus modèle de pointe ». La compétition passe de la question de savoir quel modèle en sait le plus à celle de savoir quel système apprend la bonne séquence d’actions locales. Pour la recherche en entreprise, ces actions peuvent être étroites même lorsque les questions sous-jacentes sont variées.

Un agent de recherche de support, par exemple, peut devoir reconnaître des codes d’erreur, privilégier d’abord la correspondance exacte, élargir la requête lorsque les résultats sont rares et s’arrêter après avoir trouvé une procédure faisant autorité. Un modèle généraliste peut déduire cette politique. Un modèle spécialisé peut l’encoder par l’entraînement.

L’argument économique reste une affirmation plutôt qu’un résultat de cette évaluation spécifique. AWS affirme que des modèles spécialisés plus petits peuvent offrir une latence et un coût d’inférence inférieurs. Toutefois, le tableau publié ne contient aucune mesure de latence, aucun total de jetons, aucun coût de déploiement ni comparaison directe avec un modèle de pointe.

Le service lui-même est devenu généralement disponible comme capacité de personnalisation serverless de SageMaker le 3 juin 2026. AWS a indiqué que le lancement couvrait l’orchestration des rollouts, la collecte des trajectoires, l’entraînement, la gestion des points de contrôle et l’évaluation. Son annonce de lancement mentionnait aussi Qwen3.6-27B, Nova Lite 2.0, GPT-OSS-20B et Gemma-4-31B-it parmi les modèles et régions pris en charge.

L’entraînement serverless réduit la barrière d’infrastructure, mais ne supprime pas le travail applicatif. Les équipes ont toujours besoin d’un environnement d’agent appelable, de tâches représentatives, d’une vérité terrain fiable et d’une récompense qui reflète la réussite réelle. Des récompenses mal choisies peuvent apprendre à un modèle à optimiser le score tout en manquant l’objectif métier.

Cette exigence favorise les organisations disposant de flux de travail mesurables. La qualité de la recherche convient bien, car les équipes peuvent étiqueter les documents pertinents et calculer des métriques de classement. Le support client, l’exécution de code et les opérations structurées peuvent également produire des résultats vérifiables.

La recherche ouverte est plus difficile. Une réponse plausible peut être incomplète, non étayée ou fondée sur une source trompeuse. Un unique score final peut ne pas capturer ces distinctions.

La pression pratique s’exerce donc sur deux groupes. Les fournisseurs de modèles doivent démontrer pourquoi un modèle généraliste plus grand reste utile pour des tâches répétées et bornées. Les équipes IA d’entreprise doivent déterminer si leurs charges de travail sont suffisamment stables pour justifier l’entraînement d’une politique spécialisée.

Pour les équipes qui construisent des systèmes internes interrogeables, cette décision commence par la qualité des données plutôt que par le choix du modèle. Une base de connaissances d’ingénierie fiable nécessite toujours des documents à jour, une propriété clairement définie et des sources traçables. L’entraînement ne peut pas retrouver des informations que la couche de récupération ne contient pas.

Comment l’agent de recherche Amazon SageMaker a appris toute la trajectoire

Le mécanisme fonctionne parce que SageMaker récompense le résultat final de la recherche tout en préservant la chaîne de décisions qui l’a produit.

L’affinage supervisé apprend à un modèle à imiter des exemples. Pour un agent de recherche multi-tour, ces exemples doivent montrer des trajectoires complètes et de grande qualité. Des experts devraient démontrer des requêtes utiles, des choix d’outils judicieux, l’examen des preuves, la récupération après des résultats faibles et un point d’arrêt approprié.

De telles démonstrations sont coûteuses à produire. Elles sont aussi spécifiques à l’environnement. Une trajectoire créée pour un index de documents peut ne pas convenir à un autre système doté de métadonnées, d’outils de récupération ou de contrôles d’accès différents.

L’apprentissage par renforcement à un tour évite certains coûts de démonstration, mais crée un autre décalage. Évaluer une sortie à la fois ne peut pas pleinement capturer des décisions dont la valeur ne devient visible que plusieurs tours plus tard.

Une requête vectorielle large peut sembler initialement peu productive. Ses résultats pourraient révéler un identifiant produit exact qui rendrait la requête BM25 suivante efficace. Pénaliser la première action indépendamment ignorerait sa contribution à la recherche achevée.

Le MTRL préserve cette relation. L’agent interagit avec l’environnement, reçoit des résultats de recherche, met à jour son contexte et choisit une autre action. SageMaker collecte la trajectoire obtenue et utilise la récompense finale pour ajuster la politique à l’origine de ces décisions.

La conception de la récompense d’AWS associait la qualité de récupération à un évitement explicite des échecs. Le nDCG@10 valorisait le classement de l’ensemble final de documents. La récompense négative décourageait les trajectoires dépassant le nombre de tours ou de jetons autorisé.

Cette combinaison semble centrale dans le résultat de fiabilité le plus important. Sur BrowseComp-Plus, l’agent de base a échoué sur 22,89 % de 830 questions. La version affinée a échoué sur 0,68 % des cas.

Le résultat suggère que le modèle a appris quand terminer, et pas seulement comment récupérer un meilleur classement. Le nombre moyen de tours a aussi diminué de 7,0 à 6,3 sur ce benchmark. Un nombre inférieur de tours peut indiquer une meilleure efficacité, même si l’évaluation publiée ne convertit pas cette réduction en latence ou en coût.

Le même schéma n’est pas apparu partout. Sur WixQA, le nombre moyen de tours est passé de 4,3 à 4,5. Wands est passé de 2,2 à 2,9. FreshStack est passé de 3,1 à 2,8.

Ces différences montrent que « moins de tours » n’est pas une mesure universelle d’un meilleur comportement d’agent. Une requête supplémentaire peut améliorer la couverture des preuves, tandis qu’un arrêt précoce peut produire une réponse faible. La bonne mesure doit relier le nombre de tours à la qualité de récupération et à l’achèvement de la tâche.

SageMaker exécute les rollouts et les mises à jour de gradient de manière asynchrone. Une obsolescence hors politique bornée limite l’écart entre les exemples d’entraînement et la version du modèle actuellement optimisée. La plateforme prend aussi en charge les pertes PPO, CISPO et par échantillonnage d’importance, avec plusieurs estimateurs d’avantage.

AWS a laissé ces choix à leurs valeurs par défaut dans cette expérience. Cela rend la configuration plus facile à reproduire, mais masque aussi quels choix algorithmiques ont généré les gains. Les utilisateurs bénéficient d’un parcours géré, et non d’une ablation détaillée de chaque composant d’entraînement.

L’orientation sous-jacente est étayée au-delà de ce seul article de blog. L’article évalué par les pairs WebAgent-R1, rédigé par des chercheurs d’Amazon et d’institutions universitaires, a entraîné des agents par des interactions multi-tours de bout en bout.

Sur WebArena-Lite, ce travail a fait passer le taux de réussite de Qwen2.5-3B de 6,1 % à 33,9 %. Il a fait progresser Llama-3.1-8B de 8,5 % à 44,8 %. Les auteurs ont également constaté que la phase d’amorçage par clonage comportemental influençait les résultats, ce qui complique l’affirmation selon laquelle l’apprentissage par renforcement résout à lui seul l’entraînement des agents.

L’expérience SageMaker est plus restreinte que WebAgent-R1. Elle se concentre sur la recherche documentaire plutôt que sur des actions sur des sites web en évolution. Pourtant, les deux travaux pointent vers le même mécanisme : le modèle s’améliore lorsque l’entraînement préserve les interactions entre les actions, les observations et les résultats différés.

Une meilleure fiabilité n’a pas entraîné des gains universels en recherche

Les éléments les plus solides étayent une spécialisation améliorée, et non l’affirmation générale selon laquelle le RL multi-tours améliore toutes les tâches de recherche.

Le modèle ajusté a amélioré le nDCG@10 sur trois des quatre benchmarks retenus. BrowseComp-Plus est passé de 0,5136 à 0,6354, soit un gain relatif de 23,7 %. WixQA est passé de 0,5725 à 0,6781, soit un gain de 18,4 %.

Wands est passé de 0,5762 à 0,6112, soit une amélioration de 6 %. FreshStack a évolué dans le sens inverse, reculant de 0,4112 à 0,4089.

Cette régression est faible, mais elle est importante sur le plan analytique. Elle empêche l’expérience d’étayer une conclusion simpliste selon laquelle « l’entraînement améliore la recherche ». Le modèle a appris une politique dont le transfert varie selon les domaines.

FreshStack contient des questions récentes de développeurs issues de Stack Overflow et de documentation technique. Ces requêtes peuvent dépendre d’une terminologie propre à certaines versions et de faits qui évoluent rapidement. Une politique entraînée sur des jeux de données de recherche plus larges peut ne pas améliorer cette distribution.

AWS n’a pas publié d’analyse d’erreurs expliquant cette régression. Il reste difficile de savoir si le problème provient de la sélection d’outils, de la reformulation des requêtes, de sources obsolètes, de l’alignement des récompenses ou de variations ordinaires de l’évaluation.

Les quatre tests différaient aussi sensiblement par leur taille. Ils comprenaient 147 questions Wands, 400 questions WixQA, 672 questions FreshStack et 830 questions BrowseComp-Plus. AWS n’a pas communiqué d’intervalles de confiance ni de significativité statistique.

Cette omission n’invalide pas les mesures. Elle limite toutefois la confiance avec laquelle les lecteurs peuvent généraliser les plus petits écarts, en particulier le gain de 6 % sur Wands et la légère baisse sur FreshStack.

L’évaluation combine également les tâches échouées et la qualité de recherche en attribuant aux exécutions en échec un score nDCG@10 de zéro. Ce traitement se défend, car un agent en échec ne produit aucun résultat classé utile. Toutefois, cela signifie qu’une partie de la hausse du score BrowseComp-Plus découle de la prévention des échecs.

Cette distinction importe pour les acheteurs. Un système qui cesse de tomber en panne est clairement plus utile, même si ses recherches réussies classent les documents de façon comparable. Or, l’amélioration de la fiabilité et celle de la pertinence décrivent des résultats d’ingénierie différents.

Aucune partie indépendante n’a reproduit ces résultats SageMaker précis. AWS a conçu la configuration, exécuté l’évaluation et publié l’analyse. Le rapport fournit des valeurs de benchmark détaillées, mais ne publie pas tous les artefacts d’entraînement ni toutes les trajectoires nécessaires à un audit complet.

Il n’existe pas non plus de comparaison avec un ajustement supervisé, un modèle de pointe piloté par prompt ou une autre plateforme MTRL gérée. L’agent Qwen3.6-27B de base est le seul point de référence direct. L’affirmation plus large d’AWS concernant une fiabilité de niveau modèle de pointe reste donc non testée ici.

Des recherches Amazon connexes apportent davantage d’éléments en faveur de l’approche générale, mais pas de confirmation indépendante. Dans une autre série d’expériences, des chercheurs d’Amazon ont indiqué que l’apprentissage par renforcement avait fait passer un agent d’assistant personnel Qwen2.5-32B de 39,20 % à 72 % de tâches achevées.

La même étude sur la personnalisation des agents a signalé des gains pour des modèles de recherche plus petits sur Natural Questions et Musique. Ces résultats renforcent l’idée que l’interaction avec l’environnement peut améliorer les agents. Ils proviennent néanmoins de travaux affiliés à Amazon et utilisent des modèles, des données et des tâches différents.

La sécurité et la gouvernance créent une autre incertitude. Pendant l’entraînement, l’agent appelle de manière répétée des outils réels ou simulés. Un environnement insuffisamment isolé pourrait exposer des données sensibles, déclencher des actions involontaires ou récompenser des raccourcis inacceptables en production.

Les systèmes de recherche évoluent également. Des documents sont ajoutés, les services de classement sont mis à jour et les schémas d’outils changent. Une politique ajustée pour un environnement peut perdre en précision après ces changements, même lorsque le checkpoint du modèle reste inchangé.

Les organisations devront mettre en place des tests de régression pour l’ensemble du système agentique. L’évaluation du modèle seule ne détectera pas toutes les défaillances créées par un index, une règle d’autorisation ou une réponse d’outil modifiés.

Les éléments disponibles étayent donc une conclusion circonscrite. Le RL multi-tours a amélioré la fiabilité de cet agent et la plupart de ses scores de recherche dans l’évaluation d’AWS. Il n’a pas établi un transfert universel, une parité avec les modèles de pointe ou des économies garanties.

La concurrence entre agents se déplace vers les environnements et les récompenses

L’actif stratégique devient l’environnement d’entraînement capable d’indiquer à un agent si une tâche entière a réussi.

Les modèles fondamentaux restent importants, car ils déterminent la qualité des rollouts initiaux. Un modèle de base faible peut ne pas découvrir suffisamment de trajectoires réussies pour que l’apprentissage par renforcement puisse les renforcer.

Les propres recherches d’AWS soulignent cet effet. Des modèles de base plus capables peuvent générer de meilleurs comportements candidats, créant des signaux d’entraînement plus solides. La spécialisation n’efface pas la valeur des capacités générales du modèle.

Cependant, un modèle seul ne définit pas un agent d’entreprise. Le système inclut aussi des outils, des index, des autorisations, un état, des limites de tâche et des règles d’évaluation. Le MTRL intègre ces composants périphériques dans la boucle d’entraînement.

Ce changement modifie l’endroit où les entreprises peuvent construire des performances défendables. Deux organisations peuvent partir du même modèle ouvert tout en produisant des agents différents, car leurs environnements et leurs fonctions de récompense encodent des connaissances opérationnelles différentes.

La recherche constitue un terrain de démonstration particulièrement adapté. Les jugements de pertinence fournissent un retour mesurable, et les documents récupérés peuvent être comparés à des réponses connues. La recherche oblige aussi l’agent à équilibrer la correspondance exacte, la recherche sémantique, la reformulation des requêtes et le comportement d’arrêt.

D’autres flux de travail se prêtent moins facilement à cet exercice. La recherche commerciale peut produire plusieurs résultats acceptables. Les enquêtes peuvent révéler des éléments valides absents d’un benchmark. Le travail intellectuel valorise souvent la nouveauté, la nuance et la provenance autant que l’achèvement de la tâche.

Une récompense terminale unique peut trop fortement compresser ces qualités. Les équipes pourraient avoir besoin d’évaluations composites mesurant séparément la qualité des preuves, l’exactitude des citations, la conformité aux politiques et l’efficacité des actions.

La course aux infrastructures impliquera donc davantage que l’entraînement géré. Les fournisseurs devront aider leurs clients à construire des environnements sûrs, déboguer les trajectoires, comparer les checkpoints et détecter le détournement de récompense.

L’intégration MLflow de SageMaker répond à une partie de ce besoin en exposant les traces et les récompenses au niveau de chaque tour. Les tâches reprenables sont également utiles, car les rollouts multi-tours peuvent prendre plus de temps qu’un ajustement classique. AWS indique que la limite par défaut de ses tâches est de 24 heures, bien que les utilisateurs puissent l’ajuster et reprendre à partir de checkpoints.

La prise en charge des modèles et la disponibilité régionale restent des contraintes. Au moment de l’expérience, Qwen3.6-27B était pris en charge pour le MTRL dans la région US West, Oregon. Une entreprise soumise à des exigences de résidence des données ou utilisant un modèle non pris en charge peut nécessiter un plan de déploiement différent.

L’interface serverless crée également une dépendance à la plateforme. AWS gère l’orchestration des rollouts et les détails d’optimisation qu’une équipe auto-hébergée contrôlerait autrement. Ce compromis peut accélérer le déploiement tout en rendant l’expérimentation de bas niveau plus difficile.

La recherche ouverte continue de développer des alternatives. Des frameworks tels que WebAgent-R1 exposent davantage la conception de l’entraînement, notamment les rollouts parallèles et la compression de contexte. Les services gérés regroupent des idées similaires pour les organisations qui ne souhaitent pas exploiter une infrastructure d’apprentissage par renforcement distribuée.

La répartition probable ne sera pas strictement entre géré et ouvert. Les entreprises choisiront selon la sensibilité des charges de travail, les exigences de modèles, les capacités d’ingénierie et la valeur du contrôle de chaque composant d’entraînement.

L’avantage d’AWS réside dans l’intégration. Les équipes peuvent connecter des agents hébergés via plusieurs services AWS, les entraîner avec SageMaker, inspecter les traces et déployer le modèle obtenu sur des endpoints SageMaker ou Amazon Bedrock.

Son défi restant est la preuve. Les acheteurs ont besoin d’éléments montrant que la voie gérée produit des améliorations reproductibles sur leurs propres tâches et reste stable après les changements de l’environnement.

Trois signaux mettront à l’épreuve la thèse d’AWS sur les agents plus petits

La prochaine phase devrait être évaluée à l’aune de la reproduction externe, de l’économie de production et de la stabilité entre environnements.

Le premier signal est la réplication indépendante. Une autre équipe doit reproduire les gains de recherche en utilisant les jeux de données divulgués, une référence Qwen3.6-27B comparable et les mêmes limites de tâche. Reproduire le résultat de fiabilité de BrowseComp-Plus renforcerait l’affirmation centrale d’AWS.

Une reproduction devrait séparer les gains de classement de l’évitement des échecs. Elle devrait également inclure des estimations d’incertitude et des exécutions répétées. Si l’amélioration disparaît sous ces contrôles, le résultat actuel semblera plus spécifique à la configuration d’évaluation d’AWS.

Le deuxième signal est une comparaison directe en production avec un modèle de pointe. Les équipes devraient mesurer la qualité des réponses, la pertinence de la recherche, la latence de bout en bout, les tokens consommés et les taux d’intervention sur la même charge de travail. Les coûts d’entraînement devraient être inclus aux côtés du comportement en inférence.

Si un modèle spécialisé égale le modèle plus grand tout en utilisant moins de ressources au déploiement, l’argument économique devient concret. Si les équipes doivent se réentraîner fréquemment ou maintenir une infrastructure de récompense complexe, une partie des économies attendues se déplacera ailleurs dans la pile.

Le troisième signal est la performance après modification de l’environnement. Un test utile modifierait le corpus documentaire, mettrait à jour un schéma d’outil ou introduirait un nouveau filtre de recherche. Les évaluateurs pourraient alors mesurer si l’agent s’adapte par prompting ou nécessite un nouveau cycle d’entraînement.

Des performances stables étayeraient l’affirmation d’AWS selon laquelle le MTRL enseigne un comportement de recherche transférable. Une baisse marquée montrerait que le modèle a appris une politique d’interface étroite, étroitement liée à son environnement d’origine.

Les développeurs devraient également surveiller la régression de FreshStack. Les expériences futures doivent expliquer pourquoi une politique ayant aidé trois jeux de données a légèrement nui à celui-ci. Une analyse d’erreurs ciblée révélerait si la récence, le vocabulaire technique ou la stratégie de requête a causé la différence.

Les acheteurs d’entreprise n’ont pas besoin de choisir entre les modèles de pointe et les agents spécialisés pour chaque tâche. Une architecture pratique peut acheminer les recherches courantes et mesurables vers un modèle ajusté, puis escalader les travaux inhabituels vers un modèle plus généraliste.

Cette approche hybride préserve la flexibilité tout en testant si la spécialisation produit des économies fiables. Elle limite également le risque d’imposer une même politique à chaque besoin d’information.

Le résultat de l’agent de recherche Amazon SageMaker rend cette expérimentation pertinente. Il montre une réduction mesurable des échecs et un meilleur classement dans la plupart des tests retenus. Il laisse aussi suffisamment d’incertitudes pour exiger une évaluation sur les documents et flux de travail propres à chaque organisation.

Pour les équipes qui envisagent cette voie, la prochaine étape pertinente n’est pas un déploiement immédiat. Constituez un ensemble de tests représentatif, définissez précisément ce qui constitue un échec et comparez l’agent ajusté au meilleur modèle de référence existant. Demandez-vous ensuite si l’amélioration résiste à de nouveaux documents, à des outils modifiés et à des cas limites difficiles.