Bài 1: Tiêu chí 1 project AI gây ấn tượng với nhà tuyển dụng

Sau khi hoàn thành bài này, bạn sẽ:

• Biết 7 tiêu chí cụ thể để đánh giá chất lượng 1 AI project
• Phân biệt được 3 cấp độ project (beginner / intermediate / advanced)
• Hiểu recruiter và hiring manager nhìn vào cái gì trong repo của bạn
• Tránh được các loại project không tạo ra sự khác biệt trên CV

Vị trí AI Engineer entry-level hiện nay nhận nhiều hồ sơ ứng tuyển hơn trước do số người học AI tăng nhanh trong giai đoạn 2022–2025. Điểm phân hóa thực sự giữa CV pass và CV reject thường không phải là số chứng chỉ, mà là chất lượng project.

Quy trình review CV thực tế diễn ra theo 2 tầng:

• Recruiter (non-technical): scan khoảng 6–10 giây mỗi CV. Họ tìm tên công ty cũ, job title, và link GitHub/portfolio. Nếu repo trông rỗng hoặc README không có gì — bị lọc ngay.
• Hiring manager (technical): nếu CV qua vòng recruiter, họ sẽ dành 10–20 phút đọc kỹ code, kiến trúc, và logic lựa chọn kỹ thuật.

Hai tầng này yêu cầu khác nhau. Một project tốt cần đáp ứng cả hai.

a) Giải quyết bài toán cụ thể

Domain rõ ràng và có target user xác định luôn mạnh hơn đề bài chung chung:

• Yếu: "Chatbot using LLM"
• Mạnh hơn: "Chatbot Q&A trên 500 trang quy chuẩn ISO của công ty X, dùng để nhân viên tra cứu nhanh thay vì tìm thủ công"

Ba câu hỏi nên trả lời được ngay trong README:

1. Bài toán là gì?
2. Ai dùng, để làm gì?
3. Input và output trông như thế nào?

b) End-to-end (không chỉ notebook)

Recruiter technical không đủ thời gian chạy Jupyter Notebook của bạn. Một project chứng minh được khả năng engineering cần có đường đi đầy đủ:

Data → EDA notebook → Training script → Saved model → API → Deploy → Demo URL

Minimum viable end-to-end: có 1 URL công khai mà ai cũng vào test được. Project chỉ tồn tại dưới dạng .ipynb trên Colab không cho thấy bạn biết cách đưa model ra ngoài.

c) Code quality

Hiring manager thường mở 1–2 file Python đầu tiên để đánh giá coding style. Checklist tối thiểu:

• README rõ ràng (xem mục 7 bên dưới)
• Type hints trên function signature
• Docstring trên các function chính
• Code tách module (không nhét tất cả vào 1 file)
• Có ít nhất basic unit test
• .gitignore chặn .env, *.key, credentials

# Ví dụ: function có type hint và docstring
def chunk_documents(text: str, chunk_size: int = 500) -> list[str]:
    """
    Chia văn bản thành các chunk có độ dài tối đa chunk_size token.

    Args:
        text: Văn bản đầu vào.
        chunk_size: Số token tối đa mỗi chunk. Mặc định 500.

    Returns:
        Danh sách các chunk string.
    """
    ...

d) Reproducibility

Nếu hiring manager không clone và chạy được trong 5 phút — project đó bị trừ điểm đáng kể. Yêu cầu tối thiểu:

• requirements.txt hoặc pyproject.toml với version pin (fastapi==0.111.0, không phải fastapi>=0.100)
• Setup instruction rõ ràng: clone → install → run, tối đa 3–5 lệnh
• Dockerfile nếu project có dependency phức tạp

# Ví dụ setup instruction tốt trong README
git clone https://github.com/you/churn-prediction
cd churn-prediction
pip install -r requirements.txt
cp .env.example .env   # điền API key nếu cần
uvicorn app.main:app --reload

e) Engineering decision rõ ràng

Đây là điểm phân hóa giữa người copy tutorial và người thực sự hiểu trade-off. README nên có phần giải thích các lựa chọn kỹ thuật chính:

• "Tại sao dùng ChromaDB thay vì Pinecone?" → vì ChromaDB có thể self-host, không cần managed service khi demo
• "Tại sao chunk size 500 token?" → test trên 20 câu hỏi mẫu, chunk 500 cho Answer Relevancy 0.91 vs chunk 200 cho 0.83
• "Tại sao dùng LightGBM thay vì XGBoost?" → tốc độ train nhanh hơn 2x trên dataset 50k row, F1 tương đương

