Databricks simplifie l’orchestration des agents IA, mais Postgres porte désormais le risque

Databricks simplifie l’orchestration des agents IA avec une architecture de production qui remplace plusieurs services spécialisés par une seule base de données Lakebase Postgres. La publication du 22 juillet décrit une application d’audit créée avec CLA qui traite des documents en quelques minutes au lieu de plusieurs heures. Cette amélioration est un résultat communiqué par l’entreprise, mais le changement d’architecture est plus déterminant.

Le système utilise Postgres pour les files de tâches, les nouvelles tentatives, la planification, l’attribution des coûts et les mises à jour d’état en direct. Databricks indique que CLA n’a plus besoin de courtiers externes tels que Kafka ou Redis, de planificateurs distincts tels qu’Airflow ou Temporal, ni d’un cache dédié.

Cette consolidation crée une tension évidente. Les systèmes d’orchestration spécialisés séparent les responsabilités et absorbent les défaillances complexes. Databricks place davantage de ces responsabilités dans une base de données familière, réduisant l’infrastructure tout en faisant de la conception de la base de données un élément central de la fiabilité des agents.

Databricks simplifie la pile autour des agents de longue durée

Le changement immédiat n’est pas un nouveau modèle ni un nouveau framework d’agents. Il s’agit d’un modèle de production qui fait de Lakebase le centre de contrôle du travail des agents.

Databricks et le cabinet de services professionnels CLA ont conçu le système pour l’audit assisté par agents. Les audits exigent souvent que les équipes examinent des contrats, factures, déclarations financières et documents justificatifs avant d’en extraire des informations structurées.

L’application accepte les téléversements de PDF via une interface FastAPI exécutée dans Databricks Apps. Elle stocke ces fichiers dans Unity Catalog Volumes et inscrit chaque demande d’extraction dans Lakebase.

Lakebase est le service Postgres géré de Databricks. Sa documentation Postgres décrit la mise à l’échelle automatique, les branches de base de données, les répliques en lecture, la restauration instantanée et l’intégration avec Unity Catalog.

Deux tables relationnelles constituent le cœur opérationnel. La table tasks enregistre chaque tâche logique, notamment son état, sa priorité, les informations de bail, l’affectation à un agent et le résultat final. La table task_attempts enregistre les exécutions individuelles, notamment les identifiants de tâche, les identifiants de traçage et les métadonnées de coût.

Lakeflow Jobs effectue le travail sur les documents. Chaque tâche lit un PDF stocké, appelle des composants et modèles de traitement des documents, puis réécrit son résultat dans Lakebase. MLflow capture les appels de modèles, l’utilisation des jetons, la latence et les informations de coût.

L’architecture répartit ainsi les responsabilités sans ajouter une nouvelle couche d’infrastructure. Lakeflow exécute le travail, tandis que Lakebase enregistre ce qui doit être exécuté, ce qui est en cours et ce qui est terminé.

Databricks affirme que cette conception a réduit le processus d’extraction de CLA de plusieurs heures à quelques minutes sans baisse de qualité. L’entreprise n’a pas publié de benchmark indépendant, de répartition de la charge de travail ni de taux d’erreur mesuré étayant cette déclaration.

La publication va néanmoins au-delà d’un simple diagramme de référence. Databricks identifie les modèles de concurrence, de récupération, de limitation, de rappel, d’observabilité et de facturation nécessaires pour exploiter cette architecture.

Ce niveau de détail est important, car une table de base de données ne devient pas automatiquement une file de tâches sûre. Une requête simple peut sélectionner du travail en attente, mais plusieurs workers pourraient sélectionner la même ligne avant que l’un d’eux n’en mette à jour l’état.

La conception doit également récupérer le travail après l’arrêt brutal d’un processus. Elle doit empêcher que des rappels dupliqués génèrent des résultats dupliqués. Elle doit maintenir les requêtes de modèles dans les quotas externes et permettre aux documents urgents de passer avant le travail en lot.

La conception de l’orchestration répond à ces problèmes avec des transactions et des fonctionnalités Postgres établies. La nouveauté n’est pas que Postgres puisse stocker l’état des agents. Les développeurs le font depuis des années.

