Dạy model viết SQL riêng — tốn chưa tới 1 đô/tháng

Fine-tune text-to-SQL cho SQL dialect riêng của team, deploy serverless với chi phí gần bằng không khi idle. Hướng dẫn từ A đến Z.

Bao nhiêu tiền mỗi tháng để model hiểu SQL của riêng bạn?

Team bạn dùng SQL dialect nào? Nếu câu trả lời là "chuẩn PostgreSQL" thì bạn khỏi cần bài này — GPT-4o hay Claude đều xử lý ngon. Nhưng nếu team bạn dùng ClickHouse, Trino, hoặc một dialect nội bộ đầy custom function, thì chắc bạn biết cái cảm giác: model sinh ra câu SQL nhìn đúng cú pháp mà chạy là lỗi.

Vấn đề không phải model dốt. Vấn đề là nó chưa được "mượn đúng kệ sách" — chưa ai chỉ cho nó dialect của bạn nằm ở đâu trong cái thư viện kiến thức khổng lồ mà nó đã học.

Trước khi có serverless fine-tuning — cái giá của "luôn sẵn sàng"

Giả sử team bạn 5 người, mỗi ngày có vài trăm câu hỏi dạng "lấy doanh thu Q1 theo vùng" cần chuyển sang SQL custom. Bạn fine-tune một model, deploy lên endpoint riêng. Model chạy tốt.

Rồi cuối tuần đến. Không ai query. Nhưng endpoint vẫn chạy, GPU vẫn burn tiền. Tháng đầu tiên bạn nhìn bill và thấy con số hosting đắt hơn cả tiền cà phê cả team uống trong quý.

Nói thẳng ra thì đây là trade-off kinh điển của fine-tuning: bạn trả tiền cho khả năng "luôn sẵn sàng" ngay cả khi không ai hỏi. Với startup hay team nhỏ ở Việt Nam, đây là rào cản thật sự — không phải kỹ thuật, mà là kinh tế.

Sau khi có on-demand inference — trả tiền theo câu hỏi

AWS vừa cho thấy một hướng tiếp cận khác: fine-tune Amazon Nova Micro bằng LoRA, rồi deploy qua Amazon Bedrock dạng on-demand. Không dùng, không trả tiền. Dùng bao nhiêu, trả bấy nhiêu.

Con số từ bài blog gốc của AWS: với khoảng 22,000 query/tháng, chi phí chỉ khoảng $0.80. Đúng rồi, chưa tới một đô.

LoRA — nếu bạn đã theo dõi bài mình viết về fine-tuning trước đây — là kỹ thuật chỉ train thêm một "lớp adapter" nhỏ thay vì toàn bộ model. Kết quả: file adapter chỉ vài chục MB, gắn vào model gốc lúc inference. Như một phiếu ghi chú kẹp vào cuốn sách dày — bạn không viết lại cả cuốn, chỉ thêm annotation cho phần bạn cần.

Cách tiếp cận này giải quyết đúng pain point: model vẫn hiểu SQL riêng của bạn, nhưng bạn không phải nuôi một con server 24/7 chờ người hỏi.

Thử ngay trong một buổi chiều

Muốn thử? Đây là flow tổng quát, đủ để bạn có prototype trong 3-4 tiếng:

Bước 1: Chuẩn bị dataset. Thu thập 200-500 cặp (câu hỏi tiếng tự nhiên, câu SQL đúng) từ dialect của team bạn. Format JSON, mỗi dòng một cặp input/output. Đây là bước tốn thời gian nhất — nhưng cũng quan trọng nhất.

Bước 2: Upload và fine-tune. Dùng Amazon Bedrock console hoặc API, chọn Nova Micro làm base model, upload dataset, chạy fine-tuning job. LoRA adapter sẽ được tạo sau vài giờ tùy kích thước dataset.

Bước 3: Test on-demand. Gọi model qua Bedrock API với adapter đã train. Không cần provision endpoint. Mỗi request sẽ tự động load adapter, sinh SQL, rồi trả kết quả.

Bước 4: Đánh giá. So sánh output với SQL đúng. Đo execution accuracy — câu SQL sinh ra có chạy được và trả đúng kết quả không, chứ không chỉ đo string matching.

Một lưu ý: latency sẽ cao hơn so với dedicated endpoint vì mỗi request phải load LoRA adapter. Nhưng với use case text-to-SQL interactive — người dùng hỏi, chờ vài giây — mức latency này hoàn toàn chấp nhận được.

Ba cái bẫy mình thấy team hay dính

Bẫy 1: Dataset bẩn, model học sai. Có team copy SQL từ log production mà không filter — lẫn cả query lỗi, query thừa. Model học xong sinh SQL "sáng tạo" hơn cả junior dev mới vào. Hãy curate dataset kỹ: chỉ giữ query đúng, cover đủ pattern, và bao gồm cả edge case.

Bẫy 2: Quên schema context. Model cần biết bảng nào có cột nào. Nếu prompt không kèm schema, model sẽ "đoán" tên cột — và đoán sai là chuyện thường. Luôn đưa schema vào prompt hoặc system message.

Bẫy 3: Đánh giá bằng mắt thay vì chạy thật. SQL nhìn đúng chưa chắc chạy đúng. Một câu SELECT thiếu GROUP BY có thể trả kết quả mà không báo lỗi trên một số engine — nhưng kết quả hoàn toàn sai. Luôn eval bằng execution accuracy trên database thật.

Không muốn dùng AWS? Có lựa chọn khác

Nếu team bạn đã quen self-host hoặc muốn giữ data on-premise:

Trade-off rõ ràng: self-host thì bạn kiểm soát hoàn toàn, nhưng phải lo infra. Serverless như Bedrock thì nhẹ đầu hơn, nhưng bị lock-in và phụ thuộc region availability.

Một takeaway duy nhất

Text-to-SQL cho dialect riêng không còn là bài toán "fine-tune xong rồi burn tiền hosting". Với LoRA + serverless inference, bạn có thể triển khai production-grade mà chi phí scale theo usage thật sự.

Đừng tin mình, thử đi rồi biết — bắt đầu với 200 cặp query, một buổi chiều, và xem model có viết SQL tốt hơn cái auto-complete trong DBeaver không.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo