Bài 4: Tránh 5 sai lầm phổ biến khi build portfolio

Sau bài này bạn sẽ:

• ✅ Nhận ra 5 sai lầm phổ biến nhất trong portfolio AI Engineer
• ✅ Biết triệu chứng cụ thể của từng sai lầm — tự kiểm tra portfolio hiện tại
• ✅ Có hành động sửa cụ thể cho mỗi vấn đề
• ✅ Có checklist tự review portfolio trước khi gửi CV

Triệu chứng

• Repo là notebook Iris classifier, MNIST digit classification, Titanic survival prediction — y hệt tutorial gốc.
• Code không có comment riêng, không có section nào bạn tự thêm vào.
• README paste từ docs gốc hoặc Kaggle kernel.

Tại sao đây là vấn đề

Recruiter nhận hàng chục CV mỗi ngày. Iris classifier và MNIST là hai notebook phổ biến nhất trên Kaggle — họ nhận ra ngay. Một repo tutorial không cho thấy bạn đã hiểu gì hay áp dụng được vào vấn đề khác.

Quan trọng hơn: repo giống nhau từ nhiều ứng viên khác nhau → không nổi bật.

Cách tránh

Sau khi đọc xong tutorial, làm ít nhất 1-2 modification có ý nghĩa trước khi push lên GitHub:

• Thay dataset: MNIST digit → dataset chữ viết tay tiếng Việt (có thể tự thu thập 500-1000 mẫu, hoặc dùng dataset viết tay Nôm trên Kaggle). Iris → dataset thực khác từ UCI ML Repository.
• Thêm experiment: Tutorial dùng 1 model → bạn thêm bảng so sánh 3 model (Logistic Regression, Random Forest, XGBoost) trên cùng dataset.
• Giải quyết vấn đề thực: Thay vì predict loài hoa, predict loại sản phẩm từ mô tả văn bản (text classification) với data scrape từ một trang thương mại điện tử.

Cuối cùng, document rõ trong README:

