PHASE 10 - MODERN DATA STACK & AI AUGMENTATION (Ngày 800 – 844)

Tuần 1-2 - LLM Fundamentals cho Data Work (Ngày 800-807)

Ngày 800: LLM thay đổi nghề Analytics thế nào

• Mục tiêu: Định vị đúng vai trò của LLM - công cụ tăng tốc, không thay thế tư duy đã xây dựng qua Phase 0-9.

• Lý thuyết: LLM giỏi ở việc sinh code/SQL từ ngôn ngữ tự nhiên và tóm tắt, nhưng không thay thế được việc framing đúng bài toán (Phase 4-7) hay đánh giá causal validity (Phase 5).

• Thực hành: Liệt kê 5 tác vụ trong hành trình đã học nên giao cho LLM và 5 tác vụ không nên giao (VD: không nên để LLM tự chọn phương pháp causal inference mà không review).

Ngày 801: Kiến trúc LLM - Ở mức đủ dùng

• Mục tiêu: Hiểu cơ chế cơ bản để dùng công cụ hiệu quả hơn (không cần đào sâu toán học).

• Lý thuyết: Transformer, attention mechanism (trực giác), context window, token.

• Thực hành: Tính thử số token của 1 đoạn văn bản/schema database bằng tokenizer, ước lượng chi phí gọi API cho 1 tác vụ cụ thể.

Ngày 802: Context Window & Giới hạn của LLM

• Mục tiêu: Hiểu ràng buộc thực tế khi thiết kế ứng dụng LLM cho data work.

• Lý thuyết: Context window giới hạn lượng schema/dữ liệu đưa vào prompt, hallucination - LLM có thể "bịa" tên cột/bảng không tồn tại.

• Thực hành: Thử prompt 1 LLM tạo SQL cho database không có trong training data của nó, quan sát hiện tượng hallucination tên cột.

Ngày 803: Embeddings - Khái niệm

• Mục tiêu: Nắm nền tảng cho RAG (sẽ học sâu ở tuần 4-5).

• Lý thuyết: Embedding là gì, cách đo độ tương đồng ngữ nghĩa (cosine similarity) - liên hệ lại kiến thức vector từ Phase 0.

• Thực hành: Tạo embedding cho 5 câu hỏi kinh doanh mẫu bằng 1 embedding model, tính cosine similarity giữa chúng để tìm câu hỏi tương tự nhau.

Ngày 804: Fine-tuning vs Prompting vs RAG

• Mục tiêu: Có bức tranh tổng thể về 3 cách tùy chỉnh LLM cho use case cụ thể.

• Lý thuyết: Trade-off chi phí/độ phức tạp/hiệu quả của từng phương pháp - vì sao RAG thường là lựa chọn thực tế nhất cho data work.

• Thực hành: Viết bảng so sánh 3 phương pháp, đề xuất phương pháp phù hợp cho use case "trả lời câu hỏi dữ liệu nội bộ công ty".

Ngày 805: LLM API - Thực hành cơ bản

• Mục tiêu: Làm quen thao tác gọi API thực tế.

• Lý thuyết: Cấu trúc request/response cơ bản, system prompt vs user prompt, temperature parameter.

• Thực hành: Viết script Python gọi LLM API tóm tắt 1 báo cáo phân tích đã làm ở Phase 1, thử nghiệm với temperature khác nhau.

Ngày 806: Structured Output từ LLM

• Mục tiêu: Đảm bảo output LLM dùng được trong pipeline tự động (không phải chỉ chat).

• Lý thuyết: JSON mode, function calling/tool use - cách ép LLM trả về định dạng có cấu trúc thay vì văn bản tự do.

• Thực hành: Viết prompt yêu cầu LLM phân loại 20 câu hỏi khách hàng thành JSON có category + priority, parse kết quả bằng Python.

Ngày 807: Dự án LLM Fundamentals tổng hợp

• Mục tiêu: Tổng hợp tuần 1-2.

• Lý thuyết: Checklist đánh giá khi nào 1 tác vụ data work phù hợp dùng LLM.

• Thực hành: Viết tài liệu đánh giá 5 tác vụ lặp lại trong công việc Analytics (từ các Phase trước), xác định tác vụ nào nên tự động hóa bằng LLM và ước tính thời gian tiết kiệm.

Tuần 3 - Prompt Engineering cho Data Work (Ngày 808-815)

Ngày 808: Nguyên tắc Prompt Engineering cơ bản

• Mục tiêu: Nắm best practices chung.

• Lý thuyết: Rõ ràng, cụ thể, cung cấp context, ví dụ (few-shot), yêu cầu định dạng output.

• Thực hành: Viết lại 1 prompt mơ hồ ("phân tích dữ liệu này giúp tôi") thành prompt rõ ràng, cụ thể theo nguyên tắc trên.

Ngày 809: Few-shot Prompting

• Mục tiêu: Cải thiện độ chính xác output bằng ví dụ mẫu.

• Lý thuyết: Zero-shot vs few-shot, cách chọn ví dụ đại diện.

• Thực hành: So sánh chất lượng output khi phân loại feedback khách hàng bằng zero-shot vs few-shot prompt (3-5 ví dụ mẫu).

Ngày 810: Chain-of-Thought Prompting

• Mục tiêu: Cải thiện khả năng suy luận của LLM cho bài toán phức tạp.

• Lý thuyết: Yêu cầu LLM "suy nghĩ từng bước" trước khi đưa kết luận cuối - cải thiện đáng kể cho bài toán tính toán/logic.

• Thực hành: So sánh kết quả LLM giải 1 bài toán tính toán kinh doanh (VD: tính LTV từ dữ liệu thô) có và không có chain-of-thought prompting.

Ngày 811: Prompt cho Data Analysis Tasks

• Mục tiêu: Áp dụng prompt engineering cho tác vụ phân tích cụ thể.

• Lý thuyết: Cấu trúc prompt hiệu quả cho: giải thích code, review SQL, gợi ý phương pháp phân tích.

