Lãnh đạo tư tưởng
AI tác nhân trong phát triển cơ sở dữ liệu: Điều gì thay đổi khi AI thực sự có thể thực thi truy vấn
Thêm Unite.AI vào các nguồn ưu tiên của bạn trên Google
Trong vài năm qua, quy trình phát triển cơ sở dữ liệu có AI hỗ trợ vẫn khá dễ kiểm soát. Nhà phát triển mô tả yêu cầu. AI tạo câu lệnh SQL. Nhà phát triển đọc, sửa những chỗ có vẻ chưa ổn rồi quyết định có chạy câu lệnh đó hay không.
Quy trình ấy vẫn giữ nguyên một ranh giới quan trọng: AI có thể đề xuất hành động, nhưng con người vẫn quyết định có đưa hành động đó vào cơ sở dữ liệu hay không.
Tuy nhiên, ranh giới đó đang dần biến mất khi AI tác nhân xuất hiện. Ngày nay, các hệ thống AI có thể kiểm tra lược đồ, chạy truy vấn, diễn giải kết quả và quyết định bước tiếp theo cần thực hiện. Theo một khảo sát gần đây, 62% tổ chức đã thử nghiệm các tác nhân AI, trong khi 23% cho biết họ đang mở rộng quy mô một hệ thống AI tác nhân ở đâu đó trong doanh nghiệp.
Vì vậy, các nhóm cơ sở dữ liệu cần sớm trả lời một câu hỏi về kiến trúc hệ thống. Không phải là AI có thể thực thi SQL hay không. AI làm được điều đó. Câu hỏi thực sự là điều gì thay đổi khi một trợ lý không còn chỉ đề xuất mã mà bắt đầu thao tác trực tiếp trên cơ sở dữ liệu, và cần kiểm soát quyền tự chủ đó chặt chẽ đến mức nào.
Từ đề xuất đến hành động
Một quyết định đơn giản về lập chỉ mục cho thấy vì sao sự chuyển đổi này lại quan trọng.
Tác nhân phát hiện một truy vấn chậm, tra cứu lược đồ, nhận ra rằng có thể cần thêm chỉ mục, tạo chỉ mục đó, chạy lại khối lượng công việc rồi kiểm tra kết quả.
Nó có thể thực thi một câu lệnh thông thường như sau:
CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);Câu lệnh đó không có gì khác thường. Một trợ lý AI cũng có thể đề xuất chính xác câu lệnh ấy. Khác biệt nằm ở người đưa ra quyết định cuối cùng.
Khi dùng trợ lý, nhà phát triển xem xét đề xuất, kiểm thử rồi quyết định có chạy hay không. AI đưa ra lời khuyên, nhưng con người hành động. Còn với một tác nhân có quyền thực thi, hệ thống có thể tự đưa ra quyết định và tiếp tục mà không cần chờ phê duyệt.
Nếu quyết định đó đúng, quy trình sẽ nhanh hơn. Nhưng tác nhân không phải lúc nào cũng nắm được toàn cảnh. Chúng có thể bỏ sót các phụ thuộc của ứng dụng, quy tắc kinh doanh, mô hình khối lượng công việc, khung thời gian bảo trì hoặc những thông tin khác mà người vận hành hệ thống đã biết rõ.
Vì vậy, một tác nhân có thể đưa ra quyết định trông hợp lý về mặt kỹ thuật nhưng vẫn không phù hợp với môi trường mà nó đang thao tác, xét theo những ràng buộc và yêu cầu cụ thể của môi trường đó.
Rủi ro tăng lên khi các hành động bắt đầu nối tiếp nhau. Một truy vấn tệ SELECT có thể chỉ chạy chậm. Một truy vấn tệ UPDATE có thể khóa cả một bảng lớn hoặc ảnh hưởng đến số hàng nhiều hơn dự kiến rất nhiều. Chỉ mục được dùng cho một truy vấn có thể không cần thiết nhưng lại làm tăng chi phí xử lý của các truy vấn khác. Thay đổi lược đồ có thể làm hỏng một thành phần nào đó mà tác nhân không biết là phụ thuộc vào lược đồ ấy, vì tác nhân có thể không nắm đầy đủ bối cảnh vận hành và không thể kiểm thử mọi trường hợp sử dụng có thể xảy ra.
Vấn đề không phải là tác nhân không thể đưa ra quyết định đúng đắn về cơ sở dữ liệu. Chúng thường làm được. Vấn đề là khi được phép hành động dựa trên những quyết định đó, các nhóm cần xác định rõ hơn phạm vi quyền hạn của tác nhân, thông tin mà tác nhân có thể xem, những thời điểm con người vẫn cần can thiệp, cũng như ai là người chịu trách nhiệm về kết quả.
Gartner dự đoán hơn 40% dự án AI tác nhân sẽ bị hủy trước cuối năm 2027, một phần do các biện pháp kiểm soát rủi ro chưa đầy đủ. Bài học dành cho các nhóm cơ sở dữ liệu khá đơn giản: chỉ cấp quyền thực thi sau khi đã thiết lập các biện pháp kiểm soát, chứ không phải trước.
Có thể giao phó những gì một cách an toàn?
Một số tác vụ cơ sở dữ liệu an toàn hơn nhiều khi giao cho tác nhân so với những tác vụ khác.
Phân tích truy vấn là một ví dụ điển hình. Tác nhân có thể kiểm tra số liệu thống kê truy vấn, lấy kế hoạch thực thi, kiểm tra chỉ mục và cấu trúc bảng, rồi đề xuất các cách khắc phục có khả năng hiệu quả mà không thay đổi dữ liệu trong môi trường sản xuất.
Tác nhân có thể phát hiện một truy vấn như thế này liên tục quét một bảng lớn Orders bảng:
SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;Từ đó, tác nhân có thể giải thích việc quét, đề xuất một chỉ mục và tạo câu lệnh DDL. Để hữu ích, tác nhân không cần được cấp quyền chạy CREATE INDEX để có thể hữu ích.
Điều tương tự cũng áp dụng cho các tác vụ như:
- Mô tả kế hoạch thực thi;
- Xác định các chỉ mục còn thiếu hoặc không cần thiết;
- Cảnh báo về
SELECT *các truy vấn hoặc vị từ không thể tận dụng chỉ mục; - Rà soát việc đẩy phép nối và bộ lọc xuống các bước xử lý bên dưới;
- Rà soát các phụ thuộc và lược đồ;
- Khắc phục sự cố lỗi SQL;
- Tối ưu hóa tập lệnh SQL.
Cách phân chia thực tế rất đơn giản: cấp cho tác nhân đủ quyền truy cập để hiểu vấn đề, nhưng không mặc nhiên cấp đủ quyền để thay đổi cơ sở dữ liệu. Khả năng quan sát rộng có thể hữu ích, nhưng cấp quyền thực thi rộng là một quyết định khác.
Khi nào con người vẫn cần kiểm soát
Một số quyết định về cơ sở dữ liệu vẫn cần có sự tham gia của con người. Giả sử tác nhân phát hiện một AuditLog bảng có hàng trăm triệu hàng và quyết định xóa các bản ghi cũ:
DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());Câu lệnh SQL có thể hoàn toàn hợp lệ nhưng quyết định đó vẫn có thể hết sức tồi tệ.
Có thể chính sách quản lý yêu cầu lưu giữ dữ liệu trong bảy năm. Có thể một ứng dụng phụ thuộc vào những bản ghi đó. Có thể cần xóa theo từng đợt để tránh làm tăng dung lượng nhật ký giao dịch. Cũng có thể phải lưu trữ bản ghi trước khi xóa.
Những yêu cầu đó không nhất thiết phải được thể hiện trong lược đồ.
Đây là một trong những hạn chế của cách xem công việc với cơ sở dữ liệu như một bài toán sinh mã. Cơ sở dữ liệu có các cấu trúc kỹ thuật, nhưng những quyết định liên quan thường là quyết định kinh doanh được thể hiện thông qua các thao tác kỹ thuật. Cũng cần thận trọng tương tự với những thao tác như:
DROPvà có tính phá hủyALTERcâu lệnh;- môi trường sản xuất
UPDATEvàDELETEcác thao tác; - các đợt di chuyển dữ liệu quy mô lớn;
- thay đổi vai trò và quyền;
- điều chỉnh ràng buộc;
- thay đổi ảnh hưởng đến hoạt động sao chép hoặc tính sẵn sàng;
- triển khai các thủ tục lưu trữ có chứa logic nghiệp vụ.
Một hành động đúng về mặt kỹ thuật không nhất thiết là hành động phù hợp. Vì vậy, không nên xem việc con người phê duyệt là một hạn chế bất tiện đối với AI có khả năng tự hành động. Với các thao tác cơ sở dữ liệu có tác động lớn, đây là một phần của kiến trúc.
Tác nhân AI cũng cần tuân thủ nguyên tắc quyền tối thiểu
Một lối tắt mà các nhóm cơ sở dữ liệu nên tránh là để tác nhân sử dụng thông tin xác thực sẵn có của nhà phát triển. Cách này dễ thực hiện, nhưng cũng cấp cho tác nhân mọi quyền truy cập mà nhà phát triển đó đang có.
Cách an toàn hơn cũng giống như cách áp dụng cho người dùng và dịch vụ: chỉ cấp quyền tối thiểu cần thiết. Microsoft khuyến nghị chỉ cấp những quyền cần cho nhiệm vụ và theo dõi hoạt động sử dụng quyền đặc biệt.
Chẳng hạn, một tác nhân phân tích hiệu năng có thể cần:
CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITIONCó lẽ tác nhân đó không cần:
ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadminCác tác nhân khác nhau cũng có thể có danh tính riêng. Một tác nhân lập báo cáo có thể được cấp SELECT quyền truy cập vào một vài lược đồ. Một tác nhân di chuyển dữ liệu có thể chỉ hoạt động trong môi trường phát triển hoặc thử nghiệm. Một tác nhân dùng trong môi trường sản xuất có thể được cấp quyền với phạm vi giới hạn chặt chẽ, đồng thời vẫn phải được phê duyệt trước khi thực thi.
OWASP khuyến nghị áp dụng cùng một mô hình cơ bản cho tác nhân AI: tách biệt quyền đọc và ghi, giới hạn công cụ và tài nguyên, đồng thời yêu cầu cấp phép rõ ràng đối với các hành động nhạy cảm.
Quy tắc rất đơn giản: hãy cấp cho tác nhân những quyền cần thiết để thực hiện nhiệm vụ, chứ không phải những quyền của người khởi chạy nó.
Đưa con người vào quy trình làm việc
Một mô hình tốt hơn cho công việc với cơ sở dữ liệu có tác nhân AI là quy trình được kiểm soát:
Quan sát → Phân tích → Đề xuất → Rà soát → Thực thi → Xác thực → Ghi nhận
Giả sử một tác nhân đang điều tra một điểm cuối API phản hồi chậm. Tác nhân tìm câu lệnh SQL đứng sau điểm cuối đó, kiểm tra kế hoạch thực thi và số liệu thống kê của bảng, phát hiện khả năng thiếu chỉ mục, rồi chuẩn bị tập lệnh di chuyển dữ liệu.
Trước tiên, tập lệnh có thể chạy trong môi trường thử nghiệm. Tác nhân chạy lại khối lượng công việc, kiểm tra kết quả và chuẩn bị thay đổi để đưa vào môi trường sản xuất.
Sau đó, tác nhân dừng lại.
Nhà phát triển hoặc quản trị viên cơ sở dữ liệu rà soát đợt di chuyển, kiểm tra các phần phụ thuộc và tác động đến hoạt động kinh doanh, rồi phê duyệt trước khi bất kỳ thay đổi nào được đưa vào môi trường sản xuất.
Tác nhân vẫn có thể đảm nhận nhiều công việc lặp đi lặp lại. Điều vẫn thuộc về con người là trách nhiệm cuối cùng đối với một thay đổi có tác động lớn.
Các cơ chế kiểm soát giao dịch có thể bổ sung một lớp an toàn nữa. Chẳng hạn, các điểm lưu trong giao dịch của PostgreSQL cho phép hoàn tác một phần giao dịch mà không phải loại bỏ toàn bộ những gì đã thực hiện trước đó. Cách này có thể hữu ích với các thay đổi tự động có phạm vi gắn kết chặt chẽ, nhưng việc hoàn tác không thể thay thế cho quyền hạn và quy trình phê duyệt phù hợp.
Đây cũng là trường hợp các công cụ như dbForge AI Assistant phát huy tác dụng tự nhiên. Công cụ này có thể sử dụng ngữ cảnh lược đồ để tạo và giải thích SQL, khắc phục lỗi, so sánh DDL, phát hiện chỉ mục kém hiệu quả và chuẩn bị tập lệnh tối ưu hóa, đồng thời vẫn hiển thị câu lệnh SQL để nhà phát triển rà soát.
Mục tiêu là tự động hóa các công việc thường nhật, đồng thời để những quyết định quan trọng cho con người.
Mục tiêu thực sự là quyền tự chủ có kiểm soát
AI có khả năng tự hành động không nhất thiết đồng nghĩa với việc phải chọn giữa “AI chỉ đưa ra đề xuất” và “AI vận hành cơ sở dữ liệu”. Còn rất nhiều phương án ở giữa.
Các nhóm có thể bắt đầu với những nhiệm vụ ít rủi ro hơn, chẳng hạn như giải thích SQL, rà soát lược đồ và thực hiện kiểm tra chỉ đọc. Sau đó, họ có thể từng bước giao cho tác nhân đảm nhận thêm công việc trong môi trường phát triển và thử nghiệm.
Chỉ nên cấp quyền ghi ở giai đoạn muộn hơn nhiều, với các giới hạn rõ ràng về số hàng bị ảnh hưởng, giao dịch, hoàn tác, giám sát và phê duyệt. Những thay đổi hoàn toàn tự động trong môi trường sản xuất nên hiếm khi xảy ra.
Điều đó cũng tương tự với hướng dẫn của Deloitte: bắt đầu bằng các quy trình ít rủi ro hơn và dữ liệu không trọng yếu, duy trì sự tham gia của mọi người và tăng cường quản trị khi các tác nhân được giao thêm việc.
Mục tiêu không phải là quyền tự chủ tuyệt đối. Đó là trao cho tác nhân đủ tự do để hỗ trợ, nhưng không cấp quyền truy cập vượt quá nhu cầu của nó.
Điểm mấu chốt: Phát triển cơ sở dữ liệu vẫn cần đến sự đánh giá sáng suốt
Các tác nhân AI có thể giúp giảm đáng kể khối lượng công việc lặp đi lặp lại trong kỹ thuật cơ sở dữ liệu. Chúng có thể quan sát khối lượng công việc, kiểm tra truy vấn, đối chiếu lược đồ, kế hoạch thực thi, lỗi và dữ liệu hiệu năng, rồi hành động dựa trên những gì chúng nhận thấy.
Nhưng một khi hệ thống AI có thể thay đổi trạng thái của cơ sở dữ liệu, vấn đề sẽ khác đi. Các nhóm cần có quy tắc rõ ràng về danh tính, quyền hạn, ranh giới giao dịch, phê duyệt, khả năng quan sát, khôi phục về trạng thái trước đó và nhật ký kiểm toán.
Đó là lý do vì sao trong số 88% tổ chức sử dụng AI vào năm 2025, chỉ 7% cho biết AI đã được triển khai đầy đủ trên toàn tổ chức. Thách thức lớn hơn là khiến AI đủ đáng tin cậy để vận hành trên quy mô lớn.
Phát triển cơ sở dữ liệu cũng đang đi theo hướng tương tự. Tác nhân hữu ích nhất không phải là tác nhân được phép làm nhiều việc nhất, mà là tác nhân có thẩm quyền được xác định và kiểm soát rõ ràng.
Câu hỏi giờ đây không còn là liệu AI có thể thực hiện các tác vụ cơ sở dữ liệu hay không, mà là chúng ta nên tin tưởng giao cho AI thực hiện những tác vụ nào và trong những giới hạn nào.
