Посібник для розробників попереджає, що тривале утримання транзакції бази даних протягом усього чату з ШІ може призвести до спотворення відповідей і перевантаження базової СУБД. Примітка, орієнтована на команди, що розробляють інструменти на базі LLM, стверджує, що таку практику «не слід застосовувати», і натомість пропонує чотири короткочасні патерни забезпечення узгодженості.

Чому це попередження важливе

Асистенти на базі LLM часто ставлять серію уточнюючих запитань: вони зчитують запис, запитують деталь, а потім просять підрахувати підсумок. Якщо вихідні дані змінюються між цими кроками, асистент може надати суперечливі цифри — одна з відповідей буде неправильною. Спокусливим рішенням є відкриття однієї транзакції на початку розмови та її утримання до завершення чату. На практиці такий підхід блокує версії рядків, заповнює tempdb, утримує блокування та заважає пулінгу з'єднань.

Що призводить до тривалих транзакцій

  • Багатоходовий промптинг – LLM зазвичай генерують кілька промптів, перш ніж користувач побачить відповідь.
  • Виклики інструментів, що звертаються до бази даних – Кожен хід може викликати збережену процедуру, SELECT або UPDATE.
  • Неконтрольована область дії транзакції – Розробники іноді обгортають увесь чат у блок BEGIN…COMMIT, вважаючи, що це гарантує узгодженість.

Коли чат триває довго, механізм БД має зберігати оригінальні версії рядків, щоб транзакція бачила стабільний стан. Ці версії зберігаються в tempdb, споживаючи місце та ресурси введення-виведення (I/O). Блокування, що утримуються протягом того ж періоду, перешкоджають паралельному запису, а бездіяльне з'єднання може вичерпати пул, змушуючи нових користувачів чекати на вільне місце.

Чотири короткочасні патерни

Посібник рекомендує розглядати узгодженість як питання окремого виклику інструменту, а не всієї розмови. Чотири патерни:

  1. Live statements – Кожен виклик виконується на рівні ізоляції за замовчуванням, бачачи лише ті дані, які були зафіксовані (committed) на момент виконання. Це найпростіша модель; викликаючий стороні приймає той факт, що дані могли змінитися з моменту попереднього ходу.
  2. Bounded transactions – Розробник групує кілька операторів у межах однієї короткої транзакції, яка завершується до наступного ходу LLM. Це гарантує атомарність для цієї пачки без тривалого утримання після виклику інструменту.
  3. Snapshot reads – Операція починається з визначеного часового штампа знімка (snapshot timestamp), що забезпечує стабільний вигляд бази даних протягом усього виклику. Усі операції зчитування в межах виклику бачать однакові дані, навіть якщо відбуваються паралельні записи.
  4. Materialized reports – Інструмент зчитує дані з попередньо згенерованого версіонованого набору результатів, який відображає стан бази даних на певний момент часу. Потім пагінація або подальші обчислення виконуються на цьому зафіксованому наборі даних.

У SQL Server перевірте, чи активовано READ_COMMITTED_SNAPSHOT. Не вважайте, що назва пояснює все.

Практичні правила для застосунків на базі LLM

  • Групуйте необхідне – Якщо запитання потребує багатьох значень, обчисліть їх за один виклик інструменту, а не надсилайте окремі запити, кожен з яких запускає нову транзакцію.
  • Детермінована пагінація – При відображенні результатів на різних сторінках використовуйте стабільний ключ сортування, курсор або матеріалізований набір результатів. Ніколи не тримайте транзакцію відкритою, поки користувач гортає сторінку.
  • Повертайте докази – Разом із даними додавайте метадані, які чітко визначають модель узгодженості: клас узгодженості, час початку знімка, момент відсікання звіту, актуальність даних, кількість рядків, ідентифікатор бази даних та ID трасування.
  • Стрес-тестування паралелізмом – Симулюйте паралельні записи під час формування промптів LLM і переконайтеся, що застосунок коректно виконує повторні спроби або передбачено сценарій відкату.

Висновок очевидний: чат із ШІ не повинен диктувати тривалість транзакції бази даних. Обмежуючи область дії узгодженості межами кожного виклику інструменту, розробники підтримують здоров'я бази даних, зберігають продуктивність для всіх користувачів і водночас надають LLM достатньо надійних даних для точних відповідей.