Tại sao AI "nói hay nhưng tính sai" — và cách kết hợp AI với Data Analytics đúng cách

Note nhỏ trước khi vào bài: Bài này đúng ra phải là phần tiếp theo của series về Google Antigravity và Claude Code mà tôi đang ấp ủ. Nhưng trong lúc đang chuẩn bị, tôi thấy một chủ đề xuất hiện trở lại rất nhiều — cả trong các cuộc trò chuyện với khách hàng, lẫn trong cộng đồng Data Analytics. Và nó lại đúng cái tôi đang làm thực tế. Nên thôi, bài đó để sau. Bài này phải viết ngay.

🤔 Câu chuyện bắt đầu từ một câu hỏi rất thật

Tuần trước, trong buổi workshop với một nhóm doanh nghiệp, có một anh quản lý hỏi tôi:

"Đức ơi, tôi muốn nhân viên của tôi hỏi ChatGPT về doanh số, về tồn kho, về KPI — và nó trả lời được luôn. Vậy tôi phải làm thế nào?"

Tôi hỏi lại: "Anh đã thử chưa?"

Anh gật đầu: "Thử rồi. Nó trả lời rất tự tin. Nhưng số liệu sai hoàn toàn."

Đó là điểm xuất phát của bài viết này.

Câu chuyện này không phải của riêng anh đó. Nó là câu chuyện của hàng trăm doanh nghiệp Việt Nam đang trong giai đoạn "muốn dùng AI cho dữ liệu" nhưng chưa hiểu rõ mình đang muốn gì, và AI thực sự có thể làm gì.

Các bạn hãy cùng lắng nghe đoạn hội thoại giữa AI về vấn đề này nhé:

😵 Nhầm lẫn phổ biến nhất: Tưởng AI biết tính toán

Hầu hết doanh nghiệp khi nghĩ đến "AI + Data" đều hình dung như thế này:

"Tôi chỉ cần kết nối ChatGPT với database, rồi hỏi nó bất cứ thứ gì — nó sẽ tự truy vấn và trả lời."

Nghe rất hợp lý. Nhưng có một vấn đề căn bản.

LLM — tức là các mô hình ngôn ngữ lớn như ChatGPT, Claude, Gemini — không phải là cỗ máy tính. Chúng là cỗ máy dự đoán ngôn ngữ. Chúng được huấn luyện để đoán "từ tiếp theo nên là gì" dựa trên hàng tỷ đoạn văn bản. Khi bạn hỏi "doanh số tháng này là bao nhiêu", nó không truy vấn database của bạn — nó tạo ra một câu trả lời nghe có vẻ hợp lý, dựa trên pattern ngôn ngữ nó đã học.

Hiện tượng này có tên kỹ thuật là hallucination — mô hình tự bịa ra thông tin với độ tự tin cao.

Và đây là lý do tại sao hầu hết các pilot "AI + BI" đầu tiên đều thất bại: người ta kỳ vọng AI biết tính toán, nhưng thực ra AI chỉ biết nói.

🛠️ Các công cụ BI/Data lớn đang làm gì với AI?

Trước khi đi vào kiến trúc kỹ thuật, tôi muốn điểm qua nhanh những gì các nền tảng lớn đang làm — vì đây là những thứ anh em đang dùng hàng ngày.

Power BI + Copilot (Microsoft)

Microsoft đang tích hợp Copilot trực tiếp vào Power BI và Microsoft Fabric. Tính năng nổi bật nhất: bạn có thể hỏi bằng ngôn ngữ tự nhiên để tạo ra visual, viết DAX measure, hoặc tóm tắt báo cáo.

Nhưng điều quan trọng cần hiểu: Copilot trong Power BI không tự truy vấn database raw. Nó làm việc thông qua Semantic Model (trước đây gọi là Dataset) — một lớp trừu tượng đã định nghĩa sẵn các metric, relationship, measure. AI chỉ được phép "nói chuyện" với lớp này, không phải với data thô.

