- Margo van Laar, applied AI engineer tại Anthropic (London), trình bày các best practice về prompting qua hai kịch bản thực tế: bảo trì/migrate một prompt production sẵn có, và xây một agent mới từ đầu.
- Dùng một bot hỗ trợ khách hàng "Meridian Mobile" với eval năm test case, bà sửa từng failure mode một — áp dụng "general hygiene" (cấu trúc XML, output contract), gỡ các patch dư thừa, và cấp
toolcho model thay vì bảo nó "cố gắng hơn". - Với agent xếp lịch mới, bà so sánh các model (Sonnet 4.6, Opus 4.7, adaptive thinking) và một vòng lặp agentic
generate-evaluate-repair, cho thấy vòng lặp giải hết các case với ít token và độ trễ thấp hơn.
The prompting playbook
Evaluationlà điểm khởi đầu, cung cấp sự nghiêm ngặt để biết một thay đổi prompt có thực sự cải thiện hiệu năng không; không có eval thì không phân biệt được model mới "hành xử khác" hay "kém năng lực hơn".- Một eval suite tốt phủ ba loại case: control case (luôn pass), edge case (model từng fail), và case ranh giới năng lực (nên chuyển cho người hoặc từ chối).
- Áp dụng "general hygiene" trước: gỡ nội dung dư thừa (text copy từ website, tham chiếu hero image và cookie, bảo bot rằng nó là người), và thêm cấu trúc bằng thẻ XML tách
role,guidelines,policy,tone. Output contractcải thiện tính nhất quán định dạng; kết hợp chỉ dẫn trong prompt (thẻ XML) với thay đổi harness nhưstop sequence, và dùng structured output cho schema phức tạp.- Model có thể giấu thông tin nó vốn có quyền truy cập, chứ không chỉ ảo giác (hallucinate); một patch dư thừa cho model cũ gây over-fit, nên cho góc nhìn cân bằng và xem dữ liệu khách hàng là nguồn chân lý, dùng version control cho các thay đổi phòng thủ.
- "Chỉ dẫn không thêm năng lực" — bảo model "luôn tính đúng" không làm nó giỏi tính nhẩm hơn; cách sửa là cấp một
tool(tool tính proration có schema và phần triển khai). - Nêu cả hai mặt của một đánh đổi: chỉ dẫn một chiều ("tránh escalate, tốn $8") khiến model over-fit về phía không escalate; thêm chi phí khi làm sai (hoàn tiền, niềm tin khách hàng) sẽ sửa được case billing — càng quan trọng khi model giỏi tự cân nhắc đánh đổi hơn.
- Với agent mới, model và harness quan trọng ngang prompt: Opus 4.7 với adaptive thinking pass ổn định nhưng gấp ba token và độ trễ, còn vòng
generate-evaluate-repairgồm ba prompt đơn giản giải hết case với chi phí thấp hơn và cho phép thêm ràng buộc mềm lúc runtime.
evaluation(eval) — bộ test case đo lường nghiêm ngặt hiệu năng promptcontrol case— test case rõ ràng, luôn phải passedge case— test case nơi model từng failgeneral hygiene— dọn dẹp prompt nền tảng (gỡ dư thừa, thêm cấu trúc)output contract— định dạng đầu ra model phải tuân theostop sequence— cài đặt harness báo model dừng sinh khi gặp token nhất địnhover-fitting— model tuân theo patch cũ quá máy móc, hại hành vi hiện tạitool use— cấp tool (schema + triển khai) để model làm tác vụ đáng tinadaptive thinking— để model tự quyết lượng suy luận cần dùnggenerate-evaluate-repair loop— pattern agentic gồm prompt sinh, đánh giá và sửa
Hai kịch bản và vai trò của Evaluations
Margo van Laar mở đầu: prompting là một trong những kỹ năng đầu tiên và vẫn tối quan trọng để xây hệ thống AI hiệu quả. Bài nói tập trung hai kịch bản thường gặp: (1) bảo trì/migrate một prompt production phức tạp (nhiều người đóng góp, không chủ sở hữu rõ ràng, lẫn lộn policy/tone/patch cũ) khi chuyển sang model mới khiến nhiều test case hỏng; và (2) xây mới một use case agentic từ con số không.
Điểm khởi đầu là evaluations. Khi migrate model mà hệ thống kém đi, có hai khả năng: model mới có năng lực nhưng hành xử khác (sửa được bằng prompting), hoặc model kém năng lực hơn (prompting không cứu được). Eval suite giúp phân biệt và kiểm tra regression. Một eval tốt phủ ba loại: control case (luôn pass), edge case (model từng fail), và case ranh giới năng lực (nên chuyển cho người hoặc từ chối).
Kịch bản 1: Bot hỗ trợ Meridian Mobile
Ví dụ là bot hỗ trợ khách hàng của hãng viễn thông "Meridian Mobile" với năm test case (giới hạn dữ liệu gói cơ bản, tính proration, câu hỏi theo policy, escalate khi có lỗi billing, và không giấu thông tin). Quy trình: chạy eval V0, rồi nhắm từng failure mode một.
General hygiene trước tiên: gỡ nội dung dư thừa (bảo bot nó là người — sai; text copy từ website với tham chiếu hero image và cookie), và thêm cấu trúc XML tách role, guidelines, policy, tone. Chỉ việc dọn dẹp này đã cải thiện hiệu năng. Quy tắc ngón tay cái: nếu bạn đọc prompt mà không phân biệt được guideline với policy với data, thì model cũng vậy.
Output contract: thêm định dạng đầu ra (thẻ XML), kết hợp với thay đổi harness như stop sequence để model dừng khi gặp thẻ đóng; với schema phức tạp dùng structured outputs.
Sửa ba failure mode bằng các bài học cốt lõi
- Hotspot (model giấu thông tin): khách hàng ở gói legacy, dữ liệu khách hàng cho biết họ có 5 GB, nhưng patch cũ "đừng bao giờ đưa thông tin sai, hãy trỏ tới URL" khiến model over-fit và né trả lời. Bài học: model có thể giấu thông tin nó có, không chỉ ảo giác. Sửa bằng cách cho góc nhìn cân bằng, xem dữ liệu khách hàng là nguồn chân lý, và dùng version control để theo dõi lý do các thay đổi phòng thủ.
- Proration (tính toán): model làm "tính nhẩm" mơ hồ. Bài học: "chỉ dẫn không thêm năng lực" — bảo nó "luôn tính đúng" vô ích. Sửa bằng cách cấp một
tooltính proration (định nghĩa trong API, có schema mô tả khi nào dùng, và phần triển khai toán học). - Billing error (escalate): chỉ dẫn một chiều "tránh escalate vì tốn $8" khiến model over-fit về phía không escalate, mâu thuẫn với eval. Sửa bằng cách nêu cả hai mặt: tốn $8, nhưng làm sai sẽ mất tiền hoàn và niềm tin khách hàng. Càng quan trọng khi model ngày càng giỏi tự cân nhắc đánh đổi.
Kịch bản 2: Xây agent xếp lịch mới và vòng lặp agentic
Agent mới lập lịch nhân viên bán lẻ một tuần cho tám nhân viên với các ràng buộc cứng. Vì là luật cứng, dùng hàm Python chấm số vi phạm thay vì LLM judge. Khi xây mới, phải cân nhắc cả prompt, model và harness:
- Sonnet 4.6 + prompt đơn giản: tất cả fail, đốt nhiều token, không kiểm tra lại kết quả.
- Opus 4.7: vẫn fail nhưng số vi phạm giảm rõ rệt — thêm năng lực suy luận có ích.
- Opus 4.7 + adaptive thinking: tạo lịch hợp lệ ổn định, nhưng gấp ba token và độ trễ (~100 giây).
- Sonnet 4.6 + prompt tốt hơn (bảo nó kiểm tra lại trước khi xuất): pass 2/5, fail vì chạm giới hạn output, tăng token còn không giải được.
- Vòng generate-evaluate-repair: ba prompt độc lập — generator tạo bản nháp, evaluator (dùng LLM) báo từng vi phạm kèm bằng chứng, repair sửa có mục tiêu. Cách này giải hết case với token và độ trễ thấp hơn.
Hai hướng phù hợp: Opus 4.7 với adaptive thinking, hoặc vòng lặp agentic. Lợi ích then chốt của vòng lặp: có thể thêm ràng buộc mềm lúc runtime (ví dụ "Harry không thích làm với Sally, hãy tách ra"; "cần ca thứ ba vào thứ Tư") ngay trong prompt đánh giá mà không phải sửa hàm Python ở backend.
Tổng kết
Hai kịch bản — bảo trì/migrate prompt và xây mới — cho thấy: general hygiene cải thiện ngay hiệu năng so với eval; cần eval để đo tác động thay đổi prompt một cách nghiêm ngặt; nhắm từng failure mode một, thêm cấu trúc, tránh "ban list" dài; và tách một prompt lớn thành nhiều prompt độc lập khi có thể tách các bước lặp lại được.
TL;DR
- Margo van Laar, applied AI engineer tại Anthropic (London), trình bày các best practice về prompting qua hai kịch bản thực tế: bảo trì/migrate một prompt production sẵn có, và xây một agent mới từ đầu.
- Dùng một bot hỗ trợ khách hàng "Meridian Mobile" với eval năm test case, bà sửa từng failure mode một — áp dụng "general hygiene" (cấu trúc XML, output contract), gỡ các patch dư thừa, và cấp
toolcho model thay vì bảo nó "cố gắng hơn". - Với agent xếp lịch mới, bà so sánh các model (Sonnet 4.6, Opus 4.7, adaptive thinking) và một vòng lặp agentic
generate-evaluate-repair, cho thấy vòng lặp giải hết các case với ít token và độ trễ thấp hơn.
Điểm chính
Evaluationlà điểm khởi đầu, cung cấp sự nghiêm ngặt để biết một thay đổi prompt có thực sự cải thiện hiệu năng không; không có eval thì không phân biệt được model mới "hành xử khác" hay "kém năng lực hơn".- Một eval suite tốt phủ ba loại case: control case (luôn pass), edge case (model từng fail), và case ranh giới năng lực (nên chuyển cho người hoặc từ chối).
- Áp dụng "general hygiene" trước: gỡ nội dung dư thừa (text copy từ website, tham chiếu hero image và cookie, bảo bot rằng nó là người), và thêm cấu trúc bằng thẻ XML tách
role,guidelines,policy,tone. Output contractcải thiện tính nhất quán định dạng; kết hợp chỉ dẫn trong prompt (thẻ XML) với thay đổi harness nhưstop sequence, và dùng structured output cho schema phức tạp.- Model có thể giấu thông tin nó vốn có quyền truy cập, chứ không chỉ ảo giác (hallucinate); một patch dư thừa cho model cũ gây over-fit, nên cho góc nhìn cân bằng và xem dữ liệu khách hàng là nguồn chân lý, dùng version control cho các thay đổi phòng thủ.
- "Chỉ dẫn không thêm năng lực" — bảo model "luôn tính đúng" không làm nó giỏi tính nhẩm hơn; cách sửa là cấp một
tool(tool tính proration có schema và phần triển khai). - Nêu cả hai mặt của một đánh đổi: chỉ dẫn một chiều ("tránh escalate, tốn $8") khiến model over-fit về phía không escalate; thêm chi phí khi làm sai (hoàn tiền, niềm tin khách hàng) sẽ sửa được case billing — càng quan trọng khi model giỏi tự cân nhắc đánh đổi hơn.
- Với agent mới, model và harness quan trọng ngang prompt: Opus 4.7 với adaptive thinking pass ổn định nhưng gấp ba token và độ trễ, còn vòng
generate-evaluate-repairgồm ba prompt đơn giản giải hết case với chi phí thấp hơn và cho phép thêm ràng buộc mềm lúc runtime.
Từ vựng
evaluation(eval) — bộ test case đo lường nghiêm ngặt hiệu năng promptcontrol case— test case rõ ràng, luôn phải passedge case— test case nơi model từng failgeneral hygiene— dọn dẹp prompt nền tảng (gỡ dư thừa, thêm cấu trúc)output contract— định dạng đầu ra model phải tuân theostop sequence— cài đặt harness báo model dừng sinh khi gặp token nhất địnhover-fitting— model tuân theo patch cũ quá máy móc, hại hành vi hiện tạitool use— cấp tool (schema + triển khai) để model làm tác vụ đáng tinadaptive thinking— để model tự quyết lượng suy luận cần dùnggenerate-evaluate-repair loop— pattern agentic gồm prompt sinh, đánh giá và sửa
Nội dung chi tiết
Hai kịch bản và vai trò của Evaluations
Margo van Laar mở đầu: prompting là một trong những kỹ năng đầu tiên và vẫn tối quan trọng để xây hệ thống AI hiệu quả. Bài nói tập trung hai kịch bản thường gặp: (1) bảo trì/migrate một prompt production phức tạp (nhiều người đóng góp, không chủ sở hữu rõ ràng, lẫn lộn policy/tone/patch cũ) khi chuyển sang model mới khiến nhiều test case hỏng; và (2) xây mới một use case agentic từ con số không.
Điểm khởi đầu là evaluations. Khi migrate model mà hệ thống kém đi, có hai khả năng: model mới có năng lực nhưng hành xử khác (sửa được bằng prompting), hoặc model kém năng lực hơn (prompting không cứu được). Eval suite giúp phân biệt và kiểm tra regression. Một eval tốt phủ ba loại: control case (luôn pass), edge case (model từng fail), và case ranh giới năng lực (nên chuyển cho người hoặc từ chối).
Kịch bản 1: Bot hỗ trợ Meridian Mobile
Ví dụ là bot hỗ trợ khách hàng của hãng viễn thông "Meridian Mobile" với năm test case (giới hạn dữ liệu gói cơ bản, tính proration, câu hỏi theo policy, escalate khi có lỗi billing, và không giấu thông tin). Quy trình: chạy eval V0, rồi nhắm từng failure mode một.
General hygiene trước tiên: gỡ nội dung dư thừa (bảo bot nó là người — sai; text copy từ website với tham chiếu hero image và cookie), và thêm cấu trúc XML tách role, guidelines, policy, tone. Chỉ việc dọn dẹp này đã cải thiện hiệu năng. Quy tắc ngón tay cái: nếu bạn đọc prompt mà không phân biệt được guideline với policy với data, thì model cũng vậy.
Output contract: thêm định dạng đầu ra (thẻ XML), kết hợp với thay đổi harness như stop sequence để model dừng khi gặp thẻ đóng; với schema phức tạp dùng structured outputs.
Sửa ba failure mode bằng các bài học cốt lõi
- Hotspot (model giấu thông tin): khách hàng ở gói legacy, dữ liệu khách hàng cho biết họ có 5 GB, nhưng patch cũ "đừng bao giờ đưa thông tin sai, hãy trỏ tới URL" khiến model over-fit và né trả lời. Bài học: model có thể giấu thông tin nó có, không chỉ ảo giác. Sửa bằng cách cho góc nhìn cân bằng, xem dữ liệu khách hàng là nguồn chân lý, và dùng version control để theo dõi lý do các thay đổi phòng thủ.
- Proration (tính toán): model làm "tính nhẩm" mơ hồ. Bài học: "chỉ dẫn không thêm năng lực" — bảo nó "luôn tính đúng" vô ích. Sửa bằng cách cấp một
tooltính proration (định nghĩa trong API, có schema mô tả khi nào dùng, và phần triển khai toán học). - Billing error (escalate): chỉ dẫn một chiều "tránh escalate vì tốn $8" khiến model over-fit về phía không escalate, mâu thuẫn với eval. Sửa bằng cách nêu cả hai mặt: tốn $8, nhưng làm sai sẽ mất tiền hoàn và niềm tin khách hàng. Càng quan trọng khi model ngày càng giỏi tự cân nhắc đánh đổi.
Kịch bản 2: Xây agent xếp lịch mới và vòng lặp agentic
Agent mới lập lịch nhân viên bán lẻ một tuần cho tám nhân viên với các ràng buộc cứng. Vì là luật cứng, dùng hàm Python chấm số vi phạm thay vì LLM judge. Khi xây mới, phải cân nhắc cả prompt, model và harness:
- Sonnet 4.6 + prompt đơn giản: tất cả fail, đốt nhiều token, không kiểm tra lại kết quả.
- Opus 4.7: vẫn fail nhưng số vi phạm giảm rõ rệt — thêm năng lực suy luận có ích.
- Opus 4.7 + adaptive thinking: tạo lịch hợp lệ ổn định, nhưng gấp ba token và độ trễ (~100 giây).
- Sonnet 4.6 + prompt tốt hơn (bảo nó kiểm tra lại trước khi xuất): pass 2/5, fail vì chạm giới hạn output, tăng token còn không giải được.
- Vòng generate-evaluate-repair: ba prompt độc lập — generator tạo bản nháp, evaluator (dùng LLM) báo từng vi phạm kèm bằng chứng, repair sửa có mục tiêu. Cách này giải hết case với token và độ trễ thấp hơn.
Hai hướng phù hợp: Opus 4.7 với adaptive thinking, hoặc vòng lặp agentic. Lợi ích then chốt của vòng lặp: có thể thêm ràng buộc mềm lúc runtime (ví dụ "Harry không thích làm với Sally, hãy tách ra"; "cần ca thứ ba vào thứ Tư") ngay trong prompt đánh giá mà không phải sửa hàm Python ở backend.
Tổng kết
Hai kịch bản — bảo trì/migrate prompt và xây mới — cho thấy: general hygiene cải thiện ngay hiệu năng so với eval; cần eval để đo tác động thay đổi prompt một cách nghiêm ngặt; nhắm từng failure mode một, thêm cấu trúc, tránh "ban list" dài; và tách một prompt lớn thành nhiều prompt độc lập khi có thể tách các bước lặp lại được.