Assez frais pour un agent IA ? Le budget de fraîcheur des données que personne ne définit

Par Andrew Tan

Assez frais pour un agent IA ? Le budget de fraîcheur des données que personne ne définit

La plupart des équipes parlent du contexte de l'IA comme d'un problème de stockage. La question la plus difficile est de savoir si les données sont suffisamment fraîches pour l'action que l'agent est sur le point de prendre.

Beaucoup de conversations sur l'infrastructure IA visent encore le mauvais goulot d'étranglement.

Les équipes débattent des bases de données vectorielles, de la mise en cache des prompts, de la mémoire à long terme, des serveurs MCP, et du modèle qui devrait se trouver derrière l'agent. Tout cela est important. Mais rien de tout cela ne répond à la question qui détermine réellement si un agent est sûr à utiliser en production.

Quelle est la fraîcheur des données lorsque l'agent décide de faire quelque chose ?

Cette question semble ennuyeuse. Elle ne l'est pas lorsque l'agent envoie le mauvais remboursement, approuve la mauvaise commande, escalade le mauvais incident ou appelle le mauvais outil parce qu'il regarde un dossier client datant de vingt minutes.

La plupart des équipes de données comprennent déjà la qualité, la traçabilité et la dérive de schéma. La fraîcheur est traitée comme un atout jusqu'à ce que les agents entrent en jeu. Ensuite, la fraîcheur cesse d'être une préférence de tableau de bord et devient une limite opérationnelle.

Le contexte n'est pas la même chose que la permission

C'est la partie que beaucoup d'équipes négligent.

Un agent peut avoir beaucoup de contexte et pourtant avoir le mauvais contexte pour l'action que vous voulez qu'il prenne. Dix millions de lignes dans un entrepôt ne servent à rien si le seul champ qui compte a changé il y a trois minutes et que votre synchronisation s'exécute toutes les heures.

C'est la différence entre des données informatives et des données exploitables.

Les données informatives aident un agent à expliquer ce qui s'est passé la semaine dernière. Les données exploitables lui permettent de décider ce qui devrait se passer maintenant.

Ce ne sont pas les mêmes charges de travail.

Un copilote de support résumant les cinq derniers tickets peut tolérer un certain décalage. Un agent qui décide si un remboursement a déjà eu lieu ne le peut pas.

Un assistant commercial rédigeant un compte-rendu peut travailler à partir de synchronisations CRM nocturnes. Un agent qui oriente un prospect en direct basé sur l'utilisation actuelle du produit a probablement besoin de données vieilles de quelques minutes au maximum.

Un bot financier préparant un résumé de variance mensuel peut rester en mode batch. Un agent qui gèle un paiement suspect ne le peut pas.

L'erreur est de traiter tout le contexte IA comme une catégorie appelée "données prêtes pour l'IA."

Ce n'est pas une seule catégorie. C'est une pile de décisions avec des exigences de fraîcheur différentes.

Le budget de fraîcheur

La façon la plus simple de penser à cela est un budget de fraîcheur.

Chaque tâche d'agent a un décalage maximum acceptable entre ce qui s'est passé dans le système source et ce que l'agent voit lorsqu'il agit.

Ce budget de décalage dépend de la conséquence d'avoir tort.

Voici une version simple :

Ce n'est pas un tableau universel. C'est une fonction de contrainte.

La plupart des équipes ne définissent jamais ces chiffres. Elles disent simplement qu'elles veulent de "l'IA en temps réel" ou des "pipelines prêts pour l'IA" et espèrent que la pile se résoudra plus tard.

Elle ne le fera pas.

Si vous ne définissez pas un budget de fraîcheur, le budget par défaut devient "ce que le pipeline fait déjà." C'est généralement un accident, pas un choix de conception.

Le batch est encore suffisant pour beaucoup de travaux IA

Je ne pense pas que la réponse soit de pousser chaque charge de travail dans le streaming.

C'est coûteux. Cela crée également une nouvelle classe de problèmes opérationnels si l'équipe n'en a pas besoin.

Certaines utilisations de l'IA sont parfaitement satisfaites en mode batch :

• Rédaction de résumés internes
• Préparation de notes de recherche
• Étiquetage des conversations de support pour l'analyse des tendances
• Rédaction de notes de préparation au renouvellement
• Enrichissement des documents de planification
• Création de récapitulatifs exécutifs hebdomadaires

Ces tâches bénéficient de la complétude plus que de l'immédiateté.

Vous voulez généralement l'enregistrement complet, pas le dernier événement survenu il y a quinze secondes.

Cela importe car beaucoup de messages IA actuellement présentent l'avenir comme un système géant en temps réel. C'est une bonne façon de dépenser trop.

La meilleure question est plus étroite : où les données à faible latence changent-elles réellement la qualité de l'action ?

Si la réponse est nulle part, gardez-le en batch.

Si la réponse concerne des interfaces spécifiques, déplacez d'abord ces interfaces.

Le milieu dangereux

Le vrai problème n'est pas clairement le batch et pas vraiment le temps réel.

C'est le milieu flou où les équipes ont des pipelines qui se mettent à jour toutes les heures, ou toutes les trente minutes, ou chaque fois qu'un connecteur a envie de rattraper, puis elles transmettent ces données à un agent avec la permission d'agir.

C'est là que les erreurs deviennent coûteuses.

Une fraîcheur horaire semble décente jusqu'à ce que vous la mappiez au workflow.

Si un client effectue une mise à niveau à 10h02 et que l'agent voit l'ancien plan jusqu'à 11h00, vous avez presque une heure où il peut refuser un droit que le client a déjà payé.

