Đừng gọi LLM cho mọi bảng dữ liệu

Đừng gọi LLM cho mọi bảng dữ liệu

Một playbook giúp team builder quyết định khi nào dùng model tabular, khi nào giữ ML truyền thống, và triển khai sao cho không thắng demo nhưng thua production.

Có một tín hiệu khá lạ trong tuần này: một model nền tảng chuyên cho tabular data — dữ liệu dạng bảng như CRM, ERP, spreadsheet, database quan hệ — được đưa lên SageMaker JumpStart để deploy như một endpoint production.

Điểm đáng chú ý không phải là “lại thêm một model mới”. Điểm đáng chú ý là thị trường đang nói nhỏ với builder một câu hơi đau: không phải bài toán AI nào cũng nên bị kéo vào thế giới LLM.

Nhiều team Việt Nam đang có phản xạ khá quen: có dữ liệu khách hàng, có lịch sử giao dịch, có bảng churn, thế là hỏi “dùng LLM nào?”. Nhưng nếu output bạn cần là xác suất rời bỏ, rủi ro tín dụng, dự báo chuyển đổi, hay phân loại lead, thì gọi một model sinh chữ có khi giống vào boss fight mà cầm nhầm vợt cầu lông.

NEXUS của Fundamental xuất hiện trên Amazon SageMaker JumpStart là một market signal đáng soi: AI đang tách khỏi một trục duy nhất là text generation, quay lại phục vụ dữ liệu doanh nghiệp ở đúng hình dạng của nó — bảng.

Sơ đồ minh họa cho bài Đừng gọi LLM cho mọi bảng dữ liệu

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: chọn đúng lớp model trước khi deploy

Playbook này dành cho lúc team bạn đang đứng trước câu hỏi:

“Bài toán prediction trên dữ liệu bảng này nên dùng LLM, model tabular có sẵn, AutoML, hay train ML truyền thống?”

Sau bài này, mình muốn bạn đổi một cách nghĩ: deployment không bắt đầu từ endpoint, mà bắt đầu từ loại tín hiệu trong dữ liệu.

Nếu tín hiệu nằm trong quan hệ giữa các cột — ví dụ tần suất mua hàng, ngày tương tác cuối, số ticket support, loại gói dịch vụ — thì model cần giỏi đọc bảng. Nếu tín hiệu nằm trong văn bản dài, policy, email, log tự do, LLM mới có đất diễn nhiều hơn.

Một vài thuật ngữ cần neo nhanh:

Nói thẳng ra thì: LLM giỏi nói chuyện; tabular model giỏi nhìn bảng và ra quyết định dự đoán có thể kiểm chứng hơn.

Checklist trước khi bấm deploy

Trước khi mở SageMaker JumpStart hay viết pipeline, kéo team vào một checkpoint ngắn. Không cần họp hai tiếng, nhưng phải trả lời được mấy câu này:

| Câu hỏi | Nếu câu trả lời là “có” | Gợi ý hướng đi |
|---|---:|---|
| Dữ liệu chính nằm trong bảng có schema rõ? | Có | Ưu tiên tabular model / ML truyền thống |
| Output là class, score, xác suất, ranking? | Có | Tránh dùng LLM làm lớp prediction chính |
| Cần kết quả lặp lại để audit? | Có | Ưu tiên deterministic model |
| Team thiếu data scientist để làm feature engineering dài ngày? | Có | Thử model tabular có sẵn trước |
| Dữ liệu có text dài, luật nghiệp vụ, hội thoại? | Có | LLM hoặc hybrid pipeline đáng cân nhắc |
| Có yêu cầu latency/cost chặt? | Có | Benchmark endpoint thật, không chỉ notebook |

Hình dung thế này: bạn có bảng khách hàng gồm age, plan_type, last_login_date, monthly_spend, support_ticket_count, contract_end_date, và một cột churned. Nếu mục tiêu là dự đoán khách nào có nguy cơ rời bỏ, việc bắt LLM “đọc từng dòng rồi suy luận” thường không phải nước đi đầu tiên. Bạn cần một model biết học quan hệ đa chiều giữa các cột, ổn định qua nhiều lần chạy, và dễ đo bằng AUC, precision, recall, calibration.

Ba lựa chọn triển khai, đừng chọn theo tiếng ồn

1. Giữ ML truyền thống

Đây vẫn là lựa chọn mạnh nếu team bạn có dữ liệu sạch, pipeline ổn, và người biết xử lý feature. XGBoost, LightGBM, CatBoost hoặc AutoML nội bộ không tự nhiên lỗi thời chỉ vì có model mới.

Hợp khi:

Kẹt ở đâu:

2. Dùng Large Tabular Model qua managed endpoint

NEXUS trên SageMaker JumpStart đại diện cho hướng này: deploy một model nền tảng chuyên bảng, giảm thời gian đi từ dữ liệu đến prediction. AWS đang đặt nó cạnh các lựa chọn deployment quen thuộc, nghĩa là vendor muốn biến tabular prediction thành một workflow gần hơn với “chọn model, deploy, gọi endpoint”.

Hợp khi:

Kẹt ở đâu:

3. Dùng LLM hoặc custom frontier model

Nếu bài toán có nhiều ngôn ngữ tự nhiên, quy trình nội bộ, hoặc terminology riêng, hướng customize model như Amazon Nova Forge có lý do tồn tại. Nhưng đó là game khác: bạn sẽ phải quan tâm đến hyperparameter optimization — tinh chỉnh tham số huấn luyện như learning rate, batch size, data mixing ratio — để không cải thiện domain này rồi làm hỏng năng lực chung.

