Nhiều CTO hiện nay đang chịu áp lực lớn từ board: "Chúng ta cần AI strategy." Nhưng giữa hype và thực tế có một khoảng cách rất lớn, và nếu không cẩn thận, bạn sẽ tốn 6-12 tháng lương để thuê sai người, xây sai thứ, và cuối cùng vẫn không có gì để show.

Bài này là những gì tôi đã học được qua nhiều lần thất bại và một vài lần thành công.

ML Engineer, AI Engineer, Data Scientist — Đừng Nhầm Lẫn Nữa

Trước khi hire ai, bạn phải biết mình cần gì. Đây là lỗi đầu tiên và phổ biến nhất.

Data Scientist được training để trả lời câu hỏi kinh doanh bằng dữ liệu. Họ giỏi phân tích, visualization, thống kê. Toolset: Pandas, Jupyter, SQL, R. Vấn đề: họ thường không biết cách productionize thứ mình làm. Notebook chạy được ≠ sản phẩm.

ML Engineer là người train và deploy model. Họ hiểu ML fundamentals, biết optimize training pipeline, tune hyperparameter, và — quan trọng hơn — biết cách đưa model vào production. Đây là profile hiếm nhất và đắt nhất.

AI Engineer là profile mới nổi, và thực ra phù hợp với 80% nhu cầu của startup hiện tại. Họ không train model từ đầu — họ orchestrate, integrate, và build product trên top của foundation models (GPT-4, Claude, Gemini). Toolset: LangChain/LlamaIndex, vector database, prompt engineering, RAG pipeline.

Nếu bạn đang xây sản phẩm AI mà không cần custom model, bạn cần AI Engineer, không phải ML Engineer. Đây là insight quan trọng nhất trong bài này.

Phần 1: Hire Specialist Hay Upskill Developer Hiện Tại?

Đây là câu hỏi chiến lược, không có đáp án duy nhất.

Khi nào nên upskill developer hiện tại

Nếu bạn đang ở giai đoạn thêm AI features vào product đã có — search semantic, chatbot support, content generation — thì developer giỏi của bạn hoàn toàn có thể học và làm được trong 2-3 tháng. Foundation model API hiện nay rất developer-friendly.

Chi phí upskilling thực tế thấp hơn nhiều bạn nghĩ: vài khóa học ($500-1000), thời gian tự học, và một senior làm mentor. So với salary của một AI Engineer ($80k-150k/năm), ROI rõ ràng.

Dấu hiệu upskill là đủ:

  • Use case của bạn chủ yếu là API integration (OpenAI, Anthropic, etc.)
  • Không cần custom training hay fine-tuning
  • Team hiện tại có solid engineering foundation

Khi nào phải hire specialist

Nếu bạn cần bất kỳ điều nào dưới đây, hãy hire người có kinh nghiệm thực sự:

  • Fine-tuning model trên domain-specific data
  • Build và maintain RAG pipeline phức tạp ở production scale
  • MLOps: model versioning, A/B testing models, drift detection
  • Xử lý dữ liệu lớn, real-time inference với SLA ketat

Một nguyên tắc đơn giản: nếu "khi nào model fail" là câu hỏi business-critical với bạn, bạn cần specialist.

Phần 2: Job Description Thực Tế — Tránh Buzzword

JD tệ sẽ attract người tệ. Đây là những gì tôi thấy trong 90% JD AI Engineer hiện nay và tại sao chúng fail:

Tránh những cụm này trong JD:

  • "Deep knowledge of cutting-edge AI/ML" — vague, không test được
  • "Passion for AI" — ai cũng claim điều này
  • "Experience with ChatGPT" — đây không phải technical skill
  • "Build the future of AI" — marketing copy, không phải JD

JD thực tế nên specify:

## What you'll actually do
- Design and maintain RAG pipeline serving 10k+ queries/day
- Evaluate and improve retrieval quality (precision, recall metrics)
- Integrate LLM outputs into existing product APIs (REST/GraphQL)
- Monitor model performance, implement alerting for quality degradation
- Write evals — automated test suites for LLM behavior
 
## Stack you'll work with
- LLM: Claude API, OpenAI API
- Vector DB: Pinecone hoặc pgvector (PostgreSQL)
- Orchestration: LangChain hoặc tự build
- Infra: AWS/GCP, Docker, Kubernetes
- Observability: LangSmith, Helicone, hoặc custom logging
 
## Interview signal chúng tôi tìm kiếm
- Đã ship AI feature lên production (không phải side project)
- Có thể debug tại sao RAG trả về wrong context
- Biết khi nào không nên dùng LLM

Câu phỏng vấn tôi thích nhất: "Kể cho tôi nghe một lần model/AI system của bạn fail ở production. Bạn debug thế nào?" Người không có production experience sẽ không có câu chuyện thật để kể.

Phần 3: Tech Stack Cho AI Team

Đừng over-engineer từ đầu. Đây là stack tôi recommend theo từng giai đoạn:

Giai đoạn 0-3 tháng: MVP

# LLM Provider
- OpenAI API hoặc Anthropic API (chọn một, đừng abstract quá sớm)
 
