Mở đầu — vì sao bài này quan trọng
Trong hầu hết các doanh nghiệp, dữ liệu nằm im trong database, trong Google Sheets, trong các dashboard mà rất ít người thực sự khai thác được. Lý do không phải vì thiếu dữ liệu — lý do là vì giữa "câu hỏi kinh doanh" và "câu trả lời từ dữ liệu" có một bức tường: bạn phải biết viết SQL, biết dùng công cụ phân tích, biết trình bày kết quả sao cho sếp hiểu. Bức tường này khiến một trưởng phòng marketing muốn biết "tháng vừa rồi khách hàng nào sắp rời bỏ chúng ta" phải chờ đội data cả tuần.
LLM đang phá bức tường đó. Với một prompt được viết đúng cách, bạn có thể biến câu hỏi tiếng Việt thành câu SQL chạy được, biến một bảng số liệu thô thành bản phân tích có insight, và biến insight đó thành đề xuất dashboard cho ban lãnh đạo. Nhưng — và đây là điểm mấu chốt của cả bài này — AI chỉ tốt bằng đúng lượng ngữ cảnh (context) bạn đưa cho nó. Một prompt "viết SQL đếm số user" sẽ cho ra rác nếu AI không biết bảng của bạn tên gì, cột nào là gì, kiểu dữ liệu ra sao.
Bài này tập trung riêng vào ba loại tác vụ dữ liệu phổ biến nhất trong công việc: sinh SQL (SQL generation), phân tích số liệu (analytics), và thiết kế/diễn giải dashboard. Chúng ta sẽ không bàn sâu về RAG hay function calling (những bài khác lo phần đó) — ở đây bạn học cách nói chuyện với AI như thể nó là một data analyst ngồi cạnh bạn, nhưng chỉ hiểu đúng những gì bạn nói ra thành lời.
Khái niệm cốt lõi
1. Nguyên tắc vàng: Schema đi trước, câu hỏi đi sau
Sai lầm lớn nhất khi nhờ AI viết SQL là quên đưa schema (cấu trúc bảng). AI không nhìn thấy database của bạn. Nếu bạn chỉ viết "đếm số khách hàng theo quốc gia", AI sẽ phải đoán tên bảng (customers? users? clients?), đoán tên cột (country? nation? location?). Kết quả là câu SQL trông đúng nhưng chạy sẽ báo lỗi "column does not exist".
Khuôn mẫu chuẩn cho SQL generation gồm bốn phần:
Viết câu SQL cho yêu cầu sau: [mô tả tác vụ].Schema database (dialect: PostgreSQL):
- users(id, email, country, signup_date, plan)
- subscriptions(id, user_id, monthly_amount, status, started_at, canceled_at)
- events(id, user_id, event_name, created_at)
Yêu cầu bổ sung:
- Chỉ dùng cú pháp PostgreSQL.
- Giải thích ngắn logic của câu query.
- Nếu có nhiều cách hiểu, hãy nêu giả định của bạn.
Ba yếu tố làm nên một prompt SQL tốt: (a) dialect — PostgreSQL, MySQL, BigQuery, SQL Server có cú pháp khác nhau, đặc biệt ở hàm ngày tháng và cửa sổ (window function); (b) schema đầy đủ kèm kiểu dữ liệu nếu quan trọng; (c) yêu cầu về giả định — buộc AI nói ra nó đang hiểu "khách hàng đang hoạt động" nghĩa là gì.
2. Phân tích số liệu: đưa dữ liệu vào, xin insight ra
Với tác vụ analytics, bạn không nhờ AI viết code mà nhờ nó đọc số và rút ra ý nghĩa. Ở đây context là bảng số liệu thực tế (dán trực tiếp dạng CSV hoặc Markdown table) cộng với định nghĩa nghiệp vụ. Ví dụ, AI không tự biết "churn rate 5%/tháng" là tốt hay xấu cho ngành SaaS Việt Nam — bạn phải cho nó ngưỡng tham chiếu, hoặc yêu cầu nó nêu rõ khi nào cần thêm dữ liệu.
Prompt phân tích tốt luôn tách hai lớp: mô tả (số nói gì) và diễn giải (số đó có ý nghĩa gì cho quyết định). Nếu không tách, AI hay bịa nguyên nhân ("doanh thu giảm vì khách không hài lòng") trong khi dữ liệu chưa hề chứng minh điều đó.
3. Dashboard: từ câu hỏi kinh doanh đến chỉ số cụ thể
Với dashboard, AI giúp bạn ở hai điểm: (a) đề xuất những chỉ số (metrics) nào nên đưa lên cho một đối tượng người xem cụ thể, và (b) diễn giải một dashboard có sẵn thành tóm tắt bằng lời. Chìa khóa là nói rõ ai xem và quyết định gì — dashboard cho CEO khác hoàn toàn dashboard cho trưởng nhóm vận hành.
Tình huống thực tế
Ví dụ 1 — Tiki: tìm khách hàng churn bằng một câu tiếng Việt
Bối cảnh: Một chuyên viên vận hành tại một sàn thương mại điện tử giả định giống Tiki cần danh sách khách hàng từng mua thường xuyên nhưng đã ngừng mua 90 ngày qua, để đội CRM gửi voucher win-back. Cô không biết SQL. Cô mở AI và viết:
Viết SQL (MySQL 8) cho: liệt kê khách hàng đã từng đặt ít nhất 3 đơn
nhưng không có đơn nào trong 90 ngày gần đây, tính đến hôm nay.Schema:
- customers(id, full_name, email, city, created_at)
- orders(id, customer_id, total_vnd, status, ordered_at)
status: 'completed' | 'canceled' | 'pending'Chỉ tính đơn status = 'completed'. Trả về id, họ tên, email,
số đơn đã hoàn thành, ngày đơn gần nhất. Giải thích logic.
AI trả về câu query dùng GROUP BY, HAVING COUNT(*) >= 3 và điều kiện MAX(ordered_at) < DATE_SUB(CURDATE(), INTERVAL 90 DAY), kèm giải thích rằng nó chỉ đếm đơn completed và định nghĩa "gần đây" là 90 ngày. Chuyên viên copy vào công cụ query nội bộ, chạy ra 1.240 khách hàng. Đội CRM gửi voucher, thu hồi được khoảng 8% trong số đó — một chiến dịch mà bình thường phải xếp hàng chờ đội data.
Bài học: khi schema và định nghĩa ("completed", "90 ngày") được nêu rõ, người không biết code vẫn tạo được truy vấn production-ready. Bức tường kỹ thuật bị hạ xuống.
Ví dụ 2 — Chuỗi F&B tại TP.HCM: phân tích doanh thu theo chi nhánh
Bối cảnh: Một chuỗi cà phê 12 chi nhánh xuất bảng doanh thu tháng ra CSV và muốn hiểu chuyện gì đang xảy ra. Quản lý dán bảng vào AI:
Bạn là data analyst. Phân tích bảng doanh thu tháng 5 dưới đây.Chi nhánh DT tháng 4 (triệu) DT tháng 5 (triệu) Số đơn T5 Quận 1 420 395 9.100 Thủ Đức 180 240 6.400
| ... (10 dòng nữa)Hãy: (1) mô tả các thay đổi đáng chú ý bằng số cụ thể;
(2) chỉ ra chi nhánh cần chú ý; (3) nêu 2 giả thuyết cho mỗi
bất thường, ghi rõ đâu là giả thuyết cần thêm dữ liệu để xác nhận.
KHÔNG khẳng định nguyên nhân nếu dữ liệu chưa đủ.
AI chỉ ra Quận 1 giảm 6% dù vẫn dẫn đầu, còn Thủ Đức tăng 33%. Quan trọng hơn, nó tính doanh thu trên mỗi đơn (average order value): Quận 1 khoảng 43.000đ/đơn còn Thủ Đức chỉ 37.500đ/đơn — gợi ý Thủ Đức tăng lượng khách nhưng giá trị đơn thấp hơn, có thể do khuyến mãi. AI ghi rõ đây là giả thuyết cần đối chiếu dữ liệu khuyến mãi.
Bài học: câu lệnh "KHÔNG khẳng định nguyên nhân nếu dữ liệu chưa đủ" cực kỳ giá trị. Nó chặn thói quen bịa nguyên nhân của LLM và biến bản phân tích thành công cụ ra quyết định đáng tin, thay vì một bài văn nghe hay nhưng sai.
Ví dụ 3 — Startup SaaS: thiết kế dashboard cho nhà đầu tư
Bối cảnh: Một startup SaaS B2B ở Hà Nội chuẩn bị gọi vốn vòng seed, cần một dashboard gọn cho nhà đầu tư nhưng không biết nên đưa chỉ số gì. Founder hỏi AI:
Tôi là founder SaaS B2B (phần mềm quản lý kho, khách hàng là
DN vừa và nhỏ VN). Đề xuất dashboard 1 trang cho nhà đầu tư
vòng seed. Với mỗi chỉ số: nêu tên, công thức tính từ dữ liệu
subscriptions/users, và vì sao nhà đầu tư quan tâm. Tối đa 6 chỉ số.
AI đề xuất MRR (doanh thu định kỳ hàng tháng), tỷ lệ tăng trưởng MRR tháng, Net Revenue Retention, churn rate theo logo, CAC payback và số khách hàng đang hoạt động — mỗi cái kèm công thức SQL gợi ý và một câu giải thích góc nhìn nhà đầu tư. Founder dùng chính các công thức đó để đặt hàng đội kỹ thuật dựng biểu đồ.
Bài học: khi bạn khai báo rõ người xem (nhà đầu tư seed) và bối cảnh (SaaS B2B, SME Việt Nam), AI chọn được đúng bộ chỉ số thay vì liệt kê 30 metric chung chung. Context về đối tượng quan trọng ngang với context về dữ liệu.
Hướng dẫn từng bước
Bước 1 — Xác định loại tác vụ. Hỏi bản thân: mình cần AI viết code (SQL), đọc số (analytics), hay thiết kế/diễn giải (dashboard)? Ba loại này cần ba kiểu context khác nhau.
Bước 2 — Chuẩn bị context tương ứng.
- SQL: dán schema (tên bảng, tên cột, kiểu dữ liệu, quan hệ khóa), nêu rõ dialect.
- Analytics: dán dữ liệu thật dạng bảng, kèm định nghĩa nghiệp vụ và ngưỡng tham chiếu nếu có.
- Dashboard: nêu ai xem, họ ra quyết định gì, giới hạn số lượng chỉ số.
Bước 4 — Bắt AI nêu giả định. Thêm câu: "Nếu yêu cầu có chỗ mơ hồ, hãy liệt kê các giả định của bạn trước khi trả lời." Đây là lá chắn chống lỗi im lặng.
Bước 5 — Kiểm chứng, đừng tin ngay. Với SQL: chạy thử trên môi trường an toàn, hoặc thêm LIMIT 10 trước khi chạy full. Với analytics: kiểm tra vài con số AI tính bằng tay hoặc bằng công thức Sheets. AI có thể tính sai số học, đặc biệt với dữ liệu lớn.
Bước 6 — Lặp lại có định hướng. Nếu SQL sai, đừng viết lại từ đầu — dán chính lỗi database trả về vào AI: "Câu query trên báo lỗi: [lỗi]. Sửa lại." Vòng lặp này nhanh và chính xác hơn nhiều.
Lỗi thường gặp & mẹo
Lỗi 1 — Quên schema. Đây là lỗi số một. AI đoán bừa tên bảng/cột. Mẹo: lưu sẵn schema của các bảng hay dùng thành một đoạn text để dán lại mỗi lần.
Lỗi 2 — Không nói dialect. SQL cho MySQL và cho BigQuery khác nhau ở hàm ngày (DATE_SUB vs DATE_ADD vs DATE_DIFF), ở cách xử lý chuỗi. Mẹo: luôn ghi dialect ngay dòng đầu.
Lỗi 3 — Tin số AI tính mà không kiểm. LLM giỏi diễn đạt nhưng có thể sai số học khi cộng/chia trên bảng lớn. Mẹo: với phép tính quan trọng, yêu cầu AI viết công thức để bạn tự tính trong Sheets, thay vì để nó tự cộng.
Lỗi 4 — Để AI bịa nguyên nhân. "Doanh thu giảm vì khách không hài lòng" — nghe hợp lý nhưng dữ liệu chưa chứng minh. Mẹo: thêm câu chặn "phân biệt rõ điều dữ liệu cho thấy và điều chỉ là giả thuyết".
Lỗi 5 — Dán dữ liệu nhạy cảm. Email, số điện thoại, thông tin cá nhân khách hàng không nên dán vào công cụ AI công cộng. Mẹo: ẩn danh dữ liệu (thay ID thật bằng ID giả) hoặc chỉ dán schema và số liệu tổng hợp, không dán dữ liệu cá nhân thô.
Mẹo nâng cao — few-shot cho SQL đặc thù. Nếu công ty bạn có quy ước riêng (ví dụ mọi bảng đều có cột is_deleted cần lọc), hãy đưa một câu query mẫu đúng chuẩn làm ví dụ. AI sẽ bắt chước phong cách và quy ước đó cho các query sau.
Bài tập thực hành
- SQL cơ bản: Tự viết schema cho một cửa hàng online tưởng tượng (bảng
products,orders,customers). Nhờ AI viết query "top 5 sản phẩm bán chạy nhất quý này theo doanh thu". Chạy thử (hoặc đọc kỹ) và kiểm tra AI có nêu giả định về "quý này" không.
- Phân tích: Lấy một bảng số liệu thật từ công việc của bạn (đã ẩn danh), dán vào AI với prompt yêu cầu tách "mô tả" và "diễn giải", cấm bịa nguyên nhân. So sánh kết quả với hiểu biết sẵn có của bạn — AI có bỏ sót hay bịa gì không?
- Dashboard: Chọn một vai trò cụ thể trong công ty bạn (trưởng phòng bán hàng chẳng hạn). Nhờ AI đề xuất 5 chỉ số cho dashboard của họ, kèm công thức. Đánh giá: bộ chỉ số này có thực sự giúp người đó ra quyết định hàng ngày không?
- Sửa lỗi lặp: Cố tình đưa cho AI một schema thiếu một bảng, rồi yêu cầu query cần bảng đó. Xem AI phản ứng thế nào — nó có nói ra rằng thiếu thông tin, hay im lặng bịa ra bảng?
Tóm tắt
Prompt cho tác vụ dữ liệu xoay quanh một sự thật đơn giản: AI không nhìn thấy dữ liệu của bạn, nó chỉ biết những gì bạn nói ra thành lời. Vì vậy chất lượng đầu ra tỷ lệ thuận với chất lượng context bạn cung cấp.
Với SQL generation, luôn đưa schema đầy đủ, nêu rõ dialect, và bắt AI nói ra giả định. Với analytics, dán dữ liệu thật, tách rõ mô tả khỏi diễn giải, và cấm bịa nguyên nhân khi dữ liệu chưa đủ. Với dashboard, khai báo rõ ai xem và họ ra quyết định gì để AI chọn đúng chỉ số.
Xuyên suốt cả ba, giữ nguyên tắc: nêu định dạng đầu ra rõ ràng, kiểm chứng con số thay vì tin ngay, lặp lại có định hướng bằng cách dán chính lỗi trả về, và bảo vệ dữ liệu nhạy cảm bằng cách ẩn danh. Làm chủ những khuôn mẫu này, bạn không chỉ tiết kiệm thời gian — bạn trao cho cả những người không biết code khả năng tự trả lời câu hỏi từ dữ liệu, và đó chính là lúc dữ liệu trong công ty bắt đầu thực sự tạo ra giá trị.