L’affirmation plus forte est que Postgres géré peut devenir l’épine dorsale de l’orchestration d’une charge de travail d’agents en production sans Kafka, Redis, Temporal, Airflow ni autre planificateur.

La véritable pression pèse sur l’infrastructure spécialisée

Databricks remet en question l’hypothèse selon laquelle chaque application d’agents en production nécessite un courtier, un planificateur, un cache et une pile d’observabilité distincts.

Les démonstrations d’agents exécutent souvent une requête de bout en bout dans un seul processus. Les systèmes de production se comportent différemment, car les utilisateurs soumettent des tâches simultanément, les appels de modèles échouent et les tâches individuelles ont des durées imprévisibles.

Databricks illustre cette variabilité avec deux types de documents. Une facture de deux pages peut être terminée en quelques secondes, tandis qu’un contrat de 200 pages peut nécessiter plusieurs minutes. Un worker ne peut pas supposer que les tâches seront terminées dans leur ordre de soumission.

Les quotas des modèles ajoutent une autre contrainte. Un endpoint peut limiter les requêtes par seconde, les jetons par minute, ou les deux. Le lancement simultané de centaines de documents peut déclencher une limitation et des tentatives répétées.

L’application doit également répondre à des questions opérationnelles. Les équipes doivent savoir quelle tâche a échoué, quel appel de modèle a consommé des jetons, combien a coûté chaque tentative et si une tâche abandonnée doit être relancée.

Les architectures traditionnelles attribuent souvent ces préoccupations à des produits distincts. Un courtier de messages transporte les tâches. Un moteur de workflow gère l’exécution durable. Un cache fournit un accès rapide à l’état. Une plateforme de surveillance agrège l’état, la latence et le coût.

Cette séparation peut prendre en charge des workflows complexes et de grandes organisations. Elle introduit aussi des identifiants supplémentaires, des processus de déploiement, des tableaux de bord, des modes de défaillance et du code d’intégration.

Databricks estime que cette surcharge est disproportionnée pour des tâches de longue durée indépendantes les unes des autres. L’extraction de documents correspond à cette description, car un contrat ne dépend généralement pas du résultat d’un autre contrat.

Lakebase modifie l’équation en plaçant l’état transactionnel à côté du reste de l’application Databricks. La même plateforme fournit l’interface, les fichiers, les tâches, les traces de modèles, les contrôles de gouvernance et les enregistrements de facturation.

Cette approche met la pression sur deux groupes. Les équipes de plateforme doivent justifier chaque service supplémentaire qu’elles introduisent, tandis que les fournisseurs d’orchestration doivent démontrer pourquoi leurs garanties spécialisées dépassent celles d’une file de base de données bien conçue.

Cela ne rend pas les systèmes dédiés obsolètes. Amazon, par exemple, présente AgentCore Runtime comme un environnement géré offrant l’isolation des sessions, la mise à l’échelle, l’identité et la prise en charge des agents de longue durée.

Cette approche invite les équipes à adopter un runtime spécifique aux agents. Databricks part plutôt d’une base de données opérationnelle et la relie aux services déjà utilisés pour les charges de travail de données et de machine learning.

La concurrence porte donc sur les frontières de l’infrastructure. L’exécution des agents doit-elle vivre dans un runtime spécialisé, ou une base de données doit-elle coordonner des tâches ordinaires par le biais d’un état relationnel durable ?

Databricks dispose d’un avantage structurel auprès de ses clients existants. Les équipes qui utilisent déjà Lakeflow, MLflow, Unity Catalog et Databricks Apps peuvent consolider leurs outils sans introduire un autre fournisseur ni modèle de sécurité.

Ce même avantage crée une dépendance à la plateforme. Une entreprise qui adopte le modèle complet lie l’exécution des tâches, le stockage, l’observabilité, la gouvernance et le reporting des coûts aux services Databricks.

Pour les acheteurs, « plus simple » ne peut pas seulement signifier moins de noms de produits. Cela doit signifier moins de tâches opérationnelles, une responsabilité plus claire en cas de défaillance, un comportement de récupération acceptable et une stratégie de sortie viable.

Quatre modèles Postgres rendent la file crédible