Hợp khi:

Kẹt ở đâu:

Một buổi chiều để kiểm chứng hướng tabular

Đừng bắt đầu bằng kiến trúc lớn. Làm một spike gọn trong một buổi chiều để xem hướng này có đáng farm exp tiếp không.

Bước 1: Chọn một bài toán prediction thật

Đừng dùng dataset trang trí. Lấy một bài toán có người business đang quan tâm:

Chốt rõ target column. Ví dụ: will_churn_30d, is_fraud, converted, renewed.

Bước 2: Đóng băng một bản dữ liệu nhỏ nhưng sạch

Tạo một file hoặc table snapshot gồm:

customer_id, plan_type, tenure_days, monthly_spend,
last_login_days_ago, support_ticket_count,
region, contract_end_days, will_churn_30d

Tách train/test theo thời gian nếu có thể. Với prediction doanh nghiệp, random split nhiều khi làm bạn tự lừa mình, vì tương lai bị rò vào quá khứ.

Bước 3: Deploy endpoint thử nghiệm trên SageMaker JumpStart

Trong SageMaker JumpStart, tìm model tabular tương ứng, deploy thành endpoint thử nghiệm. Mục tiêu chưa phải production hardening, mà là có một đường gọi inference đủ thật để đo.

Ví dụ gọi endpoint bằng Python, dùng tên endpoint giả định:

import boto3
import json

runtime = boto3.client("sagemaker-runtime")

payload = {
    "instances": [
        {
            "plan_type": "pro",
            "tenure_days": 420,
            "monthly_spend": 120,
            "last_login_days_ago": 14,
            "support_ticket_count": 3,
            "region": "VN",
            "contract_end_days": 45
        }
    ]
}

response = runtime.invoke_endpoint(
    EndpointName="your-tabular-endpoint",
    ContentType="application/json",
    Body=json.dumps(payload)
)

print(response["Body"].read().decode("utf-8"))

Bước 4: So với baseline ngu mà thật

Baseline không cần oai. Có thể là:

Bạn cần trả lời: model mới có cải thiện quyết định không? Ví dụ minh họa: nếu đội sales chỉ gọi được 500 khách mỗi tuần, ranking churn có giúp chọn 500 người đáng gọi hơn rule cũ không?

Bước 5: Gắn observability từ ngày đầu

Observability là khả năng quan sát hệ thống khi chạy thật: latency, lỗi, chi phí, chất lượng output. Với tabular prediction, đừng chỉ log 200 OK.

Theo dõi ít nhất:

Nếu bạn đang chạy container inference lớn, các tối ưu như SOCI index — cơ chế tải từng phần container thay vì kéo toàn bộ image ngay từ đầu — đáng để mắt tới khi cold start làm endpoint scale chậm. Không phải spike nào cũng cần, nhưng production thì thường bị mấy phút chờ vô duyên cắn vào chi phí.

Pitfall: thắng notebook, thua vận hành

Có bốn bẫy mình thấy team builder dễ dính.

Một là dùng LLM làm máy dự đoán bảng chỉ vì API tiện. Nếu bạn phải prompt cả một row rồi parse câu trả lời, hãy tự hỏi: mình đang giải bài toán prediction hay đang dựng một mini game rủi ro JSON?

Hai là tin deterministic quá mức. Kết quả lặp lại giúp audit tốt hơn, nhưng nếu dữ liệu lệch, label sai, hoặc target bị rò, model vẫn sai đều đều.

Ba là bỏ qua incentive của vendor. AWS đang đẩy nhiều nhánh: tabular model qua SageMaker, customization qua Nova Forge, multimodal qua Bedrock, observability cho inference, tối ưu cold start cho container. Tín hiệu thị trường ở đây là: cloud provider muốn gom AI workflow về managed stack. Team Việt Nam nên tận dụng tốc độ, nhưng đừng để kiến trúc bị khóa trước khi biết workload thật.

Bốn là không định nghĩa quyết định sau prediction. Score churn 0.83 để làm gì? Gọi điện, giảm giá, tạo ticket CS, hay đưa vào dashboard cho đẹp? Prediction không gắn action thì chỉ là thanh máu boss hiện lên nhưng cả đội đứng nhìn.

Nếu là mình, mình sẽ chọn thế này

Với team đang có dữ liệu bảng rõ ràng và cần ra production nhanh, mình sẽ đi theo thứ tự:

  1. Baseline hiện tại: rule hoặc model cũ, đo bằng metric gắn với quyết định.
  2. Spike Large Tabular Model: deploy nhanh, so với baseline trên test set tử tế.
  3. ML truyền thống có kiểm soát: nếu cần explainability sâu, tối ưu chi phí, hoặc custom logic.
  4. LLM/hybrid: chỉ thêm khi có text dài, reasoning, hoặc cần biến dữ liệu phi cấu trúc thành feature.
  5. Custom model training: chỉ khi domain đủ lớn, dữ liệu đủ giàu, và team chịu được vòng tuning + evaluation.

Câu trả lời rõ nhất cho builder: đừng hỏi “model nào mới nhất?”, hãy hỏi “dữ liệu của mình đang mang tín hiệu ở dạng nào?”

Bảng thì xử như bảng. Text thì xử như text. Còn nếu gặp boss fight production, nhớ mang đúng vũ khí trước khi khoe skin.

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

Nguồn tham khảo