Làm Cùng Long.
← Quay lại Kho ghi chú
Data & BI · 10 phút đọc ·

BigQuery Augmented Analytics TVFs: khi phân tích trở thành primitive cho AI agent

Một trong những câu hỏi khó nhất khi đưa AI vào data analytics không phải là:

“Model có viết SQL được không?”

Mà là:

Model có biết phải dùng phương pháp phân tích nào cho đúng câu hỏi không?

Ví dụ ba câu sau nghe khá giống nhau:

  • Vì sao doanh thu tăng?
  • Biến nào đi cùng với doanh thu?
  • Một chương trình khuyến mãi có thật sự làm doanh thu tăng không?

Nhưng chúng không phải cùng một bài toán.

Câu thứ nhất nghiêng về driver analysis.

Câu thứ hai là correlation.

Câu thứ ba là causal effect.

Nếu agent coi ba thứ là một, câu trả lời có thể trông rất thuyết phục nhưng sai về bản chất.

BigQuery vừa bổ sung sáu augmented analytics Table-Valued Functions — TVFs — để chuẩn hóa một số câu hỏi phân tích thường gặp. Google còn nhấn mạnh rằng các hàm này tạo structured SQL outputs và có thể được tích hợp thành skills cho AI agents.

Đó là phần khiến cập nhật này đáng chú ý hơn một bộ hàm SQL mới.

Mục lục

1. Sáu TVF mới giải quyết sáu loại câu hỏi khác nhau

Google giới thiệu sáu hàm.

AI.KEY_DRIVERS

Tìm các yếu tố nổi bật đi cùng sự tăng/giảm của một metric giữa hai giai đoạn hoặc hai nhóm.

Câu hỏi mẫu:

“Vì sao revenue quý này khác quý trước?”

AI.CAUSAL_EFFECT

Ước lượng ảnh hưởng của một action/event bằng cách so kết quả quan sát với baseline kỳ vọng.

Câu hỏi mẫu:

“Bao nhiêu phần của revenue lift có thể gắn với thay đổi giá thay vì tăng trưởng tự nhiên?”

ML.CORRELATION

Đánh giá hướng và độ mạnh của mối liên hệ giữa các cặp metric số.

ML.DETECT_CHANGE_POINTS

Tìm những thời điểm hoặc khoảng mà pattern của metric thay đổi đáng kể so với phần xung quanh.

ML.TREND

Tách hướng tăng/giảm nền khỏi nhiễu và dao động ngắn hạn.

ML.SEASONALITY

Tìm chu kỳ lặp lại theo giờ, ngày, tuần, tháng hoặc quý.

Sáu hàm không cạnh tranh nhau.

Chúng tạo thành một “hộp công cụ chẩn đoán”.

Và phần quan trọng là agent phải chọn đúng dụng cụ cho đúng câu hỏi.

2. KEY_DRIVERS không đồng nghĩa với causal effect

Đây là điểm tôi thấy dễ bị hiểu sai nhất.

Giả sử revenue tăng 20%.

KEY_DRIVERS có thể giúp chỉ ra rằng phần tăng tập trung ở:

  • mobile;
  • brand A;
  • khu vực HCM;
  • khách cũ;
  • nhóm sản phẩm giá cao.

Đó là thông tin rất có giá trị.

Nhưng nó chưa trả lời:

“Brand A tăng vì campaign mới hay không?”

Driver analysis có thể cho biết nơi thay đổi xuất hiện hoặc đặc trưng nào gắn với thay đổi.

Causal analysis cố trả lời câu hỏi khó hơn: nếu action đó không xảy ra, outcome kỳ vọng sẽ là gì?

Hai lớp khác nhau:

What moved together?
≠
What caused what?

Trong marketing, nhầm hai lớp này rất phổ biến.

Ví dụ Brand Search tăng cùng doanh thu không chứng minh Brand Search tạo ra toàn bộ phần tăng.

Có thể cả hai cùng tăng vì một chiến dịch TV, mùa cao điểm, khuyến mãi hoặc nhu cầu thị trường.

Nguyên tắc: KEY_DRIVERS là công cụ chẩn đoán, không phải giấy phép để tuyên bố causal.

3. Correlation vẫn chỉ là correlation

ML.CORRELATION giúp đo direction và strength của relationship giữa metric.

Điều này hữu ích để khám phá.

Ví dụ:

  • CPC và conversion rate;
  • impression và branded search;
  • session duration và LTV;
  • discount rate và units sold.