Không cần mỗi quyết định đều có benchmark, nhưng phải cho thấy bạn đã cân nhắc chứ không chỉ copy cấu hình mặc định.

f) Kết quả đo lường được

Số cụ thể quan trọng hơn mô tả chung chung. So sánh:

• Yếu: "Model đạt accuracy cao"
• Mạnh hơn: "F1=0.84 trên test set 10k rows. Baseline logistic regression F1=0.71."

Các số đáng đưa vào README:

• Metric chính (F1, accuracy, BLEU, Faithfulness...) và baseline so sánh
• Latency (ms/request hoặc ms/ảnh)
• Chi phí inference nếu dùng API trả tiền (ví dụ: "~$0.002/query với GPT-4o-mini")

Không bịa số. Nếu chưa có measurement — ghi rõ "chưa benchmark, TODO".

g) Giá trị production-ish

Project không cần production-ready hoàn toàn, nhưng cần có các dấu hiệu cho thấy bạn nghĩ tới edge case:

• Xử lý input trống hoặc sai format (không để app crash với unhandled exception)
• Có loading state / timeout khi gọi model ngoài
• Deploy URL hoạt động — nhiều CV demo URL bị die sau vài ngày; hãy dùng nền tảng free nhưng ổn định (Render, Hugging Face Spaces, Railway)

Hiểu cấp độ project giúp bạn ưu tiên đầu tư thời gian đúng chỗ.

Beginner (tutorial-level)

Ví dụ: MNIST digit classifier, Titanic survival prediction, Iris species classification.

Đây là bài tập học, không phải portfolio. Recruiter kỹ thuật nhận ra ngay. Nếu CV chỉ có loại này — không phân biệt được với hàng trăm CV khác cùng đợt. Có thể giữ trong repo nếu bạn viết README đặc biệt (thêm analysis sâu, so sánh nhiều model, ablation study), nhưng không nên đặt ở vị trí nổi bật.

Intermediate

Ví dụ: Customer churn prediction trên dataset thực (tự thu thập hoặc Kaggle + preprocessing riêng) → train → API FastAPI → deploy Render.

Đủ để pass vòng recruiter nếu README tốt và có deploy URL. Hiring manager sẽ hỏi thêm về lựa chọn kỹ thuật — chuẩn bị trả lời được.

Advanced

Ví dụ: RAG chatbot trên tài liệu nội bộ có evaluation framework (Ragas), drift monitoring, Docker compose.

Cho thấy khả năng engineering level cao hơn tutorial. Hiring manager ở mức senior hoặc lead thường tìm loại này. Không cần nhiều — 1 project advanced tốt hơn 5 project intermediate cùng pattern.

1 project chất lượng cao mạnh hơn 10 project copy tutorial.

Cấu hình portfolio hợp lý cho AI Engineer entry-level:

• 3–5 project tổng là vừa. Recruiter không đọc hết 10+ project.
• 1 project strong ở cấp advanced hoặc intermediate+: end-to-end, có metric rõ, có deploy, có engineering decision.
• 2–3 project supporting đa dạng kỹ năng: 1 ML cổ điển + 1 Computer Vision hoặc NLP + 1 LLM/Agent là cover phổ kỹ năng tốt cho AI Engineer role.

Đa dạng domain quan trọng hơn đa dạng số lượng. Nếu 5 project đều là sentiment analysis với BERT — không cho thấy bạn linh hoạt.

• Iris / Titanic / MNIST thuần — nếu không thêm gì mới (analysis độc đáo, deployment, benchmark nhiều model), chúng là bài tập chứ không phải portfolio.
• Copy Kaggle notebook không modify — hiring manager thường biết notebook gốc; copy y hệt gây phản tác dụng.
• "Build ChatGPT clone" quá generic — không có bài toán cụ thể, không có domain, không có metric. Nếu làm chatbot thì phải có context domain rõ ràng.
• Project chỉ là Jupyter Notebook trên Colab, không có deploy — recruiter không thể verify performance mà không tự chạy, phần lớn sẽ bỏ qua.
• Project "to" nhưng "in progress" mãi — ví dụ "Self-driving car simulation" hay "AGI research" khi chưa đủ thời gian để complete. CV chỉ thấy "work in progress" trong nhiều tháng gây nghi ngờ về khả năng hoàn thành.
• Project có data nhạy cảm — data từ employer cũ mà chưa có phép dùng là rủi ro pháp lý. Tránh tuyệt đối.

