Một hướng dẫn dành cho nhà phát triển cảnh báo rằng việc duy trì một giao dịch cơ sở dữ liệu (database transaction) mở trong suốt thời gian diễn ra một cuộc trò chuyện do AI điều khiển có thể làm sai lệch câu trả lời và gây nghẽn hệ quản trị cơ sở dữ liệu (DBMS) bên dưới. Lưu ý này, nhằm hướng tới các đội ngũ đang xây dựng các công cụ dựa trên LLM, cho biết thực hành này “không nên được thực hiện” và thay vào đó đề xuất bốn mô hình nhất quán ngắn hạn.
Tại sao cảnh báo này lại quan trọng
Các trợ lý chạy bằng LLM thường đặt một loạt các câu hỏi tiếp nối: chúng đọc một bản ghi, yêu cầu một chi tiết, sau đó hỏi về một tổng số. Nếu dữ liệu bên dưới thay đổi giữa các bước đó, trợ lý có thể trả về các con số mâu thuẫn nhau—một câu trả lời sẽ bị sai. Cách khắc phục đầy cám dỗ là mở một giao dịch duy nhất khi bắt đầu cuộc hội thoại và giữ nó cho đến khi cuộc trò chuyện kết thúc. Trên thực tế, cách tiếp cận đó làm chiếm dụng các phiên bản hàng (row versions), làm đầy tempdb, giữ các khóa (locks) và gây nhiễu quá trình quản lý kết nối (connection pooling).
Điều gì dẫn đến các giao dịch kéo dài
- Prompting đa lượt (Multi-turn prompting) – Các LLM thường tạo ra nhiều prompt trước khi người dùng thấy phản hồi.
- Các lệnh gọi công cụ (tool calls) truy cập cơ sở dữ liệu – Mỗi lượt có thể gọi một stored procedure, một lệnh SELECT hoặc một lệnh UPDATE.
- Phạm vi giao dịch không được kiểm soát – Các nhà phát triển đôi khi bao bọc toàn bộ cuộc trò chuyện trong một khối BEGIN…COMMIT, với giả định rằng nó đảm bảo tính nhất quán.
Khi cuộc trò chuyện kéo dài, công cụ DB phải giữ lại các phiên bản hàng gốc để giao dịch có thể nhìn thấy một chế độ xem ổn định. Các phiên bản đó nằm trong tempdb, tiêu tốn không gian và I/O. Các khóa được giữ trong cùng một khoảng thời gian sẽ chặn các tác vụ ghi đồng thời, và kết nối nhàn rỗi có thể làm cạn kiệt pool kết nối, buộc các bên gọi mới phải chờ đợi một vị trí trống.
Bốn mô hình ngắn hạn
Hướng dẫn khuyến nghị nên coi tính nhất quán là vấn đề theo từng lệnh gọi công cụ (per-tool-call) thay vì theo từng cuộc hội thoại. Bốn mô hình đó là:
- Các câu lệnh trực tiếp (Live statements) – Mỗi lệnh gọi chạy dưới mức cô lập (isolation level) mặc định, chỉ thấy dữ liệu đã được commit tại thời điểm thực thi. Đây là mô hình đơn giản nhất; bên gọi chấp nhận rằng dữ liệu có thể đã thay đổi kể từ lượt trước.
- Các giao dịch có giới hạn (Bounded transactions) – Nhà phát triển nhóm một vài câu lệnh vào trong một giao dịch ngắn duy nhất và kết thúc trước lượt LLM tiếp theo. Nó đảm bảo tính nguyên tử (atomicity) cho lô đó mà không kéo dài quá lệnh gọi công cụ.
- Đọc bản chụp (Snapshot reads) – Thao tác bắt đầu với một dấu thời gian snapshot được xác định, cung cấp một chế độ xem ổn định của cơ sở dữ liệu trong suốt thời gian gọi. Tất cả các lệnh đọc trong lần gọi đều thấy cùng một dữ liệu, ngay cả khi có các lệnh ghi đồng thời xảy ra.
- Báo cáo vật chất hóa (Materialized reports) – Công cụ đọc từ một tập kết quả đã được tạo sẵn và có phiên bản, phản ánh cơ sở dữ liệu tại một thời điểm cắt (cutoff point) đã biết. Việc phân trang hoặc các tính toán tiếp theo sau đó sẽ hoạt động trên tập dữ liệu đã được đóng băng đó.
Trong SQL Server, hãy kiểm tra xem READ_COMMITTED_SNAPSHOT có đang hoạt động hay không. Đừng giả định rằng cái tên đã nói lên toàn bộ câu chuyện.
Các quy tắc thực tế cho các ứng dụng chạy bằng LLM
- Gom nhóm những gì bạn cần (Batch what you need) – Nếu một câu hỏi yêu cầu nhiều giá trị, hãy tính toán chúng trong một lệnh gọi công cụ duy nhất thay vì đưa ra các truy vấn riêng biệt mà mỗi truy vấn đều bắt đầu một giao dịch mới.
- Phân trang xác định (Deterministic pagination) – Khi trình bày kết quả qua các trang, hãy sử dụng một khóa sắp xếp ổn định, một con trỏ (cursor) hoặc một tập kết quả đã được vật chất hóa. Đừng bao giờ giữ một giao dịch mở trong khi người dùng cuộn trang.
- Trả về bằng chứng (Return evidence) – Cùng với dữ liệu, hãy bao gồm siêu dữ liệu (metadata) để làm rõ mô hình nhất quán: lớp nhất quán (consistency class), thời gian bắt đầu snapshot, thời điểm cắt báo cáo, độ tươi của dữ liệu (data freshness), số lượng hàng, định danh cơ sở dữ liệu và một trace ID.
- Kiểm tra áp lực với tính đồng thời (Stress-test with concurrency) – Mô phỏng các lệnh ghi đồng thời trong khi LLM đang đưa ra prompt, và xác minh rằng ứng dụng sẽ thử lại hoặc chuyển sang chế độ dự phòng một cách mượt mà.
Điểm mấu chốt rất rõ ràng: một cuộc trò chuyện AI không nên quyết định vòng đời của một giao dịch cơ sở dữ liệu. Bằng cách giới hạn phạm vi nhất quán cho mỗi lệnh gọi công cụ, các nhà phát triển sẽ giữ cho cơ sở dữ liệu khỏe mạnh, duy trì hiệu suất cho tất cả người dùng và vẫn cung cấp cho LLM đủ dữ liệu đáng tin cậy để trả lời chính xác.