Claude cho Data: Validation và data quality

Gửi một báo cáo sai cho CEO thì chỉ cần một lần để mất uy tín. Claude có thể đóng vai "data QA reviewer" — kiểm tra analysis của bạn trước khi chia sẻ với stakeholders, phát hiện lỗi tính toán, logic SQL sai, và những kết luận không được dữ liệu hỗ trợ.

Bốn loại lỗi phổ biến nhất trong analysis

Hiểu loại lỗi nào hay xảy ra giúp bạn biết cần validate gì:

1. Join Explosion: Nhiều-nhiều join nhân hàng, inflate mọi count và sum
2. Incomplete Period: So sánh tháng đầy đủ với tháng chưa kết thúc
3. Denominator Shifting: Tỷ lệ thay đổi vì cách đếm mẫu số thay đổi
4. Average of Averages: Tính trung bình của trung bình khi group sizes khác nhau

Validate trước khi gửi báo cáo

Lệnh tổng quát nhất:

Hãy review analysis này trước khi tôi gửi cho leadership team.
Kiểm tra: methodology, tính chính xác của calculations,
và liệu conclusions có được dữ liệu support không.

[Paste analysis hoặc mô tả methodology]

Hoặc cụ thể hơn:

Review SQL query và kết quả này. Tôi đang báo cáo
"tỷ lệ churn giảm từ 12% xuống 9%" nhưng muốn chắc chắn
con số đúng trước khi gửi cho CFO:

[Paste query + result set]

Pre-Delivery QA Checklist

Claude sẽ chạy qua checklist có hệ thống:

Kiểm tra chất lượng dữ liệu

• Đã xác nhận bảng/source data đúng chưa?
• Dữ liệu còn fresh không — "as of" date là khi nào?
• Có gap nào trong time series không?
• NULL được xử lý đúng cách chưa (exclude, impute, hay flag)?
• Đã kiểm tra duplicate chưa?

Kiểm tra tính toán

• GROUP BY có đủ tất cả non-aggregated columns không?
• Denominator của tỷ lệ và phần trăm có đúng không?
• Join type có phù hợp (INNER vs LEFT vs FULL OUTER)?
• Nhiều-nhiều join có bị explode không?
• Subtotal có cộng đúng total không?

Kiểm tra reasonable

• Số liệu có trong tầm hợp lý không? Revenue âm? % lớn hơn 100%?
• Có thay đổi đột ngột không giải thích được không?
• Kết quả có match với dashboard/báo cáo trước đó không?

Ví dụ thực tế: Debug join explosion

Query này trả về số đơn hàng lớn hơn thực tế ~3 lần.
Hãy tìm vấn đề:

SELECT
    u.user_id,
    u.segment,
    COUNT(o.order_id) AS order_count,
    SUM(o.total_amount) AS total_spent
FROM users u
LEFT JOIN orders o ON u.user_id = o.customer_id
LEFT JOIN loyalty_points lp ON u.user_id = lp.user_id
WHERE u.is_active = true
GROUP BY u.user_id, u.segment;

Thông tin thêm: bảng loyalty_points có nhiều hàng
cho mỗi user (một hàng mỗi lần tích điểm).

Claude sẽ identify ngay: join với loyalty_points (1:many) tạo duplicate hàng orders trước khi aggregate. Fix:

-- Aggregate loyalty_points trước khi join
WITH user_points AS (
    SELECT user_id, SUM(points) AS total_points
    FROM loyalty_points
    GROUP BY user_id
)
SELECT
    u.user_id,
    u.segment,
    COUNT(o.order_id) AS order_count,
    SUM(o.total_amount) AS total_spent,
    up.total_points
FROM users u
LEFT JOIN orders o ON u.user_id = o.customer_id
LEFT JOIN user_points up ON u.user_id = up.user_id
WHERE u.is_active = true
GROUP BY u.user_id, u.segment, up.total_points;

Validate kết luận từ dữ liệu

Analyst trong team kết luận: "Users dùng feature Premium
có retention cao hơn 40% so với users thường."

Dữ liệu: premium_users retention 30d = 68%, regular retention = 48%.

Hãy review: kết luận này có vấn đề methodology nào không?
Tôi nghi có survivorship bias và selection bias.

Claude sẽ phân tích và xác nhận nghi ngờ: Users có retention cao hơn thì có xu hướng upgrade lên Premium — không phải Premium gây ra retention cao. Đây là correlation, không phải causation, và cần controlled experiment để kết luận được.

Sanity checks cho kết quả bất thường

Kết quả query cho thấy conversion rate tháng 3 = 23.7%.
Tháng trước là 8.2%. Sếp sẽ hỏi tại sao tăng vọt như vậy.

Hãy đưa ra danh sách các giả thuyết cần kiểm tra
trước khi tôi confirm con số này là đúng.

Claude sẽ gợi ý checklist điều tra:

1. Filter date có đúng không? Có đang so sánh toàn tháng với partial tháng không?
2. Định nghĩa "conversion" có thay đổi không? (thêm event type mới vào funnel?)
3. Có sự kiện marketing nào bất thường trong tháng 3 không?
4. Có lỗi tracking/logging nào trong period này không?
5. Denominator có thay đổi không? (đang đếm khác cohort?)

Cross-validation techniques

Tôi có doanh thu từ 2 nguồn:
1. Query từ orders table: 12.4 tỷ VND
2. Báo cáo từ payment gateway: 12.1 tỷ VND

Chênh lệch 300 triệu (2.4%). Hãy đề xuất cách điều tra
nguyên nhân và xác định con số nào đúng hơn.

Output của Validation Report

Claude tạo report chuẩn hóa với 3 mức đánh giá:

Documentation cho reproducibility

Giúp tôi viết documentation chuẩn cho analysis này
để người khác có thể reproduce, bao gồm:
- Data sources và ngày snapshot
- Định nghĩa chính xác của các metrics
- Methodology step-by-step
- Assumptions và limitations
- SQL queries được dùng

[Mô tả analysis]

Bước tiếp theo

Đã validate xong? Tiếp theo là tạo visualization để trình bày kết quả, hoặc xây dựng dashboard để stakeholders theo dõi thường xuyên.

Bài viết liên quan

• Claude cho Data: Data Visualization nâng cao
• Claude cho Data: Khám phá dataset mới
• Claude cho Data: Tạo biểu đồ và visualization
• Fine-tuning Claude trên AWS Bedrock — Hướng dẫn từng bước
• Claude cho Engineering: Viết documentation chuyên nghiệp