Khám phá bộ sưu tập các dataset Text-to-SQL công khai chất lượng cao, từ Spider đến NL2SQL-Bugs và OmniSQL. Hướng dẫn chi tiết cho nhà phát triển AI nghiên cứu và xây dựng mô hình chuyển đổi ngôn ngữ tự nhiên sang SQL.

Lê Lân

10/07/2025

À lôi, các bạn coder ơi! Bạn có bao giờ ước có một 'người phiên dịch' siêu đẳng giúp bạn biến mấy câu hỏi tiếng Việt bình thường thành những câu lệnh SQL 'chất lừ' mà không cần nhớ cú pháp không? Vài tháng trước, tôi đã 'khai sinh' ra <a href="https://genql.neetigya.me/">GenQL</a>, một công cụ thần kỳ làm được điều đó! GenQL không chỉ đơn thuần là dịch đâu nhé, nó còn 'hiểu' được cả cấu trúc database của bạn để đưa ra kết quả chính xác nhất nữa cơ. Hôm nay, tôi sẽ 'bật mí' cho các bạn bí kíp đằng sau GenQL: đó chính là một 'ma thuật' tên là **RAG - Retrieval-Augmented Generation**! Nghe tên có vẻ khoa học viễn tưởng nhỉ? Đừng lo, nó đơn giản là việc kết hợp mấy anh AI 'biết tuốt' (Large Language Models - LLMs) với kho tàng kiến thức bên ngoài của riêng bạn. Giống như bạn có một bộ não siêu việt, nhưng lại còn có thêm cả một thư viện khổng lồ luôn sẵn sàng tra cứu vậy! Trong dự án GenQL, tôi đã triển khai hệ thống RAG này bằng Python, dùng Firebase Functions làm 'người giúp việc tự động', OpenAI để 'phiên dịch' thành 'ngôn ngữ máy', và Pinecone làm 'thư viện đặc biệt' để lưu trữ thông tin. Hệ thống này có 3 'cánh cổng' chính: 1. Cánh cổng 'Ghi Nhớ' (Indexing Data): Biến cấu trúc database thành 'mã số bí mật' để AI hiểu. 2. Cánh cổng 'Tìm Kiếm' (Searching): Tìm kiếm thông tin liên quan đến câu hỏi của bạn. 3. Cánh cổng 'Dọn Dẹp' (Deleting Namespaces): Xóa bỏ những gì không cần thiết nữa. Nào, chúng ta hãy cùng 'giải phẫu' từng 'cánh cổng' một nhé! *** ### 1. Cánh Cổng "Ghi Nhớ": Biến Cấu Trúc Database Thành "Mã Số Bí Mật" (Indexing Data: Turning Your Schema into Searchable Vectors) **Cốt lõi vấn đề:** Bạn muốn AI hiểu database của mình? Đầu tiên, phải 'dạy' cho nó đã! Giống như bạn muốn tìm sách trong thư viện, bạn phải có danh mục sách và cách sắp xếp chúng chứ, đúng không? Ở đây, chúng ta sẽ biến thông tin database (như tên bảng, tên cột, mô tả) thành một dạng mà máy tính có thể 'hiểu' và 'so sánh' được. Dạng này gọi là **embeddings** – về cơ bản là những 'mã số bí mật' (hay vector số học) đại diện cho ý nghĩa của văn bản gốc. Sau đó, những 'mã số bí mật' này sẽ được cất giữ cẩn thận trong một 'thư viện đặc biệt' gọi là **vector database**. **Thực hiện thế nào?** * **Mô tả dữ liệu của bạn:** Tưởng tượng bạn đang viết một bản tóm tắt cực kỳ chi tiết cho mỗi bảng trong database của mình. Ví dụ: "Bảng `orders` chứa thông tin về các đơn hàng, bao gồm `order_id` (mã đơn hàng), `customer_id` (mã khách hàng), `order_date` (ngày đặt hàng), và `total_amount` (tổng tiền)." * **Tạo 'mã số bí mật' (embeddings):** Chúng ta sẽ nhờ "ông bạn" OpenAI 'dịch' những bản mô tả này thành chuỗi số dài dằng dặc. Mỗi chuỗi số này chính là một `embedding`, mang ý nghĩa của bản mô tả đó. * **Lưu vào 'thư viện đặc biệt' (vector database):** Các `embedding` này sẽ được lưu trữ vào Pinecone – 'thư viện' chuyên dụng cho các vector. Chúng ta sẽ 'dán nhãn' cho mỗi nhóm `embedding` bằng một **namespace** (tưởng tượng như một 'ngăn kéo' riêng biệt cho từng dự án hay từng người dùng vậy). **Code giả lập (cho dễ hình dung):** ```python # Pseudocode for indexing for each item in your_data: description = summarize(item) embedding = get_embedding(description) vector_db.upsert(id=item.id, vector=embedding, metadata=description, namespace=your_namespace) ``` **Tại sao phải làm vậy?** Bởi vì cách này giúp AI tìm kiếm thông tin dựa trên **ý nghĩa** của câu hỏi, chứ không phải chỉ dựa vào mấy từ khóa khô khan đâu! Hay ho chưa? <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/L1MhR2Q.png' alt='Biến dữ liệu thành vector embedding và lưu vào vector database'> *** ### 2. Cánh Cổng "Tìm Kiếm": Truy Lùng Dữ Liệu Liên Quan Bằng Câu Hỏi Thông Minh (Searching: Finding Relevant Data with Semantic Queries) **Cốt lõi vấn đề:** Khi người dùng hỏi một câu (ví dụ: "Cho tôi biết thông tin khách hàng"), bạn muốn tìm ngay lập tức những phần dữ liệu trong database có liên quan nhất đến câu hỏi đó. Làm sao để máy tính hiểu được "khách hàng" và tìm đúng bảng "customers" hay "users" đây? Đơn giản thôi, chúng ta lại dùng 'mã số bí mật' (embeddings)! **Thực hiện thế nào?** * **'Phiên dịch' câu hỏi:** Đầu tiên, câu hỏi của người dùng ("thông tin khách hàng") sẽ được "ông bạn" OpenAI 'dịch' thành một 'mã số bí mật' (embedding) y chang như cách chúng ta đã làm với cấu trúc database ở bước 1. * **'Truy lùng' trong 'thư viện đặc biệt':** Bây giờ, chúng ta sẽ đưa cái 'mã số bí mật' của câu hỏi này cho Pinecone và nhờ nó "rà soát" cả 'thư viện' để tìm những 'mã số bí mật' của database nào *giống* với nó nhất. Giống như bạn đưa một mảnh ghép hình và bảo thư viện tìm những mảnh ghép khớp vậy đó! * **Trả về kết quả:** Pinecone sẽ nhanh chóng tìm ra những 'ngăn kéo' chứa thông tin database phù hợp nhất (ví dụ: bảng `customers`, `users`) và trả về cho chúng ta. **Code giả lập:** ```python # Pseudocode for searching query_embedding = get_embedding(user_query) results = vector_db.query(vector=query_embedding, top_k=5, namespace=your_namespace) return results ``` **Tại sao phải làm vậy?** Nhờ cách này, người dùng có thể hỏi bằng ngôn ngữ tự nhiên mà vẫn nhận được câu trả lời *đúng ý*, ngay cả khi không dùng từ khóa chính xác. Cực kỳ thông minh và linh hoạt! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/G5p1fW1.png' alt='Tìm kiếm vector gần nhất trong vector database'> *** ### 3. Cánh Cổng "Dọn Dẹp": Xóa Sổ Ngăn Kéo Không Dùng Đến (Deleting a Namespace: Cleaning Up) **Cốt lõi vấn đề:** Đôi khi bạn cần 'dọn dẹp' kho dữ liệu của mình. Ví dụ, khi một dự án kết thúc hoặc bạn không muốn lưu trữ schema của một database cụ thể nữa. Thay vì xóa từng mảnh nhỏ, bạn có thể xóa toàn bộ 'ngăn kéo' đó! **Thực hiện thế nào?** Vì mỗi nhóm `embedding` của database được 'dán nhãn' bằng một **namespace** riêng, chúng ta chỉ cần gọi lệnh 'xóa' cho cái `namespace` đó là tất cả dữ liệu liên quan sẽ 'bay màu' khỏi 'thư viện đặc biệt' của bạn. Đơn giản, gọn gàng, nhanh chóng! **Code giả lập:** ```python # Pseudocode for deleting a namespace vector_db.delete(namespace=your_namespace) ``` <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/9C3B4Z1.png' alt='Xóa namespace trong vector database'> *** ### "Người Giúp Việc" Tự Động: Firebase Functions trong Python Toàn bộ các 'cánh cổng' thần kỳ này đều được triển khai dưới dạng **serverless functions** (hay nôm na là 'người giúp việc tự động' trên đám mây) bằng Firebase. Điều này giúp GenQL dễ dàng 'lớn mạnh' (scale) và kết nối với các dịch vụ khác mà không cần bạn phải lo lắng về việc quản lý máy chủ. Cứ gọi là chạy thôi! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/w9N4H0Z.png' alt='Firebase Functions giúp triển khai các API của RAG'> *** ### Lời Kết: Sức Mạnh Của RAG Trong Tay Bạn! Thấy chưa? Bằng cách 'ghi nhớ' dữ liệu của bạn dưới dạng 'mã số bí mật' (embeddings), 'tìm kiếm' thông tin bằng các câu hỏi thông minh, và 'dọn dẹp' các 'ngăn kéo' khi cần, bạn đã có thể xây dựng một hệ thống RAG siêu mạnh mẽ! Hệ thống này giúp kết nối sức mạnh của các anh AI 'biết tuốt' với kho dữ liệu riêng của bạn, mở ra vô vàn ứng dụng 'bá đạo' khác – từ tạo tài liệu database tự động cho đến quản lý kiến thức. Bạn có thể "ngó nghiêng" mã nguồn của GenQL tại GitHub repo này nhé: <a href="https://github.com/neetigyachahar/GenQL">https://github.com/neetigyachahar/GenQL</a> Chúc các bạn "hack" vui vẻ! 🚀

