Engineer xây cầu không nói: "Cầu trông có vẻ chắc, tôi đi qua 1 lần không sập, deploy cho dân dùng!"
- Phân biệt prompt engineering (cách viết) và prompt evaluation (cách đo)
- Hiểu 3 con đường sau khi viết prompt — và vì sao chỉ 1 trong 3 là production-safe
- Nhận diện bẫy "testing 2 cases rồi ship" mà hầu hết dev mắc phải
- Quyết định đúng: app của bạn có cần full eval pipeline không
Prompt engineering vs Prompt evaluation
Hai cái bổ sung nhau, không thay thế:
Module 3 dạy kỹ thuật. Module 4 dạy đo lường. Kết hợp = production-grade AI.
- Engineering không có evaluation = writing blind (không biết có tốt không)
- Evaluation không có engineering = đo nhưng không biết cải thiện sao
┌──────────────────────────────────────────────────┐ │ │ │ PROMPT ENGINEERING PROMPT EVALUATION │ │ (Module 3) (Module 4 - này) │ │ │ │ = Cách viết prompt tốt = Cách đo chất lượng│ │ │ │ Techniques: Techniques: │ │ - Clear & direct - Test dataset │ │ - Specific - Graders │ │ - Examples - Metrics │ │ - XML tags - Scoring │ │ │ │ Output: Output: │ │ Prompt v1, v2, v3 Score 3.2, 5.8, 8.9│ │ │ └──────────────────────────────────────────────────┘
3 con đường sau khi viết prompt
Bạn vừa draft prompt. Tiếp theo?
Option 1: Test 1 lần, ship
Risk: User sẽ hỏi case chưa test — prompt có thể fail catastrophically.
Khi nào OK: Hackathon, demo internal, prototype throwaway. Chắc chắn không phải production.
Option 2: Test vài lần, fix corner case, ship
Dev: "Prompt chạy với câu hỏi demo → output OK → ship"Option 2: Test vài lần, fix corner case, ship
Risk: 5 case không cover real user distribution. User sẽ dùng theo cách bạn không tưởng tượng được.
Khi nào OK: Prototype với < 10 user, có monitoring tốt, chấp nhận bug.
Option 3: Eval pipeline có hệ thống
Dev: "Test 5 case. Thấy fail 1 → tweak prompt. Ship."Option 3: Eval pipeline có hệ thống
Risk: Upfront cost (1-2 ngày build pipeline).
Benefit: Ship với confidence. Update prompt không sợ regression.
Khi nào MUST use: App production, app có ≥ 100 user, app có stake cao.
Dev:
1. Tạo test dataset 30-100 cases (có edge)
2. Build grader (code + model)
3. Run pipeline → baseline score
4. Iterate prompt → re-run
5. Ship khi score > thresholdTại sao dev hay chọn Option 1-2?
Lý do tâm lý:
Hậu quả: Bug ở production. Bạn debug. Hóa ra prompt fail trên edge case bạn chưa thấy. Giờ phải viết eval pipeline trong áp lực, tệ hơn nhiều so với làm từ đầu.
- "Tôi đã test rồi thấy work" — confirmation bias. Bạn nhớ lúc work, quên lúc không.
- "Eval pipeline tốn thời gian" — đúng, 1-2 ngày upfront. Nhưng 1 production incident = 1 tuần debug + trust mất.
- "User chắc không hỏi kỳ lạ" — wrong. User LUÔN tìm cách break system.
- "Prompt là text, không phải code" — sai mindset. Prompt LÀ code. Code production phải có test.
Ví dụ thực tế: Cost của không eval
Scenario
Customer support chatbot, ship prompt v1 sau test 5 case.
Month 1: 10 user support request. Claude trả lời ổn.
Month 2: 500 user. Bắt đầu có complaint:
Month 3: Dev phải:
Tổng cost: 2 tuần dev + trust damage.
Nếu build eval từ đầu: 2 ngày extra initially, zero incident.
ROI eval: 5x ở tình huống này.
- 5% case: Claude từ chối trả lời câu hợp lệ
- 2% case: Claude leak thông tin tenant khác
- 3% case: Claude trả lời sai policy, escalation lên legal
- Build eval pipeline crash mode (3 ngày)
- Audit toàn bộ chat log (2 ngày)
- Rewrite prompt v2 (1 ngày)
- Communication với customer bị impacted (1 tuần)
- Legal review (1 tuần)
Cấu trúc của eval pipeline
3 thành phần cốt lõi:
Xuyên suốt Module 4 bạn sẽ build từng thành phần.
- Test Dataset (Bài 6.24) — list input cases
- Runner (Bài 6.25) — chạy prompt trên mỗi case
- Grader (Bài 6.26-6.27) — chấm điểm output
┌──────────────────────────────────────────────┐ │ │ │ Test Dataset │ │ ┌──────────┐ │ │ │ 30-100 │ │ │ │ cases │ │ │ └────┬─────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ Run Prompt │ (Claude với prompt v_n) │ │ └────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ Grader │ (code / model / human) │ │ └────┬─────────┘ │ │ │ │ │ ▼ │ │ Score per case → Aggregate → Report │ │ │ └──────────────────────────────────────────────┘
Khi nào cần full eval?
✅ Must have
⚠️ Nice to have
❌ Không cần
Quy tắc: Nếu prompt sẽ chạy > 100 lần, hoặc với > 10 user, hoặc bạn không phải người duy nhất review output — có eval.
- Production app với ≥ 100 active user
- App B2B, stake cao (legal, finance, healthcare)
- Prompt nằm trong critical path (blocking flow)
- Team > 2 dev (regression risk cao)
- Hobbyist project với ít user
- Internal tool dùng bởi team bạn
- Demo để trình sếp
- Experiment trên giấy
- Prompt cho chính bạn dùng
- 1-shot query không lặp lại
Các khái niệm cần nhớ
| Term | Định nghĩa |
|---|---|
| Eval (noun) | Short cho "evaluation" — bộ dataset + grader + pipeline |
| Test case | 1 input trong dataset |
| Run | 1 lần chạy full eval từ đầu đến cuối |
| Score | Điểm 1 case, thường 1-10 |
| Average / Aggregate | Điểm trung bình cả dataset |
| Baseline | Score của v1 (chưa engineering) |
| Regression | Case trước pass giờ fail |
| Grader | Function chấm điểm — code, model, hoặc human |
| Rubric | Checklist criteria grader dựa vào |
Anti-patterns
❌ "Eval once, ship forever"
Chạy eval 1 lần, score OK, ship. 3 tháng sau không biết prompt còn hoạt động đúng không.
Fix: Chạy eval mỗi khi update prompt. Weekly/monthly chạy eval trên prod logs.
❌ Dataset quá nhỏ
3 test case → không đại diện user distribution.
Fix: Ít nhất 30 case. 100+ cho production-critical.
❌ Dataset chỉ có happy path
Toàn case dễ → score cao giả tạo.
Fix: 20-30% dataset là edge case (empty input, noise, adversarial).
❌ Dùng model grader cho tác vụ deterministic
"Check JSON valid" dùng model grader → lãng phí + ít reliable.
Fix: Code grader cho check-able programmatically. Model grader cho subjective.
❌ Không track score qua time
Score v1, v2, v3 lưu đâu? Nếu không ai biết → regression bypass.
Fix: scores.csv với columns: version, date, dataset_size, avg_score. Commit git.
Áp dụng ngay
Bài tập 1: Assessment cho app của bạn (10 phút)
Trong my-goals.md:
Bài tập 2: Analyze existing system (10 phút)
Nếu bạn làm trong 1 team có app AI, tìm hiểu:
Document và share insight.
- Có eval không?
- Nếu có: chạy bao lâu 1 lần?
- Nếu không: lần incident gần nhất liên quan prompt là bao giờ?
## Eval Assessment
1. App tôi có bao nhiêu prompt distinct? ___
2. Traffic dự kiến/ngày? ___
3. Stakes nếu prompt fail? (low/medium/high) ___
4. Dev team size? ___
→ Eval priority: [MUST / NICE / NOT NEEDED]
5. Dataset sẽ lấy từ đâu?
- [ ] User logs (sau launch)
- [ ] Synthetic (Claude generate)
- [ ] Manual curation
6. Grader type?
- [ ] Code (regex, JSON parse, length check)
- [ ] Model (Claude chấm theo rubric)
- [ ] Human (spot check)Tóm tắt
🎯 Eval = structural analysis cho prompt. Không có eval = ship blind.
🎯 Option 3 (full eval) là cách duy nhất production-safe. Option 1-2 OK cho prototype.
🎯 Upfront cost 1-2 ngày, ROI 5-10x nếu tránh được 1 production incident.
🎯 3 thành phần: Dataset + Runner + Grader. Module 4 build từng cái.
🎯 Always eval khi prompt chạy > 100 lần / > 10 user.