AI แบบเอเจนต์กับการพัฒนาฐานข้อมูล: อะไรเปลี่ยนไปเมื่อ AI เรียกใช้คิวรีได้จริง

ในช่วงไม่กี่ปีที่ผ่านมา การพัฒนาฐานข้อมูลโดยมี AI ช่วยดำเนินการเป็นไปตามรูปแบบที่ค่อนข้างสบายใจ นักพัฒนาอธิบายความต้องการ จากนั้น AI ก็สร้าง SQL ขึ้นมา นักพัฒนาอ่าน ตรวจแก้ส่วนที่เห็นว่าผิด และตัดสินใจว่าจะเรียกใช้หรือไม่

ขั้นตอนการทำงานเช่นนี้ยังคงรักษาขอบเขตสำคัญประการหนึ่งไว้ นั่นคือ AI เสนอการดำเนินการได้ แต่ยังต้องมีมนุษย์ตัดสินใจว่าจะนำการดำเนินการนั้นไปใช้กับฐานข้อมูลหรือไม่

อย่างไรก็ตาม ขอบเขตดังกล่าวกำลังเริ่มเลือนหายไปเมื่อมี AI แบบเอเจนต์ ทุกวันนี้ระบบ AI สามารถตรวจสอบสคีมา เรียกใช้คิวรี ตีความผลลัพธ์ และตัดสินใจได้ว่าจะดำเนินการอะไรต่อ จากผลสำรวจล่าสุด องค์กร 62% กำลังทดลองใช้เอเจนต์ AI อยู่แล้ว ขณะที่ 23% รายงานว่าได้นำระบบแบบเอเจนต์ไปใช้งานในวงกว้างในส่วนใดส่วนหนึ่งขององค์กร

ดังนั้น ทีมฐานข้อมูลจึงต้องตอบคำถามด้านสถาปัตยกรรมที่ค่อนข้างเร่งด่วน ไม่ใช่คำถามว่า AI เรียกใช้ SQL ได้หรือไม่ เพราะทำได้อยู่แล้ว คำถามที่แท้จริงคือ จะเกิดอะไรขึ้นเมื่อผู้ช่วยเลิกแนะนำโค้ดแล้วเริ่มดำเนินการกับฐานข้อมูลเอง และควรควบคุมความเป็นอิสระในการดำเนินการนั้นอย่างเข้มงวดเพียงใด

จากคำแนะนำสู่การลงมือทำ

การตัดสินใจง่าย ๆ เรื่องการทำดัชนีแสดงให้เห็นว่าเหตุใดการเปลี่ยนแปลงนี้จึงสำคัญ

เอเจนต์พบคิวรีที่ทำงานช้า ตรวจดูสคีมา พิจารณาว่าการเพิ่มดัชนีอาจช่วยได้ จึงสร้างดัชนีขึ้นมา เรียกใช้เวิร์กโหลดอีกครั้ง แล้วตรวจสอบผลลัพธ์

เอเจนต์อาจเรียกใช้คำสั่งทั่วไปอย่างเช่น:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

คำสั่งนี้ไม่มีอะไรผิดปกติ ผู้ช่วย AI ก็อาจแนะนำสิ่งเดียวกันได้ทุกประการ ความแตกต่างอยู่ที่ว่าใครเป็นผู้ตัดสินใจขั้นสุดท้าย

เมื่อใช้ผู้ช่วย นักพัฒนาจะตรวจสอบคำแนะนำ ทดสอบ แล้วตัดสินใจว่าจะเรียกใช้หรือไม่ AI ให้คำแนะนำ แต่มนุษย์เป็นผู้ลงมือทำ ส่วนเอเจนต์ที่มีสิทธิ์เรียกใช้คำสั่งสามารถตัดสินใจเองและดำเนินการต่อโดยไม่ต้องรอการอนุมัติ

หากการตัดสินใจนั้นถูกต้อง ขั้นตอนการทำงานก็จะรวดเร็วขึ้น แต่เอเจนต์ไม่ได้เห็นภาพรวมทั้งหมดเสมอไป เอเจนต์อาจมองข้ามการพึ่งพากันของแอปพลิเคชัน กฎทางธุรกิจ รูปแบบเวิร์กโหลด ช่วงเวลาบำรุงรักษา หรือบริบทอื่น ๆ ที่ผู้ดูแลระบบมองเห็นได้ชัดเจน