L’architecture fonctionne parce qu’elle transforme des primitives de base de données familières en garanties explicites sur la concurrence, la récupération, la limitation et les nouvelles tentatives.

Le premier modèle concerne le retrait de tâches de la file en toute sécurité face à la concurrence. Un worker sélectionne les lignes éligibles avec FOR UPDATE SKIP LOCKED, ce qui verrouille les lignes sélectionnées tout en permettant aux autres workers de les ignorer.

PostgreSQL présente SKIP LOCKED comme utile pour éviter les contentions lorsque plusieurs consommateurs accèdent à une table semblable à une file. Il avertit également que cette option présente une vue incohérente, ce qui la rend inadaptée aux requêtes générales.

Cette distinction résume la force de la conception. La table des tâches n’est pas utilisée pour des rapports arbitraires pendant le retrait de la file. Les workers ont besoin de revendiquer exclusivement les tâches disponibles sans attendre derrière le verrou d’un autre worker.

La requête ordonne le travail selon la priorité décroissante et l’heure de création. Les tâches les plus prioritaires sont exécutées en premier, tandis que les tâches de même priorité conservent un ordre premier entré, premier sorti.

Le deuxième modèle utilise des baux à expiration. Lorsqu’un worker revendique une tâche, il enregistre une heure d’expiration du bail plutôt que d’attribuer la propriété indéfiniment.

Un processus de balayage périodique remet les tâches expirées dans la file. Si un worker disparaît à cause d’une éviction, d’un déploiement, d’une erreur mémoire ou d’un arrêt brutal du processus, un autre worker peut récupérer sa tâche en quelques minutes.

Les baux résolvent le problème du travail abandonné, mais ils introduisent aussi une exigence. L’application doit choisir des périodes d’expiration supérieures aux durées normales des tâches, ou renouveler les baux tant que le travail continue.

Un bail qui expire trop tôt peut faire passer un travail sain pour abandonné. Un bail qui dure trop longtemps augmente le temps de récupération après une véritable défaillance.

Le troisième modèle contrôle la consommation des modèles avant l’envoi. L’orchestrateur prend en charge une limite de tâches simultanées, un budget de jetons projeté, ou une combinaison des deux.

Un plafond de concurrence compte les lignes actuellement marquées comme étant en cours de traitement. Comme la base de données conserve ce décompte, la restriction reste visible malgré les redémarrages des workers et les multiples répliques de l’orchestrateur.

Un budget de jetons estime la consommation de chaque tâche en cours. L’orchestrateur n’envoie une nouvelle tâche que lorsque ses jetons projetés restent dans la limite configurée.

Lorsque les deux contrôles sont activés, la contrainte la plus stricte l’emporte. Cela convient aux charges de travail qui alternent entre de nombreuses petites factures et quelques contrats gourmands en jetons.

Le quatrième modèle rend les rappels idempotents. L’idempotence signifie que répéter la même requête produit le même résultat effectif, au lieu d’appliquer deux fois le changement.

Les interruptions réseau et les proxys peuvent faire arriver un rappel plusieurs fois. Databricks accepte les rappels pour les tâches en traitement ou remises en file, tout en traitant les états déjà terminés comme des opérations sans effet.

Ce comportement réduit le risque de traitement ou de facturation en double. Il dépend toutefois d’identités de tâches stables, de transitions d’état rigoureuses et d’une limite transactionnelle incluant la mise à jour du résultat.

Ensemble, ces quatre modèles créent une file crédible. Les transactions empêchent les revendications concurrentes, les baux récupèrent le travail abandonné, les budgets limitent l’envoi et les rappels idempotents tolèrent les nouvelles livraisons.

C’est ainsi que Databricks simplifie une file de tâches d’agents sans prétendre qu’une paire de tables suffit à elle seule. Le code de l’application met toujours en œuvre la politique qui régit chaque transition.

Le mécanisme convient aux tâches dont les structures de dépendance sont relativement simples. Il devient moins attrayant lorsque le travail exige des workflows imbriqués, des actions compensatoires, des validations humaines ou de longues chaînes d’événements planifiés.

Un moteur de workflow dédié représente souvent directement ces relations. Avec une file de base de données, les développeurs doivent les modéliser sous forme de tables, de transitions d’état et de logique applicative.

