Thực hành: đưa kết quả mô hình AI lên Power BI, Looker hoặc Streamlit, bắt đầu từ một bảng bốn cột

Thử hình dung: mô hình đã chạy xong, điểm dự đoán đã nằm trong warehouse, vậy mà ba tuần sau trưởng phòng kinh doanh vẫn chưa mở ra xem lần nào. Trong tình huống như vậy, chỗ hỏng không nằm ở mô hình. Nó nằm ở chỗ kết quả chưa xuất hiện trên màn hình mà người ra quyết định nhìn vào mỗi ngày.

Màn hình đó thường thuộc một công cụ BI. IBM định nghĩa BI là tập hợp các quy trình công nghệ để thu thập, quản lý và phân tích dữ liệu của tổ chức. IBM cũng nhấn mạnh BI mang tính mô tả: nó giải thích chuyện đã xảy ra để giúp ra quyết định tốt hơn. Kết quả AI thì nhìn theo hướng ngược lại.

Theo cách phân loại của CareerFoundry, phân tích dự đoán (predictive) tìm cách đoán điều có khả năng xảy ra trong tương lai. Như vậy, bạn đang đặt một con số về tương lai vào một công cụ được làm ra để kể về quá khứ.

Hướng dẫn dưới đây đi qua từng bước để làm việc đó cho đúng. Ví dụ xuyên suốt là một tình huống giả định: điểm rủi ro rời bỏ (churn) của khách hàng ở một công ty viễn thông.

Bạn sẽ dựng gì, và cần chuẩn bị gì?

Bạn sẽ làm ra hai thứ. Thứ đầu tiên là một bảng đầu ra AI mà công cụ BI nào cũng đọc được. Thứ hai là một app Streamlit đọc bảng đó, dùng làm bản demo trước khi đưa vào Power BI hoặc Looker của khách hàng.

App demo có thể xong khá nhanh. Phần tích hợp vào BI của khách thì cần lên kế hoạch riêng, như Bước 5 sẽ nói.

Bạn cần Python, pandas, một bảng điểm (có thể bắt đầu bằng file CSV xuất từ warehouse; tutorial của Streamlit dùng BigQuery làm ví dụ) và quyền đọc bảng đó. Streamlit là framework Python mã nguồn mở, làm ra cho data scientist và kỹ sư AI/ML. Nếu bạn đã quen pandas thì không cần học thêm frontend.

Bước 1: Tại sao phải thiết kế bảng trước khi chọn công cụ?

Lỗi đầu tiên, và cũng là lỗi tốn kém nhất, là đổ thẳng output của notebook vào dashboard. Muốn dùng lâu dài, một bảng điểm churn nên có ít nhất bốn cột sau. Đây là gợi ý thiết kế, không phải chuẩn của nhà cung cấp nào.

-- Giản lược: schema gợi ý cho bảng đầu ra mô hình
customer_id     STRING,
churn_score     FLOAT,     -- dự đoán, từ 0 đến 1
model_version   STRING,    -- ví dụ 'churn-v3'
scored_at       TIMESTAMP  -- thời điểm chấm điểm

Hai cột cuối là phần dân data science hay bỏ qua, trong khi người làm BI lại cần nhất. Giả sử trưởng phòng hỏi “sao tuần này khách A từ 0,2 lên 0,8?”. Không có model_version, bạn không phân biệt được khách thay đổi hay mô hình thay đổi. Không có scored_at, không ai biết con số đã cũ bao lâu.

Kiểm tra sau bước này: chạy một query đếm số dòng theo model_version. Nếu chỉ thấy đúng một phiên bản thì bạn đang ghi đè lịch sử. Hãy quyết định ngay từ bây giờ có giữ lịch sử hay không.

Bước 2: Dựng prototype Streamlit hiển thị khách rủi ro cao

Trước khi động vào hệ thống BI của khách, bạn nên có một bản demo chạy được. Việc đầu tiên là credential. Streamlit đọc secrets từ file .streamlit/secrets.toml trong thư mục gốc của app, nhờ vậy key không bao giờ phải nằm trong code.

mkdir -p .streamlit
touch .streamlit/secrets.toml
echo ".streamlit/secrets.toml" >> .gitignore

Nội dung file secrets thì làm theo đúng hướng dẫn kết nối của warehouse bạn dùng. Với BigQuery, tutorial của Streamlit ghi cụ thể cần dán những gì. Tiếp theo là app tối thiểu: đọc bảng điểm, hiện thời điểm chấm điểm mới nhất ở đầu trang, rồi hiện 20 khách rủi ro cao nhất.

import pandas as pd
import streamlit as st

# Giản lược: đọc từ CSV xuất từ warehouse.
# Khi nối warehouse thật, thay pd.read_csv bằng client theo tutorial BigQuery.
@st.cache_data(ttl=600)
def load_scores(path):
    return pd.read_csv(path, parse_dates=["scored_at"])

df = load_scores("churn_scores.csv")

st.write("Dự đoán rủi ro rời bỏ, chấm điểm lúc:", df["scored_at"].max())
top = df.sort_values("churn_score", ascending=False).head(20)
st.write(top[["customer_id", "churn_score", "model_version"]])

Chạy bằng streamlit run app.py là bạn có một bảng xếp hạng kèm dòng ghi thời điểm chấm điểm. Phần quan trọng nhất là decorator st.cache_data.

Theo tài liệu Streamlit, khi có st.cache_data, query chỉ chạy lại khi câu query thay đổi hoặc sau 10 phút, và ttl=600 (600 giây) quy định khoảng thời gian đó.