• Thực hành: Viết prompt yêu cầu LLM review 1 đoạn code dbt/Python đã viết ở Phase 2-4, đánh giá chất lượng gợi ý nhận được.

Ngày 812: Prompt cho Business Context

• Mục tiêu: Đưa đủ ngữ cảnh kinh doanh vào prompt để LLM đưa ra gợi ý phù hợp thực tế (không chung chung).

• Lý thuyết: Domain context injection - cung cấp thông tin ngành, KPI công ty, ràng buộc thực tế vào system prompt.

• Thực hành: Viết system prompt đóng vai "trợ lý phân tích cho công ty SaaS B2B" với đầy đủ context (metric quan tâm, giọng văn báo cáo), test với vài câu hỏi.

Ngày 813: Đánh giá Chất lượng Output LLM

• Mục tiêu: Không tin tưởng mù quáng - cần framework đánh giá.

• Lý thuyết: Các tiêu chí đánh giá: tính chính xác (factuality), tính liên quan, tính nhất quán qua nhiều lần chạy.

• Thực hành: Chạy cùng 1 prompt phân tích 5 lần, đánh giá độ nhất quán của kết quả, xác định điểm cần con người review thêm.

Ngày 814: Giới hạn Đạo đức & Rủi ro khi dùng LLM cho Data Work

• Mục tiêu: Có góc nhìn cân bằng, tránh rủi ro thực tế.

• Lý thuyết: Rủi ro leak dữ liệu nhạy cảm (PII) qua prompt (liên hệ Data Governance Phase 8), rủi ro quyết định sai vì tin tưởng quá mức vào hallucination.

• Thực hành: Viết checklist "an toàn" trước khi gửi bất kỳ dữ liệu nào vào LLM API bên ngoài (đã anonymize PII chưa, có vi phạm data contract không).

Ngày 815: Dự án Prompt Engineering tổng hợp

• Mục tiêu: Tổng hợp tuần 3.

• Lý thuyết: Checklist viết prompt hiệu quả và an toàn cho data work.

• Thực hành: Xây "prompt library" cá nhân gồm 5-7 prompt template tái sử dụng cho các tác vụ thường gặp (review SQL, giải thích metric, tóm tắt báo cáo, gợi ý phương pháp).

Tuần 4-5 - Text-to-SQL (Ngày 816-825)

Ngày 816: Text-to-SQL - Bài toán & Thách thức

• Mục tiêu: Hiểu vì sao đây là 1 trong những ứng dụng LLM thực tế nhất cho Analytics.

• Lý thuyết: Thách thức: LLM cần hiểu schema thực tế (không phải schema chung chung), business logic ẩn (VD: "active user" định nghĩa thế nào - liên hệ Semantic Layer Phase 2).

• Thực hành: Thử prompt 1 LLM sinh SQL cho database Phase 2 mà không cung cấp schema, quan sát lỗi xảy ra.

Ngày 817: Schema-aware Prompting

• Mục tiêu: Cải thiện độ chính xác bằng cách cung cấp schema đúng cách.

• Lý thuyết: Cách format schema hiệu quả trong prompt (DDL statement, mô tả column, sample values).

• Thực hành: Viết prompt kèm đầy đủ DDL của 3-4 bảng mart đã xây ở Phase 2, test lại text-to-SQL với cùng câu hỏi Ngày 816.

Ngày 818: Xử lý Business Logic phức tạp trong Text-to-SQL

• Mục tiêu: Giải quyết vấn đề LLM không biết định nghĩa metric nội bộ.

• Lý thuyết: Đưa định nghĩa metric chuẩn hóa (đã xây ở Phase 2 semantic layer) vào context, few-shot example với business logic đặc thù.

• Thực hành: Test text-to-SQL cho câu hỏi cần business logic đặc thù (VD: "active user" theo định nghĩa riêng của công ty), so sánh kết quả có/không cung cấp definition.

Ngày 819: Kết nối Text-to-SQL với Semantic Layer (liên hệ Phase 2)

• Mục tiêu: Thấy kiến trúc thực tế - text-to-SQL hiệu quả nhất khi query qua semantic layer thay vì raw table.

• Lý thuyết: Vì sao query qua metrics layer (dbt Semantic Layer/Cube đã học Phase 2) giảm rủi ro sai logic so với để LLM tự viết JOIN phức tạp.

• Thực hành: Thiết kế kiến trúc: LLM sinh truy vấn tới semantic layer (dùng metric đã định nghĩa) thay vì sinh raw SQL trực tiếp trên warehouse.

Ngày 820: Validation & Safety cho Text-to-SQL

• Mục tiêu: Đảm bảo an toàn khi cho phép LLM tự sinh và chạy SQL.

• Lý thuyết: Read-only permission, query cost estimation trước khi chạy (liên hệ dry-run BigQuery Phase 3), giới hạn row limit.

• Thực hành: Thiết kế pipeline validation: kiểm tra SQL sinh ra chỉ là SELECT (không DELETE/UPDATE), ước tính chi phí trước khi thực thi.

Ngày 821: Xây dựng Text-to-SQL Pipeline hoàn chỉnh

• Mục tiêu: Ghép các bước thành hệ thống end-to-end.

• Lý thuyết: Kiến trúc: câu hỏi tự nhiên → LLM (schema-aware) → SQL → validation → thực thi → trả kết quả + giải thích.

• Thực hành: Cài đặt pipeline text-to-SQL hoàn chỉnh bằng Python cho warehouse đã xây ở Phase 2-3, test với 10 câu hỏi kinh doanh khác nhau.

Ngày 822: Đánh giá Độ chính xác Text-to-SQL

• Mục tiêu: Đo lường hệ thống nghiêm túc thay vì "cảm thấy đúng".

• Lý thuyết: Execution accuracy (kết quả đúng) vs exact match (SQL giống hệt) - execution accuracy quan trọng hơn.

• Thực hành: Xây bộ test 15 câu hỏi có đáp án đúng đã biết trước, đo tỷ lệ execution accuracy của pipeline đã xây.

Ngày 823: Xử lý Câu hỏi Mơ hồ & Follow-up