Nhưng correlation dễ bị lạm dụng.

Ba khả năng cơ bản:

A ảnh hưởng B

Có thể.

B ảnh hưởng A

Cũng có thể.

C có một biến thứ ba ảnh hưởng cả A và B

Rất thường xuyên.

Ví dụ số người tìm “đồng hồ Saga” và doanh thu Saga cùng tăng.

Có thể Search tạo doanh thu.

Cũng có thể event 20/10 làm cả search demand lẫn doanh thu tăng.

Một agent analytics nên biết giới hạn này và dùng ngôn ngữ đúng mức.

Nên nói:

“Có mối tương quan mạnh cần điều tra tiếp.”

Không nên nhảy thành:

“X làm Y tăng.”

4. Trend, seasonality và change point nên được tách riêng

Ba khái niệm này cũng rất hay bị trộn.

Trend

Hướng dài hơn.

Ví dụ CPA tăng dần suốt 12 tuần.

Seasonality

Pattern lặp lại.

Ví dụ cuối tuần traffic cao hơn, hoặc tháng 11–12 luôn tăng nhu cầu.

Change point

Một thời điểm cấu trúc thay đổi.

Ví dụ từ ngày 15/9 conversion rate chuyển sang một mặt bằng thấp hơn hẳn.

Nếu không tách, chúng ta dễ tối ưu sai.

Một đợt CPA tăng có thể là:

  • xu hướng xấu dần;
  • mùa vụ bình thường;
  • một change point do tracking;
  • một spike ngắn hạn.

Cả bốn nhìn trên dashboard đều có thể chỉ hiện thành “CPA tăng”.

Nhưng action khác nhau hoàn toàn.

Trend → xem nguyên nhân dài hạn.
Seasonality → lập kế hoạch trước.
Change point → tìm event gần thời điểm gãy.
Spike ngắn → có thể chỉ cần chờ thêm dữ liệu.

5. Vì sao TVF phù hợp với AI agent?

Google đưa ra hai đặc tính đáng chú ý.

Chạy ngay nơi dữ liệu nằm

Không cần export ra tool khác cho từng bước phân tích.

Điều này giảm:

  • data movement;
  • copy dữ liệu tạm;
  • mismatch version;
  • logic lặp lại ở notebook.

Structured SQL output

Đây là phần agent-friendly nhất.

LLM mạnh ở việc:

  • hiểu câu hỏi;
  • chọn bước;
  • giải thích;
  • kết nối nhiều tool.

Nhưng LLM không phải lúc nào cũng nên tự “phát minh” thuật toán hoặc tự đọc một đống raw rows rồi kết luận.

Nếu tool trả lại output có schema rõ, agent có thể reasoning trên một bề mặt ổn định hơn.

Ví dụ:

User hỏi
  ↓
Agent phân loại câu hỏi
  ↓
Chọn TVF
  ↓
BigQuery xử lý
  ↓
Structured result
  ↓
Agent giải thích + chọn bước tiếp

Thay vì:

User hỏi
  ↓
LLM tự nghĩ phương pháp
  ↓
LLM tự sinh SQL tùy ý
  ↓
LLM đọc raw output
  ↓
LLM tự kết luận

Không phải workflow thứ hai luôn sai.

Nhưng workflow đầu dễ kiểm soát hơn cho những phép phân tích lặp lại.

6. Chaining: từ một câu hỏi thành workflow phân tích

Google nhấn mạnh các TVF có thể chain.

Đây là nơi agent thực sự có ích.

Ví dụ metric revenue có biến động.

Agent có thể:

Bước 1 — Detect change point

Tìm thời điểm cấu trúc thay đổi.

Bước 2 — Trend

Xem thay đổi đó là một điểm gãy thật hay chỉ nằm trong xu hướng đã có.

Bước 3 — Seasonality

Kiểm tra pattern có trùng mùa vụ không.

Bước 4 — Key drivers

Tìm segment đóng góp lớn cho chênh lệch.

Bước 5 — Causal effect

Nếu có một intervention cụ thể đủ điều kiện phân tích, ước lượng impact.

Điểm hay ở đây là workflow không được hardcode hoàn toàn.

Agent có thể chọn bước tiếp theo dựa trên output trước.

Nhưng từng bước phân tích lõi vẫn dùng primitive chuẩn.

Đây là mô hình hybrid mà tôi cho rằng phù hợp hơn “AI tự phân tích tất cả”.