ดังนั้น เอเจนต์อาจตัดสินใจได้อย่างสมเหตุสมผลในเชิงเทคนิค แต่ก็ยังเป็นการตัดสินใจที่ไม่เหมาะกับสภาพแวดล้อมที่กำลังทำงานอยู่ เมื่อพิจารณาจากข้อจำกัดและข้อกำหนดเฉพาะของสภาพแวดล้อมนั้น

ความเสี่ยงจะยิ่งเพิ่มขึ้นเมื่อการดำเนินการเริ่มต่อเนื่องกันเป็นทอด ๆ การสืบค้นที่ไม่ดี SELECT อาจแค่ทำงานช้าเท่านั้น ส่วนคำสั่งที่ไม่ดี UPDATE อาจล็อกตารางขนาดใหญ่ทั้งตาราง หรือส่งผลต่อจำนวนแถวมากกว่าที่ตั้งใจไว้มาก ดัชนีที่ใช้กับคิวรีหนึ่งอาจไม่จำเป็น แต่กลับเพิ่มภาระให้คิวรีอื่น การเปลี่ยนสคีมาอาจทำให้สิ่งที่เอเจนต์ไม่รู้ว่าต้องพึ่งพาสคีมานั้นเสียหาย เพราะเอเจนต์อาจไม่มีบริบทการปฏิบัติงานทั้งหมด และไม่สามารถทดสอบกรณีใช้งานที่เป็นไปได้ทุกรูปแบบ

ดังนั้น ปัญหาไม่ใช่ว่าเอเจนต์ตัดสินใจเกี่ยวกับฐานข้อมูลได้ไม่ดี เพราะบ่อยครั้งเอเจนต์ก็ตัดสินใจได้ดี ปัญหาอยู่ที่ว่าเมื่ออนุญาตให้เอเจนต์ลงมือทำตามการตัดสินใจเหล่านั้นแล้ว ทีมจะต้องกำหนดให้ชัดเจนยิ่งขึ้นว่าเอเจนต์มีอำนาจได้แค่ไหน มองเห็นบริบทใดได้บ้าง และจุดใดที่มนุษย์ยังต้องเข้ามาแทรกแซง รวมถึงใครยังคงต้องรับผิดชอบต่อผลลัพธ์

Gartner คาดว่า โครงการ AI แบบเอเจนต์มากกว่า 40% จะถูกยกเลิกภายในสิ้นปี 2027 ส่วนหนึ่งเป็นเพราะการควบคุมความเสี่ยงไม่เพียงพอ สำหรับทีมฐานข้อมูล บทเรียนค่อนข้างตรงไปตรงมา คือควรกำหนดมาตรการควบคุมก่อนให้สิทธิ์เรียกใช้คำสั่ง ไม่ใช่ทำในภายหลัง

งานใดบ้างที่มอบหมายได้อย่างปลอดภัย

งานด้านฐานข้อมูลบางอย่างปลอดภัยกว่ามากเมื่อต้องมอบหมายให้เอเจนต์ทำ

การวิเคราะห์คิวรีเป็นตัวอย่างที่ดี เอเจนต์สามารถตรวจสอบสถิติคิวรี ดึงแผนการทำงาน ตรวจดูดัชนีและโครงสร้างตาราง แล้วเสนอแนวทางแก้ไขที่น่าจะได้ผล โดยไม่เปลี่ยนแปลงข้อมูลในระบบจริง

เอเจนต์อาจพบคิวรีที่สแกนตารางขนาดใหญ่ซ้ำ ๆ Orders ตาราง:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

จากนั้นเอเจนต์ก็อธิบายการสแกน เสนอดัชนี และสร้าง DDL ได้ โดยไม่จำเป็นต้องได้รับอนุญาตให้เรียกใช้ CREATE INDEX ก็มีประโยชน์ได้

หลักการเดียวกันนี้ใช้ได้กับงานต่าง ๆ เช่น:

• อธิบายแผนการทำงานของคิวรี;
• ระบุดัชนีที่ขาดหายไปหรือไม่จำเป็น;
• ระบุ SELECT * คิวรีหรือเงื่อนไขที่ไม่สามารถใช้ดัชนีค้นหาได้;
• ตรวจสอบการผลักการทำงานของการเชื่อมตารางและตัวกรองลงไปยังชั้นที่ต่ำกว่า;
• ตรวจสอบการพึ่งพากันและสคีมา;
• แก้ไขปัญหาข้อผิดพลาดของ SQL;
• ปรับสคริปต์ SQL ให้เหมาะสม