Ce compromis doit orienter l’adoption. Les équipes doivent choisir ce modèle parce que leur workflow est suffisamment simple, et non parce que Postgres peut théoriquement représenter tous les workflows possibles.

Une base de données relie état, visibilité et coût

La partie la plus distinctive de la conception n’est pas la mise en file. C’est la décision de dériver la visibilité opérationnelle et l’attribution des coûts à partir des mêmes enregistrements de tâches.

Les opérateurs ont besoin de plus qu’une étiquette « terminé » ou « échec ». Le tableau de bord CLA affiche le nombre de tâches mises en file d’attente, en cours de traitement, terminées, échouées et annulées.

Il présente également les jetons d’entrée et de sortie, les coûts des modèles, les coûts de calcul, le temps de réponse médian et le niveau de confiance par document. Les filtres couvrent les plages temporelles, les états des tâches et les agents individuels.

La latence médiane est un choix judicieux pour cette charge de travail. Les délais de réessai et la saturation de la file d’attente peuvent créer des retards extrêmes qui faussent une moyenne simple.

Postgres LISTEN/NOTIFY fournit le mécanisme de mise à jour en direct. Un déclencheur de base de données publie un événement lorsque l’état d’une tâche change, et le backend de l’application maintient une connexion en écoute.

Le backend transmet ces événements aux navigateurs via Server-Sent Events. SSE est un flux HTTP unidirectionnel qui permet à un serveur d’envoyer des mises à jour sur une connexion persistante avec le navigateur.

Databricks indique que les changements du tableau de bord apparaissent généralement en une seconde environ. Cette conception ne nécessite ni Redis, ni serveur WebSocket, ni bus de messages pour ce parcours.

Le système conserve l’interrogation comme solution de repli permanente. Les navigateurs demandent des données fraîches toutes les dix secondes lorsque le streaming devient indisponible.

Cette solution de repli est importante, car les proxys d’entrée cloud peuvent interrompre un flux sans générer d’erreur claire dans le navigateur. Un tableau de bord qui ne repose que sur des événements poussés peut devenir obsolète sans que personne ne s’en aperçoive.

Le tableau de bord combine des informations dont les vitesses d’actualisation diffèrent. L’état Postgres est immédiat, tandis que les données de traçage MLflow arrivent en moins d’une seconde, selon Databricks.

Les requêtes de facturation peuvent prendre plusieurs dizaines de secondes. L’application exécute donc des requêtes d’état rapides pendant les actualisations normales et réserve les requêtes de facturation plus lentes aux actions des utilisateurs.

L’attribution des coûts exige un niveau de filtrage supplémentaire. Les tables de facturation Databricks incluent l’activité à l’échelle du compte ; une requête brute combinerait donc les dépenses de tâches et d’applications sans rapport.

L’orchestrateur enregistre les exécutions spécifiques de Databricks Job attribuées à ses tâches. Les requêtes de facturation filtrent ensuite l’activité du compte sur ces identifiants.

Cela permet à un entrepôt SQL de prendre en charge plusieurs applications tout en garantissant que chaque tableau de bord n’affiche que sa propre charge de travail. Les opérateurs peuvent affiner davantage les résultats par statut, agent ou date.

Cette conception répond à des questions concrètes que la supervision générique masque souvent. Une équipe peut examiner le coût des tâches échouées sur sept jours ou comparer les dépenses médianes entre agents.

Ce lien entre l’identité d’une tâche et son coût est pertinent au-delà de l’audit. Les applications d’IA perdent fréquemment la relation entre une demande utilisateur, les tentatives qu’elle a déclenchées et la facture de modèle qui en résulte.

Un enregistrement de tâche durable donne aux équipes une clé de jointure stable. Il relie l’intention métier, l’historique d’exécution, les traces de modèles, l’activité de calcul et la sortie finale.

Les équipes à forte intensité de connaissances rencontrent un problème similaire après l’exécution. Elles doivent conserver les documents, décisions et résultats entourant le travail automatisé dans un contexte consultable.

Une base de connaissances d’ingénierie structurée peut compléter les traces d’exécution en conservant le contexte humain derrière les incidents et les décisions de conception.

