Un guide pour les développeurs avertit que le maintien d'une transaction de base de données ouverte pendant toute la durée d'un chat piloté par l'IA peut corrompre les réponses et saturer le SGBD sous-jacent. La note, destinée aux équipes qui développent des outils basés sur les LLM, indique que cette pratique « ne devrait pas être pratiquée » et propose à la place quatre modèles de cohérence à courte durée de vie.

Pourquoi cet avertissement est important

Les assistants alimentés par les LLM posent souvent une série de questions de suivi : ils lisent un enregistrement, demandent un détail, puis demandent un total. Si les données sous-jacentes changent entre ces étapes, l'assistant peut renvoyer des chiffres contradictoires — l'une des réponses sera fausse. La solution tentante consiste à ouvrir une transaction unique au début de la conversation et à la maintenir active jusqu'à la fin du chat. En pratique, cette approche mobilise les versions de lignes, remplit la tempdb, maintient des verrous et interfère avec le pool de connexions.

Ce qui conduit à des transactions de longue durée

  • Prompting multi-tours – Les LLM génèrent généralement plusieurs prompts avant que l'utilisateur ne voie une réponse.
  • Appels d'outils (tool calls) qui interrogent la base de données – Chaque tour peut invoquer une procédure stockée, un SELECT ou un UPDATE.
  • Portée de transaction non contrôlée – Les développeurs enveloppent parfois l'intégralité du chat dans un bloc BEGIN…COMMIT, en supposant que cela garantit la cohérence.

Lorsque la conversation s'étire, le moteur de base de données doit conserver les versions originales des lignes afin que la transaction bénéficie d'une vue stable. Ces versions résident dans la tempdb, consommant de l'espace et des entrées/sorties (I/O). Les verrous maintenus pendant cette même période bloquent les écritures concurrentes, et la connexion inactive peut épuiser le pool, forçant les nouveaux appelants à attendre un créneau libre.

Quatre modèles à courte durée de vie

Le guide recommande de traiter la cohérence comme une préoccupation par appel d'outil plutôt que par conversation. Les quatre modèles sont :

  1. Instructions en direct (Live statements) – Chaque appel s'exécute sous le niveau d'isolation par défaut, ne voyant que les données qui ont été validées (committed) au moment de l'exécution. C'est le modèle le plus simple ; l'appelant accepte que les données puissent avoir changé depuis le tour précédent.
  2. Transactions limitées (Bounded transactions) – Un développeur regroupe quelques instructions au sein d'une seule transaction courte qui se termine avant le prochain tour du LLM. Cela garantit l'atomicité de ce lot sans persister au-delà de l'appel d'outil.
  3. Lectures par instantané (Snapshot reads) – L'opération commence avec un horodatage de snapshot défini, offrant une vue stable de la base de données pendant toute la durée de l'appel. Toutes les lectures effectuées au cours de l'appel voient les mêmes données, même si des écritures concurrentes ont lieu.
  4. Rapports matérialisés (Materialized reports) – L'outil lit un ensemble de résultats pré-généré et versionné qui reflète la base de données à un point de coupure connu. La pagination ou les calculs ultérieurs s'opèrent alors sur cet ensemble de données figé.

Dans SQL Server, vérifiez si READ_COMMITTED_SNAPSHOT est actif. Ne supposez pas que le nom résume toute la situation.

Règles pratiques pour les applications pilotées par LLM

  • Regroupez ce dont vous avez besoin (Batching) – Si une question nécessite de nombreuses valeurs, calculez-les dans un seul appel d'outil plutôt que d'émettre des requêtes séparées qui lancent chacune une nouvelle transaction.
  • Pagination déterministe – Lors de la présentation de résultats sur plusieurs pages, utilisez une clé de tri stable, un curseur ou un ensemble de résultats matérialisé. Ne laissez jamais une transaction ouverte pendant que l'utilisateur fait défiler la page.
  • Retournez des preuves – En plus des données, incluez des métadonnées qui rendent le modèle de cohérence explicite : la classe de cohérence, l'heure de début du snapshot, le point de coupure du rapport, la fraîcheur des données, le nombre de lignes, l'identité de la base de données et un ID de traçage (trace ID).
  • Testez la résistance avec la concurrence – Simulez des écritures concurrentes pendant que le LLM génère des prompts, et vérifiez que l'application effectue des tentatives de réessai ou bascule sur un mode de repli de manière fluide.

L'essentiel est clair : un chat IA ne doit pas dicter la durée de vie d'une transaction de base de données. En limitant la portée de la cohérence à chaque appel d'outil, les développeurs maintiennent la santé de la base de données, préservent les performances pour tous les utilisateurs et fournissent tout de même au LLM suffisamment de données fiables pour répondre avec précision.