Recruiter thường không chạy code. Họ scan visual trong 30 giây đầu khi mở GitHub repo:

1. README có ảnh hoặc GIF demo không? — Repo không có hình thường bị close ngay. 1 screenshot giao diện hoặc GIF demo đủ để giữ attention.
2. 3 thứ đầu tiên của README: project goal (1-2 câu), demo link, tech stack. Nếu phải scroll mới thấy project làm gì — README thất bại.
3. Commit history: Một commit duy nhất "Initial commit" với 200 files cho thấy bạn dump code lên một lần, không develop iteratively. Nhiều commit đều đặn (dù nhỏ) trông professional hơn.
4. Stars / forks: Nice-to-have nhưng không quyết định. Recruiter biết project portfolio ít người star.

Cấu trúc README tối thiểu để pass recruiter:

# Project Name

<1-2 câu mô tả bài toán và kết quả chính>

**Demo:** [link]  |  **Tech stack:** Python, FastAPI, ChromaDB, Docker

![demo screenshot hoặc GIF]

## Quick Start
```bash
git clone ...
pip install -r requirements.txt
uvicorn app.main:app
```

## Results
| Metric | Value |
|--------|-------|
| F1 Score | 0.84 |
| Latency | ~120ms |

Hiring manager thường là kỹ sư senior hoặc tech lead. Trong 15 phút, họ kiểm tra theo thứ tự:

1. Architecture diagram hoặc mô tả kiến trúc trong README — không cần fancy, 1 ASCII diagram hoặc ảnh draw.io đủ cho thấy bạn nhìn toàn bộ hệ thống.

   PDF files → Chunking → Embedding (text-embedding-3-small)
        → ChromaDB → Retrieval → LLM (GPT-4o-mini) → Response

2. Cấu trúc thư mục — separation of concerns rõ không? Có tách src/, tests/, scripts/ không, hay tất cả nằm chung 1 folder?
3. 1–2 file code chính — clean không, có hardcode magic number không, có xử lý exception không.
4. Tests — chạy pytest có pass không. Không có test = dấu hiệu đỏ.
5. Engineering decision trong README — tại sao chọn công nghệ X, tại sao cấu hình Y. (Xem mục 3e.)
6. Demo URL — mở thử. Rất nhiều CV có demo URL không còn hoạt động. Nếu URL die, project đó mất điểm lớn.

Lỗi phổ biến nhất:

# Hardcode — hiring manager thấy ngay
OPENAI_API_KEY = "sk-proj-xxxx..."  # KHÔNG bao giờ commit key
CHROMA_PATH = "/Users/yourname/projects/rag/chroma_db"  # path cứng local machine

# Đúng — dùng environment variable
import os
OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")
CHROMA_PATH = os.getenv("CHROMA_PATH", "./data/chroma_db")

Ba ví dụ dưới đây minh họa cho 3 loại project trong portfolio AI Engineer. Số liệu là ví dụ minh họa, không phải benchmark chuẩn.

Project 1 — ML cổ điển

Tên: Customer Churn Prediction

Bài toán: Dự báo khách hàng nào sẽ rời mạng trong 30 ngày tới, từ dataset 50k customer của 1 công ty viễn thông.

Stack: Python, LightGBM, SHAP, FastAPI, PostgreSQL, Render

Kết quả: F1=0.84 trên test set. Baseline logistic regression F1=0.71. Deploy FastAPI trên Render. Monitor drift weekly bằng Evidently.

Engineering decision đáng ghi: Chọn LightGBM vì train 2x nhanh hơn XGBoost trên dataset này, F1 chênh lệch dưới 0.5%. Dùng SHAP để explain prediction cho non-technical stakeholders.

Project 2 — Computer Vision

Tên: Phát hiện sản phẩm lỗi từ ảnh dây chuyền sản xuất

Bài toán: Phân loại ảnh sản phẩm đạt / lỗi từ camera conveyor belt. Dataset 2,000 ảnh tự annotate bằng Label Studio.

Stack: YOLOv8 (ultralytics v8.2), Gradio, Google Colab Pro (train), Hugging Face Spaces (demo)