แนวทางแบ่งงานในทางปฏิบัตินั้นเรียบง่าย คือให้เอเจนต์เข้าถึงข้อมูลมากพอที่จะทำความเข้าใจปัญหา แต่อย่าให้สิทธิ์มากพอที่จะเปลี่ยนแปลงฐานข้อมูลโดยอัตโนมัติ การเปิดให้มองเห็นข้อมูลได้อย่างกว้างขวางอาจเป็นประโยชน์ แต่การให้สิทธิ์ดำเนินการอย่างกว้างขวางเป็นการตัดสินใจอีกเรื่องหนึ่ง

จุดที่การควบคุมโดยมนุษย์ยังคงสำคัญ

การตัดสินใจบางอย่างเกี่ยวกับฐานข้อมูลยังต้องมีมนุษย์เข้ามาร่วมพิจารณา สมมติว่าเอเจนต์พบ AuditLog ตารางที่มีข้อมูลหลายร้อยล้านแถว แล้วตัดสินใจว่าควรลบระเบียนเก่าออก:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

คำสั่ง SQL อาจถูกต้องทุกประการ แต่การตัดสินใจก็ยังอาจแย่อย่างยิ่งได้

บางทีนโยบายด้านกฎระเบียบอาจกำหนดให้เก็บรักษาข้อมูลไว้เป็นเวลาเจ็ดปี แอปพลิเคชันบางตัวอาจต้องอาศัยระเบียนเหล่านั้น การลบข้อมูลอาจต้องทำเป็นชุด ๆ เพื่อหลีกเลี่ยงการขยายตัวของบันทึกธุรกรรม หรืออาจต้องเก็บถาวรระเบียนก่อนนำออก

ข้อกำหนดเหล่านี้ไม่ได้มีอยู่ในสคีมาเสมอไป

นี่เป็นหนึ่งในข้อจำกัดของการมองงานฐานข้อมูลว่าเป็นปัญหาการสร้างโค้ด ฐานข้อมูลประกอบด้วยโครงสร้างทางเทคนิค แต่การตัดสินใจเกี่ยวกับโครงสร้างเหล่านั้นมักเป็นการตัดสินใจทางธุรกิจที่แสดงออกผ่านการดำเนินการทางเทคนิค ข้อควรระวังเดียวกันนี้ควรใช้กับการดำเนินการต่าง ๆ เช่น:

• DROP และการดำเนินการที่ทำลายข้อมูล ALTER คำสั่ง;
• ระบบจริง UPDATE และ DELETE การปฏิบัติงาน;
• การย้ายข้อมูลขนาดใหญ่;
• การเปลี่ยนแปลงบทบาทและสิทธิ์;
• การแก้ไขข้อจำกัด;
• การเปลี่ยนแปลงที่ส่งผลต่อการจำลองข้อมูลหรือความพร้อมใช้งาน;
• การปรับใช้โพรซีเยอร์ที่จัดเก็บไว้ซึ่งมีตรรกะทางธุรกิจ

การดำเนินการที่ถูกต้องในทางเทคนิคไม่ได้หมายความว่าจะเหมาะสมเสมอไป ดังนั้นจึงไม่ควรมองการอนุมัติจากมนุษย์ว่าเป็นข้อจำกัดที่น่ารำคาญของ AI แบบเอเจนต์ สำหรับการดำเนินการกับฐานข้อมูลที่มีผลกระทบสูง การอนุมัตินี้เป็นส่วนหนึ่งของสถาปัตยกรรม

เอเจนต์ AI ก็ต้องใช้สิทธิ์เท่าที่จำเป็นเช่นกัน

ทางลัดอย่างหนึ่งที่ทีมฐานข้อมูลควรหลีกเลี่ยงคือการปล่อยให้เอเจนต์ใช้ข้อมูลประจำตัวที่นักพัฒนามีอยู่แล้ว วิธีนี้ง่ายก็จริง แต่ทำให้เอเจนต์เข้าถึงทุกสิ่งที่นักพัฒนาคนนั้นเข้าถึงได้

แนวทางที่ปลอดภัยกว่าก็เหมือนกับที่ใช้กับผู้ใช้และบริการ นั่นคือให้สิทธิ์เท่าที่จำเป็น Microsoft แนะนำให้มอบเฉพาะสิทธิ์ที่จำเป็นต่องาน และติดตามตรวจสอบกิจกรรมที่ใช้สิทธิ์ระดับสูง

ตัวอย่างเช่น เอเจนต์วิเคราะห์ประสิทธิภาพอาจต้องใช้:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

แต่ก็น่าจะไม่จำเป็นต้องใช้:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