Đây chính xác là thiết kế đúng — và tôi sẽ giải thích tại sao ngay bên dưới.

Microsoft Fabric + AI Skills

Fabric đang đẩy mạnh tính năng AI Skills — cho phép bạn tạo một "AI assistant" được kết nối với Lakehouse hoặc Warehouse của tổ chức. Cơ chế: bạn định nghĩa schema, context, và các câu hỏi mẫu — AI học từ đó và trả lời câu hỏi người dùng bằng cách tự sinh SQL rồi thực thi.

Một bước tiến đáng chú ý. Nhưng vẫn cần được thiết kế đúng để không bị "tự do quá mức".

Tableau + Tableau AI (Salesforce Einstein)

Tableau đang tích hợp Einstein AI để hỗ trợ Ask Data — đặt câu hỏi ngôn ngữ tự nhiên và nhận visual tự động. Ngoài ra còn có Explain Data — tự động phân tích tại sao một điểm dữ liệu bất thường lại xuất hiện.

Tableau làm khá tốt ở tầng semantic mapping: nó cho phép bạn định nghĩa từ đồng nghĩa, từ nghiệp vụ — giúp AI hiểu "doanh thu" và "revenue" là một thứ.

Databricks + Genie (AI/BI)

Databricks ra mắt Genie — một data assistant cho phép người dùng đặt câu hỏi bằng ngôn ngữ tự nhiên và nhận câu trả lời từ dữ liệu trong Lakehouse. Điểm mạnh của Genie: nó kết hợp với Unity Catalog để có data governance rõ ràng, và dùng certified answers — tức là những câu hỏi đã được data team xác nhận đáp án đúng để AI học theo.

🧱 Hai khái niệm kỹ thuật anh em cần nắm

Đây là phần nhiều người bỏ qua — và đó là lý do họ triển khai AI data app sai.

Deterministic — "Kết quả phải đoán được"

Deterministic có nghĩa: cùng một input, luôn luôn cho ra cùng một output.

SQL là deterministic. DAX là deterministic. Python script tính KPI là deterministic. Bạn chạy đi chạy lại 1000 lần, kết quả luôn như nhau nếu data không thay đổi.

Ngược lại, LLM là non-deterministic — cùng một câu hỏi, câu trả lời có thể khác nhau giữa các lần chạy. Không phải vì sai, mà vì bản chất xác suất của mô hình.

Tại sao điều này quan trọng? Vì trong banking, tài chính, kiểm toán — người ta cần chứng minh con số đến từ đâu. Kiểm toán viên hỏi "con số 48.7 tỷ này tính thế nào?" — bạn phải chỉ ra được SQL query, timestamp, người chạy. Không thể trả lời "AI nói vậy".

💡 Nguyên tắc vàng: Mọi con số trong báo cáo tài chính phải đến từ tầng deterministic. LLM không được phép "tự tính" bất kỳ con số nào.

Harness — "Bộ khung kiểm soát AI"

Harness là bộ khung bao quanh một LLM để kiểm soát những gì nó được làm và không được làm.

Hãy nghĩ đơn giản thế này: LLM giống một nhân viên mới rất thông minh, nói chuyện rất hay, nhưng hay "sáng tạo" số liệu. Harness là quy trình làm việc bắt buộc nhân viên đó phải tuân theo — chỉ được dùng data từ nguồn chính thức, phải ghi lại mọi bước, kết quả phải qua xét duyệt trước khi gửi.

Một Harness trong data application thường gồm:

• Intent Layer — LLM đọc câu hỏi, hiểu người dùng muốn gì
• Tool Layer — Danh sách công cụ LLM được phép gọi (SQL, API, calculator…)
• Execution Layer — Nơi thực thi deterministic: SQL chạy trên database thật
• Validation Layer — Kiểm tra output trước khi trả về
• Presentation Layer — LLM diễn giải kết quả bằng ngôn ngữ tự nhiên