La valeur du modèle Lakebase va donc au-delà de la réduction du nombre de services. Il crée un récit opérationnel unique pour chaque tâche, de sa soumission à son coût et son résultat, en passant par les réessais.

Une infrastructure plus simple déplace le risque vers la conception de la base de données

Databricks réduit les frais d’intégration, mais n’élimine pas la complexité des systèmes distribués. Il la déplace vers les schémas, les transactions, les baux et le code applicatif.

L’expression « aucune infrastructure externe » mérite une lecture attentive. L’application dépend toujours de plusieurs services Databricks, notamment Apps, Lakeflow Jobs, MLflow, Unity Catalog Volumes et Lakebase.

La simplification intervient au sein d’une plateforme gérée unique. Elle ne réduit pas l’architecture à un seul processus ou un seul service.

Cette distinction compte lors d’une panne. Une file Lakebase peut rester durable tandis que le service de jobs est indisponible, mais l’application doit tout de même disposer d’un comportement testé pour les retards de distribution et la récupération.

Les équipes doivent également déterminer ce qui se passe lorsqu’un callback réussit mais qu’une opération environnante échoue. L’idempotence ne protège contre les livraisons répétées que si chaque effet secondaire utilise des identifiants et des frontières cohérents.

Le contrôle des limites de débit comporte lui aussi une part d’incertitude. Un budget de jetons projeté dépend de l’estimation de la consommation d’un document avant son traitement par le modèle.

Les estimations peuvent sous-évaluer les documents complexes ou surévaluer les documents simples. Une sous-estimation peut déclencher une limitation côté fournisseur, tandis qu’une surestimation peut laisser inutilisée une capacité de modèle disponible.

La conception publiée ne fournit ni résultats de débit, ni limites de profondeur de file, ni taux d’échec, ni charge de base de données, ni données d’exploitation comparatives. Elle ne compare pas non plus directement l’implémentation à un moteur de workflow dédié.

Databricks indique que le temps d’extraction est passé d’heures à quelques minutes. Toutefois, l’entreprise ne divulgue ni l’échantillon de documents, ni le processus de revue humaine, ni la mesure de précision, ni la configuration du modèle, ni le workflow de référence.

Les lecteurs devraient considérer ce résultat comme le récit d’un client en production, et non comme un benchmark contrôlé. L’architecture peut être utile même sans démontrer des gains de performance universels.

Postgres peut lui-même devenir un point de contention. Les retraits fréquents de la file, les mises à jour de statut, les calculs de budget de jetons, les lectures du tableau de bord et les jointures de facturation proviennent tous d’enregistrements opérationnels liés.

Lakebase offre un calcul avec autoscaling et un stockage durable indépendant. Ces fonctionnalités peuvent réduire la planification de capacité, mais l’autoscaling n’élimine ni les requêtes inefficaces ni la contention sur les verrous.

Les tables de file d’attente évoluent aussi différemment des tables d’application ordinaires. L’historique des tentatives s’accumule, les enregistrements terminés conservent leur valeur pour les audits, et les index doivent prendre en charge à la fois la planification en direct et l’analyse historique.

Les politiques de rétention et d’archivage font donc partie de la conception de la file. Sans elles, les requêtes opérationnelles peuvent progressivement entrer en concurrence avec les charges de reporting.

La sécurité mérite une attention égale. La table des tâches peut contenir des emplacements de documents, des résultats extraits, des scores de confiance, des attributions d’agents et des identifiants d’exécution.

Databricks indique que Unity Catalog fournit une identité et des autorisations partagées. Les équipes doivent néanmoins appliquer le principe du moindre privilège, protéger les endpoints webhook et décider quels opérateurs peuvent consulter des résultats sensibles.

Le branching de base de données peut aider à reproduire des défauts dans un environnement isolé. Il peut aussi copier des données opérationnelles sensibles, ce qui exige un masquage et des contrôles d’accès adaptés à la charge d’audit.

La question concurrentielle plus large reste sans réponse. AlloyDB AI de Google positionne également une infrastructure compatible PostgreSQL comme fondation pour les applications d’IA, notamment pour les recherches vectorielles et hybrides.

