Una guía para desarrolladores advierte que mantener una transacción de base de datos abierta durante la duración de un chat impulsado por IA puede corromper las respuestas y saturar el DBMS subyacente. La nota, dirigida a equipos que construyen herramientas basadas en LLM, afirma que esta práctica "no debe realizarse" y ofrece, en su lugar, cuatro patrones de consistencia de corta duración.

Por qué es importante la advertencia

Los asistentes impulsados por LLM suelen hacer una serie de preguntas de seguimiento: leen un registro, solicitan un detalle y luego piden un total. Si los datos subyacentes cambian entre esos pasos, el asistente puede devolver cifras contradictorias; una de las respuestas será incorrecta. La solución tentadora es abrir una única transacción al inicio de la conversación y mantenerla viva hasta que termine el chat. En la práctica, ese enfoque bloquea versiones de filas, llena la tempdb, mantiene bloqueos (locks) e interfiere con el pool de conexiones.

Qué provoca transacciones de larga duración

  • Prompting de múltiples turnos – Los LLM suelen generar varios prompts antes de que el usuario vea una respuesta.
  • Llamadas a herramientas que acceden a la base de datos – Cada turno puede invocar un procedimiento almacenado, un SELECT o un UPDATE.
  • Alcance de transacción no controlado – Los desarrolladores a veces envuelven todo el chat en un bloque BEGIN…COMMIT, asumiendo que esto garantiza la consistencia.

Cuando el chat se prolonga, el motor de la base de datos debe conservar las versiones originales de las filas para que la transacción vea una vista estable. Esas versiones residen en tempdb, consumiendo espacio y E/S (I/O). Los bloqueos mantenidos durante el mismo periodo impiden a los escritores concurrentes, y la conexión inactiva puede agotar el pool, obligando a los nuevos usuarios a esperar un espacio libre.

Cuatro patrones de corta duración

La guía recomienda tratar la consistencia como una preocupación por cada llamada a herramienta, en lugar de por cada conversación. Los cuatro patrones son:

  1. Sentencias en vivo (Live statements) – Cada llamada se ejecuta bajo el nivel de aislamiento predeterminado, viendo solo los datos que se han confirmado (committed) en el momento de la ejecución. Este es el modelo más sencillo; el llamador acepta que los datos pueden haber cambiado desde el turno anterior.
  2. Transacciones acotadas (Bounded transactions) – Un desarrollador agrupa un puñado de sentencias dentro de una única transacción corta que finaliza antes del siguiente turno del LLM. Esto garantiza la atomicidad para ese lote sin prolongarse más allá de la llamada a la herramienta.
  3. Lecturas de instantánea (Snapshot reads) – La operación comienza con una marca de tiempo de instantánea (snapshot timestamp) definida, lo que proporciona una vista estable de la base de datos durante la duración de la llamada. Todas las lecturas dentro de la llamada ven los mismos datos, incluso si ocurren escrituras concurrentes.
  4. Informes materializados (Materialized reports) – La herramienta lee de un conjunto de resultados versionado y pregenerado que refleja la base de datos en un punto de corte conocido. La paginación o los cálculos posteriores operan sobre ese conjunto de datos congelado.

En SQL Server, compruebe si READ_COMMITTED_SNAPSHOT está activo. No asuma que el nombre lo dice todo.

Reglas prácticas para aplicaciones impulsadas por LLM

  • Agrupe lo que necesite (Batch) – Si una pregunta requiere muchos valores, calcúlelos en una sola llamada a herramienta en lugar de emitir consultas separadas que inicien una nueva transacción cada una.
  • Paginación determinista – Al presentar resultados a través de varias páginas, utilice una clave de ordenación estable, un cursor o un conjunto de resultados materializado. Nunca mantenga una transacción abierta mientras el usuario se desplaza.
  • Devuelva evidencia – Junto con los datos, incluya metadatos que hagan explícito el modelo de consistencia: la clase de consistencia, la hora de inicio de la instantánea, el punto de corte del informe, la frescura de los datos, el recuento de filas, la identidad de la base de datos y un ID de seguimiento (trace ID).
  • Realice pruebas de estrés con concurrencia – Simule escrituras concurrentes mientras el LLM está generando prompts y verifique que la aplicación reintente la operación o recurra a un plan de contingencia de forma fluida.

La conclusión es clara: un chat de IA no debe dictar la vida útil de una transacción de base de datos. Al limitar el alcance de la consistencia a cada llamada a herramienta, los desarrolladores mantienen la salud de la base de datos, preservan el rendimiento para todos los usuarios y siguen proporcionando al LLM suficientes datos fiables para responder con precisión.