Hình dung như một nhà hàng: khách gọi món (người dùng), phục vụ ghi phiếu (Intent Layer), bếp nấu theo công thức chuẩn (Execution Layer), kiểm tra món trước khi mang ra (Validation), rồi phục vụ giới thiệu món (Presentation). Không ai để bếp tự quyết định khách muốn ăn gì. Không ai để phục vụ tự nấu.

🏗️ Kiến trúc 5 tầng — Và mapping vào công cụ thực tế

Đây là kiến trúc tôi đang dùng và tư vấn cho khách hàng. Không phải lý thuyết — đây là những gì đang chạy trong production.

[Người dùng — Câu hỏi tiếng Việt tự nhiên]
              ↓
[Tầng 1 — Intent & Semantic]   ← LLM hiểu câu hỏi
              ↓
[Tầng 2 — Query Generation]    ← LLM sinh SQL/DAX
              ↓
[Tầng 3 — Execution]           ← DETERMINISTIC: chạy trên data thật
              ↓
[Tầng 4 — Validation]          ← Kiểm tra schema, logic, range
              ↓
[Tầng 5 — Presentation]        ← LLM diễn giải kết quả
              ↓
[Câu trả lời có số liệu đáng tin cậy]

Mapping vào công cụ thực tế:

Semantic Layer — lớp quan trọng nhất trong toàn bộ kiến trúc — chính là thứ đảm bảo Tầng 3 luôn deterministic. Trong Power BI đó là Semantic Model với các measure DAX đã định nghĩa. Trong Databricks đó là Unity Catalog. Trong dbt đó là Semantic Layer với metrics được version-controlled.

LLM không được phép "tự sáng tạo" công thức tính. Nó chỉ được phép gọi các metric đã được data team định nghĩa sẵn.

🎓 Cách tôi đưa điều này vào giảng dạy tại KPIM Academy

Phần này là phần tôi muốn chia sẻ thật nhất — vì đây là thứ tôi đang làm, không phải thứ tôi nghe ở đâu đó.

Cách 1 — Harness đơn giản với NotebookLM, ChatGPT Projects cho newbie

Với học viên mới, không cần build hệ thống phức tạp. Tôi dạy họ tạo một "AI Query Assistant" đơn giản bằng cách:

Bước 1 — Định nghĩa Data Schema. Upload schema của database vào ChatGPT Project hoặc NotebookLM. Không phải data thật — chỉ cần cấu trúc bảng, tên cột, mô tả ý nghĩa từng cột.

Bước 2 — Định nghĩa Semantic Model đơn giản. Mô tả các khái niệm nghiệp vụ: "doanh thu" = SUM(so_luong * don_gia), "khách hàng active" = những khách có giao dịch trong 90 ngày gần nhất...

Bước 3 — Thêm Guardrails bằng System Prompt. Ví dụ: "Bạn chỉ được dùng các bảng và cột đã được liệt kê. Không được tự sáng tạo tên bảng. Luôn trả về SQL có thể chạy được trực tiếp."

Bước 4 — Test và iterate. Học viên hỏi bằng tiếng Việt, AI trả về SQL, học viên chạy thử, kiểm tra kết quả.

Kết quả: học viên vừa học SQL vừa hiểu nghiệp vụ, tốc độ viết query tăng gấp 3–5 lần. Quan trọng hơn — họ học được cách đọc và kiểm tra SQL, không phải blindly tin vào AI.

🎯 Mục tiêu không phải là để AI thay thế việc viết SQL. Mục tiêu là dùng AI như một "pair programmer" giúp học viên học nhanh hơn và hiểu sâu hơn.

Cách 2 — Agent với MCP Tool Execution cho người muốn đi xa hơn

Với học viên đã có nền tảng, tôi dạy cách xây một agent thật sự:

Thiết lập Agent Skills: Định nghĩa các "skill" mà agent có thể làm — ví dụ get_sales_by_month, get_top_customers, compare_periods. Mỗi skill là một function Python hoặc SQL procedure đã được test kỹ.