• Mục tiêu: Xử lý hội thoại nhiều lượt (thực tế người dùng ít khi hỏi rõ ràng ngay lần đầu).

• Lý thuyết: Conversation history trong context, cách LLM hỏi lại làm rõ khi câu hỏi mơ hồ thay vì đoán bừa.

• Thực hành: Mở rộng pipeline Ngày 821 để hỗ trợ câu hỏi follow-up (VD: "còn theo khu vực thì sao?" sau câu hỏi đầu).

Ngày 824: So sánh Text-to-SQL Tools có sẵn trên thị trường

• Mục tiêu: Biết công cụ thương mại/mã nguồn mở hiện có, không cần tự xây mọi thứ từ đầu.

• Lý thuyết: Tổng quan các công cụ text-to-SQL phổ biến hiện nay (tích hợp trong BI tool, công cụ độc lập) - điểm mạnh/yếu so với tự xây.

• Thực hành: Đọc tài liệu 1-2 công cụ text-to-SQL thương mại/mã nguồn mở, so sánh với pipeline tự xây ở Ngày 821.

Ngày 825: Dự án Text-to-SQL tổng hợp

• Mục tiêu: Tổng hợp tuần 4-5.

• Lý thuyết: Checklist triển khai text-to-SQL an toàn và đáng tin cậy trong tổ chức.

• Thực hành: Hoàn thiện pipeline text-to-SQL, viết tài liệu hướng dẫn sử dụng và giới hạn (khi nào nên tin, khi nào cần verify thủ công) cho người dùng không kỹ thuật.

Tuần 6-7 - RAG on Warehouse & Semantic Layer (Ngày 826-835)

Ngày 826: RAG - Khái niệm cốt lõi

• Mục tiêu: Hiểu kiến trúc giúp LLM trả lời dựa trên dữ liệu/tài liệu nội bộ thay vì chỉ kiến thức đã train.

• Lý thuyết: Retrieval-Augmented Generation - tìm thông tin liên quan trước, sau đó đưa vào context cho LLM sinh câu trả lời.

• Thực hành: Vẽ sơ đồ kiến trúc RAG đầy đủ (query → embedding → vector search → retrieve → LLM generate).

Ngày 827: Vector Database - Giới thiệu

• Mục tiêu: Làm quen hạ tầng lưu trữ embedding.

• Lý thuyết: Vector database (Pinecone, Weaviate, hoặc pgvector extension cho Postgres đã học Phase 8) - cách lưu và tìm kiếm theo độ tương đồng.

• Thực hành: Cài đặt pgvector trên Postgres local, tạo bảng lưu embedding và thử truy vấn similarity search.

Ngày 828: Chunking Strategy

• Mục tiêu: Chia tài liệu thành đơn vị phù hợp cho retrieval.

• Lý thuyết: Trade-off chunk size (quá nhỏ mất context, quá lớn giảm độ chính xác retrieval), overlap giữa chunk.

• Thực hành: Chia 1 tài liệu dài (VD: docs dbt project từ Phase 2) thành các chunk theo 2 chiến lược khác nhau, so sánh chất lượng retrieval.

Ngày 829: Xây dựng RAG cho Documentation nội bộ

• Mục tiêu: Ứng dụng thực tế đầu tiên - trả lời câu hỏi về hệ thống dữ liệu đã xây.

• Lý thuyết: Index hóa toàn bộ dbt docs, data contracts (Phase 2), tài liệu kiến trúc (Phase 3, 8) đã viết xuyên suốt hành trình.

• Thực hành: Xây RAG pipeline index hóa toàn bộ tài liệu kỹ thuật đã viết từ Phase 2-8, test câu hỏi "bảng fact_orders có những cột gì và ai sở hữu nó?"

Ngày 830: RAG cho Metric Definitions (kết nối Semantic Layer)

• Mục tiêu: Giải quyết vấn đề "metric nào định nghĩa thế nào" bằng RAG thay vì tra cứu thủ công.

• Lý thuyết: Index hóa toàn bộ metric definition đã chuẩn hóa ở Phase 2, giúp bất kỳ ai hỏi "Active User được tính thế nào" đều nhận câu trả lời nhất quán.

• Thực hành: Xây RAG trả lời câu hỏi về định nghĩa metric, test với 5 metric đã định nghĩa ở Phase 1-2.

Ngày 831: Kết hợp RAG với Text-to-SQL

• Mục tiêu: Ghép 2 kiến trúc đã học thành hệ thống mạnh hơn.

• Lý thuyết: RAG cung cấp context về business logic/metric definition trước, sau đó dùng context đó để cải thiện text-to-SQL.

• Thực hành: Mở rộng pipeline text-to-SQL (Ngày 821) để trước tiên retrieve metric definition liên quan qua RAG, rồi mới sinh SQL.

Ngày 832: Đánh giá Chất lượng RAG

• Mục tiêu: Đo lường hệ thống RAG nghiêm túc.

• Lý thuyết: Retrieval quality (có tìm đúng chunk liên quan không) và generation quality (câu trả lời có chính xác dựa trên chunk không) - 2 điểm lỗi riêng biệt cần đánh giá tách bạch.

• Thực hành: Xây bộ test 10 câu hỏi có đáp án đúng đã biết, đánh giá riêng retrieval accuracy và answer accuracy.

Ngày 833: Xử lý Tài liệu Lỗi thời (Stale Documentation)

• Mục tiêu: Giải quyết vấn đề thực tế - tài liệu thường không cập nhật kịp thay đổi hệ thống.

• Lý thuyết: Chiến lược đồng bộ RAG index với thay đổi hệ thống (liên hệ CI/CD Phase 2 - tự động re-index khi docs thay đổi).

• Thực hành: Thiết kế quy trình tự động re-index RAG mỗi khi dbt docs được regenerate (liên hệ CI pipeline đã xây Phase 2).

Ngày 834: Giới hạn của RAG cho Data Work

• Mục tiêu: Có góc nhìn thực tế, tránh kỳ vọng quá mức.

• Lý thuyết: RAG tốt cho câu hỏi "tra cứu thông tin", không tốt cho câu hỏi cần tính toán phức tạp hoặc suy luận nhiều bước (cần kết hợp với text-to-SQL hoặc agent).