# Vector Search (nếu cần RAG)
- pgvector trên PostgreSQL đang dùng (đừng vội deploy Pinecone riêng)
 
# Observability tối thiểu
- Log input/output của mọi LLM call
- Track latency và cost per request

Giai đoạn 3-12 tháng: Scale

# Orchestration
llm_framework: LangChain hoặc LlamaIndex
# Lưu ý: cân nhắc tự build nếu use case đủ đơn giản
 
# Vector Database (khi pgvector không đủ)
options:
  - Pinecone: managed, expensive
  - Weaviate: self-hosted, flexible
  - Qdrant: performance tốt, Go-based
 
# MLOps
experiment_tracking: MLflow hoặc Weights & Biases
model_serving: BentoML, Ray Serve, hoặc simple FastAPI
eval_framework: LangSmith, Braintrust, hoặc tự build
 
# Cost Monitoring (critical!)
tools:
  - Helicone: proxy layer, analytics
  - LiteLLM: unified API, routing, fallback

Một mistake tôi thấy nhiều team mắc phải: deploy Kubernetes cluster cho AI workload khi traffic chưa đến 1000 req/day. Premature optimization ở infra là waste tiền và focus.

Observability — Phần Bị Bỏ Qua Nhiều Nhất

AI systems cần một loại observability khác với traditional software. Bạn không chỉ monitor uptime và error rate — bạn cần monitor quality.

# Minimum viable logging cho mỗi LLM call
{
  "request_id": "uuid",
  "timestamp": "iso8601",
  "model": "claude-3-5-sonnet",
  "input_tokens": 1247,
  "output_tokens": 340,
  "latency_ms": 2100,
  "cost_usd": 0.0089,
  "user_id": "...",
  "session_id": "...",
  "eval_score": null  # fill in sau với human/automated eval
}

Nếu bạn không có eval pipeline, bạn đang bay mù. Mỗi model update, mỗi prompt change có thể silently degrade quality mà không có alert nào.

Phần 4: Onboarding AI Engineer

AI Engineer mới join cần một onboarding track khác với software engineer thông thường.

Tuần 1: Context dump

  • Đọc toàn bộ current prompt library (nếu có)
  • Chạy và đọc kết quả của tất cả existing evals
  • Shadow on-call shift để thấy production incidents thực tế
  • Meet với product/business stakeholder để hiểu use case thực sự

Tuần 2-4: First task Đừng assign feature mới. Assign một improvement task có baseline rõ ràng:

  • "Eval score hiện tại là 73%. Tìm cách lên 80% mà không tăng cost."
  • Đây test cả technical skill lẫn product sense

Sai lầm phổ biến khi onboard AI engineer: Không share cost dashboard. AI engineer cần biết mỗi thay đổi của họ tốn bao nhiêu tiền. Nếu họ không có visibility vào cost, họ sẽ vô tình build những thứ không sustainable.

Phần 5: Culture — Fail Fast Nhưng Có Trách Nhiệm

AI development có đặc điểm riêng về failure mode mà culture của team phải address.

Không phải mọi experiment đều cần approval

AI improvement thường là iterative: thay prompt, đổi chunk size, thử model khác. Nếu mỗi thay đổi nhỏ đều cần sprint ticket và approval, team sẽ chậm và frustrated.

Tôi dùng framework đơn giản này:

Low risk (experiment freely):
  - Prompt wording changes
  - Retrieval parameter tuning
  - Model swapping trong same tier

Medium risk (cần review):
  - Thay đổi system prompt cốt lõi
  - Thêm/bỏ tool/function trong agent
  - Thay đổi output format

High risk (cần approval + rollback plan):
  - Thay model provider
  - Thay vector DB schema
  - Deploy autonomous agent vào production

Accountability trong AI failures

AI systems fail theo cách đặc biệt: họ không crash, họ cho output tệ. Và output tệ đôi khi rất khó detect.

Culture phải normalize việc report quality issues, không phải hide chúng. Tôi có rule: nếu ai trong team thấy AI output tệ, họ có responsibility log nó vào eval dataset ngay lập tức. Không cần fix ngay, nhưng phải capture.

Kết Luận

Cấu trúc team lý tưởng theo quy mô:

Startup (< 20 người): 1-2 AI Engineer kiêm backend, không cần ML Engineer riêng trừ khi core product là custom model. Ưu tiên người có production experience hơn người có academic background.

Scaleup (20-200 người): Dedicated AI team 3-5 người: 1 tech lead AI (strong on system design), 2-3 AI Engineer, 1 part-time Data Scientist cho analytics. Bắt đầu build MLOps foundation.

Enterprise (> 200 người): Chia theo domain (AI Platform team riêng vs product AI team), có ML Engineer cho custom models, có dedicated MLOps. Budget riêng cho compute và data infrastructure.

Một điều cuối: đừng đợi đến khi "sẵn sàng" mới bắt đầu. AI landscape thay đổi quá nhanh, và learning-by-doing là cách duy nhất thực sự work. Bắt đầu nhỏ, measure kỹ, scale những gì có kết quả.