เอเจนต์แต่ละตัวอาจมีข้อมูลประจำตัวที่แตกต่างกันได้เช่นกัน เอเจนต์สำหรับจัดทำรายงานอาจได้รับ SELECT สิทธิ์เข้าถึงสคีมาเพียงไม่กี่ชุด เอเจนต์สำหรับย้ายข้อมูลอาจทำงานได้เฉพาะในสภาพแวดล้อมการพัฒนาหรือสภาพแวดล้อมทดสอบก่อนขึ้นระบบจริง ส่วนเอเจนต์ที่ทำงานในระบบจริงอาจได้รับสิทธิ์ที่กำหนดขอบเขตไว้อย่างเข้มงวด และยังต้องได้รับการอนุมัติก่อนจึงจะดำเนินการได้

OWASP แนะนำแนวทางพื้นฐานเดียวกันนี้สำหรับเอเจนต์ AI ได้แก่ แยกสิทธิ์อ่านและเขียน จำกัดเครื่องมือและทรัพยากร และกำหนดให้ต้องได้รับอนุญาตอย่างชัดแจ้งก่อนดำเนินการที่มีความอ่อนไหว

หลักการนั้นเรียบง่าย คือให้สิทธิ์แก่เอเจนต์เท่าที่งานของมันต้องใช้ ไม่ใช่ให้สิทธิ์เท่ากับบุคคลที่เริ่มใช้งานเอเจนต์

ให้มนุษย์เป็นส่วนหนึ่งของกระบวนการทำงาน

รูปแบบที่ดีกว่าสำหรับงานฐานข้อมูลแบบเอเจนต์คือกระบวนการทำงานที่มีการควบคุม:

สังเกต → วิเคราะห์ → เสนอแนวทาง → ตรวจทาน → ดำเนินการ → ตรวจสอบความถูกต้อง → บันทึก

สมมติว่าเอเจนต์กำลังตรวจสอบจุดเชื่อมต่อ API ที่ทำงานช้า เอเจนต์ค้นหา SQL ที่อยู่เบื้องหลัง ตรวจสอบแผนการประมวลผลและสถิติของตาราง พบว่ามีแนวโน้มว่าขาดดัชนี และจัดเตรียมสคริปต์การย้ายข้อมูล

จากนั้นจึงเรียกใช้สคริปต์ในสภาพแวดล้อมทดสอบก่อนขึ้นระบบจริงได้ เอเจนต์เรียกใช้เวิร์กโหลดซ้ำ ตรวจสอบผลลัพธ์ และเตรียมการเปลี่ยนแปลงสำหรับระบบจริง

จากนั้นเอเจนต์ก็หยุด

นักพัฒนาหรือผู้ดูแลระบบฐานข้อมูลจะตรวจทานการย้ายข้อมูล ตรวจสอบการพึ่งพาและผลกระทบทางธุรกิจ แล้วอนุมัติก่อนที่จะนำสิ่งใดขึ้นสู่ระบบจริง

เอเจนต์ยังคงจัดการงานซ้ำ ๆ ได้อีกมาก แต่ความรับผิดชอบขั้นสุดท้ายต่อการเปลี่ยนแปลงที่มีผลกระทบสูงยังคงเป็นของมนุษย์

การควบคุมธุรกรรมช่วยเพิ่มความปลอดภัยได้อีกชั้นหนึ่ง ตัวอย่างเช่น จุดบันทึกใน PostgreSQL ช่วยให้ย้อนกลับธุรกรรมเพียงบางส่วนได้โดยไม่ต้องยกเลิกทุกอย่างที่ดำเนินการมาก่อนหน้านั้น วิธีนี้อาจช่วยได้เมื่อต้องดำเนินการเปลี่ยนแปลงอัตโนมัติที่มีความเกี่ยวเนื่องกันอย่างใกล้ชิด แต่การย้อนกลับไม่อาจใช้แทนการกำหนดสิทธิ์และการอนุมัติที่เหมาะสมได้

เครื่องมืออย่าง dbForge AI Assistant ก็เหมาะกับขั้นตอนนี้เช่นกัน โดยสามารถใช้บริบทของสคีมาเพื่อสร้างและอธิบาย SQL แก้ไขปัญหาข้อผิดพลาด เปรียบเทียบ DDL ตรวจหาดัชนีที่ไม่มีประสิทธิภาพ และจัดเตรียมสคริปต์เพื่อเพิ่มประสิทธิภาพ ทั้งยังแสดง SQL ที่ได้ให้นักพัฒนาตรวจทานได้