Lê Lân

09/07/2025

Tìm hiểu về Retrieval-Augmented Generation (RAG) qua ví dụ thực tế với GenQL. Hướng dẫn chi tiết cách index, tìm kiếm và quản lý dữ liệu bằng embeddings, vector database và LLM để xây dựng hệ thống AI thông minh.

Lê Lân

04/07/2025

Tìm hiểu cách xây dựng một Query Builder tùy chỉnh cho SQLite bằng TypeScript để nâng cao chất lượng code và làm việc hiệu quả hơn với database, từ kinh nghiệm thực tế khi phát triển ứng dụng từ điển tiếng Ả Rập.

Lê Lân

01/07/2025

Khám phá bí quyết tăng tốc truy vấn SQL bằng cách đọc và phân tích kế hoạch thực thi của database. Tìm hiểu về EXPLAIN, SHOW PLAN, tối ưu hóa dựa trên chi phí, và sự khác biệt giữa Index Seek và Index Scan để cải thiện hiệu năng SQL của bạn.

Lê Lân

27/06/2025

Tìm hiểu cách PostgreSQL Table Partitioning giúp bạn quản lý và tăng tốc các cơ sở dữ liệu lớn một cách hiệu quả. Khám phá các loại phân vùng, cách triển khai và những lợi ích vượt trội để tối ưu hiệu suất.

Lê Lân

24/06/2025

Khám phá báo cáo đánh giá khả năng tạo SQL của 19 mô hình LLM phổ biến trên bộ dữ liệu 200 triệu dòng GitHub. Xem điểm hiệu suất, độ chính xác và so sánh với con người.

Lê Lân

24/06/2025

Khám phá Snowflake Copilot Inline – tính năng AI đột phá tích hợp trực tiếp vào Snowflake Workspaces, giúp bạn viết, tối ưu SQL và sửa lỗi cực nhanh, biến bạn thành 'phù thủy' dữ liệu chỉ trong tích tắc. Đừng bỏ lỡ công cụ thay đổi cuộc chơi này!

Lê Lân

22/06/2025

Khám phá Copilot tích hợp trong SQL Server Management Studio 21 (SSMS 21). Tìm hiểu cách AI giúp tăng tốc độ viết SQL, chuyển ngôn ngữ tự nhiên thành truy vấn, giải thích code phức tạp và hỗ trợ gỡ lỗi, nâng tầm năng suất cho mọi chuyên gia dữ liệu.

Lê Lân

19/06/2025

Khám phá cách kết hợp SQL và AI (watsonx.ai) để truy vấn Elasticsearch dễ dàng mà không cần Query DSL phức tạp, giúp sếp và đồng nghiệp không rành kỹ thuật cũng có thể tự hỏi đáp dữ liệu.

Lê Lân

19/06/2025