• Thực hành: Phân loại 10 câu hỏi thực tế thành "phù hợp RAG thuần túy" vs "cần RAG + tính toán thêm", giải thích lý do.

Ngày 835: Dự án RAG tổng hợp

• Mục tiêu: Tổng hợp tuần 6-7.

• Lý thuyết: Checklist triển khai RAG đáng tin cậy cho data platform.

• Thực hành: Hoàn thiện hệ thống RAG kết hợp text-to-SQL, viết tài liệu kiến trúc và demo với 5 câu hỏi thực tế kết hợp cả tra cứu metric definition và truy vấn dữ liệu.

Tuần 8 - AI Agents cho BI (Ngày 836-842)

Ngày 836: AI Agent - Khái niệm khác biệt với Chatbot đơn thuần

• Mục tiêu: Hiểu bước tiến từ "trả lời 1 câu hỏi" sang "tự thực hiện chuỗi hành động".

• Lý thuyết: Agent = LLM + khả năng gọi tool (function calling) + vòng lặp lên kế hoạch-thực thi-quan sát (ReAct pattern).

• Thực hành: Vẽ sơ đồ so sánh kiến trúc chatbot đơn thuần (1 lượt hỏi-đáp) và agent (nhiều bước, dùng tool).

Ngày 837: Tool Use / Function Calling

• Mục tiêu: Cài đặt khả năng agent gọi công cụ bên ngoài.

• Lý thuyết: Định nghĩa tool schema, cách LLM quyết định khi nào gọi tool nào.

• Thực hành: Định nghĩa 3 tool (query warehouse, tra cứu metric definition qua RAG, tạo biểu đồ) và cho phép LLM tự chọn tool phù hợp theo câu hỏi.

Ngày 838: Multi-step Reasoning Agent

• Mục tiêu: Xây agent giải quyết câu hỏi cần nhiều bước.

• Lý thuyết: Agent chia câu hỏi phức tạp thành các bước con, thực thi tuần tự, tổng hợp kết quả cuối.

• Thực hành: Test agent với câu hỏi cần nhiều bước (VD: "so sánh doanh thu tháng này với cùng kỳ năm trước theo từng khu vực và vẽ biểu đồ"), quan sát agent chia nhỏ và thực thi thế nào.

Ngày 839: Agent cho BI Dashboard tự động

• Mục tiêu: Ứng dụng cụ thể - tự động sinh insight từ dashboard.

• Lý thuyết: Agent định kỳ quét metric, phát hiện thay đổi bất thường (liên hệ Data Observability Phase 2), tự động viết tóm tắt insight.

• Thực hành: Thiết kế agent chạy hàng ngày: query các metric chính, so sánh với baseline, tự viết đoạn tóm tắt "điều gì đáng chú ý hôm nay".

Ngày 840: Human-in-the-loop cho Agent

• Mục tiêu: Thiết kế an toàn - không để agent tự động hành động không kiểm soát.

• Lý thuyết: Điểm nào cần con người xác nhận trước khi agent tiếp tục (VD: trước khi gửi báo cáo ra ngoài, trước khi chạy truy vấn tốn kém).

• Thực hành: Thêm bước approval thủ công vào agent đã xây ở Ngày 839 trước khi gửi tóm tắt insight qua email/Slack.

Ngày 841: Giới hạn & Rủi ro của AI Agent trong Data Work

• Mục tiêu: Có góc nhìn thực tế, tránh rủi ro vận hành.

• Lý thuyết: Rủi ro agent lặp vô hạn (infinite loop), rủi ro chi phí API không kiểm soát, rủi ro agent đưa kết luận sai nhưng trình bày tự tin (liên hệ lại tầm quan trọng của causal inference Phase 5 - agent không tự biết correlation khác causation).

• Thực hành: Thiết kế giới hạn an toàn cho agent (max số bước, max chi phí/phiên, timeout), viết checklist review trước khi đưa agent vào production.

Ngày 842: Dự án AI Agent tổng hợp

• Mục tiêu: Tổng hợp tuần 8.

• Lý thuyết: Checklist triển khai AI agent cho BI an toàn và hữu ích.

• Thực hành: Hoàn thiện agent tự động sinh insight hàng ngày (kết hợp text-to-SQL + RAG + tool use), có giới hạn an toàn và human-in-the-loop, demo end-to-end.

Ngày 843-844 - Capstone Phase 10

Ngày 843: Capstone - Tích hợp AI Augmentation vào Platform đã xây

• Mục tiêu: Ghép toàn bộ Phase 10 vào hệ thống đã xây xuyên suốt Phase 2-9.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Tích hợp text-to-SQL + RAG + agent vào 1 giao diện thống nhất (có thể là CLI hoặc web app đơn giản) kết nối với warehouse/semantic layer đã xây.

Ngày 844: Capstone - Demo & Tổng kết Phase 10

• Mục tiêu: Hoàn thiện và kết thúc Phase 10, chuẩn bị bước vào chuỗi Capstone lớn cuối cùng.

• Lý thuyết: Nhìn lại toàn bộ hành trình: từ nền tảng toán/lập trình (Phase 0) đến khả năng tăng tốc bằng AI (Phase 10) - đây là bộ kỹ năng hiếm có kết hợp đầy đủ chiều sâu kỹ thuật, tư duy quyết định, và khả năng làm chủ công cụ hiện đại nhất.

• Thực hành: Quay demo ngắn (3-5 phút) toàn bộ hệ thống AI-augmented analytics đã xây, cập nhật portfolio GitHub, viết bài tổng kết Phase 10, sẵn sàng bước vào chuỗi 4 Capstone cuối cùng.

CAPSTONE 1-4 (Ngày 845 – 920)

CAPSTONE 1 - UBER DECISION PLATFORM (Ngày 845-860)

Kiến trúc mục tiêu: Events → Kafka → Spark → Iceberg → dbt → Metrics Layer → Dashboard

Ngày 845: Kickoff - System Design Doc