AWS adopte une approche plus spécifique aux agents avec des services gérés d’exécution, de mémoire, d’identité et d’orchestration. Les systèmes de workflow dédiés continuent de se concentrer sur l’exécution durable de graphes de processus complexes.

Databricks a montré que Postgres peut couvrir un terrain intermédiaire significatif. L’entreprise n’a pas démontré que l’orchestration centrée sur la base de données devrait remplacer ces systèmes pour toutes les charges de travail d’agents.

Le cas d’adoption le plus solide concerne des tâches indépendantes et longues sur une plateforme Databricks existante. Le plus faible concerne des workflows inter-systèmes aux dépendances complexes et aux exigences strictes de portabilité.

Trois signaux mettront à l’épreuve le cas de l’orchestration Lakebase

La prochaine épreuve sera de savoir si l’architecture CLA devient un modèle de production reproductible plutôt qu’une implémentation client soigneusement conçue.

Le premier signal sera l’adoption au-delà de l’extraction de documents. Databricks devrait publier des exemples impliquant des agents de codage, des opérations client, la remédiation de données ou des workflows de recherche.

Ces charges de travail mettraient à l’épreuve des tailles de tâches, structures de dépendances, autorisations d’outils et exigences d’approbation humaine différents. Des résultats similaires renforceraient l’affirmation selon laquelle Lakebase est un magasin d’état général pour les agents.

Si les futurs exemples restent limités à des tâches documentaires indépendantes, la conception restera utile. Son champ d’application pratique sera simplement plus étroit que ne le laisse entendre le langage plus large sur l’orchestration.

Le deuxième signal sera constitué de données opérationnelles comparatives. Les équipes ont besoin de connaître le débit de la file, les temps de récupération, l’utilisation de la base de données, les taux d’échec et la latence de distribution sous charge soutenue.

Une comparaison avec des workers adossés à Redis ou un moteur de workflow durable serait particulièrement utile. Elle pourrait montrer à quel moment la réduction du travail d’intégration l’emporte sur la logique supplémentaire de machine à états au sein de l’application.

Des données transparentes renforceraient l’argument de simplification de Databricks. L’absence de telles données laisserait les acheteurs dépendre de descriptions d’architecture et de résultats rapportés par les clients.

Le troisième signal sera la productisation. Le modèle actuel repose sur du code applicatif qui implémente le verrouillage, les baux, la limitation de débit, les callbacks, le streaming du tableau de bord et l’attribution de facturation.

Databricks pourrait transformer certaines parties de cette conception en modèles, composants gérés, bibliothèques de référence ou capacités Lakebase intégrées. Cela réduirait la quantité de code critique pour la correction que chaque client doit maintenir.

La productisation révélerait également comment Databricks définit la frontière entre les fonctionnalités de base de données et les fonctionnalités de workflow. Une couche gérée plus large concurrencerait plus directement les runtimes d’agents et les plateformes d’orchestration.

Les équipes qui évaluent ce modèle devraient commencer par la forme de leurs workflows. Des tâches indépendantes avec des états terminaux clairs s’alignent bien avec la conception CLA.

Elles devraient ensuite tester le comportement en cas d’échec avant d’optimiser le débit. Arrêtez les workers, retardez les callbacks, dupliquez les requêtes, épuisez les quotas de modèles et interrompez les flux du tableau de bord.

Enfin, comparez la charge opérationnelle avec une alternative spécialisée. Comptez les services supprimés, mais aussi les transitions personnalisées, les règles de récupération, les tests et les runbooks ajoutés.

Databricks simplifie l’infrastructure visible autour de l’orchestration des agents, et Lakebase fournit à cette conception un noyau transactionnel crédible. La question ouverte est de savoir si votre application est suffisamment simple pour que cette consolidation reste simple.

Si c’est le cas, une file centrée sur la base de données peut raccourcir le chemin entre le prototype et un système de production observable. Dans le cas contraire, le broker ou le moteur de workflow absent réapparaîtra sous forme de code applicatif. La prochaine étape appropriée est un pilote axé sur les échecs, utilisant des tailles de tâches réelles, des quotas réels et des objectifs de récupération réels.