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
Mở đầu: Engineer xây cầu không "thử đi qua 1 lần rồi ship"
Họ:
- Tính toán tải trọng (structural analysis)
- Test với tải giả lập
- Audit an toàn
- Monitor sau khi khai trương
Prompt engineering đang ở giai đoạn "thử đi qua rồi ship". Dev viết prompt, test 2-3 case thấy OK, đẩy lên prod. User gặp case chưa test → app hỏng → incident.
Prompt evaluation là "structural analysis" cho prompt. Giai đoạn chín muồi của AI engineering không thể thiếu nó.
Prompt engineering vs Prompt evaluation
┌──────────────────────────────────────────────────┐
│ │
│ 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│
│ │
└──────────────────────────────────────────────────┘Hai cái bổ sung nhau, không thay thế:
- 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
Module 3 dạy kỹ thuật. Module 4 dạy đo lường. Kết hợp = production-grade AI.
3 con đường sau khi viết prompt
Bạn vừa draft prompt. Tiếp theo?
Option 1: Test 1 lần, ship
Dev: "Prompt chạy với câu hỏi demo → output OK → 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: "Test 5 case. Thấy fail 1 → tweak prompt. 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:
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 > threshold- 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.
Tại sao dev hay chọn Option 1-2?
Lý do tâm lý:
- "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.
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.
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:
- 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
Month 3: Dev phải:
- 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)
- 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.
Cấu trúc của eval pipeline
┌──────────────────────────────────────────────┐
│ │
│ Test Dataset │
│ ┌──────────┐ │
│ │ 30-100 │ │
│ │ cases │ │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Run Prompt │ (Claude với prompt v_n) │
│ └────┬─────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Grader │ (code / model / human) │
│ └────┬─────────┘ │
│ │ │
│ ▼ │
│ Score per case → Aggregate → Report │
│ │
└──────────────────────────────────────────────┘3 thành phần cốt lõi:
- 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
Xuyên suốt Module 4 bạn sẽ build từng thành phần.
Khi nào cần full eval?
Must have
- 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)
Nice to have
- Hobbyist project với ít user
- Internal tool dùng bởi team bạn
- Demo để trình sếp
Không cần
- Experiment trên giấy
- Prompt cho chính bạn dùng
- 1-shot query không lặp lại
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.
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:
Eval Assessment
- App tôi có bao nhiêu prompt distinct? ___
- Traffic dự kiến/ngày? ___
- Stakes nếu prompt fail? (low/medium/high) ___
- Dev team size? ___
→ Eval priority: [MUST / NICE / NOT NEEDED]
- Dataset sẽ lấy từ đâu? — [ ] User logs (sau launch) — [ ] Synthetic (Claude generate) — [ ] Manual curation
- Grader type? — [ ] Code (regex, JSON parse, length check) — [ ] Model (Claude chấm theo rubric) — [ ] Human (spot check)
### 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:
- 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ờ?
Document và share insight.
---Tóm tắt bài học
- 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.