Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm rất phổ biến mà tôi gặp ở hầu hết học viên: họ tin rằng viết prompt là một hành động "một lần là xong". Ngồi xuống, gõ vài dòng, thấy AI trả về kết quả trông ổn ổn, thế là chốt và mang đi dùng. Rồi ba tuần sau, khi kết quả bắt đầu sai lệch, họ lại ngồi sửa theo cảm tính, thêm một câu ở đây, bỏ một từ ở kia, và cầu nguyện.
Đây chính là lý do phần lớn các dự án ứng dụng AI trong doanh nghiệp Việt Nam dừng lại ở mức "demo trông hay ho" nhưng không bao giờ đạt được độ ổn định để đưa vào vận hành thật. Vấn đề không nằm ở mô hình. Vấn đề nằm ở phương pháp lặp — cách bạn cải tiến một prompt từ phiên bản 0.1 lên phiên bản đủ tốt để giao cho khách hàng thật.
Bài học này không dạy bạn thêm một kỹ thuật viết prompt mới. Nó dạy bạn một quy trình: cách coi prompt như một sản phẩm cần được thử nghiệm, đo lường và cải tiến có kỷ luật. Khi bạn nắm được methodology này, bạn sẽ ngừng "đoán" và bắt đầu "biết" — biết chắc phiên bản nào tốt hơn, tốt hơn bao nhiêu, và vì sao. Đây là ranh giới giữa một người nghịch AI cho vui và một người làm prompt engineering nghiêm túc để kiếm tiền.
Khái niệm cốt lõi
Prompt là sản phẩm, không phải là một câu nói
Tư duy nền tảng của toàn bộ bài này gói gọn trong một câu: hãy đối xử với prompt như đối xử với code. Code thì được version (đánh số phiên bản), được test (kiểm thử), được deploy (triển khai), rồi được theo dõi và cải tiến. Prompt cũng vậy.
Khi bạn coi prompt là "một câu nói", bạn sửa nó tùy hứng và không có cách nào biết mình đang tiến bộ hay thụt lùi. Khi bạn coi nó là "một sản phẩm", bạn buộc phải trả lời ba câu hỏi kỷ luật: Phiên bản hiện tại tốt đến mức nào? Thay đổi tôi vừa làm khiến nó tốt lên hay xấu đi? Và tôi có bằng chứng gì để khẳng định điều đó?
Vòng lặp cải tiến bốn bước
Toàn bộ methodology xoay quanh một vòng lặp lặp đi lặp lại:
- Giả thuyết (Hypothesis) — Bạn dự đoán một thay đổi cụ thể sẽ cải thiện kết quả. Ví dụ: "Nếu tôi thêm 2 ví dụ few-shot vào prompt phân loại email, tỷ lệ phân loại đúng sẽ tăng."
- Thử nghiệm (Experiment) — Bạn tạo phiên bản mới, chỉ thay đổi đúng một thứ, và chạy nó trên một bộ dữ liệu kiểm thử cố định.
- Đo lường (Measure) — Bạn so sánh kết quả mới với phiên bản cũ bằng con số, không bằng cảm giác.
- Quyết định (Ship or discard) — Nếu tốt hơn, giữ lại và biến nó thành phiên bản chuẩn. Nếu không, vứt đi và thử giả thuyết khác.
Bộ dữ liệu kiểm thử (eval set) — trái tim của việc lặp
Bạn không thể cải tiến cái mà bạn không đo được. Muốn đo được, bạn cần một eval set: một tập hợp cố định gồm các đầu vào mẫu kèm đầu ra mong đợi (hoặc tiêu chí đánh giá). Không cần nhiều — 20 đến 50 ví dụ được chọn kỹ thường đã đủ để phát hiện phiên bản nào tốt hơn.
Eval set nên bao gồm ba loại: các trường hợp phổ biến (happy path), các trường hợp khó/biên (edge cases), và các trường hợp đã từng sai trong quá khứ (regression cases). Chính bộ regression này giúp bạn tránh cái bẫy kinh điển: sửa được lỗi A nhưng vô tình làm hỏng thứ B mà trước đó vốn đang chạy tốt.
Đừng tin vào cảm giác (don't trust your gut)
Bộ não con người cực kỳ giỏi tự lừa dối. Khi bạn vừa bỏ 30 phút chỉnh một prompt, bạn sẽ vô thức muốn tin rằng nó tốt hơn — đây là thiên kiến xác nhận (confirmation bias). Bạn đọc một output mới, thấy nó "nghe có vẻ mượt hơn", và kết luận thay đổi thành công. Nhưng "nghe mượt hơn" trên một ví dụ không nói lên điều gì về 200 ví dụ thật ngoài đời.
Đó là lý do đo lường bằng số quan trọng đến vậy. Con số không có cảm xúc và không thiên vị công sức bạn đã bỏ ra.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán phân loại đánh giá sản phẩm
Giả định một đội vận hành tại một sàn thương mại điện tử lớn như Tiki cần tự động phân loại hàng chục nghìn review sản phẩm mỗi ngày thành ba nhóm: khiếu nại về chất lượng, khiếu nại về giao hàng, và phản hồi tích cực. Prompt phiên bản đầu (v1) đạt độ chính xác 71% khi đo trên eval set gồm 50 review đã được nhân viên gắn nhãn tay.
Thay vì viết lại toàn bộ prompt cho "hoành tráng hơn", đội trưởng áp dụng vòng lặp một-biến-một-lần. Giả thuyết đầu tiên: nhiều review bị phân loại sai vì lẫn lộn giữa "giao hàng chậm" và "chất lượng kém". Họ thêm đúng 3 ví dụ few-shot minh họa ranh giới này — đó là thay đổi duy nhất. v2 lên 82%. Giả thuyết thứ hai: yêu cầu AI xuất ra lý do phân loại trước khi đưa kết luận (một dạng cho AI suy nghĩ). v3 lên 89%. Giả thuyết thứ ba, đổi giọng văn hệ thống, không cải thiện gì — họ vứt đi.
Bài học: ba vòng lặp nhỏ, mỗi vòng đo bằng cùng một eval set 50 mẫu, đã nâng độ chính xác từ 71% lên 89% một cách có bằng chứng. Nếu họ gộp cả ba thay đổi vào một lần, họ sẽ không bao giờ biết rằng cái làm nên khác biệt là few-shot và reasoning, còn đổi giọng văn chỉ là công sức lãng phí.
Ví dụ 2 — Một fintech ở TP.HCM và cái bẫy regression
Một công ty fintech giả định tại TP.HCM dùng AI để tóm tắt hồ sơ vay của khách hàng cho nhân viên thẩm định. Prompt của họ chạy tốt suốt hai tháng. Rồi một hôm, một bạn junior chỉnh prompt để xử lý tốt hơn các hồ sơ có nhiều nguồn thu nhập. Trên vài hồ sơ phức tạp, kết quả trông tuyệt vời, nên bạn ấy triển khai ngay.
Ba ngày sau, bộ phận thẩm định phàn nàn: các hồ sơ đơn giản — vốn chiếm 80% khối lượng — giờ bị tóm tắt lê thê, thừa thông tin, chậm hơn hẳn. Thay đổi "cải thiện" trường hợp khó đã phá hỏng trường hợp phổ biến. Vì không có eval set nào bao gồm cả hồ sơ đơn giản lẫn phức tạp, lỗi này lọt lưới hoàn toàn.
Sau sự cố, đội xây một eval set 40 hồ sơ trộn cả đơn giản và phức tạp, thêm vào đó các case từng gây lỗi. Từ đó, mọi thay đổi prompt đều phải chạy qua bộ này trước khi triển khai.
Bài học: một prompt "tốt hơn" cho một tình huống có thể "tệ hơn" cho tình huống khác. Nếu không có bộ regression đại diện cho toàn bộ khối lượng thật, bạn đang triển khai trong mù mờ. Việc lặp không chỉ là tiến lên — mà còn là đảm bảo không thụt lùi ở nơi khác.
Ví dụ 3 — Đội marketing dùng A/B để chọn prompt viết tiêu đề
Một startup SaaS giả định cần AI viết tiêu đề email cho các chiến dịch. Ở đây "đúng" không tồn tại — không có đáp án chuẩn cho một tiêu đề hay. Vậy đo bằng gì? Đội này dùng chính chỉ số kinh doanh: tỷ lệ mở email (open rate).
Họ chuẩn bị hai phiên bản prompt. Prompt A yêu cầu tiêu đề "ngắn gọn, tạo tò mò". Prompt B yêu cầu "nêu rõ lợi ích cụ thể kèm con số". Mỗi phiên bản sinh tiêu đề cho một nửa danh sách 10.000 người nhận, chia ngẫu nhiên. Kết quả sau ba ngày: prompt A đạt open rate 18,2%, prompt B đạt 24,7%. Con số này áp đảo mọi tranh luận cảm tính trong phòng họp về việc "kiểu nào nghe hay hơn".
Bài học: khi không có đáp án đúng/sai tuyệt đối, hãy để chỉ số kinh doanh thật làm trọng tài. Đây là dạng lặp cao cấp nhất — thử nghiệm trực tiếp trên người dùng thật (online experiment), thay vì chỉ trên eval set trong phòng thí nghiệm (offline).
Hướng dẫn từng bước
Bước 1 — Xây eval set trước khi chỉnh sửa bất cứ thứ gì. Thu thập 20–50 đầu vào thật, đại diện cho ba nhóm: phổ biến, khó, và từng gây lỗi. Với mỗi đầu vào, ghi rõ đầu ra mong đợi hoặc tiêu chí "thế nào là đạt". Đây là khoản đầu tư đắt nhất và đáng giá nhất.
Bước 2 — Đo baseline. Chạy prompt hiện tại qua toàn bộ eval set và ghi lại điểm số gốc. Bạn không thể biết mình có tiến bộ hay không nếu không có điểm khởi đầu.
Bước 3 — Viết ra một giả thuyết cụ thể. Không phải "làm cho nó tốt hơn" mà là "thêm ví dụ few-shot cho trường hợp X sẽ giảm lỗi loại Y". Giả thuyết càng cụ thể, thí nghiệm càng rõ ràng.
Bước 4 — Thay đổi đúng một biến. Tạo phiên bản mới, đặt tên rõ ràng (v2, v3...), và chỉ động vào một thứ.
Bước 5 — Chạy lại eval set và so sánh bằng số. Đối chiếu điểm mới với baseline. Nhìn cả điểm tổng lẫn từng nhóm case để phát hiện regression.
Bước 6 — Quyết định: giữ hay bỏ. Tốt hơn có ý nghĩa thì biến nó thành baseline mới. Không thì ghi lại "giả thuyết này thất bại" và quay lại bước 3. Ghi lại cả thất bại cũng quan trọng như ghi lại thành công.
Bước 7 — Với các thay đổi hệ trọng, kiểm chứng trên người dùng thật. Sau khi qua vòng offline, dùng A/B test trên một phần lưu lượng thật trước khi triển khai toàn bộ.
Lỗi thường gặp & mẹo
Lỗi 1 — Thay đổi nhiều thứ cùng lúc. Đây là lỗi phổ biến nhất và tai hại nhất. Bạn sẽ mất khả năng quy kết nguyên nhân. Kỷ luật: một vòng lặp, một biến.
Lỗi 2 — Không có eval set, chỉ thử vài ví dụ ngẫu nhiên. Bạn sẽ tối ưu cho vài ví dụ trong đầu mình mà bỏ quên phần lớn tình huống thật. Mẹo: bắt đầu nhỏ, 20 ví dụ vẫn tốt hơn con số 0 rất nhiều.
Lỗi 3 — Tin vào cảm giác "nghe hay hơn". Một output đẹp không đại diện cho toàn bộ. Luôn quy về con số.
Lỗi 4 — Sửa lỗi mới, phá lỗi cũ (regression). Luôn giữ các case đã từng lỗi trong eval set và chạy lại chúng ở mỗi vòng.
Lỗi 5 — Lặp mãi không dừng. Đừng đuổi theo sự hoàn hảo. Đặt ngưỡng "đủ tốt" ngay từ đầu (ví dụ: 90% chính xác) và dừng khi đạt. Chi phí cải tiến thêm thường tăng vọt trong khi lợi ích giảm dần.
Mẹo — Ghi nhật ký thí nghiệm. Một bảng đơn giản: phiên bản, thay đổi gì, điểm số, kết luận giữ/bỏ. Sau vài tuần, cuốn nhật ký này trở thành tài sản trí tuệ quý giá của đội.
Mẹo — Tách "tác giả prompt" và "người chấm điểm". Người viết luôn thiên vị tác phẩm của mình. Nếu có thể, để người khác hoặc một AI khác chấm điểm eval set một cách khách quan.
Bài tập thực hành
- Chọn một prompt bạn đang dùng (hoặc tự viết một prompt phân loại tin nhắn khách hàng thành "cần hỗ trợ gấp" / "hỏi thông tin" / "phản hồi tích cực"). Xây một eval set gồm 15 tin nhắn thật, gắn nhãn đúng cho từng cái.
- Đo baseline: chạy prompt qua 15 tin nhắn, đếm số phân loại đúng, ghi lại tỷ lệ.
- Viết ra ba giả thuyết cải tiến khác nhau (ví dụ: thêm few-shot, thêm bước reasoning, làm rõ định nghĩa từng nhãn). Với mỗi giả thuyết, tạo một phiên bản chỉ thay đổi đúng thứ đó.
- Chạy từng phiên bản qua cùng eval set, lập bảng so sánh điểm số. Xác định phiên bản thắng và giải thích bằng con số vì sao nó thắng.
- Cố tình thêm 3 tin nhắn "khó" vào eval set, chạy lại phiên bản thắng, và kiểm tra xem nó có bị regression ở các case cũ không.
Tóm tắt
Cải tiến prompt không phải là năng khiếu, mà là một quy trình có kỷ luật. Hãy coi prompt như một sản phẩm: version nó, test nó, deploy nó. Trái tim của quy trình là eval set — một bộ dữ liệu kiểm thử cố định giúp bạn biến cảm giác mơ hồ thành con số rõ ràng. Vòng lặp gồm bốn bước: đưa giả thuyết, thí nghiệm với đúng một biến thay đổi, đo bằng số, rồi quyết định giữ hay bỏ.
Ba nguyên tắc bạn cần khắc cốt ghi tâm: thí nghiệm nhỏ và mỗi lần một biến; đo lường trước khi kết luận; và tuyệt đối đừng tin vào cảm giác — con số mới là trọng tài. Khi cần độ chắc chắn cao nhất, hãy đưa thay đổi ra kiểm chứng trên người dùng thật qua A/B test. Nắm vững methodology này, bạn không còn "đoán" nữa — bạn "biết", và đó chính là điều tách một người chơi AI nghiệp dư khỏi một prompt engineer chuyên nghiệp.