• Mục tiêu: Lên kế hoạch kiến trúc trước khi code, giống quy trình thiết kế hệ thống thực tế.

• Lý thuyết: Không có lý thuyết mới - áp dụng tư duy system design đã tích lũy từ Phase 2-3.

• Thực hành: Viết tài liệu thiết kế hệ thống (1-2 trang) cho nền tảng ra quyết định kiểu Uber: nguồn dữ liệu (ride request, trip completed, driver location), luồng xử lý, các metric chính (ETA accuracy, surge pricing, driver utilization).

Ngày 846: Event Generator giả lập

• Mục tiêu: Tạo nguồn dữ liệu streaming để mô phỏng hệ thống thực.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết script Python sinh sự kiện ride giả lập liên tục (ride_requested, ride_accepted, ride_completed) với timestamp, vị trí, giá cước ngẫu nhiên hợp lý.

Ngày 847: Kafka Ingestion

• Mục tiêu: Đưa sự kiện vào hệ thống streaming (áp dụng Phase 3).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Thiết lập Kafka topic cho từng loại sự kiện, đăng ký schema qua Schema Registry, chạy event generator gửi liên tục vào Kafka.

Ngày 848: Spark Structured Streaming → Bronze Iceberg

• Mục tiêu: Xử lý streaming và lưu trữ vào data lake (áp dụng Phase 3).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết job Spark Structured Streaming đọc từ Kafka, ghi liên tục vào Bronze zone dạng Iceberg table.

Ngày 849: Data Quality trên Bronze Layer

• Mục tiêu: Đảm bảo dữ liệu sạch trước khi transform (áp dụng Phase 2).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết bộ Soda/dbt test kiểm tra tính hợp lệ của sự kiện (giá cước không âm, timestamp hợp lý, không trùng event_id).

Ngày 850: dbt Staging Layer

• Mục tiêu: Chuẩn hóa dữ liệu thô (áp dụng Phase 2).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết staging model cho từng loại sự kiện, chuẩn hóa tên cột và kiểu dữ liệu.

Ngày 851: dbt Intermediate Layer - Trip Aggregation

• Mục tiêu: Ghép các sự kiện rời rạc thành 1 chuyến đi hoàn chỉnh.

• Lý thuyết: Không có lý thuyết mới - áp dụng accumulating snapshot fact đã học Phase 2.

• Thực hành: Viết intermediate model ghép ride_requested → ride_accepted → ride_completed thành 1 dòng dữ liệu "trip" đầy đủ với các mốc thời gian.

Ngày 852: dbt Mart Layer - Fact & Dimension

• Mục tiêu: Xây warehouse layer phục vụ phân tích (áp dụng Kimball Phase 2).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây fact_trips, dim_driver, dim_rider, dim_location hoàn chỉnh với test và docs.

Ngày 853: Metrics Layer

• Mục tiêu: Chuẩn hóa định nghĩa metric (áp dụng Semantic Layer Phase 2).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Định nghĩa metric qua dbt Semantic Layer/MetricFlow: ETA accuracy, average surge multiplier, driver utilization rate, completion rate.

Ngày 854: Orchestration - Airflow DAG hoàn chỉnh

• Mục tiêu: Tự động hóa toàn bộ pipeline (áp dụng Phase 3).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết Airflow DAG orchestrate: kiểm tra Spark streaming job đang chạy → dbt run → dbt test → refresh dashboard.

Ngày 855: Data Governance - PII Masking

• Mục tiêu: Bảo vệ dữ liệu vị trí/danh tính (áp dụng Phase 8).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Áp dụng masking cho thông tin định danh driver/rider, thiết lập RLS để phân tích viên chỉ thấy dữ liệu đã ẩn danh phần nào cần thiết.

Ngày 856: Dashboard - Metrics chính

• Mục tiêu: Trực quan hóa kết quả (áp dụng Phase 1).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây dashboard Power BI/Looker hiển thị ETA accuracy, surge pricing theo khu vực/giờ, driver utilization theo thời gian thực.

Ngày 857: Tích hợp Text-to-SQL/RAG

• Mục tiêu: Cho phép truy vấn ad-hoc bằng ngôn ngữ tự nhiên (áp dụng Phase 10).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Kết nối pipeline text-to-SQL đã xây ở Phase 10 vào metrics layer của platform này, test với câu hỏi như "khu vực nào có ETA accuracy thấp nhất tuần này?".

Ngày 858: Observability & Alerting

• Mục tiêu: Đảm bảo hệ thống được giám sát (áp dụng Phase 2).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Thiết lập alert khi completion rate giảm bất thường hoặc pipeline trễ so với SLA đã định.

Ngày 859: Tài liệu hóa hoàn chỉnh

• Mục tiêu: Chuẩn bị cho portfolio.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết README kiến trúc đầy đủ kèm sơ đồ, đưa lên GitHub.

Ngày 860: Demo & Retrospective

• Mục tiêu: Tổng kết Capstone 1.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Quay demo ngắn giới thiệu toàn bộ pipeline và dashboard, viết retrospective (điều gì khó nhất, sẽ làm khác đi thế nào nếu làm lại).

CAPSTONE 2 - NETFLIX GROWTH ANALYTICS (Ngày 861-876)

Trọng tâm: Retention, Cohort, Experimentation, Forecasting.

Ngày 861: Kickoff & Chọn Dataset

• Mục tiêu: Khởi động dự án phân tích tăng trưởng.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Chọn/tạo dataset giả lập hành vi xem phim và subscription (user, content, watch events, subscription status theo thời gian), viết đề cương dự án.

Ngày 862: Data Modeling cho Subscription Events

• Mục tiêu: Chuẩn hóa dữ liệu subscription (áp dụng Phase 2 SCD Type 2).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây model dbt cho lịch sử trạng thái subscription (dùng SCD Type 2 để track upgrade/downgrade/cancel).

Ngày 863: Retention & Cohort Analysis

• Mục tiêu: Áp dụng lại kỹ thuật Phase 1 ở quy mô lớn hơn.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây cohort retention table đầy đủ theo tháng đăng ký, phân tích theo phân khúc (gói cước, thiết bị, khu vực).