Nếu không cache, mỗi lần người xem bấm một bộ lọc sẽ là một lần query tốn tiền vào warehouse.

Kiểm tra sau bước này: thêm tạm một dòng print trong load_scores, tải lại trang vài lần và xem terminal. Nếu dòng đó in ra ở mỗi lần tải thì cache chưa có tác dụng. Khi đã nối warehouse thật, hãy xem thêm lịch sử query trên warehouse.

Bước 3: Chỉnh ttl theo nhịp chạy của mô hình

Đừng giữ nguyên ttl=600 chỉ vì tutorial dùng con số đó. Tài liệu Streamlit ghi rõ: nếu database cập nhật thường xuyên hơn thì cần chỉnh ttl hoặc bỏ cache.

Áp vào ví dụ churn: nếu mô hình chấm điểm mỗi đêm một lần thì ttl=600 đã quá đủ, bạn có thể đặt dài hơn. Còn với một mô hình chống gian lận chấm điểm liên tục, cache 10 phút có thể khiến người vận hành thấy một giao dịch đáng ngờ trễ tới 10 phút.

Vì thế hãy hỏi nhịp chạy của pipeline trước, rồi mới chọn con số. Dòng scored_at ở đầu app cũng có tác dụng ở đây: người xem tự biết số liệu cũ bao lâu và sẽ ít phải hỏi bạn hơn.

Bước 4: Deploy để có một đường link

Streamlit có Community Cloud, nền tảng miễn phí để deploy và chia sẻ app. Nếu dùng dữ liệu thật của khách hàng, bạn phải hỏi chính sách bảo mật của họ trước. Nếu dùng dữ liệu giả lập hoặc dữ liệu công khai, đây là cách nhanh nhất để có một đường link đưa vào portfolio.

Bước 5: Khi nào chuyển sang Power BI hay Looker?

Prototype Streamlit giúp khách hàng gật đầu. Nhưng dashboard dùng hằng ngày thường phải nằm trong công cụ BI mà họ đã trả tiền. Hai lựa chọn phổ biến có cách làm khá khác nhau.

	Power BI	Looker	Streamlit
Đưa bảng AI vào bằng cách	Kết nối nguồn dữ liệu cloud hoặc on-premises	Mô tả bảng bằng LookML	Viết Python query trực tiếp
Điểm mạnh	Copilot dựng báo cáo từ yêu cầu bằng ngôn ngữ tự nhiên	Có API và nhiều cách embed dữ liệu	Nhanh, hợp với kỹ sư AI/ML
Cần hỏi trước	Tính năng phụ thuộc SKU và capacity	Ai bên khách viết và duyệt LookML	Có được phép host bên ngoài không

Với Power BI, Microsoft cho biết công cụ kết nối được dữ liệu từ mọi nguồn, cả cloud lẫn on-premises, và Copilot cho phép mô tả báo cáo mình cần bằng ngôn ngữ tự nhiên. Nhưng Microsoft cũng ghi rõ: có tính năng nào hay không phụ thuộc vào cả SKU lẫn mức capacity. Đừng demo Copilot cho khách khi chưa biết họ dùng license nào.

Google mô tả Looker là sản phẩm để khám phá, chia sẻ và trực quan hóa dữ liệu của công ty. Phần mô hình hóa dùng LookML, ngôn ngữ mô tả dữ liệu SQL và các tùy chọn dành cho người dùng.

Vì thế bảng điểm churn của bạn chỉ khám phá được trong Looker sau khi đã được mô hình hóa bằng LookML. Việc này phải nằm trong kế hoạch dự án, không phải chuyện cấu hình năm phút.

Với Tableau hay bất kỳ công cụ nào khác, nguyên tắc vẫn vậy: bảng ở Bước 1 càng sạch thì việc kết nối càng nhẹ.

Những lỗi nào hay gặp nhất?

Lỗi phổ biến nhất là đặt điểm dự đoán cạnh doanh thu thực tế mà không ghi nhãn, khiến người xem tưởng cả hai đều là số đã xảy ra. Hãy đặt tiêu đề kiểu “Dự đoán rủi ro rời bỏ, mô hình churn-v3” thay vì chỉ ghi “Churn”.

Lỗi thứ hai là commit secrets.toml lên git. Lỗi thứ ba là để cache lâu hơn nhịp chạy của mô hình rồi thắc mắc vì sao số liệu không đổi. Lỗi cuối cùng là hứa một tính năng Power BI trước khi kiểm tra SKU.

Kỹ năng này thể hiện ra sao khi làm với khách hàng và trên CV?

Khi làm với khách hàng, câu đầu tiên bạn nên hỏi không phải “dùng mô hình gì” mà là “sáng thứ Hai anh chị mở màn hình nào?”. Câu trả lời sẽ quyết định bạn làm Power BI, viết LookML hay dựng một app Streamlit.

Trên CV, một dòng như “dựng app Streamlit hiển thị điểm churn kèm phiên bản mô hình và thời điểm chấm điểm, cache theo nhịp pipeline”, có kèm đường link, thuyết phục hơn nhiều so với chữ “Streamlit” đứng trơ trọi trong mục kỹ năng.

Một mô hình tốt mà không ai mở ra xem thì cũng như chưa deploy. Muốn nó được mở ra, hãy bắt đầu từ những chi tiết nhỏ: một bảng bốn cột, một con số ttl khớp nhịp pipeline và một dòng nhãn ghi rõ chữ “dự đoán”.