ある開発者ガイドは、AI駆動のチャットの間、データベーストランザクションを開いたままにすると、回答が不整合になったり、基盤となるDBMSを圧迫したりする可能性があると警告しています。LLMを活用したツールを構築するチームに向けたこの注記では、そのような手法は「行うべきではない」としており、代わりに4つの短寿命の整合性パターンを提案しています。

なぜこの警告が重要なのか

LLM搭載のアシスタントは、一連の追加質問を行うことがよくあります。例えば、レコードを読み取り、詳細を要求し、次に合計を尋ねるといった具合です。もしこれらのステップの間に基盤となるデータが変更されると、アシスタントは矛盾する数値を返す可能性があり、回答のいずれかが誤ったものになります。魅力的な解決策は、会話の開始時に単一のトランザクションを開き、チャットが終わるまで維持することです。しかし実際には、そのアプローチは行バージョンを拘束し、tempdbを埋め、ロックを保持し、コネクションプーリングを妨害します。

長寿命のトランザクションを招く要因

  • マルチターン・プロンプティング – LLMは通常、ユーザーが回答を受け取る前に、複数のプロンプトを生成します。
  • データベースにアクセスするツール呼び出し – 各ターンで、ストアドプロシージャ、SELECT、またはUPDATEが呼び出される可能性があります。
  • 管理されていないトランザクションスコープ – 開発者は、整合性が保証されると想定して、チャット全体をBEGIN…COMMITブロックで囲んでしまうことがあります。

チャットが長引くと、トランザクションが安定したビューを参照できるように、DBエンジンは元の行バージョンを保持し続けなければなりません。これらのバージョンはtempdbに格納され、スペースとI/Oを消費します。同じ期間保持されるロックは、並行して書き込みを行う処理をブロックし、アイドル状態の接続はプールを使い果たし、新しい呼び出し元が空きスロットを待たなければならない状況を招く可能性があります。

4つの短寿命パターン

このガイドでは、整合性を「会話ごと」ではなく「ツール呼び出しごと」の懸念事項として扱うことを推奨しています。4つのパターンは以下の通りです。

  1. ライブ・ステートメント (Live statements) – 各呼び出しはデフォルトの分離レベルで実行され、実行の瞬間にコミットされているデータのみを参照します。これは最もシンプルなモデルであり、呼び出し側は、前のターンからデータが変更されている可能性があることを受け入れます。
  2. 境界付きトランザクション (Bounded transactions) – 開発者は、いくつかのステートメントを単一の短いトランザクション内にまとめ、次のLLMターンが始まる前に完了させます。これにより、ツール呼び出しを超えて長引くことなく、そのバッチの原子性を保証できます。
  3. スナップショット読み取り (Snapshot reads) – 操作は定義されたスナップショットのタイムスタンプから開始され、呼び出しの間、データベースの安定したビューを提供します。並行して書き込みが発生しても、呼び出し内のすべての読み取りは同じデータを見ることができます。
  4. マテリアライズド・レポート (Materialized reports) – ツールは、既知のカットオフ時点のデータベースを反映した、事前に生成されたバージョン管理済みの結果セットから読み取ります。ページネーションやさらなる計算は、その固定されたデータセットに対して行われます。

SQL Serverでは、READ_COMMITTED_SNAPSHOTが有効かどうかを確認してください。名前だけですべてが分かるとは限らないので注意が必要です。

LLM駆動型アプリのための実践的なルール

  • 必要なものをバッチ化する – 質問に多くの値が必要な場合は、それぞれが新しいトランザクションを開始する個別のクエリを発行するのではなく、単一のツール呼び出しでそれらを計算してください。
  • 決定論的なページネーション – 結果をページをまたいで表示する場合は、安定した並べ替えキー、カーソル、またはマテリアライズドされた結果セットを使用してください。ユーザーがスクロールしている間、トランザクションを開いたままにしてはいけません。
  • エビデンスを返す – データとともに、整合性モデルを明示するメタデータを含めてください。具体的には、整合性クラス、スナップショット開始時刻、レポートのカットオフ、データの鮮度、行数、データベース識別子、およびトレースIDです。
  • 並行性によるストレス・テスト – LLMがプロンプトを生成している間に並行して書き込みを行うシミュレーションを行い、アプリケーションが適切にリトライまたはフォールバックを行うことを確認してください。

結論は明確です。AIチャットがデータベーストランザクションの寿命を決定すべきではありません。整合性の範囲を各ツール呼び出しに限定することで、開発者はデータベースの健全性を維持し、すべてのユーザーのパフォーマンスを確保しつつ、LLMが正確に回答するために十分な信頼できるデータを提供し続けることができます。