Ngày 864: Churn Prediction Model

• Mục tiêu: Áp dụng lại Phase 4 Classification.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây model XGBoost dự đoán churn dựa trên hành vi xem (tần suất, đa dạng thể loại, thời gian từ lần xem cuối), đánh giá bằng business cost matrix.

Ngày 865: Thiết kế A/B Test - Thay đổi Recommendation

• Mục tiêu: Áp dụng Phase 5 A/B Testing.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Thiết kế thí nghiệm giả lập "thay đổi thuật toán gợi ý nội dung", xác định hypothesis, metric chính (watch time), power analysis.

Ngày 866: Phân tích A/B Test với CUPED

• Mục tiêu: Áp dụng kỹ thuật giảm variance đã học Phase 5.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Phân tích kết quả thí nghiệm giả lập, áp dụng CUPED để tăng độ nhạy phát hiện effect.

Ngày 867: Causal Inference - Đánh giá Rollout theo Khu vực

• Mục tiêu: Áp dụng DiD đã học Phase 5.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Giả lập tình huống 1 tính năng mới được rollout ở 1 số khu vực trước, dùng Difference-in-Differences đánh giá tác động lên watch time.

Ngày 868: Forecasting Tăng trưởng Subscriber

• Mục tiêu: Áp dụng Phase 4 Forecasting.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây model Prophet/SARIMA dự báo số subscriber mới theo tháng, có tính đến seasonality (VD: tăng vọt dịp lễ khi có nội dung hot).

Ngày 869: Uplift Model cho Chiến dịch Giữ chân

• Mục tiêu: Áp dụng Phase 5 Uplift Modeling.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây uplift model xác định nhóm subscriber nào nên nhận ưu đãi giữ chân (retention offer), tránh lãng phí ngân sách cho nhóm "Sure Things".

Ngày 870: Dashboard Tăng trưởng

• Mục tiêu: Trực quan hóa toàn bộ insight.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây dashboard tổng hợp retention, churn risk, forecast subscriber, và kết quả A/B test.

Ngày 871: Viết Executive Summary/Memo

• Mục tiêu: Áp dụng Phase 9 Communication.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết decision memo theo Pyramid Principle tổng hợp toàn bộ phát hiện, kèm khuyến nghị hành động cụ thể.

Ngày 872: AI-augmented Insight Generation

• Mục tiêu: Áp dụng Phase 10 AI Agent.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Chạy agent tự động quét các metric tăng trưởng, sinh tóm tắt insight hàng tuần cho dashboard.

Ngày 873: Data Governance Review

• Mục tiêu: Áp dụng Phase 8.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Rà soát PII trong dữ liệu hành vi xem (nhạy cảm hơn dữ liệu giao dịch thông thường), đảm bảo tuân thủ.

Ngày 874: Tài liệu hóa

• Mục tiêu: Chuẩn bị portfolio.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết README và case study cho dự án theo cấu trúc đã học Phase 9.

Ngày 875: Refine & Peer Review

• Mục tiêu: Nâng cao chất lượng trước khi hoàn thiện.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Tự review lại toàn bộ dự án theo checklist chất lượng đã tích lũy qua các Phase, sửa các điểm yếu.

Ngày 876: Demo & Retrospective

• Mục tiêu: Tổng kết Capstone 2.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Quay demo, viết retrospective, cập nhật portfolio.

CAPSTONE 3 - AMAZON PRICING OPTIMIZATION (Ngày 877-892)

Trọng tâm: Elasticity, Forecasting, Optimization.

Ngày 877: Kickoff & Dataset

• Mục tiêu: Khởi động dự án pricing.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Chọn/tạo dataset giả lập giá bán, số lượng bán, tồn kho theo SKU và thời gian, viết đề cương dự án.

Ngày 878: Ước lượng Price Elasticity

• Mục tiêu: Áp dụng Phase 6 Pricing Optimization.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Ước lượng elasticity cho từng nhóm sản phẩm bằng regression log-log, kiểm soát confounder mùa vụ/khuyến mãi (liên hệ Phase 5).

Ngày 879: Demand Forecasting theo SKU

• Mục tiêu: Áp dụng Phase 4 Forecasting ở quy mô nhiều chuỗi.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây forecast demand cho top 20 SKU bằng XGBoost với lag feature (liên hệ Ngày 439-442, hierarchical forecasting).

Ngày 880: Price Optimization bằng Linear Programming

• Mục tiêu: Áp dụng Phase 6 LP.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Giải bài toán tối ưu giá cho danh mục sản phẩm tối đa hóa lợi nhuận tổng thể với ràng buộc tồn kho, dựa trên elasticity đã ước lượng.

Ngày 881: Mô phỏng Dynamic Pricing bằng Bandit

• Mục tiêu: Áp dụng Phase 6 RL Basics.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Cài đặt Thompson Sampling cho bài toán chọn mức giá tối ưu trong thời gian thực cho 1 sản phẩm có nhu cầu biến động nhanh.

Ngày 882: Phân tích Cạnh tranh bằng Game Theory

• Mục tiêu: Áp dụng Phase 7 Game Theory.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây payoff matrix cho tình huống cạnh tranh giá với 1 đối thủ giả định, tìm Nash Equilibrium, đánh giá rủi ro "race to the bottom".

Ngày 883: Thiết kế A/B Test cho Thay đổi Giá

• Mục tiêu: Áp dụng Phase 5.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Thiết kế thí nghiệm thay đổi giá (dùng cluster randomization theo khu vực đã học Phase 5 để tránh network effect giữa khách hàng).

Ngày 884: Causal Inference trên Lịch sử Thay đổi Giá

• Mục tiêu: Áp dụng IV/RDD đã học Phase 5.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Dùng RDD phân tích tác động của 1 ngưỡng giá tự nhiên trong lịch sử (VD: ngưỡng miễn phí ship) lên hành vi mua hàng.

Ngày 885: Pricing tích hợp Inventory (Newsvendor)