Chào bạn! Bạn có tò mò làm thế nào mà các mô hình AI hiện nay lại có thể "thông minh" đến mức hiểu và thậm chí tự tạo ra các câu lệnh SQL phức tạp không? Bí mật nằm ở "thức ăn" của chúng đấy: những bộ dữ liệu chất lượng cao! Giống như một vận động viên cần chế độ dinh dưỡng đặc biệt, các mô hình AI cũng cần "nạp" những bộ dữ liệu chuẩn mực để được huấn luyện (training) và đánh giá (evaluation) một cách hiệu quả nhất cho từng "bài toán" cụ thể.Để bạn không phải "lạc lối" giữa "mê cung" thông tin, chúng mình đã dốc hết tâm huyết tổng hợp một danh sách "siêu to khổng lồ" các bộ dữ liệu Text2SQL công khai, đáng chú ý nhất trong vài năm trở lại đây. Mục tiêu ư? Đơn giản là giúp các nhà phát triển AI dễ dàng tiếp cận và "xài" chúng hiệu quả nhất!Trong danh sách này, chúng mình sẽ sắp xếp các bài báo và địa chỉ bộ dữ liệu theo trình tự thời gian, từ cũ đến mới. Bạn sẽ gặp gỡ những "ngôi sao" của làng Text2SQL, đặc biệt là các bộ dữ liệu chuyên dùng để "kiểm tra sức mạnh" mô hình như Spider hay BIRD-SQL. À, còn có cả "bonus" bảng xếp hạng (leaderboard) liên quan nữa nhé!Đặc biệt, ngay sau đây, chúng mình sẽ "khui hộp" chi tiết hơn về những bộ dữ liệu "nóng hổi" nhất vừa chào sân trong năm 2025 này. Và yên tâm đi, tụi mình sẽ luôn "túc trực" để cập nhật những thông tin mới nhất đến bạn!Này bạn! Bạn đã bao giờ "ngứa mắt" với những câu lệnh SQL do AI tạo ra, nhìn thì tưởng đúng mà chạy lại ra kết quả... sai bét nhè chưa? Đó chính là lúc "ác quỷ" mang tên lỗi ngữ nghĩa (semantic errors) tung hoành đấy! Và đây là lúc chúng ta cần chào đón NL2SQL-BUGs – bộ dữ liệu "tiên phong" trong việc "vạch mặt" những lỗi khó chịu này khi AI cố gắng biến ngôn ngữ tự nhiên của chúng ta thành SQL (NL2SQL). Mục tiêu chính của em nó là giải quyết vấn đề nan giải: các câu truy vấn SQL do mô hình hiện tại tạo ra vẫn chứa lỗi ngữ nghĩa mà hệ thống cứ "ngó lơ", không hề nhận ra!Để "tóm gọn" hết lũ lỗi này, với sự góp sức của các chuyên gia, NL2SQL-BUGs đã xây dựng một hệ thống phân loại lỗi "tỉ mỉ" đến từng chân tơ kẽ tóc, với hai cấp độ chi tiết (bao gồm 9 danh mục chính và 31 danh mục phụ). Nó chứa đến 2.018 trường hợp đã được "đánh dấu" lỗi rõ ràng. Kết quả thử nghiệm "phũ phàng" cho thấy, ngay cả những mô hình AI "lão làng" nhất hiện tại cũng chỉ đạt độ chính xác phát hiện lỗi trung bình có 75.16% thôi! "Tuyệt vời" hơn nữa, NL2SQL-BUGs còn giúp chúng ta "khui" ra thành công 122 lỗi chú thích hiện có trong các "ông lớn" benchmark như BIRD và Spider! Nhờ có bộ dữ liệu này, chúng ta giờ đây đã có một "công cụ kiểm tra chất lượng" cực kỳ quan trọng để phát hiện và "sửa sai" cho các hệ thống NL2SQL. Quá đã luôn phải không nào?<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9pie2xh0u5ubxeo9r296.png' alt='Minh họa cơ chế phát hiện lỗi ngữ nghĩa trong NL2SQL-Bugs'>Nếu bạn đang "đau đầu" tìm kiếm một "kho dữ liệu" Text2SQL "khổng lồ" để "nuôi nấng" mô hình AI của mình, thì xin chúc mừng, bạn đã tìm thấy "chân ái" rồi đấy! Đó chính là OmniSQL và bộ dữ liệu SynSQL-2.5M! "Em nó" được mệnh danh là bộ dữ liệu tổng hợp (synthetic dataset) Text2SQL đa lĩnh vực lớn nhất tính đến thời điểm hiện tại.Cứ tưởng tượng mà xem, SynSQL-2.5M được tạo ra hoàn toàn bằng công nghệ dữ liệu tổng hợp "đỉnh cao", không cần đến việc thu thập thủ công "cực nhọc"! Nó chứa đến 2.5 triệu mẫu chất lượng "chuẩn không cần chỉnh", bao phủ 16.583 cơ sở dữ liệu và vô số cấu trúc cú pháp SQL "phong phú" đa dạng. Điều tuyệt vời là bộ dữ liệu này được tạo ra dựa trên các mô hình ngôn ngữ lớn mã nguồn mở và quan trọng hơn hết, nó được phát hành theo giấy phép Apache 2.0 "rộng rãi", cho phép bạn tha hồ "ngâm cứu" và sử dụng để huấn luyện mô hình "cá nhân" của mình. À, bật mí thêm là nhóm phát triển còn "chiêu đãi" chúng ta cả dòng mô hình OmniSQL (7B/14B/32B) nữa đó! Quá tuyệt vời để bắt đầu khám phá phải không?<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c2jc8ri5n3ep59v4nspz.png' alt='Sơ đồ cấu trúc OmniSQL và SynSQL-2.5M'>Này bạn, có bao giờ bạn "ngẩn ngơ" tự hỏi: "Làm sao mà mấy con AI "siêu phàm" kia lại có thể biến câu hỏi tiếng Việt/Anh của mình thành một câu SQL "khó nhằn" vậy nhỉ?" hay "Liệu có cách nào để 'mổ xẻ' xem nó suy nghĩ thế nào không ta?". Nếu bạn đang "xoắn não" với những câu hỏi đó, thì TINYSQL chính là "cứu cánh" dành cho bạn!TinySQL được tạo ra để giải quyết một vấn đề "đau đầu" của các nhà nghiên cứu: các bộ dữ liệu SQL hiện tại quá phức tạp, khiến việc tìm hiểu sâu về khả năng giải thích (interpretability) cơ chế hoạt động của mô hình trở nên "bất khả thi". Nhưng với TinySQL, mọi thứ lại khác! Bằng cách "kiểm soát" độ phức tạp của các lệnh SQL và các biến thể ngôn ngữ, TinySQL cung cấp các "bài tập" truy vấn từ cơ bản đến "nâng cao dần". Điều này giúp các nhà nghiên cứu dễ dàng "mổ xẻ" hành vi của mô hình, "thấu hiểu" cách các kiến trúc Transformer học và tạo ra truy vấn SQL, đồng thời "kiểm chứng" độ tin cậy của các phương pháp giải thích. Tóm lại, TINYSQL là một "vũ khí" cực kỳ lợi hại để phân tích cơ chế mô hình, kiểm chứng công nghệ giải thích và thậm chí là cải tiến thiết kế bộ dữ liệu tổng hợp! Quá tiện lợi cho dân nghiên cứu phải không?<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9cssntszzpsknwy3yiql.png' alt='Mức độ phức tạp tăng dần trong TinySQL'>Giờ thì, hãy cùng "ngụp lặn" vào danh sách các bộ dữ liệu Text2SQL "siêu khủng" mà chúng tôi đã cất công tổng hợp nhé!🆕 Các Bộ Dữ Liệu Mới Nhất (2025)<ul><li><strong>TINYSQL</strong> [<a href="https://arxiv.org/html/2503.12730">Bài báo</a>][<a href="https://huggingface.co/collections/withmartian/tinysql-6760e92748b63fa56a6ffc9f">Bộ dữ liệu</a>]<br/>*Thời gian:* 03/2025<br/>*Mô tả:* TinySQL là một bộ dữ liệu Text2SQL được cấu trúc tỉ mỉ, giúp bạn nghiên cứu khả năng giải thích (interpretability) của mô hình. Nó "bắc cầu" một cách khéo léo giữa các ví dụ "đơn giản" và các tác vụ thực tế phức tạp, nhưng lại với độ phức tạp có thể kiểm soát được.</li><li><strong>NL2SQL-Bugs</strong> [<a href="https://arxiv.org/pdf/2503.11984">Bài báo</a>][<a href="https://github.com/HKUSTDial/NL2SQL-Bugs-Benchmark">Bộ dữ liệu</a>]<br/>*Thời gian:* 03/2025<br/>*Mô tả:* NL2SQL-BUGs là bộ dữ liệu benchmark chuyên dụng để phát hiện và phân loại các lỗi ngữ nghĩa trong quá trình chuyển đổi Ngôn ngữ tự nhiên sang SQL (NL2SQL). Mặc dù các mô hình NL2SQL hiện đại đã đạt được tiến bộ đáng kể, chúng vẫn thường xuyên tạo ra các truy vấn sai ngữ nghĩa, có thể thực thi thành công nhưng lại cho ra kết quả không chính xác. Benchmark này nhằm hỗ trợ nghiên cứu phát hiện lỗi ngữ nghĩa, vốn là điều kiện tiên quyết cho bất kỳ sự sửa lỗi tiếp theo nào.</li><li><strong>OmniSQL</strong> [<a href="https://arxiv.org/html/2503.02240">Bài báo</a>][<a href="https://huggingface.co/datasets/seeklhy/SynSQL-2.5M">Bộ dữ liệu</a>]<br/>*Thời gian:* 03/2025<br/>*Mô tả:* Tính đến tháng 3 năm 2025, SynSQL-2.5M là bộ dữ liệu Text2SQL tổng hợp lớn nhất và đa dạng nhất cho đến nay. Nó đại diện cho một cột mốc quan trọng trong cộng đồng Text2SQL. Chúng tôi khuyến khích các nhà nghiên cứu, những người thực hành và những người đam mê dữ liệu khám phá và xây dựng mô hình sử dụng bộ dữ liệu này. Nếu bạn thấy nó hữu ích, hãy cân nhắc "tặng sao" hoặc trích dẫn công trình của chúng tôi nhé. Phản hồi của bạn là động lực lớn nhất để chúng tôi tiếp tục tiến xa.</li></ul>🗂️ Các Bộ Dữ Liệu Khác<ul><li><strong>WikiSQL</strong> [<a href="https://arxiv.org/pdf/1709.00103.pdf">Bài báo</a>][<a href="https://github.com/salesforce/WikiSQL">Bộ dữ liệu</a>]<br/>*Thời gian:* 09/2017<br/>*Mô tả:* Salesforce đề xuất bộ dữ liệu Text-to-SQL lớn WikiSQL. Dữ liệu này đến từ Wikipedia, thuộc một miền duy nhất, chứa 80.654 câu hỏi ngôn ngữ tự nhiên và 77.840 câu lệnh SQL. Các câu lệnh SQL tương đối đơn giản, không bao gồm các phép toán phức tạp như sắp xếp, nhóm và truy vấn con.</li><li><strong>Spider 1.0</strong> [<a href="https://arxiv.org/pdf/1809.08887.pdf">Bài báo</a>][<a href="https://yale-lily.github.io/spider">Bảng xếp hạng</a>]<br/>*Thời gian:* 09/2018<br/>*Mô tả:* Đại học Yale đề xuất bộ dữ liệu Text-to-SQL Spider với nhiều cơ sở dữ liệu, nhiều bảng và truy vấn một lượt. Đây cũng được công nhận là danh sách đánh giá đa miền quy mô lớn khó nhất trong ngành. Nó chứa 10.181 câu hỏi ngôn ngữ tự nhiên và 5.693 câu lệnh SQL.</li><li><strong>SParC</strong> [<a href="https://arxiv.org/pdf/1906.02285.pdf">Bài báo</a>][<a href="https://yale-lily.github.io/sparc">Bảng xếp hạng</a>]<br/>*Thời gian:* 06/2019<br/>*Mô tả:* Đại học Yale đề xuất bộ dữ liệu lớn SParC cho các tác vụ phân tích cú pháp ngữ nghĩa phức tạp, đa miền và phụ thuộc ngữ cảnh (nhiều lượt) và Text-to-SQL. Nó bao gồm 4.298 chuỗi câu hỏi mạch lạc (hơn 12 nghìn câu hỏi riêng lẻ được chú thích với các truy vấn SQL do 14 sinh viên Yale chú thích), thu được từ tương tác của người dùng với 200 cơ sở dữ liệu phức tạp trên 138 miền.</li><li><strong>CSpider</strong> [<a href="https://arxiv.org/pdf/1906.02285.pdf">Bài báo</a>][<a href="https://taolusi.github.io/CSpider-explorer/">Bảng xếp hạng</a>]<br/>*Thời gian:* 09/2019<br/>*Mô tả:* Đại học Westlake đề xuất bộ dữ liệu tiếng Trung lớn CSpider cho tác vụ phân tích cú pháp ngữ nghĩa phức tạp và đa miền và Text-to-SQL, được dịch từ Spider bởi 2 nhà nghiên cứu NLP và 1 sinh viên khoa học máy tính. Nó bao gồm 10.181 câu hỏi và 5.693 truy vấn SQL phức tạp duy nhất trên 200 cơ sở dữ liệu với nhiều bảng bao gồm 138 miền khác nhau.</li><li><strong>CoSQL</strong> [<a href="https://ar5iv.labs.arxiv.org/html/1909.05378">Bài báo</a>][<a href="https://yale-lily.github.io/cosql">Bảng xếp hạng</a>]<br/>*Thời gian:* 09/2019<br/>*Mô tả:* Đại học Yale và Salesforce Research đề xuất một cơ sở dữ liệu đa miền CoSQL, bao gồm hơn 30 nghìn lượt đối thoại cộng với hơn 10 nghìn truy vấn SQL được chú thích, thu được từ bộ sưu tập Wizard-of-Oz (WOZ) gồm 3 nghìn cuộc đối thoại truy vấn 200 cơ sở dữ liệu phức tạp trải dài 138 miền.</li><li><strong>KaggleDBQA</strong> [<a href="https://arxiv.org/abs/2106.11455">Bài báo</a>][<a href="https://github.com/Chia-Hsuan-Lee/KaggleDBQA/">Bộ dữ liệu</a>]<br/>*Thời gian:* 06/2021<br/>*Mô tả:* KaggleDBQA là một bộ dữ liệu đánh giá phức tạp và đa miền của các cơ sở dữ liệu Web thực, với các kiểu dữ liệu đặc trưng theo miền, định dạng gốc và câu hỏi không giới hạn.</li><li><strong>Spider-Syn</strong> [<a href="https://ar5iv.labs.arxiv.org/html/2106.01065">Bài báo</a>][<a href="https://github.com/ygan/Spider-Syn">Bộ dữ liệu</a>]<br/>*Thời gian:* 06/2021<br/>*Mô tả:* Spider-Syn là bộ dữ liệu benchmark được thiết kế để đánh giá và nâng cao tính mạnh mẽ của các mô hình Text-to-SQL chống lại việc thay thế từ đồng nghĩa trong các câu hỏi ngôn ngữ tự nhiên. Được phát triển bởi các nhà nghiên cứu từ Đại học Queen Mary London và các cộng tác viên, Spider-Syn dựa trên bộ dữ liệu Spider gốc.</li><li><strong>SEDE</strong> [<a href="https://ar5iv.labs.arxiv.org/html/2106.05006">Bài báo</a>][<a href="https://github.com/hirupert/sede">Bộ dữ liệu</a>]<br/>*Thời gian:* 06/2021<br/>*Mô tả:* SEDE (Stack Exchange Data Explorer) là bộ dữ liệu mới cho các tác vụ Text-to-SQL với hơn 12.000 truy vấn SQL và mô tả ngôn ngữ tự nhiên của chúng. Nó dựa trên việc sử dụng thực tế của người dùng từ nền tảng Stack Exchange Data Explorer, mang đến sự phức tạp và thách thức chưa từng thấy trong bất kỳ bộ dữ liệu phân tích cú pháp ngữ nghĩa nào khác, như bao gồm lồng ghép phức tạp, thao tác ngày tháng, thao tác số và văn bản, tham số, và quan trọng nhất: sự thiếu chi tiết và giả định ẩn.</li><li><strong>CHASE</strong> [<a href="https://aclanthology.org/2021.acl-long.180.pdf">Bài báo</a>][<a href="https://github.com/xjtu-intsoft/chase">Bộ dữ liệu</a>]<br/>*Thời gian:* 08/2021<br/>*Mô tả:* CHASE là bộ dữ liệu tiếng Trung quy mô lớn và thực dụng cho tác vụ Text-to-SQL phụ thuộc ngữ cảnh đa cơ sở dữ liệu (giao diện ngôn ngữ tự nhiên cho các cơ sở dữ liệu quan hệ). Nó được phát hành cùng với bài báo ACL 2021 của chúng tôi: CHASE: A Large-Scale and Pragmatic Chinese Dataset for Cross-Database Context-Dependent Text-to-SQL.</li><li><strong>Spider-DK</strong> [<a href="https://ar5iv.labs.arxiv.org/html/2109.05157">Bài báo</a>][<a href="https://github.com/ygan/Spider-DK">Bộ dữ liệu</a>]<br/>*Thời gian:* 09/2021<br/>*Mô tả:* Spider-DK là bộ dữ liệu benchmark được thiết kế để đánh giá và nâng cao tính mạnh mẽ của các mô hình Text-to-SQL khi xử lý kiến thức miền. Được phát triển bởi các nhà nghiên cứu từ Đại học Queen Mary London, Spider-DK xây dựng dựa trên bộ dữ liệu Spider gốc.</li><li><strong>EHRSQL</strong> [<a href="https://arxiv.org/html/2301.07695">Bài báo</a>][<a href="https://github.com/glee4810/EHRSQL">Bộ dữ liệu</a>]<br/>*Thời gian:* 01/2023<br/>*Mô tả:* EHRSQL là bộ dữ liệu quy mô lớn, chất lượng cao được thiết kế cho tác vụ hỏi đáp Text-to-SQL trên Hồ sơ Sức khỏe Điện tử từ MIMIC-III và eICU. Bộ dữ liệu bao gồm các câu hỏi được thu thập từ 222 nhân viên bệnh viện, như bác sĩ, y tá, người xem xét bảo hiểm và đội ngũ hồ sơ sức khỏe.</li><li><strong>BIRD-SQL</strong> [<a href="https://arxiv.org/pdf/2305.03111.pdf">Bài báo</a>][<a href="https://bird-bench.github.io/">Bảng xếp hạng</a>]<br/>*Thời gian:* 05/2023<br/>*Mô tả:* Đại học Hồng Kông và Alibaba đề xuất bộ dữ liệu đa miền quy mô lớn BIRD, chứa hơn 12.751 cặp câu hỏi-SQL duy nhất, 95 cơ sở dữ liệu lớn với tổng dung lượng 33.4 GB. Nó cũng bao gồm hơn 37 miền chuyên ngành, như blockchain, khúc côn cầu, chăm sóc sức khỏe và giáo dục, v.v.</li><li><strong>UNITE</strong> [<a href="https://ar5iv.labs.arxiv.org/html/2305.16265">Bài báo</a>][<a href="https://github.com/awslabs/unified-text2sql-benchmark">Bộ dữ liệu</a>]<br/>*Thời gian:* 05/2023<br/>*Mô tả:* Benchmark hợp nhất UNITE được tạo thành từ 18 bộ dữ liệu Text-to-SQL công khai, chứa các câu hỏi ngôn ngữ tự nhiên từ hơn 12 miền, các truy vấn SQL từ hơn 3.9K mẫu và 29K cơ sở dữ liệu. So với benchmark Spider được sử dụng rộng rãi, chúng tôi giới thiệu thêm ~120K ví dụ và tăng gấp ba lần các mẫu SQL, như các câu hỏi so sánh và boolean.</li><li><strong>Archer</strong> [<a href="https://arxiv.org/html/2402.12554">Bài báo</a>] [<a href="https://sig4kg.github.io/archer-bench/">Bảng xếp hạng</a>]<br/>*Thời gian:* 02/2024<br/>*Mô tả:* Archer là bộ dữ liệu Text-to-SQL song ngữ đầy thách thức, đặc biệt tập trung vào suy luận phức tạp, bao gồm số học, suy luận thông thường và suy luận giả thuyết. Nó chứa 1.042 câu hỏi tiếng Anh và 1.042 câu hỏi tiếng Trung, cùng với 521 truy vấn SQL duy nhất, bao phủ 20 cơ sở dữ liệu tiếng Anh trên 20 miền.</li><li><strong>BookSQL</strong> [<a href="https://arxiv.org/html/2406.07860">Bài báo</a>][<a href="https://github.com/Exploration-Lab/BookSQL">Bộ dữ liệu</a>]<br/>*Thời gian:* 06/2024<br/>*Mô tả:* BookSQL có 100 nghìn cặp Truy vấn-SQL, gấp khoảng 1.25 lần bộ dữ liệu Text-to-SQL lớn nhất hiện có: WikiSQL. Đặc biệt, để thiết kế các truy vấn, chúng tôi đã tham khảo ý kiến các chuyên gia tài chính để hiểu các trường hợp sử dụng thực tế khác nhau. Chúng tôi cũng dự định tạo một bảng xếp hạng nơi các nhà nghiên cứu có thể đánh giá các mô hình Text-to-SQL khác nhau cho miền kế toán.</li><li><strong>Spider 2.0</strong> [<a href="https://spider2-sql.github.io/">Bài báo</a>] [<a href="https://spider2-sql.github.io/">Bảng xếp hạng</a>]<br/>*Thời gian:* 08/2024<br/>*Mô tả:* Spider 2.0, được đề xuất bởi XLang AI, đóng vai trò là một khung đánh giá nâng cao cho các tác vụ Text-to-SQL trong các quy trình làm việc cấp doanh nghiệp thực tế. Nó chứa 600 vấn đề quy trình làm việc Text-to-SQL phức tạp, bắt nguồn từ các trường hợp sử dụng cơ sở dữ liệu doanh nghiệp khác nhau. Bộ dữ liệu bao gồm các cơ sở dữ liệu có nguồn gốc từ các ứng dụng dữ liệu thực tế, thường chứa hơn 1.000 cột và được lưu trữ trong các hệ thống đám mây hoặc cục bộ như BigQuery, Snowflake hoặc PostgreSQL.</li><li><strong>BEAVER</strong> [<a href="https://arxiv.org/html/2409.02038">Bài báo</a>][<a href="https://github.com/peterbaile/beaver">Bộ dữ liệu</a>]<br/>*Thời gian:* 09/2024<br/>*Mô tả:* BEAVER, có nguồn gốc từ các kho dữ liệu doanh nghiệp thực tế cùng với các truy vấn ngôn ngữ tự nhiên và các câu lệnh SQL đúng của chúng mà chúng tôi thu thập từ lịch sử người dùng thực tế.</li><li><strong>PRACTIQ</strong> [<a href="https://arxiv.org/html/2410.11076">Bài báo</a>]<br/>*Thời gian:* 10/2024<br/>*Mô tả:* PRACTIQ: Một bộ dữ liệu Text-to-SQL hội thoại thực tế với các truy vấn mơ hồ và không thể trả lời.</li><li><strong>TURSpider</strong> [<a href="https://ieeexplore.ieee.org/document/10753591">Bài báo</a>][<a href="https://github.com/alibugra/TURSpider">Bộ dữ liệu</a>]<br/>*Thời gian:* 11/2024<br/>*Mô tả:* TURSpider là bộ dữ liệu Text-to-SQL tiếng Thổ Nhĩ Kỳ mới, bao gồm các truy vấn phức tạp, tương tự như trong bộ dữ liệu Spider gốc. Bộ dữ liệu TURSpider bao gồm hai tập con chính: tập phát triển và tập huấn luyện, phù hợp với cấu trúc và quy mô của bộ dữ liệu Spider phổ biến. Tập phát triển chứa 1034 hàng dữ liệu với 1023 câu hỏi duy nhất và 584 truy vấn SQL riêng biệt. Trong tập huấn luyện, có 8659 hàng dữ liệu, 8506 câu hỏi duy nhất và các truy vấn SQL tương ứng.</li><li><strong>synthetic_text_to_sql</strong> [<a href="https://huggingface.co/datasets/gretelai/synthetic_text_to_sql">Bộ dữ liệu</a>]<br/>*Thời gian:* 11/2024<br/>*Mô tả:* gretelai/synthetic_text_to_sql là một bộ dữ liệu phong phú gồm các mẫu Text-to-SQL tổng hợp chất lượng cao, được thiết kế và tạo ra bằng Gretel Navigator, và được phát hành theo giấy phép Apache 2.0.</li></ul>Tham khảo thêm nhé:<ul><li><a href="https://github.com/sqlflash/Awesome-Text2SQL-Dataset">Awesome-Text2SQL-Dataset</a></li><li><a href="https://github.com/eosphoros-ai/Awesome-Text2SQL">Awesome-Text2SQL</a></li><li>Bài viết gốc: <a href="https://sqlflash.ai/blog/sql-llm-dataset/">sqlflash.ai/blog/sql-llm-dataset/</a></li></ul>