Kết hợp Harness Layer: System prompt xác định rõ agent chỉ được gọi các skill đã định nghĩa. Không được tự sáng tạo logic ngoài danh sách đó.

MCP Tool Execution: Dùng Model Context Protocol (MCP) để kết nối agent với database thật — SQL Server, Fabric, PostgreSQL. Agent gọi tool, tool execute query, trả kết quả về cho agent diễn giải.

Ví dụ flow thực tế:

User: "Top 5 khách hàng doanh thu tháng này?"
Agent: [Gọi skill get_top_customers với params: period=current_month, limit=5]
Tool: [Execute SQL, trả về JSON với 5 dòng data thật]
Agent: "5 khách hàng có doanh thu cao nhất tháng 4/2026 là: ..."

Tôi đang dạy pattern này trong KPIM Academy và triển khai cho khách hàng — từ chuỗi bán lẻ thời trang đến ngân hàng. Nguyên tắc giống nhau, quy mô khác nhau.

💬 Góc nhìn thẳng thắn: Khi nào NÊN và KHÔNG NÊN

Sau khi triển khai nhiều dự án thực tế, đây là những gì tôi học được:

✅ Nên dùng AI cho Data khi:

• Người dùng cần tự phục vụ (self-service BI) mà không biết SQL
• Cần tóm tắt, diễn giải, kể chuyện từ số liệu
• Cần gợi ý insight bất thường, anomaly detection
• Hỗ trợ data analyst viết query nhanh hơn

❌ Không nên (hoặc cần cực kỳ cẩn thận) khi:

• Báo cáo tài chính, kiểm toán, compliance — số phải đúng tuyệt đối
• Hệ thống real-time risk management
• Môi trường không có semantic layer được định nghĩa rõ
• Team chưa có khả năng verify output của AI

⚠️ Sai lầm tôi thấy nhiều nhất:

• Để AI truy cập raw database không có guardrails
• Không có validation layer — tin AI luôn 100%
• Không log lại tool calls và outputs — không audit được
• Kỳ vọng AI thay thế data analyst thay vì augment họ

🚀 Bắt đầu từ đâu nếu anh/chị muốn làm điều này?

Không cần build hệ thống phức tạp ngay. Tôi suggest lộ trình 3 bước:

Bước 1 — Xây Semantic Foundation trước. Định nghĩa rõ các metric, KPI, business terms của tổ chức. Không có cái này, AI sẽ hiểu sai nghiệp vụ dù technical đúng.

Bước 2 — Pilot với một use case hẹp. Chọn một loại câu hỏi cụ thể, xây harness cho nó, test kỹ trước khi mở rộng. Đừng build "hỏi gì cũng được" ngay từ đầu.

Bước 3 — Đo lường và iterate. Tạo bộ câu hỏi test chuẩn (golden dataset), chạy định kỳ để đảm bảo AI vẫn trả lời đúng sau mỗi lần cập nhật.

🧠 Kết luận — Một câu để nhớ

Nếu anh/chị chỉ nhớ được một điều từ bài này:

"Dùng AI để hiểu câu hỏi và kể câu chuyện. Dùng code để tính toán. Đừng để AI làm việc của nhau."

AI + Data Analytics không phải là chuyện kết nối ChatGPT vào database rồi hỏi thoải mái. Nó là chuyện thiết kế một kiến trúc có tầng lớp rõ ràng, nơi mỗi thành phần làm đúng việc của mình.

Khi anh hiểu điều đó — anh sẽ biết tại sao những pilot AI thất bại và cách làm cho chúng thành công.

Bài tiếp theo tôi sẽ quay lại series Google Antigravity + Claude Code như đã hứa. Nhưng nếu anh/chị muốn tìm hiểu sâu hơn về cách xây AI Data App đúng cách — hoặc muốn áp dụng vào tổ chức của mình — có thể kết nối với tôi qua KPIM hoặc theo dõi các khóa học tại COMPA Class.