• Mục tiêu: Kết nối Pricing với Inventory Optimization (Phase 6).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Mở rộng bài toán pricing để tính đến chi phí tồn kho dư thừa cho sản phẩm theo mùa, dùng newsvendor model.

Ngày 886: Dashboard Khuyến nghị Giá

• Mục tiêu: Trực quan hóa kết quả cho stakeholder pricing team.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây dashboard hiển thị giá hiện tại, giá đề xuất, elasticity, và tác động dự kiến lên lợi nhuận cho từng SKU.

Ngày 887: Text-to-SQL cho Câu hỏi Pricing

• Mục tiêu: Áp dụng Phase 10.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Kết nối pipeline text-to-SQL vào warehouse pricing, test câu hỏi như "sản phẩm nào có elasticity cao nhất trong nhóm điện tử?".

Ngày 888: Viết Báo cáo Chiến lược Pricing

• Mục tiêu: Áp dụng Phase 9.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết memo/báo cáo chiến lược pricing hoàn chỉnh, trình bày trade-off và khuyến nghị theo Pyramid Principle.

Ngày 889: Rà soát Đạo đức Pricing

• Mục tiêu: Cân nhắc khía cạnh đạo đức của price discrimination (liên hệ Phase 7 Behavioral Economics + Phase 8 Governance).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết đánh giá rủi ro đạo đức/pháp lý của chiến lược giá phân biệt đề xuất, đảm bảo không vi phạm nguyên tắc công bằng cơ bản.

Ngày 890: Tài liệu hóa

• Mục tiêu: Chuẩn bị portfolio.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết README và case study đầy đủ.

Ngày 891: Refine

• Mục tiêu: Nâng cao chất lượng.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Tự review theo checklist tổng hợp, sửa điểm yếu.

Ngày 892: Demo & Retrospective

• Mục tiêu: Tổng kết Capstone 3.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Quay demo, viết retrospective, cập nhật portfolio.

CAPSTONE 4 - EXECUTIVE DECISION INTELLIGENCE PLATFORM (Ngày 893-920)

Dự án tổng kết cuối cùng - tích hợp toàn bộ hành trình vào 1 hệ thống thống nhất: Data Sources → Ingestion → Warehouse → Transformation → Metrics Layer → Experimentation → Forecasting → Optimization → Decision Support

Ngày 893: Kickoff - Vision & Architecture Document

• Mục tiêu: Lên kế hoạch cho dự án lớn nhất và cuối cùng của roadmap.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết tài liệu vision đầy đủ: mục tiêu platform, các module chính, tiêu chí thành công. Đây là bản tổng hợp mọi kiến trúc đã thiết kế xuyên suốt Phase 2-10.

Ngày 894: Data Sources Inventory & Ingestion Design

• Mục tiêu: Thiết kế tầng thu thập dữ liệu.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Liệt kê toàn bộ nguồn dữ liệu platform sẽ dùng (kết hợp dữ liệu từ Capstone 1-3 nếu phù hợp), thiết kế kiến trúc ingestion (batch qua Airflow + streaming qua Kafka).

Ngày 895: Xây dựng Ingestion Layer

• Mục tiêu: Hiện thực hóa thiết kế Ngày 894.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Cài đặt pipeline ingestion batch và streaming, đưa dữ liệu vào Bronze zone.

Ngày 896: Warehouse Layer Setup

• Mục tiêu: Xây tầng lưu trữ trung tâm.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Thiết lập warehouse (Iceberg + Trino hoặc Snowflake/BigQuery tùy lựa chọn), thiết kế zone Bronze/Silver/Gold.

Ngày 897: Transformation Layer (dbt)

• Mục tiêu: Xây tầng biến đổi dữ liệu hoàn chỉnh.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây dbt project đầy đủ staging → intermediate → mart, áp dụng toàn bộ best practices đã học Phase 2.

Ngày 898: Data Quality & Contracts

• Mục tiêu: Đảm bảo độ tin cậy dữ liệu.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Thiết lập dbt tests, Soda checks, và data contracts cho các bảng quan trọng nhất.

Ngày 899: Metrics/Semantic Layer

• Mục tiêu: Chuẩn hóa toàn bộ định nghĩa metric của tổ chức.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây metrics layer hoàn chỉnh (dbt Semantic Layer/MetricFlow) tổng hợp mọi metric quan trọng đã định nghĩa xuyên suốt roadmap (Phase 1, 2, Capstone 1-3).

Ngày 900: Data Governance Framework

• Mục tiêu: Đảm bảo tuân thủ và bảo mật.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Áp dụng đầy đủ PII classification, masking, access control, audit logging đã học Phase 8.

Ngày 901: Tích hợp Experimentation Platform

• Mục tiêu: Đưa năng lực A/B testing vào platform như 1 module tự phục vụ.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây module cho phép định nghĩa thí nghiệm, tự động tính power analysis, và phân tích kết quả (bao gồm CUPED) - đóng gói lại toàn bộ Phase 5.

Ngày 902: Tích hợp Forecasting Module

• Mục tiêu: Đưa năng lực dự báo vào platform như 1 dịch vụ dùng chung.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây module forecasting tự phục vụ (chọn metric → tự động chạy Prophet/XGBoost → trả về forecast + uncertainty interval), đóng gói lại Phase 4.

Ngày 903: Tích hợp Optimization Module

• Mục tiêu: Đưa năng lực optimization vào platform.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây module cho phép định nghĩa bài toán optimization đơn giản (VD: phân bổ ngân sách) và giải bằng PuLP/OR-Tools, đóng gói lại Phase 6.

Ngày 904: AI Augmentation Layer

• Mục tiêu: Tích hợp toàn bộ Phase 10 vào platform.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Kết nối text-to-SQL, RAG (trên toàn bộ docs + metric definitions của platform), và AI agent sinh insight tự động vào 1 giao diện thống nhất.

Ngày 905: Reading Log - Đọc sâu 1 thư viện lõi của Platform

• Mục tiêu: Duy trì thói quen reading log đã rèn luyện xuyên suốt roadmap, áp dụng cho chính hệ thống đang hoàn thiện.