Kết quả: mAP50=0.91. Latency 80ms/ảnh trên NVIDIA T4. Demo public trên HF Spaces.

Engineering decision đáng ghi: Chọn YOLOv8n (nano) thay vì YOLOv8m vì latency mục tiêu <100ms với T4; mAP chỉ kém 3 điểm nhưng nhanh hơn 2.5x.

Project 3 — LLM / Agent

Tên: RAG chatbot tra cứu quy định nội bộ

Bài toán: Cho phép nhân viên đặt câu hỏi bằng tiếng Việt về 500 file PDF quy định, thay cho tìm kiếm thủ công.

Stack: LangChain v0.2, ChromaDB, GPT-4o-mini, FastAPI, Docker Compose, Grafana + Prometheus

Kết quả eval (Ragas v0.1): Faithfulness=0.87, Answer Relevancy=0.91, trên 100 câu hỏi test.

Engineering decision đáng ghi: Chunk size 500 token với 50 token overlap — test 200/500/800 token trên 20 câu, 500 cho Answer Relevancy cao nhất. ChromaDB vì self-hostable, tránh vendor lock-in trong môi trường demo.

Nếu bạn đến từ ngành khác (y tế, tài chính, HR, logistics...), domain knowledge cũ là lợi thế thực sự — không phải điều cần che giấu. Project kết hợp domain cũ + kỹ thuật AI thường mạnh hơn project generic vì:

• Bạn hiểu bài toán thực sự (không chỉ làm theo tutorial)
• Bạn biết data của domain đó trông như thế nào, biết edge case nào quan trọng
• Dễ gây ấn tượng với công ty đang tuyển AI Engineer có domain cụ thể

Ví dụ:

• Bác sĩ / điều dưỡng → AI triage triệu chứng, phân loại X-quang trên public dataset (CheXpert, NIH Chest X-rays)
• Kế toán / tài chính → Fraud detection, credit scoring, dự báo dòng tiền
• HR → Resume screening, phân tích văn hóa công ty từ Glassdoor reviews
• Logistics → Dự báo nhu cầu, tối ưu tuyến đường

Điều quan trọng: phải trình bày rõ bạn đã làm gì về mặt kỹ thuật (không chỉ nói "tôi hiểu domain") và kết quả đo lường được là gì.

• Làm theo trend, không có bài toán riêng: Thấy nhiều người làm RAG chatbot → làm RAG chatbot y hệt → CV không khác biệt. Bài toán domain cụ thể mới là điểm phân hóa.
• Project scope quá lớn, không complete được: "Self-driving car simulation", "AI tổng hợp âm nhạc theo cảm xúc người dùng" — khó complete trong thời gian có hạn. Kết quả: repo "work in progress" nhiều tháng. Bắt đầu nhỏ, complete đầy đủ, rồi mở rộng.
• Quên deploy: Recruiter không chạy notebook của bạn. Không có URL demo = không có cách verify nhanh.
• Code không clean: Hiring manager thấy hardcode, không có type hint, exception bị bắt bằng except: pass — sẽ flag là code quality issue trong code review round thực.
• README 5 trang lý thuyết, không có quick start: README viết nhiều về background lý thuyết, ít về cách chạy. Recruiter scroll qua mà không thấy demo link hay quick start trong 10 giây đầu — close tab.
• Demo URL die: Deploy xong nhưng không kiểm tra lại trước khi submit CV. Free tier của một số platform có sleep policy (Render free tier sleep sau 15 phút inactive, cold start ~30 giây) — ghi chú điều này trong README để người review biết.

7 tiêu chí một project AI gây ấn tượng:

1. Giải quyết bài toán cụ thể với domain và target user rõ ràng
2. End-to-end: có deploy URL công khai
3. Code quality: type hint, docstring, module hóa, không leak secret
4. Reproducibility: pin version, setup instruction 3–5 lệnh
5. Engineering decision rõ ràng trong README
6. Kết quả đo lường được: metric + baseline + latency
7. Production-ish: xử lý error case, deploy URL hoạt động

Portfolio hợp lý: 3–5 project, tập trung 1 strong + 2–3 supporting đa dạng domain (ML cổ điển, CV hoặc NLP, LLM/Agent).

Bài 2: Project Scoping — thu hẹp phạm vi để hoàn thành