Bài 2 — Truy vấn dữ liệu bằng ngôn ngữ tự nhiên (text-to-SQL) cho PM

Bối cảnh & vấn đề của bạn

Bạn muốn biết "tuần rồi có bao nhiêu user mới hoàn tất bước thanh toán đầu tiên, chia theo nền tảng". Bạn không viết được SQL, và mỗi lần nhờ analyst là một lần chờ. Text-to-SQL để bạn hỏi bằng ngôn ngữ tự nhiên và nhận truy vấn chạy được — nhưng chỉ AN TOÀN khi bạn biết cách kiểm soát.

AI giúp được gì

AI dịch câu hỏi kinh doanh thành SQL dựa trên schema bạn cung cấp. Nhiều BI tool (Metabase, Looker, Hex, Mode) và cả ChatGPT/Claude đều làm được. Vai trò của bạn: cung cấp schema chính xác, đọc-hiểu SQL đủ để phát hiện sai logic, và luôn chạy trên môi trường chỉ-đọc.

Điểm quan trọng cần nhớ: text-to-SQL không thay bạn tư duy về câu hỏi kinh doanh — nó chỉ dịch câu hỏi đã rõ thành cú pháp. Nếu bạn hỏi mơ hồ ("cho tôi xem doanh thu"), AI phải tự đoán khoảng thời gian, đơn vị tiền tệ, có tính hoàn tiền hay không — và mỗi lần đoán là một lần rủi ro sai. Bạn càng chỉ định rõ, kết quả càng đáng tin. Đây là kỹ năng cốt lõi của PM: biến câu hỏi mơ hồ của sếp thành câu hỏi dữ liệu chính xác.

Ví dụ cụ thể

Câu hỏi: "Số user đăng ký trong 7 ngày qua đã thực hiện ít nhất 1 giao dịch, chia theo platform." Bạn cung cấp schema, AI sinh SQL với JOIN giữa users và events, lọc event_name='transaction', signup_ts >= now()-7d, GROUP BY platform. Bạn đọc và thấy nó dùng COUNT(*) — nhưng bạn cần COUNT(DISTINCT user_id) để không đếm trùng user giao dịch nhiều lần. Bạn yêu cầu sửa.

Prompt mẫu — sinh SQL có kiểm soát

Schema:
- users(user_id, signup_ts, country, platform)
- events(event_id, user_id, event_name, ts, amount)

Câu hỏi: Đếm số user DUY NHẤT đăng ký trong 7 ngày qua
và có >=1 event 'transaction', chia theo platform.

Yêu cầu:
- Dialect: PostgreSQL.
- Chỉ dùng bảng/cột ở trên. Nếu thiếu thông tin, HỎI LẠI, đừng đoán.
- Dùng COUNT(DISTINCT user_id) để tránh đếm trùng.
- Ghi chú mỗi mệnh đề WHERE làm gì.
- KHÔNG viết lệnh ghi/xóa (INSERT/UPDATE/DELETE/DROP).

Các bước làm

• Chuẩn bị schema đúng (copy từ data catalog hoặc hỏi analyst 1 lần).
• Diễn đạt câu hỏi rõ: metric, cửa sổ thời gian, cách gom nhóm, đơn vị đếm (user hay lượt).
• Yêu cầu AI ghi chú từng mệnh đề để bạn hiểu logic.
• Đọc soát: đơn vị đếm (DISTINCT?), khoảng thời gian, có lọc bot/nội bộ chưa.
• Chạy SQL trên read-only replica hoặc trong BI tool, không chạy trên DB production ghi được.
• Kiểm tra tính hợp lý (sanity check): tổng có gần con số bạn biết không?

Template tái dùng — Checklist duyệt SQL do AI sinh

[ ] Chỉ dùng bảng/cột có thật (không ảo giác schema)
[ ] Đơn vị đếm đúng: COUNT(DISTINCT user_id) vs COUNT(*)
[ ] Khoảng thời gian & múi giờ đúng
[ ] Đã loại bot / tài khoản nội bộ / test
[ ] JOIN không làm nhân đôi dòng (kiểm tra khóa)
[ ] Không có lệnh ghi/xóa
[ ] Chạy trên môi trường read-only
[ ] Kết quả qua sanity check với con số đã biết

Sai lầm thường gặp

• Đếm trùng. COUNT(*) thay vì COUNT(DISTINCT user_id) thổi phồng con số — sai lầm phổ biến nhất khiến PM báo cáo sai.
• Ảo giác cột/bảng. AI bịa cột is_active không tồn tại; SQL trông đúng nhưng chạy lỗi hoặc tệ hơn: chạy được nhưng sai nghĩa. Luôn đối chiếu schema.
• Quên loại nội bộ/bot. Traffic của chính team QA có thể làm metric lệch. Yêu cầu lọc rõ.
• Rủi ro ghi dữ liệu (rò rỉ/hư hại). Nếu cho AI-agent quyền chạy SQL tự động mà không giới hạn read-only, một lệnh sai có thể sửa/xóa dữ liệu thật. Luôn dùng tài khoản chỉ-đọc.
• Múi giờ. "Hôm qua" theo UTC khác "hôm qua" theo giờ VN — lệch một ngày làm sai toàn báo cáo.

Kết bài: bạn đã lấy được số. Bài 3 sẽ biến số thành dashboard trực quan.