7. Ví dụ với marketing analytics

Giả sử team hỏi:

“Customer-Score-Lv3 giảm 18% tuần này, nguyên nhân là gì?”

Một agent tốt không nên trả lời ngay.

Nó cần chẩn đoán.

Kiểm tra dữ liệu trước

  • tracking có thay đổi không?
  • conversion definition có đổi không?
  • dữ liệu đủ ngày chưa?
  • latency/backfill thế nào?
  • có campaign lớn mới chạy/tắt không?

Nếu data integrity chưa pass, mọi phân tích sau đều dễ sai.

Detect change point

Lv3 giảm dần hay giảm mạnh từ một ngày cụ thể?

Trend và seasonality

Có phải pattern lặp theo ngày/tuần?

Key drivers

Drop tập trung ở:

  • channel;
  • campaign type;
  • brand;
  • device;
  • geo;
  • product group?

Correlation

Có metric nào di chuyển cùng?

Ví dụ CPC, lead quality, show-up rate, site speed.

Causal effect

Chỉ dùng khi có một intervention đủ rõ và thiết kế dữ liệu phù hợp.

Ví dụ thay landing page, đổi bidding policy hoặc chạy geo experiment.

Kết quả cuối cùng không nên là “AI nói nguyên nhân là X”.

Nên là:

Observed
→ Diagnostic evidence
→ Candidate drivers
→ Causal evidence nếu có
→ Confidence
→ Recommended checks/actions

8. Một kiến trúc agent phân tích dữ liệu thực dụng

Tôi sẽ chia thành sáu lớp.

1. Metric contract

Định nghĩa metric trước.

Không để agent tự đoán “conversion” nghĩa là gì.

2. Data quality gate

Freshness, row count, schema, null, duplication.

3. Analytical intent router

Câu hỏi đang là:

  • describe;
  • compare;
  • diagnose;
  • correlate;
  • forecast;
  • causal?

4. Analytical primitives

TVFs, SQL templates, statistical functions.

5. Interpretation layer

LLM giải thích kết quả, nêu giới hạn và đề xuất bước tiếp.

6. Decision log

Lưu:

  • câu hỏi;
  • dữ liệu;
  • method;
  • result;
  • confidence;
  • action;
  • outcome sau đó.

Kiến trúc này làm một việc rất quan trọng:

tách “tư duy linh hoạt” khỏi “phép tính phải đúng”.

9. Các guardrail cần có

Augmented analytics không làm biến mất rủi ro.

Một agent data vẫn cần guardrail.

Không chạy causal analysis chỉ vì user dùng chữ “ảnh hưởng”

Cần kiểm tra giả định và dữ liệu.

Không biến correlation thành causation

Ngôn ngữ output phải phân biệt.

Không bỏ qua metric definition

Revenue gross, net hay attributed revenue là ba thứ khác nhau.

Không dùng output ngoài domain dữ liệu

Nếu dataset không có offline sales, đừng kết luận về toàn bộ business.

Không coi statistical significance là business significance

Một effect nhỏ có thể có ý nghĩa thống kê nhưng không đáng hành động.

Không tự động thay đổi production từ kết quả phân tích

Analytics → recommendation trước.

Write action → approval riêng.

10. Khi nào không nên dùng agent?

Nếu câu hỏi đã có report cố định và query cố định, agent có thể là thừa.

Ví dụ:

“Doanh thu hôm qua là bao nhiêu?”

Một scheduled query + dashboard thường ổn định hơn.

Agent tạo giá trị khi:

  • câu hỏi thay đổi theo context;
  • cần chọn phương pháp;
  • cần chain nhiều bước;
  • cần giải thích;
  • cần truy vấn tiếp dựa trên kết quả;
  • cần tổng hợp evidence thành decision support.

Một nguyên tắc đơn giản:

Nếu workflow hoàn toàn deterministic, automation truyền thống thường tốt hơn. Nếu workflow cần judgement giữa nhiều bước, agent mới bắt đầu có lợi thế.

BigQuery Augmented Analytics TVFs rất thú vị vì chúng nằm đúng giao điểm này.

Chúng biến một phần reasoning thành những khối phân tích chuẩn.

Agent vẫn linh hoạt.

Nhưng không phải “tự nghĩ mọi thứ”.

Với Data + AI, tôi cho rằng đó là hướng trưởng thành hơn.

Đọc tiếp trong Series Agentic Stack 2026

Nguồn tham khảo