• Lý thuyết: Reading log tốt ghi lại: vấn đề thư viện giải quyết, kiến trúc tổng quan, 1-2 đoạn code/pattern đáng nhớ nhất, liên hệ với kiến thức đã học trước đó trong roadmap.

• Thực hành: Chọn 1 thư viện lõi đang dùng nhiều nhất trong platform (VD: MetricFlow, PyIceberg, hoặc framework agent đang dùng ở Phase 10), đọc sâu source code/docs của nó và viết reading log đầy đủ - áp dụng đúng template đã tạo từ Ngày 61 của hành trình.

Ngày 906: Dashboard & Executive Reporting Layer

• Mục tiêu: Xây tầng trình bày cho ban lãnh đạo.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây dashboard điều hành tổng hợp (North Star Metric + các metric chiến lược), áp dụng toàn bộ nguyên tắc storytelling đã học Phase 1 và 9.

Ngày 907: Decision Memo Automation

• Mục tiêu: Tự động hóa 1 phần quy trình viết memo (kết hợp AI Phase 10 + kỹ năng viết Phase 9).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây tính năng tự động sinh bản nháp decision memo (theo cấu trúc Pyramid Principle) từ kết quả phân tích, con người review và tinh chỉnh trước khi gửi.

Ngày 908: Observability & Monitoring toàn Platform

• Mục tiêu: Đảm bảo platform được giám sát toàn diện.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Thiết lập observability đầy đủ (5 trụ cột đã học Phase 2) cho toàn bộ pipeline, alerting khi có bất thường.

Ngày 909: Security & Access Control

• Mục tiêu: Đảm bảo platform an toàn khi có nhiều người dùng.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Rà soát và hoàn thiện IAM, RLS, secrets management cho toàn bộ platform (áp dụng Phase 3, 8).

Ngày 910: CI/CD cho Toàn bộ Platform

• Mục tiêu: Đảm bảo platform có thể phát triển tiếp bền vững.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Hoàn thiện pipeline CI/CD cho dbt, cho AI augmentation layer, và cho toàn bộ hạ tầng orchestration.

Ngày 911: Performance Optimization Pass

• Mục tiêu: Áp dụng kiến thức Phase 8 Internals để tối ưu toàn hệ thống.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Rà soát và tối ưu các điểm nghẽn hiệu năng (query chậm, job Spark tốn tài nguyên, chi phí warehouse cao bất thường).

Ngày 912: End-to-end Testing

• Mục tiêu: Đảm bảo toàn bộ hệ thống hoạt động đúng khi ghép lại.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Chạy test end-to-end toàn bộ luồng: ingestion → transformation → metrics → experimentation/forecasting/optimization → dashboard/AI layer, sửa lỗi phát sinh.

Ngày 913: Tài liệu hóa - Architecture Document

• Mục tiêu: Ghi lại toàn bộ quyết định kiến trúc.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết tài liệu kiến trúc đầy đủ kèm sơ đồ cho toàn bộ platform, giải thích lý do lựa chọn công nghệ ở từng tầng.

Ngày 914: Tài liệu hóa - User Guide

• Mục tiêu: Giúp người khác (hoặc chính mình sau này) dùng lại platform.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết hướng dẫn sử dụng cho từng module (cách chạy thí nghiệm, cách lấy forecast, cách hỏi AI agent).

Ngày 915: Portfolio Case Study Writeup

• Mục tiêu: Biến dự án thành tài sản nghề nghiệp.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Viết case study hoàn chỉnh theo cấu trúc đã học Phase 9 (bối cảnh → thách thức → phương pháp → kết quả → bài học), đây sẽ là centerpiece của portfolio.

Ngày 916: Executive Presentation Prep

• Mục tiêu: Chuẩn bị trình bày dự án tổng kết.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Xây bộ slide executive summary (áp dụng Pyramid Principle + One-slide summary đã học Phase 9) trình bày toàn bộ platform.

Ngày 917: Mock Demo/Rehearsal

• Mục tiêu: Luyện tập trước khi trình bày chính thức (hoặc dùng cho phỏng vấn).

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Quay thử buổi trình bày đầy đủ 15-20 phút, tự đánh giá và ghi chú điểm cần cải thiện.

Ngày 918: Final Refinements

• Mục tiêu: Hoàn thiện lần cuối dựa trên phản hồi tự đánh giá.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Sửa các điểm yếu phát hiện ở Ngày 917 - cả về code, dashboard, lẫn cách trình bày.

Ngày 919: Full System Demo Day

• Mục tiêu: Trình bày chính thức toàn bộ hành trình.

• Lý thuyết: Không có lý thuyết mới.

• Thực hành: Quay video demo hoàn chỉnh (hoặc trình bày trực tiếp nếu có audience) toàn bộ Executive Decision Intelligence Platform - sản phẩm đại diện cho toàn bộ ~920 ngày học tập.

Ngày 920: Tổng kết Toàn bộ Hành trình & Bước tiếp theo

• Mục tiêu: Khép lại roadmap, nhìn về phía trước.

• Lý thuyết: Nhìn lại hành trình đầy đủ: Foundation → Business Analytics → Analytics Engineering → Data Engineering → ML for Decision Making → Experimentation & Causal Inference → Optimization → Decision Science → Platform Internals → Executive Analytics → Modern Data Stack & AI → 4 Capstone lớn. Đây là 1 trong số ít lộ trình bao phủ trọn vẹn từ Business đến Analytics đến Data Platform đến Decision Science.

• Thực hành: Viết bài tổng kết toàn bộ hành trình (những gì tự hào nhất, những gì sẽ tiếp tục học sâu hơn), hoàn thiện portfolio GitHub lần cuối, và lên kế hoạch ứng dụng: tìm việc ở vị trí Analytics Engineer/Data Engineer/Decision Scientist, hoặc tiếp tục đào sâu 1 nhánh chuyên biệt (VD: chuyên sâu Causal Inference, chuyên sâu Data Platform Engineering, hoặc chuyên sâu AI-augmented Analytics).