AI Agent với database là chuyện chạy được thật, không phải trình diễn. Anh em gõ một câu tiếng Việt, nó trả về đúng con số trong database của công ty. Tôi có demo trong video bên dưới. Nhưng phần lớn người thử xong đều bảo nó không chính xác. Bài này đi vào bốn chặng bên trong, chỉ đúng hai chỗ nó hay hỏng, và cách chữa nằm ở chỗ ít ai để ý: mô tả đặt ngay trong database chứ không nhồi vào prompt.
Video gốc dài 25 phút. Bài viết này bổ sung thêm phần bài kiểm chuẩn quốc tế cho việc dịch câu hỏi ra SQL, cú pháp mô tả copy dùng được luôn cho SQL Server, PostgreSQL và Oracle, cùng bảng so sánh hai kiểu đặt AI.
Bài này có gì mà video chưa có?
Video là bản nói. Bài này là bản chép lại có kèm thứ mang về dùng được. Cụ thể:
- Bốn chặng bên trong, gọi đúng tên từng chặng theo sơ đồ trong video.
- Hai chỗ hỏng, và cách nhận ra mình đang hỏng ở chỗ nào.
- Con số từ một bài kiểm chuẩn quốc tế cho thấy vì sao mô tả lại quan trọng đến vậy.
- Ba khối lệnh copy được: thêm mô tả cho SQL Server, mẫu mô tả chia đầu mục, và cú pháp Annotations của Oracle.
- Một bảng so sánh AI đặt ngoài tool với AI đặt trong lõi database.
Vì sao chỉ chat với AI thì không tạo ra lợi thế?
Vì cái anh em gõ vào ô chat thì ai cũng gõ được, còn thứ tạo ra lợi thế lại nằm trong nhà anh em. Nó nằm ở tri thức của anh em, nằm ở quy trình của doanh nghiệp, và nằm ở dữ liệu nội bộ.
Tôi nói thẳng. Một ông trợ lý AI chỉ biết chat thì nó cũng chỉ giỏi ngang cái nó học được từ internet. Nó không biết bảng nhân viên của anh em có bao nhiêu cột. Nó không biết cột type bằng 0 nghĩa là nam hay nữ. Muốn nó làm ra tiền thì phải cho nó chọc vào đúng đống dữ liệu của mình.
Và đây là chỗ nhiều anh em rén. Nghe tới database là nghĩ ngay tới việc phải biết viết câu lệnh, biết viết function, biết viết thủ tục. Rào cản đó có thật, nhưng nó vừa hạ xuống rất nhiều lần. Tôi có chia sẻ cách một đội ngũ AI Agent chạy việc thật trong bài AI Agent vận hành doanh nghiệp. Bài này đi sâu đúng một mảnh trong đó, là mảnh dữ liệu.
Không biết SQL thì hỏi được dữ liệu không?
Được. Anh em gõ tiếng Việt, hệ thống tự dịch ra câu lệnh, tự chạy, tự trả bảng kết quả kèm nhận xét. Tôi demo trên một database SQL Server chứa dữ liệu của mạng hỏi đáp Stack Overflow, nơi người dùng đăng bài rồi up vote hoặc down vote cho nhau.
Trước đây phải làm việc này thế nào?
Phải mở đúng bảng, biết đúng tên cột, rồi gõ câu lệnh bằng tay.
Đây là kinh điển. SQL là ngôn ngữ chuẩn duy nhất để nói chuyện với database, loại database nào cũng vậy. Ai từng làm nghề đều phải học nó.
Bây giờ gõ tiếng Việt vào thì sao?
Nó tự tìm bảng, tự nối bảng, tự lọc, tự sắp xếp. Anh em không cần biết select cái gì, join bảng nào, lọc where ra sao.
Tôi gõ đúng một câu tiếng Việt vào khung chat nằm ngay trong công cụ quản trị database. Nó chạy một bước tên là đọc dữ liệu, rồi trả về bảng xếp hạng.
Anh em để ý chỗ này nhá. Tôi không hề bảo nó lấy điểm danh vọng, cũng không bảo nó lấy vị trí. Nó tự thêm vào, vì nó hiểu ngôn ngữ tự nhiên nên nó phán đoán được thứ tôi sẽ hỏi tiếp. Hỏi câu sau kiểu người này đã đăng bao nhiêu bài, nó cũng tự đi tìm bảng bài đăng rồi trả về con số.
Bản chất là gì? Bản chất là cái rào cản kỹ thuật đã tụt xuống. Trước đây phải có người biết nghề mới hỏi được dữ liệu. Bây giờ người hiểu nghiệp vụ là hỏi được.
Chính hãng database có làm chuyện này không?
Có. Và họ còn đưa thẳng vào cú pháp SQL luôn. Trên Oracle Autonomous Database, anh em thêm hai chữ select ai rồi viết câu hỏi bằng tiếng người, database tự lo phần còn lại.
Bốn biến thể đó nằm trong tài liệu chính thức, chép về chạy được ngay:
SQL> select ai how many customers exist;
CUSTOMER_COUNT
--------------
55500
SQL> select ai showsql how many customers exist;
RESPONSE
------------------------------------------------
SELECT COUNT(*) AS total_customers
FROM SH.CUSTOMERS
SQL> select ai narrate how many customers exist;
RESPONSE
------------------------------------------------
There are a total of 55,500 customers in the database.
SQL> select ai chat how many customers exist;Cái đáng chú ý không phải cú pháp. Cái đáng chú ý là ai đang làm việc này. Database là tầng gần như cuối cùng để lưu dữ liệu của anh em, những thông tin quan trọng nhất nằm hết ở đấy. Chính các hãng database đang kéo AI lại gần tầng đó. Nghĩa là cách doanh nghiệp mình vận hành sẽ đổi, đổi nhiều.
AI Agent đi qua mấy chặng để đẻ ra một câu SQL?
Bốn chặng, tính từ lúc anh em bấm gửi cho tới lúc câu lệnh chạy thật. Hiểu bốn chặng này thì sau đó nó sai ở đâu anh em chỉ mặt được ngay.
| Khối trên sơ đồ | Nó làm gì | Hỏng ở đây thì biểu hiện ra sao |
|---|---|---|
| User Question | Câu hỏi thuần tiếng Việt của anh em | Hỏi mơ hồ, nó tự đoán ý rồi đi sai hướng |
| Copilot Model | Bộ điều phối, quyết định có đi đọc dữ liệu hay không | Nó trả lời chay, không hề chạm vào database |
| Selected Schema | Khoanh vùng từ vài trăm bảng còn vài bảng liên quan | Vớ nhầm bảng, con số ra vô lý mà vẫn trông có vẻ đúng |
| LLM | Bộ não, hiểu ngữ nghĩa rồi chuyển thành câu lệnh | Câu lệnh chạy được nhưng không đúng thứ anh em hỏi |
| SQL Query | Câu lệnh thật chạy trong database | Chạy chậm, khoá bảng, tốn tài nguyên |
Chặng khoanh vùng là chặng quan trọng nhất mà ít người để ý. Hình dung thế này. Hệ thống của anh em có vài trăm bảng. Câu hỏi của tôi là tìm bài đăng của một người dùng. Vậy nó chỉ cần bảng user và bảng post thôi. Bảng up vote không quan trọng, bảng thanh toán không quan trọng. Nó khoanh lại còn hai bảng, rồi mới gửi phần mô tả của hai bảng đó cho bộ não.
Vì sao phải khoanh? Vì bộ não nào cũng có sức chứa. Nhồi cả trăm bảng vào thì nó quên, mà lại tốn tiền.
Nó sai ở chỗ nào?
Sai ở hai chỗ, cả hai đều nằm trước khi câu lệnh được sinh ra. Ngoài kia rất nhiều người bảo nó không chính xác. Không chính xác tức là câu query sai. Mà câu query sai thì phải đi ngược lại, tìm ở đằng trước nó.
Chỗ sai thứ nhất, nó khoanh vùng sai
Nó chọn nhầm bảng. Anh em có bảng tên là NV, nó không biết NV là nhân viên hay là nhà vợ. Có cột tên L_name, nó không biết đó là last name. Chọn nhầm bảng thì bộ não phía sau có xịn tới đâu cũng chịu, vì nó chỉ được nhìn thấy đúng thứ đã bị khoanh sai.
Đây không phải chuyện lý thuyết. Bài kiểm chuẩn quốc tế cho việc dịch câu hỏi ra SQL tên là BIRD, gồm 12.751 cặp câu hỏi và câu lệnh trên 95 database thật, tổng 33,4 GB, trải 37 lĩnh vực nghề. Nhóm làm bài kiểm này chỉ ra rằng nhóm lỗi lớn nhất chính là chọn nhầm bảng nhầm cột và hiểu sai nội dung dữ liệu. Đúng chặng khoanh vùng.
Chỗ sai thứ hai, chọn nhầm bộ não
Bộ não nằm bên dưới là thứ anh em tự chọn được. Trong demo tôi chọn Claude Sonnet 4.5. Chọn bộ não khác thì nó khác nhau ở hai thứ: khác về tiền, và khác về lượng ngữ cảnh cùng khả năng suy luận nó gánh được.
Có mô hình trả lời rất nhanh mà không chính xác. Có mô hình chậm hơn nhưng suy luận sâu. Việc của anh em là chọn đúng mô hình cho đúng độ khó của câu hỏi. Câu hỏi đếm một con số thì đừng phí tiền gọi mô hình suy luận sâu. Câu hỏi nối năm bảng kèm điều kiện chồng nhau thì đừng tiếc.
Tôi có phân tích kỹ chuyện chọn và điều phối mô hình trong bài Dynamic Workflow trên Opus 4.8, và chuyện năng lực từng đời mô hình đổi ra sao trong bài Claude Fable 5 và ba thay đổi cho doanh nghiệp.
Con số của bài kiểm BIRD nói thêm một điều đáng suy nghĩ. Người thật, gồm kỹ sư dữ liệu và sinh viên ngành database, đạt 92,96%. Hệ thống tốt nhất trên bảng xếp hạng tính tới giữa năm 2026 đạt 81,95%. Bản GPT-4 gốc hồi 2023 chỉ 54,89%. Nghĩa là kể cả bộ não xịn nhất thì vẫn còn khoảng cách hơn mười điểm phần trăm so với người biết nghề. Đừng giao cho nó một câu hỏi rồi tin luôn kết quả.
Vì sao nó không hiểu bảng NV là bảng nhân viên?
Vì nó chưa bao giờ được học database của anh em. Đây là chỗ nhiều người hiểu nhầm nhất, nên tôi nói cho kỹ.
Các bộ não này được huấn luyện từ blog, từ YouTube, từ đủ thứ nội dung trên internet. Không ông nào có dữ liệu bên trong database của anh em cả. Không ông nào biết NV nghĩa là gì, không ông nào biết cột type bằng 1 là nữ.
Vậy nếu chúng ta cứ vứt một cái database trần trụi vào rồi bảo mày cứ lấy thông tin đi, đương nhiên nó không làm được. Nó phải mường tượng. Mà mường tượng thì nhập nhằng, mà nhập nhằng thì chọn sai.
Ngược lại, cho nó hiểu tường tận từng bảng từng cột thì nó ra quyết định chính xác hơn hẳn. Lúc đó nó có khác gì một nhân viên có năng lực, hiểu được thiết kế database đâu.
Nhồi hết mô tả vào prompt có được không?
Được, nhưng tệ. Anh em hoàn toàn có thể mô tả bằng mồm toàn bộ database ngay trong câu prompt hoặc trong system instruction. Database của tôi có bảng tên là nhân viên, bảng đó có các cột này cột kia, cột này giá trị gì. Viết ra được hết.
Nhưng nó tệ vì ba lý do, cái nào cũng đau.
- Prompt dài thòng lòng. Nhiều bảng, nhiều cột, nhiều mô tả thì đoạn đầu vào phình ra không kiểm soát được.
- Dài thì nó quên. Bộ não chỉ chứa được một lượng token nhất định. Vượt cái đó thì nó quên đoạn trước. Viết càng dài lại càng dở, chưa chắc đã tốt hơn.
- Dài thì tốn tiền. Các mô hình tính tiền theo tổng số token gửi lên. Gửi càng dài càng tốn. Chuyện tiền token này tôi có chia sẻ nguyên cách tính và cách siết trong bài Tối ưu chi phí token khi cho AI vận hành kênh YouTube.
Đấy. Ba cái giá đó trả mãi không hết. Vậy có cách nào khác không?
Đặt mô tả ở đâu cho đúng?
Đặt ngay trong chính database. Anh em đã cắm nó vào database rồi, vậy tại sao lại đi mô tả ở chỗ khác?
Mọi database đều có sẵn chỗ để ghi mô tả cho bảng và cho cột. Mặc định chỗ đó rỗng. Tôi chạy một câu lệnh kiểm tra và nó hiện ra đúng như vậy.
Nhìn bảng kết quả là hiểu ngay. Cột nào để NULL thì bộ não phải tự mường tượng. Cột nào đã có mô tả thì nó đọc thẳng.
Cách thêm mô tả, ba loại database hay gặp nhất:
[1] SQL Server, dùng extended property tên MS_Description
EXEC sp_addextendedproperty
@name = N'MS_Description',
@value = N'Bang luu thong tin nguoi dung. Moi dong la mot tai khoan.',
@level0type = N'SCHEMA', @level0name = N'dbo',
@level1type = N'TABLE', @level1name = N'Users';
EXEC sp_addextendedproperty
@name = N'MS_Description',
@value = N'So lan nguoi dung nay da thuc hien UpVote cho bai cua nguoi khac.',
@level0type = N'SCHEMA', @level0name = N'dbo',
@level1type = N'TABLE', @level1name = N'Users',
@level2type = N'COLUMN', @level2name = N'UpVotes';
[2] PostgreSQL
COMMENT ON TABLE public.users IS 'Bang luu thong tin nguoi dung.';
COMMENT ON COLUMN public.users.upvotes IS 'So lan nguoi dung da up vote.';
[3] Oracle
COMMENT ON TABLE hr.employees IS 'Bang nhan su. Moi dong la mot nhan vien.';
COMMENT ON COLUMN hr.employees.hire_date IS 'Ngay vao lam chinh thuc.';Càng mô tả chi tiết thì nó càng hiểu dữ liệu của anh em. Mà quan trọng hơn: mô tả nằm trong database thì mọi công cụ cắm vào đều đọc được, không phải chép lại vào từng prompt.
Tôi ví dụ một cột tên là type. Nó không hiểu type là gì đâu. Anh em ghi rõ vào: 0 nghĩa là nam, 1 nghĩa là nữ. Sau này ai hỏi tìm những người là nam giới thì nó mới biết đường mà lọc. Không ghi thì nó lấy gì mà hiểu.
Làm sao tốt hơn một dòng mô tả?
Chia mô tả thành các đầu mục có cấu trúc, thay vì một dòng chữ chạy dài. Tôi nói thật với anh em là hoàn toàn có cách làm tốt hơn, và suy ra được từ nguyên lý chứ không phải mẹo.
Nếu mô tả chỉ là một dòng text dài dài dài, thì máy phải đọc hết cả dòng rồi mới hiểu cột này nghĩa gì. Nhưng nếu chia thành đầu mục thì khác hẳn.
Có đầu mục thì làm được thêm một việc mà một dòng text không làm được: lọc. Tôi bảo nó hãy lọc ra những bảng có độ bảo mật tuyệt đối trong database của tôi, nó vào phần ghi chú và tìm ra hết. Tức là anh em đánh ghi chú theo quy tắc để sau này máy tìm theo quy tắc đó.
Mẫu tôi hay dùng, chép về sửa lại theo nhà mình:
Mo ta: Bang luu thong tin nguoi dung, moi dong la mot tai khoan.
Muc do quan trong: Rat cao
Bao mat: Tuyet doi, khong duoc dua ra ngoai
Nghiep vu so huu: Van hanh
Khoa noi: Users.Id noi sang Posts.OwnerUserId
Luu y: Tai khoan he thong ten Community khong phai nguoi that, loai ra khi thong keSáu dòng đó dán vào ô mô tả của bảng. Bộ não đọc được, mà con người mở ra cũng đọc được. Dòng cuối là dòng đắt nhất: nó chặn đúng loại lỗi mà nhìn số không phát hiện ra.
Và tiên phong ở việc này thì có hãng đã làm sẵn cho chúng ta rồi. Họ viết luôn cú pháp cho mình dùng. Oracle từ bản 23ai có tính năng tên là Annotations, cho phép gắn cặp tên và giá trị thẳng vào bảng và vào cột ngay lúc tạo:
CREATE TABLE employees (
id NUMBER(5) PRIMARY KEY
ANNOTATIONS (Identity, Display 'Ma nhan vien'),
ename VARCHAR2(50)
ANNOTATIONS (Display 'Ten nhan vien'),
salary NUMBER
ANNOTATIONS (Display 'Luong', Confidential)
) ANNOTATIONS (Display 'Bang nhan su');
ALTER TABLE employees ANNOTATIONS (ADD Department 'HR');Đọc lại danh sách đó bằng các view USER_ANNOTATIONS và USER_ANNOTATIONS_USAGE. Anh em thấy chưa, đúng cái tư tưởng đầu mục ở trên, nhưng hãng đã chuẩn hoá thành cú pháp.
Oracle đưa AI vào lõi database nghĩa là gì?
Nghĩa là chính database tự suy luận, chứ không phải một công cụ bên ngoài suy luận hộ rồi bắn câu lệnh vào. Đây là khác biệt lớn nhất, và tôi phải nói rõ vì nhìn bên ngoài hai thứ này giống hệt nhau.
Bản thân tôi làm trong lĩnh vực này lâu năm, hỗ trợ database cho nhiều doanh nghiệp và công ty chứng khoán lớn, nên tôi hiểu dòng đó nặng cỡ nào. Trước đây database khá bảo thủ. Nó chỉ chứa dữ liệu thôi, đơn thuần chứa dữ liệu.
| Chỗ đặt AI | Ai dịch câu hỏi ra câu lệnh | Dịch sai thì chuyện gì xảy ra | Ví dụ trong video |
|---|---|---|---|
| Ngoài, ở tầng công cụ | Công cụ gọi mô hình, nhận câu lệnh rồi bắn vào database | Nó dừng. Không tìm được thì thôi, người phải hỏi lại | Khung chat trong công cụ quản trị SQL Server |
| Trong lõi database | Chính database nhận câu hỏi và tự chuyển thành câu lệnh | Có đường suy luận lại ngay bên trong để tìm câu trả lời đúng | Select AI của Oracle |
Cái khung chat trong công cụ quản trị mà tôi demo, nói cho đúng thì nó vẫn hơi giả cầy. AI của nó là AI đi qua một cái tool. Chúng ta gửi yêu cầu qua giao diện, giao diện phân tích rồi gửi câu lệnh vào database. Lõi database không khác gì trước kia.
Còn Oracle thì họ đưa AI vào trong lõi. Theo công bố chính thức, Oracle AI Database 26ai là bản kế tiếp thay cho 23ai, ra cùng đợt cập nhật tháng 10 năm 2025, và khách hàng cài được cả trên máy chủ tại chỗ chứ không bắt buộc lên cloud của họ. Bản này gắn thêm tìm kiếm vector, Model Context Protocol, và các framework agentic AI ngay trong database.
Và đây là điều đáng để anh em suy ra. Một hãng ra thứ gì đó thì các hãng khác sẽ chạy theo, sớm hay muộn. Giống hồi ChatGPT ra đời rồi cả loạt hãng khác ra theo. Nên đừng bám vào tool, đừng bám vào cái vỏ bên ngoài. Bám vào nguyên lý.
Gói cả quy trình vào một bảng thì trông thế nào?
| Chặng | Việc phải làm | Làm ở đâu | Dấu hiệu đã xong |
|---|---|---|---|
| 1. Chọn phạm vi | Chọn ra 5 tới 10 bảng hay bị hỏi nhất, đừng ôm cả database | Trên giấy, cùng người hiểu nghiệp vụ | Có danh sách bảng kèm tên người chịu trách nhiệm |
| 2. Viết mô tả bảng | Mỗi bảng một câu, nói rõ một dòng trong bảng là cái gì | Trong database, bằng lệnh ở mục trên | Chạy câu kiểm tra, không còn bảng nào để NULL |
| 3. Viết mô tả cột | Ưu tiên cột viết tắt, cột mã số, cột ngày | Trong database | Cột nào có mã số đều ghi rõ từng giá trị nghĩa là gì |
| 4. Thêm đầu mục | Mức độ quan trọng, bảo mật, khoá nối, lưu ý | Trong database, theo mẫu sáu dòng | Lọc thử theo đầu mục bảo mật, ra đúng danh sách |
| 5. Chọn bộ não | Câu dễ dùng mô hình rẻ, câu khó dùng mô hình suy luận | Trong phần cấu hình của công cụ | Cùng một câu hỏi, hai mô hình cho cùng một kết quả |
| 6. Nghiệm thu | Ra 20 câu hỏi có đáp án biết trước, chạy rồi đối chiếu | Bộ câu hỏi để riêng, chạy lại mỗi lần đổi mô tả | Tỉ lệ đúng đo được bằng số, không đoán |
Bước 6 là bước hay bị bỏ nhất. Không có bộ câu hỏi có đáp án biết trước thì anh em không bao giờ biết mô tả mình vừa thêm là làm nó tốt lên hay tệ đi.
Giới hạn thật, chỗ nào nó vẫn chưa làm được?
Nói cho sòng phẳng. Tôi liệt kê đúng những chỗ tôi đã vấp.
Nó viết được câu lệnh chạy được, không có nghĩa là câu lệnh ngon. Câu lệnh nó sinh ra hay quét nhiều hơn cần thiết. Bài kiểm BIRD có hẳn một thang điểm riêng phạt câu lệnh đúng mà chậm. Muốn biết câu lệnh của nó có ngon không thì phải mở kế hoạch thực thi ra xem, tôi có chia sẻ cách đọc trong bài Tối ưu MySQL với EXPLAIN và EXPLAIN ANALYZE.
Cùng một câu hỏi, hôm nay nhanh mai chậm. Chuyện này không phải lỗi của AI, nó là bản tính của database. Tôi có phân tích nguyên nhân trong bài Câu lệnh SQL lúc nhanh lúc chậm.
Có index rồi mà vẫn chậm. Nhiều anh em nghĩ cứ tạo index là xong. Không phải. Xem Vì sao có index mà SQL vẫn chậm. Còn nếu chưa biết bắt đầu từ đâu thì đọc Tối ưu SQL nên bắt đầu từ đâu trước.
Mô tả sai còn nguy hơn không có mô tả. Không có mô tả thì nó mường tượng và hay trả lời lệch, người nhìn ra ngay. Mô tả sai thì nó tự tin trả lời sai, mà số trông vẫn hợp lý. Nên mô tả phải do người hiểu nghiệp vụ duyệt, đừng để một mình kỹ thuật viết.
Nó không hiểu quy tắc ngầm trong nhà anh em. Kiểu đơn hàng trạng thái 9 là đơn test, không tính doanh thu. Cái đó không nằm trong dữ liệu, nó nằm trong đầu người làm lâu năm. Không ghi vào mô tả thì không ông AI nào đoán ra.
Bảy ngày tới anh em làm được gì?
Đây là việc làm được ngay, không cần xin ngân sách, không cần đổi hệ thống.
- Ngày 1. Chọn đúng một bảng hay bị hỏi nhất. Một thôi.
- Ngày 2. Chạy câu kiểm tra mô tả ở mục trên, đếm xem bao nhiêu cột đang để NULL.
- Ngày 3. Ngồi với người hiểu nghiệp vụ của bảng đó, viết mô tả cho bảng và cho từng cột.
- Ngày 4. Thêm mô tả vào database bằng lệnh đã có sẵn ở trên.
- Ngày 5. Viết 20 câu hỏi tiếng Việt mà anh em biết trước đáp án đúng.
- Ngày 6. Cắm công cụ vào, chạy 20 câu, đếm số câu đúng.
- Ngày 7. Câu nào sai thì lần ngược lại: nó khoanh nhầm bảng, hay nó hiểu nhầm cột. Sửa mô tả rồi chạy lại đúng 20 câu đó.
Cứ làm đi. Sai lại sửa. Một bảng chạy ngon rồi thì nhân sang bảng thứ hai nhanh hơn nhiều.
Câu hỏi hay gặp
Không biết SQL thì có làm được không?
Được. Anh em gõ câu hỏi bằng tiếng Việt, hệ thống lo phần câu lệnh. Nhưng phần mô tả bảng và cột thì phải có người hiểu nghiệp vụ ngồi cùng, vì đó mới là thứ quyết định nó đúng hay sai. Đây là việc của người hiểu nghề, không phải việc của người biết gõ lệnh.
Mô tả nên viết tiếng Việt hay tiếng Anh?
Viết bằng thứ tiếng mà người dùng sẽ hỏi. Người trong công ty hỏi bằng tiếng Việt thì mô tả tiếng Việt, để nghĩa khớp thẳng. Riêng tên nghiệp vụ nội bộ thì ghi cả hai cách gọi trong cùng một dòng mô tả, vì mỗi phòng ban gọi một kiểu.
Database của tôi có 300 bảng, có phải mô tả hết không?
Không. Đừng ôm hết, ôm hết là bỏ giữa chừng. Bắt đầu từ nhóm bảng bị hỏi nhiều nhất, thường chỉ khoảng 5 tới 10 bảng đã gánh phần lớn câu hỏi. Mô tả xong nhóm đó, đo tỉ lệ đúng, rồi mở rộng dần.
Có sợ nó xoá dữ liệu không?
Cách chặn nằm ở quyền, không nằm ở lời dặn. Tạo một tài khoản riêng cho AI Agent, chỉ cấp quyền đọc, chỉ cho nhìn đúng các bảng đã chọn. Đừng cấp tài khoản quản trị rồi dặn nó đừng xoá. Dặn không phải là cơ chế.
Database không phải SQL thì có làm được không?
Có, nhưng cơ chế khác. Chỗ ghi mô tả và cách khoanh vùng ở mỗi loại một khác, nên đừng bê nguyên cách làm của SQL Server sang. Với MongoDB thì còn thêm chuyện kiến trúc lưu trữ, tôi có phân tích trong bài MongoDB lúc nhanh lúc chậm.
Câu lệnh nó sinh ra chạy chậm thì sửa ở đâu?
Sửa ở phía database, không sửa ở phía AI. Phần lớn ca chậm là do thiếu index hoặc index đặt sai thứ tự cột. Thứ tự cột trong index quan trọng hơn nhiều người nghĩ, tôi có chia sẻ trong bài Tầm quan trọng của thứ tự các cột trong index PostgreSQL.
Đúc kết
Rào cản công nghệ đã hạ xuống thật. Trước đây phải biết viết câu lệnh mới hỏi được dữ liệu, bây giờ hỏi bằng tiếng Việt là ra.
Nhưng thứ quyết định nó đúng hay sai không nằm ở mô hình. Nó nằm ở chỗ anh em có chịu ngồi mô tả dữ liệu của mình hay không. Mô tả đặt trong database, chia thành đầu mục, do người hiểu nghiệp vụ duyệt. Đấy là toàn bộ phần khó, mà cũng là toàn bộ phần tạo ra lợi thế.
Và một câu cuối. Đừng bám vào tool. Hãng nào ra tool xịn thì hãng khác cũng ra theo trong vài tháng. Hiểu nguyên lý thì đổi tool nào anh em cũng dựng lại được hệ thống của mình.
Cứ làm đi, sai lại sửa. Nếu anh em cùng góc nhìn này và muốn đi sâu hơn thì liên hệ với tôi. Tùy anh em.
Nguồn tham khảo
- Oracle, trang công bố chính thức Oracle AI Database 26ai: oracle.com
- Oracle, tài liệu Examples of Using Select AI: docs.oracle.com
- Oracle, tài liệu Schema Annotations trên Database 23ai: docs.oracle.com
- BIRD, bài kiểm chuẩn cho việc dịch câu hỏi ra SQL và bảng xếp hạng: bird-bench.github.io
- Bài báo gốc của BIRD trên arXiv, mã 2305.03111: arxiv.org
- Microsoft, tài liệu sp_addextendedproperty: learn.microsoft.com
- PostgreSQL, tài liệu lệnh COMMENT: postgresql.org