Lê Lân

18/06/2025

Bạn đang hăm hở xây dựng thế hệ AI Agent tiếp theo, một hệ thống thông minh, tự động, sẵn sàng để thấu hiểu, suy luận và hành động đúng không? Nghe đã thấy 'đỉnh của chóp' rồi đó! Nhưng khoan đã, cái bộ não kỹ thuật số này lấy 'kiến thức bí mật' hay những ngữ cảnh quan trọng để đưa ra quyết định thông minh từ đâu ra vậy ta? À, thường thì 'kho báu' này nằm ngay trong cái database SQL đáng tin cậy của bạn đấy! Từ lịch sử người dùng, danh mục sản phẩm cho đến dữ liệu cảm biến thời gian thực, tất cả đều là nền tảng để AI của chúng ta 'hiểu chuyện'.Bạn đã thiết kế xong 'chú' AI của mình, đặt ra các mục tiêu, và nó đã sẵn sàng 'xông pha' tương tác. Nhưng rồi... một khoảng lặng đáng sợ! Đó là khoảnh khắc mà 'chú' AI cần 'nghĩ ngợi' để lôi cái mẩu thông tin quan trọng từ database ra nhằm xây dựng ngữ cảnh, và cái khoảnh khắc đó cứ như dài vô tận vậy. Cái 'chú' AI tinh vi của bạn, được thiết kế để hành động cực nhanh, bỗng dưng bị 'đứng hình' vì một câu truy vấn SQL chậm chạp, biến khả năng suy luận 'thời gian thực' thành nỗi thất vọng 'chờ tí nhé!'. Này các bạn ơi, đây chính là lúc tối ưu hóa truy vấn SQL trở nên **cực kỳ quan trọng** cho một AI Agent thực sự 'bá đạo'!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ov3r3hb62qvl7kyyp8x3.jpg' alt='Ảnh chế về các truy vấn SQL chậm gây ức chế'>Nó cứ như việc bạn giao cho một thám tử thiên tài giải quyết một vụ án, nhưng mỗi khi cần một manh mối (một mảnh dữ liệu), anh ta lại phải tự tay lục lọi qua hàng núi tài liệu lộn xộn trong một kho lưu trữ đầy bụi bặm vậy. Vị thám tử thì thông minh đấy, nhưng cái khâu truy xuất thông tin lại làm tê liệt tốc độ và hiệu quả của anh ta. 'Chú' AI của chúng ta cũng chẳng khác gì đâu! Vậy làm sao để đảm bảo 'chú' AI của chúng ta nhận được ngữ cảnh nhanh chóng và hiệu quả? Dựa trên những nguyên tắc tối ưu hóa đã có, chúng ta hãy cùng xem 'kế hoạch tác chiến' nhé!**1. Trở Thành 'Thám Tử Dữ Liệu' Với EXPLAIN (hoặc tương đương):**Trước khi AI Agent của bạn có thể hành động thông minh, bạn cần phải hiểu nó đang 'thu thập trí tuệ' của mình như thế nào. Lệnh `EXPLAIN` (hoặc các lệnh tương đương tùy theo database bạn dùng) chính là công cụ 'giải mã' chiến lược mà database dùng để tìm và trả về dữ liệu. Nó giống như một chiếc máy X-quang, giúp bạn nhìn xuyên thấu 'bộ não' của database, xem nó đang làm gì sau hậu trường để xử lý truy vấn của bạn.**Cảnh báo đỏ cho các Agent:** Bạn có thấy nó đang 'quét' hàng triệu dòng dữ liệu chỉ để tìm một mẩu thông tin nhỏ xíu mà 'chú' AI của bạn cần ngay lập tức không? Nếu có, thì đó chính là một nút thắt cổ chai khổng lồ, ảnh hưởng trực tiếp đến tốc độ phản hồi của AI đấy!**Các thao tác `SORT` 'đắt đỏ':** Nếu 'chú' AI cần dữ liệu đã được sắp xếp cho logic của nó, các thao tác `SORT` này có thể 'ngốn' rất nhiều bộ nhớ, làm chậm toàn bộ quá trình xây dựng ngữ cảnh.**`Full Table Scan` (Quét toàn bộ bảng):** Kẻ thù không đội trời chung của tốc độ! 'Chú' AI của bạn không nên phải chờ database đọc toàn bộ một bảng khổng lồ chỉ để hiểu một tình huống cụ thể nào đó đâu nhé! Đây là dấu hiệu của một truy vấn kém hiệu quả.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/explain_sql.png' alt='Minh họa lệnh EXPLAIN trong SQL'>**2. Làm Sắc Nét Tiêu Điểm Của Agent (Tối Ưu Hóa Chính Câu Truy Vấn!):**Đây chính là nơi bạn có thể đạt được những cải thiện hiệu suất 'khủng' nhất cho AI Agent của mình đấy! Hãy coi các truy vấn của bạn như những mũi tên, và mục tiêu là bắn trúng tâm điểm, không lan man.**Lọc dữ liệu chính xác với mệnh đề `WHERE`:** Hãy trang bị cho các truy vấn của 'chú' AI khả năng 'phẫu thuật' cực kỳ chính xác. Chỉ lấy đúng dữ liệu cần thiết cho tác vụ hoặc quyết định hiện tại thôi nhé. Mệnh đề `WHERE` càng cụ thể, ngữ cảnh càng được xây dựng nhanh chóng.**`JOIN` hiệu quả:** Nếu 'chú' AI cần kết hợp thông tin từ nhiều bảng (ví dụ: hồ sơ người dùng + lịch sử tương tác), hãy đảm bảo các thao tác `JOIN` đó phải thật 'gọn gàng và mạnh mẽ', chỉ kết nối những gì thực sự cần, không thừa thãi dữ liệu không cần thiết.**Danh sách `IN` ngắn gọn:** Nếu 'chú' AI đang kiểm tra một tập hợp các mục đã biết, hãy giữ danh sách đó thật 'gọn gàng' nhé. Tránh dùng `IN` với danh sách quá dài, đôi khi `EXISTS` hoặc `JOIN` lại là lựa chọn tốt hơn!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/query_optimization.png' alt='Minh họa các mẹo tối ưu hóa truy vấn SQL'>**3. Tạo Lối Đi Riêng Tốc Hành Với `Indexes` (Chỉ Mục):**Hãy hình dung `indexes` như việc bạn tạo ra một hệ thống sắp xếp hồ sơ siêu hiệu quả cho những dữ liệu mà AI Agent của bạn thường xuyên cần đến. Giống như một thư viện có thẻ mục lục vậy, giúp bạn tìm sách trong tích tắc!Hãy xác định các cột mà 'chú' AI của bạn thường xuyên sử dụng để tìm kiếm trong mệnh đề `WHERE` hoặc để sắp xếp (`ORDER BY`) cho quá trình suy luận của nó. Việc đánh `index` cho các cột này giống như việc bạn tạo cho 'chú' AI một đường dây trực tiếp đến thông tin vậy, không cần phải lục tung cả kho dữ liệu nữa.**Lợi ích cho Agent:** Truy xuất ngữ cảnh nhanh hơn = ra quyết định nhanh hơn = một 'chú' AI phản hồi tốt hơn và có vẻ 'thông minh' hơn hẳn!**Cẩn thận nhé!** Đừng 'vung tay quá trán' mà đánh `index` khắp mọi nơi nhé. Chúng giúp tăng tốc độ đọc (tuyệt vời cho AI Agent khi lấy ngữ cảnh) nhưng lại có thể làm chậm tốc độ ghi (thêm, sửa, xóa dữ liệu). Hãy dùng `EXPLAIN` để kiểm tra tác động của chúng và tìm ra sự cân bằng hoàn hảo!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/database_index.png' alt='Minh họa chỉ mục (index) trong cơ sở dữ liệu'>**4. 'Đại Tu' Cho Nhu Cầu Phức Tạp Của Agent:**Khi các AI Agent phải xử lý những bộ dữ liệu khổng lồ, liên tục phát triển, đây là lúc bạn cần nghĩ đến những 'ca phẫu thuật' lớn hơn để nâng cấp 'phần cứng' cho chúng!**`Table Partitioning` (Phân vùng bảng):** Nếu 'chú' AI của bạn suy luận dựa trên dữ liệu chuỗi thời gian (ví dụ: hoạt động người dùng hàng ngày), việc phân vùng theo ngày có thể giúp nó chỉ cần truy vấn một phần dữ liệu gần đây nhất, làm tăng tốc độ thu thập ngữ cảnh một cách đáng kinh ngạc. Tưởng tượng như bạn không cần tìm kiếm trong cả núi thư từ của nhiều năm, mà chỉ cần xem hộp thư của tuần này thôi!**`Data Structure Redesign` (Thiết kế lại cấu trúc dữ liệu):** Đôi khi, cách dữ liệu được cấu trúc cần phải được điều chỉnh để phù hợp hơn với cách 'chú' AI của bạn suy nghĩ và truy cập thông tin. Đây là một 'phi vụ' cần tìm hiểu sâu, có thể tốn công sức, nhưng đối với các Agent phức tạp, nó có thể mang lại sự thay đổi lớn về hiệu suất.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/data_partitioning.png' alt='Minh họa phân vùng dữ liệu trong database'>**Tự Tay 'Khám Bệnh' Query Với Python và PostgreSQL (Ví Dụ 'Thực Chiến'):**Nếu bạn cũng là một 'dev Python' chính hiệu như tôi, đây là cách bạn có thể sử dụng `EXPLAIN` để 'săm soi' các nút thắt cổ chai tiềm ẩn về hiệu suất như `full table scan` hay các thao tác `sort` 'đắt đỏ', những thứ có thể ảnh hưởng trực tiếp đến khả năng phản hồi của AI Agent.Giả sử bạn có một database PostgreSQL đã được cài đặt và schema bảng của bạn trông như thế này:```sqlCREATE TABLE documents ( id SERIAL PRIMARY KEY, title TEXT, content TEXT, created_at TIMESTAMP DEFAULT NOW());```Bây giờ, hãy tạo một file Python và gõ vào đoạn mã sau. Hãy nhớ thay thế `your_db`, `your_user`, `your_password` bằng thông tin database của bạn nhé!```pythonimport psycopg2# Kết nối đến database PostgreSQL của bạnconn = psycopg2.connect( dbname="your_db", user="your_user", password="your_password", host="localhost", port="5432")cur = conn.cursor()# Đây là câu truy vấn mà AI Agent của bạn có thể chạyquery = """SELECT * FROM documentsWHERE content ILIKE '%recycling%'ORDER BY created_at DESCLIMIT 10;"""# Sử dụng EXPLAIN ANALYZE để xem PostgreSQL đã làm gì 'dưới mũ'cur.execute(f"EXPLAIN (ANALYZE, BUFFERS, VERBOSE) {query}")plan = cur.fetchall()print("Kế hoạch truy vấn (Query Plan):\\n")for row in plan: print(row[0])cur.close()conn.close()```Lưu file lại và chạy thử nhé, sau đó hãy quan sát kết quả. Và nếu bạn vẫn chưa hiểu mình đang thấy gì, thì bạn biết phải làm gì rồi đó – hãy đào sâu tìm hiểu thêm về kết quả của `EXPLAIN` nhé! Nó là cả một nghệ thuật đó!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/python_postgres_explain.png' alt='Ví dụ Python kết nối PostgreSQL và sử dụng EXPLAIN'>**Lời Khuyên Từ Tớ Dành Cho Các 'Dev AI':**Đối với AI Agent, tốc độ và hiệu quả của việc truy xuất dữ liệu để xây dựng ngữ cảnh không chỉ là 'vấn đề của database' đâu nhé, nó là **yếu tố cốt lõi** quyết định hiệu suất của Agent đấy! Một truy vấn chậm chạp đồng nghĩa với một 'chú' AI suy nghĩ chậm chàm, dẫn đến trải nghiệm người dùng tệ hại hoặc tự động hóa kém hiệu quả. Việc thường xuyên tối ưu hóa các truy vấn SQL mà 'nuôi sống' AI Agent của bạn giống như việc bạn đang 'mài sắc' các công cụ nhận thức của chúng vậy.Hãy sử dụng `EXPLAIN` một cách 'tôn thờ', ưu tiên điều chỉnh truy vấn và đánh `index` một cách thông minh. Còn bạn thì sao? Bạn đang làm cách nào để đảm bảo AI Agent của mình nhận được dữ liệu cần thiết, khi cần, mà không bị 'delay' vậy? Chia sẻ chiến lược xây dựng ngữ cảnh hiệu quả của bạn ở phần bình luận nhé! 👇

