Exa 3.0 pose une meilleure question : que peut laisser de côté l'agent ?
La mise à jour d'Exa associe des extraits sélectionnés entre résultats, une offre Lite moins chère et une couverture élargie. L'enjeu : un contexte plus utile sans perdre la condition qui change la réponse.
Marque Exa provenant de ses ressources officielles, présentée avec ses couleurs et proportions d'origine à des fins d'identification éditoriale. Ce n'est ni une capture de résultats ni une reproduction de ses graphiques de performances ; aucun partenariat n'est suggéré.
Un agent qui étudie un abonnement logiciel trouve la réponse sur dix pages. Toutes répètent la description du produit, la navigation et l'argumentaire commercial. La décision dépend pourtant de trois détails : le prix, la période de facturation et l'éventuelle présence de la fonction recherchée dans une autre formule. Davantage de texte peut rendre la réponse plus difficile à trouver.
Le 19 octobre 2026, Exa a lancé Exa 3.0, améliorant son infrastructure de recherche et rendant Dynamic Highlights disponible de manière générale. L'entreprise a également introduit Lite à 4 dollars pour 1 000 requêtes, à côté d'Auto à 7 dollars pour 1 000 requêtes. Exa fournit des API de recherche web et de contenu aux applications et agents : une infrastructure intégrée par le développeur, plutôt qu'une simple interface conversationnelle supplémentaire. Annonce de lancement.
Notre point de vue : le changement important consiste à sélectionner des preuves utiles à l'échelle de tous les résultats. Un contexte réduit peut diminuer les coûts et les distractions, mais la question décisive est celle des détails conservés. Voici les conséquences pour la recherche pratique, le sens des tarifs et une manière d'évaluer l'intégration sans confondre un test du fournisseur avec votre propre charge de travail.
Le résultat de recherche fait désormais partie de l'espace de travail du modèle
Un moteur traditionnel aide une personne à choisir une page. Un agent consomme souvent directement les éléments retournés, puis décide de répondre, de chercher encore ou d'appeler un autre outil. La qualité de la recherche affecte donc davantage qu'une liste de liens. Elle détermine ce que le prochain appel au modèle peut savoir.
Cela crée une taxe sur le contexte : chaque paragraphe hors sujet prend la place d'un élément utile. La répétition aggrave le problème. Cinq pages reprenant le même communiqué peuvent étouffer le document technique contenant une limitation importante. Une grande fenêtre de contexte augmente la capacité, mais ne décide pas quelle source mérite l'attention.
Exa s'attaque à ce choix avant que le modèle de réponse reçoive les données. Son point d'accès de recherche peut renvoyer ensemble les URL et les passages pertinents. Son API Contents distincte récupère les informations d'URL déjà connues. Les développeurs choisissent le rôle du service : trouver des candidats, extraire des preuves ou fournir des éléments à une recherche plus large. Référence de l'API Search.
Cette distinction aide les lecteurs qui découvrent l'entreprise. Une application utilisant Exa a toujours besoin de ses propres instructions, de sa présentation et de ses règles de décision. L'API fournit des preuves ; elle ne définit pas une réponse acceptable pour une comparaison juridique, un assistant d'achat ou une migration logicielle. Ces choix relèvent de la conception du produit.
Dynamic Highlights répartit le contexte entre les pages
Les extraits ordinaires peuvent être sélectionnés page par page. Cette approche accorde parfois un espace similaire à chaque résultat alors que plusieurs répètent le même fait. Dynamic Highlights examine les documents récupérés ensemble, pour favoriser les éléments les plus solides et réserver moins d'espace aux répétitions. Exa a présenté une préversion de recherche le 28 août, puis a rendu la fonction généralement disponible en octobre. Explication de Dynamic Highlights.
Un exemple permet de comprendre. Supposons que six pages décrivent un lancement, que deux présentent le même tableau technique et qu'une autre explique une restriction. Un extrait de taille fixe pour chacune produit un ensemble long et répétitif. Un budget partagé entre résultats donne au système la possibilité de garder la fiche technique une seule fois et de réserver de la place à la restriction.
C'est le comportement souhaité, pas une garantie pour chaque requête. La recherche doit reconnaître l'importance de la restriction. Si la question demande seulement le prix affiché, une condition de déploiement en entreprise peut sembler secondaire alors qu'elle est décisive pour l'acheteur. Bien formuler la requête et effectuer un contrôle complémentaire reste nécessaire.
Infographie éditoriale originale. Les blocs expliquent le principe de répartition ; ils sont illustratifs et ne reproduisent pas des nombres de jetons mesurés chez Exa.
Exa affirme que Dynamic Highlights utilise 95 % de jetons en moins que le texte intégral des pages dans son évaluation. La référence compte : des pages complètes contiennent bien plus de matière que des extraits déjà sélectionnés. Le rapport d'août décrit séparément une réduction de 30 % des jetons totaux de l'agent dans ses évaluations agentiques. Ces chiffres portent sur des quantités différentes et ne sont pas des économies interchangeables sur la facture totale d'une application.
La leçon d'évaluation est simple. Comptez les données renvoyées par la recherche, mais aussi le travail effectué ensuite par le modèle. Une réponse de recherche réduite est un mauvais compromis si les preuves manquantes déclenchent plusieurs requêtes supplémentaires ou une réponse erronée. Une compression utile préserve les faits permettant à l'agent de s'arrêter pour la bonne raison.
Lite et Auto constituent un choix à tester sur de vraies questions
Selon le lancement d'Exa, Lite et Auto utilisent le même index. Auto consacre davantage de calcul aux étapes de recherche. Le développeur dispose donc d'un choix entre un coût de base inférieur et un mode visant une meilleure qualité. Cela ne prouve pas que Lite suffit pour toute question apparemment simple, ni qu'Auto est nécessaire pour chaque question importante.
Les tarifs publiés rendent le coût d'un petit pilote facile à comprendre. Aux prix de base annoncés, 10 000 requêtes Lite coûtent 40 dollars et 10 000 requêtes Auto coûtent 70 dollars. Ce sont des exemples arithmétiques de requêtes de recherche, pas des devis pour des tâches complètes d'agent. Un processus peut effectuer plusieurs appels et entraîner d'autres frais.
| Question pour l'application | Lite | Auto |
|---|---|---|
| Prix de base annoncé | 4 dollars pour 1 000 requêtes | 7 dollars pour 1 000 requêtes |
| Relation entre les index | Même index qu'Auto | Même index que Lite |
| Calcul de recherche | Option moins coûteuse | Davantage de calcul aux étapes de recherche |
| Évaluation pertinente | Recherches courantes et tâches répétées circonscrites | Questions où manquer un résultat pertinent coûte cher |
La documentation tarifaire d'Exa indique que le prix de base inclut jusqu'à 10 résultats. Les résultats supplémentaires et les synthèses de pages générées entraînent des frais distincts. La récupération d'URL connues via Contents est également un produit séparé. Une application utilisant la recherche, des consultations intégrales et un modèle doit mesurer le coût combiné par réponse acceptée. Tarification actuelle.
Une politique de routage peut rester modeste. Commencez une recherche circonscrite avec le mode le moins cher, puis augmentez l'effort si les preuves ne répondent pas à la question. Gardez des questions difficiles et représentatives dans l'évaluation plutôt que de mesurer seulement les appels apparemment réussis. Un coût moyen faible n'est utile que s'il inclut les demandes réellement importantes pour les utilisateurs.
Trois recherches ordinaires montrent l'importance du détail manquant
Prenons une note de comparaison des tarifs concurrents. L'application doit comparer trois services par période de facturation, sièges inclus et disponibilité d'une fonction requise. Les extraits courts peuvent supprimer les répétitions commerciales et faciliter l'assemblage du tableau. Ils doivent néanmoins préserver la différence entre un engagement mensuel et un prix présenté comme équivalent mensuel d'une formule annuelle.
Le résultat doit rattacher chaque fait comparable à son URL et à sa date d'observation. Une ligne sans prix confirmé peut rester inconnue. Combler le manque par un chiffre déduit donne un tableau plus complet en apparence, mais une moins bonne décision d'achat. L'optimisation utile consiste à lire moins sans dégrader la décision, plutôt qu'à densifier le tableau à tout prix.
Un assistant de documentation pour développeurs teste un autre échec. Une question de migration peut recevoir des réponses d'une référence API actuelle, d'un vieux tutoriel et d'un journal de modifications. L'ancien tutoriel peut correspondre parfaitement aux mots de la requête tout en recommandant un paramètre obsolète. L'assistant a besoin du contexte de version et de date, ainsi que d'un moyen d'ouvrir la référence faisant autorité lorsqu'un extrait reste ambigu.
Une recherche de produit ou de service local ajoute la fraîcheur. Le lancement d'Exa décrit une couverture plus large du commerce, des entreprises locales et des informations sensibles au temps. Un résultat aide à découvrir une possibilité, mais l'application doit vérifier le prix, la disponibilité ou les horaires actuels du vendeur sélectionné avant de formuler une recommandation exploitable. Plus la réponse se rapproche d'une transaction, moins un horodatage non examiné est acceptable.
Ce sont des scénarios d'intégration illustratifs, pas les résultats de notre propre test d'API. Ils montrent pourquoi une même fonction de recherche apporte une valeur différente selon les produits. Une note hebdomadaire en arrière-plan peut accepter une autre politique de fraîcheur qu'un assistant répondant à une personne qui veut acheter immédiatement.
Commencez par une petite requête et conservez les champs de preuve
L'API officielle accepte une requête, un type de recherche et le contenu demandé. Les développeurs créent une clé dans le tableau de bord d'Exa et la gardent côté serveur. La structure HTTP suivante demande des extraits selon la référence actuelle ; c'est un point de départ à adapter, pas une requête exécutée pour cet article. Exa explique la sélection entre résultats dans son annonce Dynamic Highlights.
{
"query": "official pricing and annual billing terms for a project management service",
"type": "auto",
"numResults": 5,
"contents": {
"highlights": true
}
}
Envoyez la requête à https://api.exa.ai/search avec une authentification côté serveur via l'en-tête x-api-key. Gardez les identifiants hors du code navigateur, des notebooks publiés et des captures. Conservez les titres, URL et passages sélectionnés au lieu de tout concaténer en bloc anonyme ; la vérification ultérieure exige de connaître l'origine des preuves. Authentification et champs de réponse.
- Choisissez un travail et définissez la réponse acceptable. Pour une note tarifaire, précisez les champs requis et le comportement en cas de valeur manquante.
- Constituez un petit jeu représentatif de questions. Incluez une recherche normale, un prix modifié, un ancien exemple d'API et une question sans réponse claire.
- Testez Lite et Auto sur les mêmes questions. Gardez le modèle de réponse et les exigences de sortie constants pour interpréter la comparaison.
- Examinez les pages d'origine pour les affirmations importantes. Vérifiez les conditions, dates et contradictions au lieu de noter seulement la fluidité.
- Mesurez le travail total. Relevez les appels de recherche, le contexte reçu, les récupérations complémentaires, les jetons de réponse, la latence et les réponses acceptées.
- Définissez une règle d'escalade. Rouvrez une source ou demandez davantage de contexte si les preuves nécessaires manquent. Autorisez l'application à dire qu'un fait reste non confirmé.
L'évaluation n'a pas besoin de devenir un projet complexe de benchmark. Quelques échecs bien choisis peuvent révéler davantage que des centaines de questions faciles. L'objectif est de trouver le moment où l'application doit cesser de compresser et examiner les données plus en détail.
Un court passage et une synthèse générée n'ont pas le même rôle
La documentation Contents distingue les extraits copiés, le texte intégral et les synthèses générées. Cette frontière est utile. Un passage montre les mots de la source. Une synthèse générée est l'interprétation de ces mots par un autre modèle. Aucun des deux ne doit perdre son identité lors du transfert au modèle de réponse. Guide de l'API Contents.
La récupération intégrale garde sa place. Une exception peut apparaître sous un tableau tarifaire, ou le sens d'une phrase dépendre d'une définition antérieure. Ouvrir la source lorsqu'une décision exige un contexte large est raisonnable, même si les extraits compacts fonctionnent bien pour découvrir des informations. Les deux étapes peuvent se compléter : réduire d'abord les candidats, puis examiner les preuves déterminantes.
Infographie éditoriale originale. Le contrôle est une recommandation de conception applicative, pas une affirmation selon laquelle Exa approuve automatiquement les décisions.
Une autre préoccupation de sécurité concerne les contenus non fiables. Une page récupérée est une preuve sur le monde, pas une permission de modifier les instructions d'un agent ou d'exposer des identifiants. Les applications associant recherche, courriel, achat ou outils de fichiers doivent préserver cette frontière. Une source peut décrire un paiement sans être autorisée à l'exécuter pour l'utilisateur.
Les développeurs doivent aussi examiner ce que révèlent leurs requêtes. Une recherche sur un client confidentiel, un nom de projet interne ou un produit non lancé envoie des informations hors de l'application. Les conditions adaptées de traitement et de conservation dépendent du travail. Réduire le contexte reçu ne diminue pas la sensibilité de la requête envoyée.
Une meilleure recherche doit rendre la réponse plus facile à contester
L'attente la plus solide pour Exa 3.0 est un trajet plus court de la question aux preuves utiles. Une couverture élargie, une répartition partagée des extraits et deux tarifs donnent des options concrètes aux développeurs. Le lancement défend une idée commerciale intéressante : sélectionner moins d'éléments peut améliorer la qualité de la recherche, plutôt que simplement réduire les coûts.
Le risque est l'omission invisible. Une réponse concise peut sembler d'autant plus autoritaire que les conditions gênantes ont disparu en amont. Les applications doivent permettre d'inspecter la source et la rouvrir lorsque la décision dépend d'un détail absent de l'extrait.
Le résultat important est une réponse encore défendable après avoir cliqué sur le lien. La recherche réussit lorsque le lecteur comprend la conclusion, retrouve le passage justificatif et reconnaît les incertitudes restantes. Un budget de contexte réduit mérite sa place en préservant cette capacité.
Sources
- Présentation d'Exa 3.0, 19 octobre 2026.
- Mécanisme Dynamic Highlights et évaluations du fournisseur, 28 août 2026 ; le lancement d'octobre remplace le statut de préversion.
- Référence de l'API Search, consultée le 23 octobre 2026.
- Guide de l'API Contents, consulté le 23 octobre 2026.
- Tarifs et définitions des frais, consultés le 23 octobre 2026.
- Ressources officielles de marque Exa et règles d'affichage, consultées le 23 octobre 2026.
Gardez la réponse et les preuves ensemble
Pour les lecteurs qui souhaitent un espace distinct pour leurs liens sources et leurs recherches vérifiées, Telli.sh est une possibilité. Ouvrir votre espace de notes.