เป้าหมายคือทำให้งานประจำเป็นระบบอัตโนมัติ ขณะเดียวกันก็ให้มนุษย์เป็นผู้ตัดสินใจเรื่องสำคัญ

เป้าหมายที่แท้จริงคือการให้อิสระภายใต้การควบคุม

AI แบบเอเจนต์ไม่ได้หมายความว่าต้องเลือกระหว่าง “AI แค่เสนอคำแนะนำ” กับ “AI จัดการฐานข้อมูลเอง” เพราะยังมีทางเลือกอีกมากระหว่างสองขั้วนี้

ทีมต่าง ๆ เริ่มต้นจากงานที่มีความเสี่ยงต่ำกว่าได้ เช่น การอธิบาย SQL การตรวจทานสคีมา และการตรวจสอบแบบอ่านอย่างเดียว จากนั้นจึงค่อย ๆ มอบหมายงานเพิ่มเติมให้เอเจนต์ในสภาพแวดล้อมการพัฒนาและสภาพแวดล้อมทดสอบก่อนขึ้นระบบจริง

ควรให้สิทธิ์เขียนในภายหลังอีกมาก และต้องกำหนดขอบเขตให้ชัดเจนในเรื่องจำนวนแถวที่ได้รับผลกระทบ ธุรกรรม การย้อนกลับ การติดตามตรวจสอบ และการอนุมัติ การเปลี่ยนแปลงในระบบจริงแบบอัตโนมัติเต็มรูปแบบควรเกิดขึ้นไม่บ่อย

แนวทางนี้ยังคล้ายกับคำแนะนำของ Deloitte ด้วย กล่าวคือ เริ่มจากเวิร์กโฟลว์ที่มีความเสี่ยงต่ำกว่าและข้อมูลที่ไม่สำคัญ ให้คนที่เกี่ยวข้องรับทราบและมีส่วนร่วมอยู่เสมอ และเสริมสร้างการกำกับดูแลเมื่อเอเจนต์มีความสามารถมากขึ้น

เป้าหมายไม่ใช่การให้อิสระอย่างเต็มที่ แต่คือการให้เอเจนต์มีอิสระมากพอที่จะช่วยงานได้ โดยไม่ให้สิทธิ์เข้าถึงเกินกว่าที่จำเป็น

ข้อสรุป: การพัฒนาฐานข้อมูลยังต้องอาศัยวิจารณญาณ

เอเจนต์ AI ช่วยลดงานซ้ำซากในการวิศวกรรมฐานข้อมูลได้มาก โดยสามารถตรวจดูเวิร์กโหลด ตรวจสอบคิวรี เชื่อมโยงสคีมา แผนการทำงาน ข้อผิดพลาด และข้อมูลประสิทธิภาพ แล้วดำเนินการตามสิ่งที่พบ

แต่เมื่อระบบ AI สามารถเปลี่ยนแปลงสถานะของฐานข้อมูลได้ โจทย์ก็เปลี่ยนไป ทีมต่าง ๆ จำเป็นต้องมีกฎเกณฑ์ที่ชัดเจนเกี่ยวกับตัวตน สิทธิ์การเข้าถึง ขอบเขตของธุรกรรม การอนุมัติ การติดตามตรวจสอบ การย้อนกลับ และบันทึกการตรวจสอบ

นั่นจึงเป็นเหตุผลที่ว่า ในบรรดาองค์กร 88% ที่ใช้ AI ในปี 2025 มีเพียง 7% เท่านั้นที่ระบุว่าได้นำ AI ไปใช้งานเต็มรูปแบบทั่วทั้งองค์กรแล้ว โจทย์ที่ยากกว่าคือการทำให้ AI เชื่อถือได้มากพอที่จะปฏิบัติงานในวงกว้าง

การพัฒนาฐานข้อมูลก็กำลังมุ่งไปในทิศทางเดียวกัน เอเจนต์ที่มีประโยชน์ที่สุดไม่ใช่เอเจนต์ที่ได้รับอนุญาตให้ทำสิ่งต่าง ๆ ได้มากที่สุด แต่เป็นเอเจนต์ที่มีขอบเขตอำนาจชัดเจนและควบคุมได้

คำถามไม่ใช่อีกต่อไปว่า AI สามารถดำเนินงานเกี่ยวกับฐานข้อมูลได้หรือไม่ แต่เป็นคำถามว่าเราควรไว้วางใจให้ AI ดำเนินงานใด และภายใต้ข้อจำกัดแบบใด