Lê Lân

17/06/2025

Tìm hiểu cách chỉ mục (indexes) biến các truy vấn cơ sở dữ liệu chậm chạp thành những "tên lửa" siêu tốc. Bài viết giải thích chi tiết về chỉ mục, cách hoạt động của B-tree, so sánh hiệu suất giữa có và không có chỉ mục, và những sai lầm cần tránh khi dùng chỉ mục trong cả SQL và NoSQL.

Lê Lân

15/06/2025

Chán ngán với SQL client chậm chạp? TurboSQL mang đến tốc độ thần tốc, thiết kế tối ưu phím tắt, sắp xếp thông minh và sức mạnh AI để bạn làm việc với dữ liệu nhanh chóng, hiệu quả. Trải nghiệm ngay phiên bản miễn phí hoặc nâng cấp để bứt phá năng suất!

Lê Lân

15/06/2025

Khám phá USPL, công cụ Python siêu nhẹ giúp các mô hình ngôn ngữ lớn như ChatGPT hiểu và tạo câu lệnh SQL chính xác từ dữ liệu đa bảng, giải quyết vấn đề 'ảo giác' khi xử lý JOINs và foreign keys. Tìm hiểu cách TSIA PEI LIN tạo ra USPL và những bài học đắt giá trong việc thiết kế prompt hiệu quả cho LLM.

Lê Lân

15/06/2025