## Origin
Started from [Andrew Ng's ML Specialization notebook](URL),
modified:
- Replaced Iris dataset with Vietnam flower species dataset (450 samples, 5 classes)
- Added cross-validation instead of single train/test split
- Added confusion matrix and per-class F1 analysis

Câu này cho recruiter thấy bạn biết mình làm gì và tại sao, không phải copy blind.

Triệu chứng

• GitHub repo chỉ có file .ipynb.
• README hướng dẫn: "Clone repo → tạo venv → pip install -r requirements.txt → chạy notebook cell by cell".
• Không có URL public nào để test ngay.

Tại sao đây là vấn đề

Recruiter dành 30 giây cho mỗi CV. Họ sẽ không clone repo, không setup local environment để xem project của bạn chạy thế nào. Nếu không có link demo, project đó không tồn tại với họ.

Thêm vào đó, một AI Engineer trong môi trường thực phải biết cách đưa model ra ngoài để người khác dùng được — không có deploy nghĩa là thiếu production-thinking.

Cách tránh

Deploy lên một trong các nền tảng free tier sau:

• Hugging Face Spaces: hỗ trợ Gradio và Streamlit, free CPU instance, giới hạn RAM 16 GB (đủ cho hầu hết prototype). Phù hợp ML/DL demo.
• Render free tier: deploy FastAPI/Flask app, sleep sau 15 phút inactive nhưng đủ cho CV.
• Railway free tier: tương tự Render, $5 credit/tháng (đủ cho project nhỏ).
• Streamlit Community Cloud: deploy Streamlit app từ GitHub repo trong vài phút, hoàn toàn free cho public repo.

Sau khi deploy:

• Đặt URL vào đầu README — dòng đầu tiên sau project name, trước mọi thứ khác.
• Thêm screenshot hoặc GIF demo ngay dưới URL (bài 18 của series sẽ hướng dẫn cách tạo GIF).
• Test URL từ tab ẩn danh (incognito) mỗi tuần để đảm bảo không die silent.

# RAG Chatbot for Internal Docs

**Live Demo**: https://your-app.hf.space

![Demo](docs/demo.gif)

...

Triệu chứng

• README 5 dòng: "This is an AI project for [vague use case]."
• Không có quick start — người đọc không biết cách chạy.
• Không có demo link, không có architecture diagram.
• Code không có comment, không có docstring.

Tại sao đây là vấn đề

README là điểm tiếp xúc đầu tiên. Nếu người đọc (recruiter, hiring manager, hay đồng nghiệp tương lai) không hiểu project làm gì trong 1 phút đọc nhanh, họ sẽ rời đi mà không đọc thêm. Một README nghèo nàn cũng cho thấy thiếu kỹ năng giao tiếp — thứ quan trọng không kém kỹ năng code trong môi trường làm việc thực.

Cách tránh

README tối thiểu cần có các mục sau (bài 17 của series sẽ đi chi tiết hơn):

1. Project name + live demo link (dòng đầu)
2. Problem: Bạn giải quyết vấn đề gì? Ai gặp vấn đề đó?
3. Solution: Approach của bạn là gì? (1-2 câu)
4. Architecture diagram hoặc flow diagram đơn giản
5. Tech stack: Python 3.11, FastAPI, ChromaDB, OpenAI API v1.x
6. Quick start: clone → install → chạy trong dưới 5 lệnh
7. Results: số metric cụ thể (xem sai lầm #5)
8. Engineering decisions: tại sao chọn X thay vì Y (xem sai lầm #4)

Một test đơn giản: đưa README cho người chưa thấy project của bạn. Sau 1 phút đọc, họ có giải thích lại được project làm gì không? Nếu không, README cần viết lại.

Triệu chứng

• Code dùng ChromaDB nhưng README không giải thích tại sao chọn ChromaDB thay vì Pinecone, Weaviate, hay FAISS.
• Hyperparameter như chunk_size=500, k=5 hardcode, không có ghi chú.
• Architecture diagram có (hoặc không có) nhưng không giải thích trade-off của thiết kế.

Tại sao đây là vấn đề

Trong buổi phỏng vấn technical, hiring manager rất hay hỏi về decision trong project của bạn: "Tại sao chọn X?", "Đã thử Y chưa?", "Nếu scale lên 10x thì cần thay gì?" Nếu decision không có rationale, bạn không chứng minh được rằng mình đã nghĩ về trade-off — câu trả lời dễ bị "ấp úng".

Ngoài ra, người đọc từ bên ngoài không có cách nào biết bạn đã cân nhắc kỹ hay chọn ngẫu nhiên.

Cách tránh

Thêm section "Engineering Decisions" trong README. Mỗi decision chỉ cần 1-2 câu rationale:

## Engineering Decisions

**Vector store: ChromaDB over Pinecone**
Prototype scale (<100K vectors), free tier đủ dùng, không cần managed service.
Nếu scale >1M vectors hoặc cần multi-tenant, sẽ migrate sang Pinecone/Weaviate.

**Chunk size: 500 tokens**
Tested 200, 500, 1000 tokens. Recall@5 tốt nhất ở 500 (0.87 vs 0.79 ở 200 và 0.83 ở 1000)
trên test set 50 câu hỏi. Context window vẫn đủ để model không bị truncate.

**API framework: FastAPI over Flask**
LLM call là async I/O — FastAPI native async giúp xử lý concurrent request tốt hơn.
Flask sync blocking không phù hợp khi mỗi request có thể mất 2-5s chờ OpenAI API.

**Embedding model: text-embedding-3-small (OpenAI)**
Cost: $0.02/1M tokens (vs $0.13/1M cho text-embedding-3-large).
Benchmark trên dataset nội bộ: small đạt 0.84 recall@5, large đạt 0.87.
Chênh lệch 3% không justify cost gap 6.5x ở prototype stage.

Format không quan trọng bằng việc có rationale. Ngay cả "tôi chưa có thời gian compare, sẽ benchmark sau" cũng tốt hơn im lặng — cho thấy bạn biết mình chưa làm gì.

Triệu chứng

• "Chatbot rất thông minh và trả lời chính xác."
• "Model đạt accuracy cao trên test set."
• "Latency nhanh, dưới 1 giây."
• Không có con số, không có bảng so sánh.

Tại sao đây là vấn đề

Claim không có số không thuyết phục được ai có kinh nghiệm kỹ thuật. "Accuracy cao" là 60% hay 95%? "Latency nhanh" là 50ms hay 800ms? Thiếu số liệu cũng đặt câu hỏi: bạn có thực sự đo lường hay chỉ cảm nhận chủ quan?

Data-driven thinking là skill cốt lõi của AI Engineer. Portfolio không có metric là tự mâu thuẫn với vai trò đó.

Cách tránh

Báo cáo metric cụ thể tùy loại project:

ML classification / regression

## Results

| Model | Accuracy | F1 (macro) | AUC-ROC | Train time |
|---|---|---|---|---|
| Logistic Regression (baseline) | 0.76 | 0.70 | 0.82 | 2s |
| Random Forest | 0.81 | 0.78 | 0.87 | 45s |
| XGBoost (tuned) | **0.84** | **0.81** | **0.89** | 3 min |

Tuning: RandomizedSearchCV, 50 iterations, 5-fold CV.
Test set: 20% stratified split, seed=42.

LLM / RAG project

## Results

Evaluated with [Ragas](https://github.com/explodinggradients/ragas) v0.1.x
on test set 80 question-answer pairs (manually labeled):

| Metric | Score |
|---|---|
| Faithfulness | 0.87 |
| Answer Relevancy | 0.91 |
| Context Recall | 0.83 |
| Context Precision | 0.79 |

Latency (HF Spaces CPU, avg over 100 requests):
- P50: 2.1s | P95: 4.8s | P99: 7.2s

Inference / serving project

## Performance

Measured on single T4 GPU (Google Colab free tier):
- Throughput: 48 RPS (batch size 8)
- Latency P50: 82ms | P95: 210ms
- GPU memory: 6.2 GB / 16 GB

Baseline (single-threaded CPU): 3.2 RPS

Nếu project quá nhỏ để có benchmark đầy đủ, ít nhất ghi rõ test set size và điều kiện đo:

Accuracy: 0.84 on 200-sample held-out test set (stratified, seed=42).

Con số nhỏ nhưng rõ ràng luôn tốt hơn claim mơ hồ.

Sai lầm #6: Project quá to, chưa hoàn thành

Bài 2 đã đi sâu về scoping. Nhắc lại ngắn gọn: "AI doctor diagnoses all diseases" — sau 6 tháng dev, demo chỉ handle được 1 loại triệu chứng trên 2 bộ data test. Kết quả: reject.

Scope nhỏ + complete + deployed + documented > scope to + dở dang. Recruiter muốn thấy bạn ship, không muốn nghe về vision.

Sai lầm #7: Code chất lượng thấp

• 1 file main.py 2000 dòng, không module hóa.
• Variable name: x, df1, model_v3_final_final.
• Không có type hint, không có docstring.
• API key hardcode trong code hoặc commit vào Git.

Module 2 của series (bài 7-10) sẽ đi chi tiết về cấu trúc thư mục, refactor, type hints, và logging. Điểm cần nhớ ngay: không bao giờ commit secret — dùng .env + .gitignore.

Sai lầm #8: Version control hygiene kém

• 1 commit "initial commit" → toàn bộ project final.
• Hoặc ngược lại: 500 commit "wip", "fix fix", "test", "test2", "asdf".
• Không có branch, không có pull request nào.

Git history là portfolio phụ. Hiring manager kỹ tính sẽ xem commit message để đánh giá cách bạn làm việc. Bài 5-6 (Module 2) sẽ hướng dẫn Git workflow cụ thể cho dự án AI cá nhân.

Dùng checklist 5 bước này trước mỗi lần gửi CV:

Bước 1: Clone test trên máy sạch

Clone repo trên máy mới (hoặc xóa cache local), làm theo README từ đầu. Setup có chạy được không? Nếu bạn cần nhớ thêm bước nào không có trong README, đó là bug trong documentation.

Bước 2: Nhờ người ngoài đọc README

Nhờ 1 developer (không phải bạn thân đã nghe bạn nói về project 10 lần, mà là người thực sự chưa biết gì về project) đọc README trong 1 phút. Hỏi: "Project này làm gì? Giá trị của nó là gì?" Nếu họ không trả lời được, README cần viết lại.

Bước 3: Kiểm tra pronouns

Trong README, tìm "I" vs "we". Solo project nên nhất quán dùng "I" — "I built", "I chose", "I tested". Team project cần ghi rõ vai trò của từng người: "I was responsible for the RAG pipeline; teammate A handled the frontend."

Bước 4: Kiểm tra broken link và broken demo

Click từng link trong README từ tab ẩn danh. Demo URL còn sống không? Nếu deploy trên Render free tier, service có bị sleep và cần 30 giây warm up không? Nếu có, ghi chú trong README để người dùng không nghĩ demo bị lỗi.

Bước 5: Kiểm tra security

Chạy lệnh sau trong thư mục repo:

# Tìm file có thể chứa secret bị commit nhầm
git log --all --full-history -- "*.env" "*.key" "*secret*" "*credential*"

# Tìm pattern API key trong toàn bộ Git history
git log -p | grep -i "sk-\|api_key\|secret_key\|password\|token" | head -20

Nếu có kết quả, cần xử lý trước khi đưa link cho ai: rotate key ngay lập tức, dùng git filter-repo để xóa secret khỏi history, hoặc đơn giản nhất là tạo repo mới với history sạch.

Đọc bài 1-4 xong, hãy làm ngay thay vì để đọc tiếp:

1. Mở danh sách repo GitHub hiện tại của bạn.
2. Chạy qua checklist 5 bước ở phần trên cho từng repo.
3. List ra các vấn đề cụ thể — ví dụ: "Repo X không có deploy link", "Repo Y README thiếu architecture", "Repo Z dùng Iris dataset không modify".
4. Fix 1-2 vấn đề mỗi tuần. Đừng cố fix tất cả trong 1 ngày — chất lượng thấp hơn sửa từng cái cẩn thận.
5. Sau 1 tháng, chạy lại checklist.

Một số điểm cần tránh

• Mong portfolio hoàn hảo ngay: không thực tế. Portfolio tốt là portfolio được iterate liên tục, không phải portfolio được viết xong một lần.
• Không update sau khi học thêm: khi bạn học được cách dùng Ragas để eval RAG, quay lại repo RAG cũ và thêm evaluation section. Portfolio nên phản ánh level hiện tại của bạn, không phải level 6 tháng trước.
• So sánh với senior 5-10 năm kinh nghiệm: không cùng tiêu chí. Recruiter tuyển junior đánh giá khác — họ tìm potential, learning speed, và ability to ship — không phải production-grade codebase hoàn chỉnh.

Module 1 (bài 1-4) đã cover chiến lược nền tảng cho portfolio:

• Bài 1 — Tiêu chí recruiter dùng để đánh giá project: real problem, measurable outcome, complete + deployed, clean code, documented.
• Bài 2 — Scoping: thu hẹp phạm vi để hoàn thành trong 2-4 tuần, tránh over-engineer ở prototype stage.
• Bài 3 — Cấu trúc portfolio: cân bằng giữa ML cổ điển + deep learning + LLM, 3-4 project đủ mạnh hơn 10 project nửa vời.
• Bài 4 — 5 sai lầm cụ thể: copy tutorial, không deploy, README nghèo, thiếu decision rationale, không đo metric.

Module 2 (bài 5-10) chuyển sang code quality: Git workflow, cấu trúc thư mục, refactor notebook, type hints, logging.

Bài 5: Git workflow cá nhân cho dự án AI — commit convention, branching model phù hợp solo project, và cách viết commit message mô tả đủ để hiring manager hiểu được tiến trình làm việc.