คู่มือสำหรับนักพัฒนาเตือนว่า การเปิด transaction ของฐานข้อมูลค้างไว้ตลอดระยะเวลาการแชทที่ขับเคลื่อนด้วย AI อาจทำให้คำตอบผิดเพี้ยนและทำให้ระบบจัดการฐานข้อมูล (DBMS) ที่ใช้งานอยู่ทำงานหนักจนเกินไป ข้อความดังกล่าวซึ่งมุ่งเป้าไปที่ทีมที่กำลังสร้างเครื่องมือที่ใช้ LLM เป็นพื้นฐาน ระบุว่าแนวปฏิบัตินี้ “ไม่ควรทำ” และได้เสนอรูปแบบการรักษาความสอดคล้องของข้อมูล (consistency patterns) แบบระยะสั้น 4 รูปแบบแทน
ทำไมคำเตือนนี้จึงสำคัญ
ผู้ช่วยที่ขับเคลื่อนด้วย LLM มักจะถามคำถามต่อเนื่องเป็นชุด เช่น อ่านข้อมูลหนึ่งรายการ ขอรายละเอียด แล้วจึงถามหายอดรวม หากข้อมูลพื้นฐานมีการเปลี่ยนแปลงระหว่างขั้นตอนเหล่านั้น ผู้ช่วยอาจให้ตัวเลขที่ขัดแย้งกัน ซึ่งจะทำให้คำตอบหนึ่งผิดพลาด วิธีแก้ที่ดูเหมือนจะง่ายคือการเปิด transaction เดียวไว้ตั้งแต่เริ่มการสนทนาและเปิดค้างไว้จนกว่าการแชทจะสิ้นสุด แต่ในทางปฏิบัติ วิธีนี้จะทำให้เกิดการจอง row versions, ทำให้ tempdb เต็ม, ถือครอง locks และรบกวนการทำงานของ connection pooling
สิ่งที่นำไปสู่การเปิด transaction ค้างไว้นานเกินไป
- Multi-turn prompting – โดยปกติแล้ว LLM จะสร้าง prompt หลายครั้งก่อนที่ผู้ใช้จะเห็นคำตอบ
- Tool calls ที่เรียกใช้งานฐานข้อมูล – ในแต่ละรอบอาจมีการเรียกใช้ stored procedure, คำสั่ง SELECT หรือ UPDATE
- ขอบเขตของ transaction ที่ควบคุมไม่ได้ – นักพัฒนาบางครั้งครอบการแชททั้งหมดไว้ในบล็อก BEGIN…COMMIT โดยสันนิษฐานว่ามันจะช่วยรับประกันความสอดคล้องของข้อมูล
เมื่อการแชทลากยาวขึ้น DB engine จะต้องเก็บรักษา row versions ดั้งเดิมไว้เพื่อให้ transaction มองเห็นข้อมูลที่คงที่ (stable view) ซึ่ง version เหล่านั้นจะถูกเก็บไว้ใน tempdb ทำให้สิ้นเปลืองพื้นที่และ I/O นอกจากนี้ การถือครอง locks เป็นเวลานานยังไปขัดขวางผู้เขียนข้อมูล (writers) รายอื่นที่ทำงานพร้อมกัน และการเชื่อมต่อที่ปล่อยว่างไว้ (idle connection) อาจทำให้ connection pool เต็ม จนบังคับให้ผู้เรียกใช้งานรายใหม่ต้องรอคิวว่าง
4 รูปแบบการทำงานแบบระยะสั้น
คู่มือแนะนำให้จัดการเรื่องความสอดคล้องของข้อมูล (consistency) ในระดับการเรียกใช้เครื่องมือแต่ละครั้ง (per-tool-call) แทนที่จะเป็นระดับการสนทนา (per-conversation) โดยมี 4 รูปแบบดังนี้:
- Live statements – การเรียกแต่ละครั้งจะทำงานภายใต้ isolation level เริ่มต้น โดยจะเห็นเฉพาะข้อมูลที่ได้รับการ commit แล้ว ณ ขณะที่ทำงาน นี่คือโมเดลที่ง่ายที่สุด โดยผู้เรียกใช้งานต้องยอมรับว่าข้อมูลอาจเปลี่ยนแปลงไปจากรอบก่อนหน้า
- Bounded transactions – นักพัฒนาจะรวมคำสั่งจำนวนหนึ่งไว้ภายใน transaction สั้นๆ เพียงชุดเดียว ซึ่งจะสิ้นสุดลงก่อนที่ LLM จะเริ่มรอบถัดไป วิธีนี้ช่วยรับประกันความเป็น atomicity สำหรับชุดคำสั่งนั้นๆ โดยไม่ค้างคาเกินกว่าการเรียกใช้เครื่องมือ
- Snapshot reads – การทำงานจะเริ่มต้นด้วยการกำหนด snapshot timestamp เพื่อให้เห็นภาพรวมของฐานข้อมูลที่คงที่ตลอดระยะเวลาการเรียกใช้งาน การอ่านข้อมูลทั้งหมดภายในรอบนั้นจะเห็นข้อมูลชุดเดียวกัน แม้ว่าจะมีการเขียนข้อมูลพร้อมกันก็ตาม
- Materialized reports – เครื่องมือจะอ่านข้อมูลจากชุดผลลัพธ์ (result set) ที่ถูกสร้างไว้ล่วงหน้าและมีการระบุเวอร์ชัน ซึ่งสะท้อนถึงสถานะของฐานข้อมูล ณ จุดตัดเวลาที่กำหนด จากนั้นการทำ pagination หรือการคำนวณเพิ่มเติมจะทำงานบนชุดข้อมูลที่ถูกแช่แข็ง (frozen dataset) นั้น
ใน SQL Server ให้ตรวจสอบว่า READ_COMMITTED_SNAPSHOT เปิดใช้งานอยู่หรือไม่ อย่าทึกทักเอาเองว่าชื่อนั้นจะบอกรายละเอียดทั้งหมด
กฎที่นำไปใช้ได้จริงสำหรับแอปพลิเคชันที่ขับเคลื่อนด้วย LLM
- รวบรวมสิ่งที่จำเป็นเป็นชุด (Batch) – หากคำถามต้องการค่าหลายค่า ให้คำนวณค่าเหล่านั้นในการเรียกใช้เครื่องมือเพียงครั้งเดียว แทนที่จะส่งคำสั่ง query แยกกันซึ่งแต่ละครั้งจะเริ่ม transaction ใหม่
- การทำ pagination ที่แน่นอน (Deterministic pagination) – เมื่อแสดงผลลัพธ์ข้ามหน้า ให้ใช้ ordering key ที่คงที่, cursor หรือ materialized result set และอย่าเปิด transaction ค้างไว้ในขณะที่ผู้ใช้กำลังเลื่อนหน้าจอ
- ส่งคืนหลักฐาน (Return evidence) – นอกเหนือจากข้อมูลแล้ว ควรแนบ metadata ที่ระบุโมเดลความสอดคล้องของข้อมูลให้ชัดเจน เช่น consistency class, เวลาเริ่มต้น snapshot, จุดตัดการรายงาน (reporting cutoff), ความสดใหม่ของข้อมูล (data freshness), จำนวนแถว (row count), ข้อมูลระบุตัวตนของฐานข้อมูล (database identity) และ trace ID
- ทดสอบความทนทานด้วยการทำงานพร้อมกัน (Stress-test with concurrency) – จำลองการเขียนข้อมูลพร้อมกันในขณะที่ LLM กำลังสร้าง prompt และตรวจสอบว่าแอปพลิเคชันมีการลองใหม่ (retry) หรือถอยกลับ (fallback) อย่างราบรื่น
บทสรุปนั้นชัดเจน: การแชทด้วย AI ไม่ควรเป็นตัวกำหนดอายุขัยของ transaction ในฐานข้อมูล การกำหนดขอบเขตความสอดคล้องของข้อมูลไว้ที่การเรียกใช้เครื่องมือแต่ละครั้ง จะช่วยให้นักพัฒนาสามารถรักษาความสมบูรณ์ของฐานข้อมูล รักษาประสิทธิภาพสำหรับผู้ใช้ทุกคน และยังให้ข้อมูลที่เชื่อถือได้เพียงพอแก่ LLM เพื่อตอบคำถามได้อย่างแม่นยำ