Si une commande est annulée à 14h11 et que votre assistant d'inventaire ne l'apprend pas avant 15h00, il peut recommander un stock dont vous n'avez plus besoin.

Si un drapeau de rétrofacturation atterrit dans un système avant un autre, votre agent de risque peut voir un compte sain et approuver la prochaine transaction en toute confiance.

Rien n'est évidemment cassé dans ces exemples. Les tâches ont été exécutées. Les tables ont été mises à jour. Le tableau de bord semble probablement correct.

Le problème est que la fenêtre d'action est plus serrée que la fenêtre de données.

Cet écart est là où vivent les échecs des agents.

Les portes d'approbation sont aussi une stratégie de fraîcheur

Il y a un autre point qui se perd dans la course à l'automatisation.

Parfois, la bonne réponse n'est pas des données plus rapides. Parfois, la bonne réponse est une porte d'approbation.

Si un agent travaille sur un contexte obsolète ou ambigu, vous n'avez pas toujours besoin de bloquer l'utilisation pour toujours. Vous pouvez simplement avoir besoin de changer la dernière étape.

Laissez l'agent rassembler les données. Laissez-le rédiger la réponse. Laissez-le recommander l'action. Ensuite, exigez une approbation humaine si le budget de fraîcheur n'est pas respecté ou si la décision touche à l'argent, à la conformité, à l'accès ou au risque client.

Ce n'est pas un échec de l'automatisation. C'est une partie de la conception.

Les bons systèmes IA ne pensent pas seulement à la qualité du modèle. Ils pensent à quand ne pas agir seuls.

C'est particulièrement vrai lorsque les données sous-jacentes arrivent par un mélange de synchronisations batch, de pipelines CDC, de flux d'événements et d'API externes qui se déplacent tous à des vitesses différentes.

Vous avez besoin de fraîcheur par interface, pas par slogan de plateforme

Beaucoup de positionnements de vendeurs brouillent cela intentionnellement.

La promesse ressemble généralement à ceci : connectez toutes vos données, alimentez vos agents, débloquez des décisions en temps réel.

Très bien. Mais quelles décisions ?

Vous n'avez pas besoin d'une seule cible de fraîcheur pour toute l'entreprise. Vous avez besoin de cibles de fraîcheur par interface.

Commencez par les endroits où un agent passe du conseil à l'action :

• approuver ou refuser quelque chose
• envoyer une communication client
• changer l'accès ou les droits
• déplacer de l'argent
• ouvrir ou fermer des incidents
• déclencher automatiquement des systèmes en aval

Ces interfaces méritent des limites de décalage explicites, une surveillance, un comportement de repli et une propriété.

Si le pipeline manque le budget, que doit-il se passer ?

Peut-être que l'action est mise en pause.

Peut-être que l'agent peut encore rédiger mais pas envoyer.

Peut-être qu'il peut opérer sur un sous-ensemble d'outils sûr et restreint.

Peut-être qu'il a besoin d'un humain dans la boucle.

L'essentiel est de définir cela avant que le premier incident ne vous l'enseigne.

Ce que cela signifie pour la pile de données

Une fois que vous définissez des budgets de fraîcheur, la conversation sur la pile devient plus facile.

Vous pouvez arrêter de débattre du batch contre le streaming comme idéologie.

Certaines interfaces nécessitent un traitement événementiel. Certaines ont besoin de CDC avec des SLA serrés. Certaines sont bien avec des synchronisations planifiées. Certaines nécessitent un chemin hybride où le même workflow gère à la fois les remplissages historiques et les mises à jour à faible latence.

Cette dernière catégorie est celle qui devient rapidement douloureuse si votre architecture divise le batch et le streaming en systèmes séparés.

Maintenant, vous maintenez deux versions de la même logique métier. L'une répond aux questions historiques. L'autre alimente les actions en direct. Elles dérivent. Votre agent obtient un état incohérent selon le chemin qu'il a emprunté.

C'est pourquoi je pense que le meilleur design à long terme n'est pas "temps réel partout." C'est un runtime qui peut gérer à la fois le batch et le streaming, plus l'orchestration autour d'eux, sans forcer l'équipe à reconstruire le workflow chaque fois qu'une exigence de fraîcheur change.

C'est aussi là que layline.io s'inscrit. Le but n'est pas de transformer chaque pipeline en flux. Le but est de permettre aux équipes de resserrer la fraîcheur là où l'action l'exige, de garder le batch là où c'est suffisant, et de gérer les deux dans un modèle opérationnel unique.

Le test pratique

Si votre équipe déploie des agents IA en ce moment, posez une question pour chaque action d'agent :

Quelle est l'âge maximum des données que nous pouvons tolérer avant que cette action ne devienne dangereuse, erronée ou embarrassante ?

Écrivez le chiffre.

Si personne ne peut y répondre, vous n'avez pas encore de problème IA. Vous avez un problème de besoins.

Et si la réponse est "ça dépend," c'est bien. Décomposez-le par interface jusqu'à ce que cela cesse de dépendre.

Les équipes qui feront cela correctement ne seront pas celles avec la pile IA la plus bruyante. Elles seront celles qui savent quelles décisions nécessitent des secondes, lesquelles nécessitent des minutes, lesquelles peuvent attendre jusqu'à demain, et où un humain a encore sa place dans la boucle.

Cela semble moins excitant que les démonstrations d'agents habituelles.

C'est aussi la différence entre un système utile et un système qui crée un nouveau type de rotation d'astreinte.

Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère à la fois les charges de travail batch et en temps réel à grande échelle.