Framework Prompt Engineering 80/20 #10

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Đừng dán dữ liệu riêng tư, thông tin khách hàng hoặc quyết định quan trọng vào chatbot công khai.

Trả lời ngắn: Framework Prompt Engineering 80/20 là khung năm ô giúp bạn ưu tiên phần làm AI bớt phải đoán: một nhiệm vụ, context cần thiết, output mong muốn, tiêu chí chấm và điểm dừng để kiểm. Nó không bảo đảm câu trả lời đúng; nó giúp bạn viết, thử và sửa prompt có trật tự.

Đọc xong, bạn sẽ hiểu:

• Năm ô nào thường tạo phần lớn độ rõ của một prompt.
• Khi nào cần thêm role, constraint hoặc ví dụ thay vì viết prompt dài hơn.
• Cách test hai prompt bằng cùng một case giả và biết lúc phải dừng để kiểm nguồn.

1. Framework Prompt Engineering 80/20: lấy phần ít mà rõ trước

a. 80/20 ở đây không phải lời hứa

Trong bài này, “80/20” chỉ là tên dễ nhớ cho checklist năm ô thường đáng kiểm trước; nó không phải framework chuẩn hay tỷ lệ chất lượng đã được bảo đảm.

Framework là khung các ô hoặc bước có thể dùng lại. Cụm “80/20” trong bài này chỉ là cách nhớ: đừng bắt đầu bằng mười mẹo lẻ; hãy làm rõ vài phần hay khiến model đoán sai nhất trước.

Nó không có nghĩa năm ô sẽ làm mọi câu trả lời tốt lên đúng 80%. Mỗi model, dữ liệu và việc làm khác nhau. Có việc chỉ cần một câu ngắn; có việc cần tài liệu nguồn, công cụ chuyên môn hoặc người chịu trách nhiệm kiểm lại.

Ví dụ, “Viết giúp tôi email” có thể đủ nếu cả hai bên đã biết email nào. Nhưng “xử lý phản hồi khách hàng này” để trống quá nhiều: xử lý là tóm tắt, xin lỗi, phân loại hay chuyển cấp? Khi phần quan trọng trống, model tự lấp bằng cách dự đoán.

b. Một khung nhỏ tốt hơn một prompt phình to

Nhiều người thấy output lệch liền thêm vai trò, giọng điệu, mười tính từ và vài dấu chấm than. Phần thêm chỉ có ích nếu nó làm rõ việc cần làm hoặc cách kiểm kết quả. Prompt dài mà vẫn mơ hồ giống phiếu giao hàng viết kín trang nhưng thiếu địa chỉ.

Bài Những lỗi Prompt phổ biến đã chỉ ra các chỗ hay hỏng. Bài này gom chúng thành một khung để bạn đi từ trái sang phải, rồi quay lại test. Nếu output sai, đừng sửa cả năm ô một lúc; Prompt Debugging sẽ giúp bạn giữ case lỗi và đổi từng phần.

Hình 1 — Prompt rõ bắt đầu bằng năm ô khiến phần cần đoán giảm đi, không phải bằng thật nhiều câu chữ.

2. Năm ô tạo phần lớn độ rõ

a. Ô 1: một nhiệm vụ

Nhiệm vụ là một việc cụ thể model cần làm trong lượt đó. “Đọc phản hồi này rồi liệt kê ba vấn đề khách nêu trực tiếp” là một nhiệm vụ. “Tóm tắt, trả lời khách, đề xuất chính sách và làm báo cáo” là bốn nhiệm vụ trộn vào nhau.

Không phải model hoàn toàn không làm được nhiều bước. Vấn đề là khi bốn bước cùng nằm trong một câu, bạn khó biết output hỏng ở bước nào. Nếu phải làm nhiều bước, tách để mỗi bước có đầu ra kiểm được: trước hết trích vấn đề; sau khi duyệt danh sách đó mới soạn phản hồi; cuối cùng mới lập báo cáo từ bản đã duyệt.

b. Ô 2: context cần thiết

Context là thông tin model cần có để làm nhiệm vụ. Context có thể là đoạn phản hồi giả, đối tượng người đọc, sản phẩm, thời hạn hoặc phần tài liệu được phép dùng. Context không phải mọi thứ bạn biết; nó là thứ thiếu đi thì kết quả dễ trật.

Ví dụ, bạn muốn tóm tắt email họp. Hãy đưa nội dung email, ai sẽ đọc bản tóm tắt và điều nào cần giữ nguyên. Nếu không có email gốc, model không thể tóm tắt chính xác. Nó có thể viết một bản nghe rất trôi chảy, nhưng đó là bản do model tạo ra chứ không phải tóm tắt dữ liệu thật.

Context giống nguyên liệu nấu ăn. Bạn có thể ghi công thức thật đẹp, nhưng không có gạo thì không thể yêu cầu nồi cơm ra đúng món. Prompt không tạo ra dữ liệu bị thiếu.

c. Ô 3: output mong muốn

Output là toàn bộ kết quả AI trả lại. Trong ô này, hãy mô tả output format: kết quả phải là ba bullet, bảng hai cột, email tối đa 120 từ, JSON theo schema hay danh sách câu hỏi. Nói format trước giúp model bớt chọn hộ bạn cách trình bày.

Đừng chỉ viết “ngắn gọn”. Thay vào đó, hãy nói “ba bullet, mỗi bullet tối đa 20 từ”. Hai yêu cầu này khác nhau: “ngắn gọn” là cảm giác, còn số bullet và giới hạn từ là thứ bạn có thể quan sát.

d. Ô 4: rubric để chấm

Rubric là danh sách tiêu chí bạn dùng để chấm output. Với phản hồi khách hàng, rubric có thể là: chỉ lấy điều khách nói trực tiếp, đủ ba vấn đề và không bịa nguyên nhân. Rubric không làm dữ liệu mới xuất hiện; nó chỉ nói thế nào là đạt.

Nó giống bảng kiểm khi nhận hàng. “Hàng tốt” quá chung. “Đủ ba hộp, vỏ không rách, đúng mã đơn” thì người giao và người nhận cùng biết phải nhìn gì.

e. Ô 5: điểm dừng để kiểm

Điểm dừng để kiểm là câu nói rõ lúc model cần thừa nhận thiếu thông tin, hỏi lại hoặc ghi phần chưa kiểm chứng. Ví dụ: “Nếu phản hồi không nêu nguyên nhân, ghi ‘chưa đủ dữ liệu’, không suy đoán.”

Ô này rất quan trọng khi output có thể ảnh hưởng tới khách hàng, tài chính, sức khỏe hoặc quyết định thật. Model có thể tạo văn bản nghe hợp lý khi nguồn thiếu. Một câu dừng không biến model thành người kiểm chứng, nhưng nó làm giới hạn hiện ra thay vì bị che bởi câu chữ tự tin.

3. Ghép năm ô thành prompt có thể kiểm

a. Từ câu mơ hồ tới câu có thể chấm

Giả sử phản hồi giả là: “Tôi không đăng nhập được từ sáng. Tôi đã đổi mật khẩu nhưng vẫn lỗi. Tôi cần dùng tài khoản trước chiều nay.”

Prompt A: “Xử lý phản hồi này giúp tôi.” Prompt này không cho biết bạn cần tóm tắt, trả lời hay tự đoán nguyên nhân. Nếu model viết email xin lỗi rất hay, bạn vẫn không biết nó có hoàn thành đúng việc không.

Prompt B có thể viết như sau:

Từ phản hồi dưới đây, liệt kê ba vấn đề khách nêu trực tiếp. Dùng đúng 3 bullet, mỗi bullet dưới 18 từ. Không đoán nguyên nhân kỹ thuật. Nếu một vấn đề không có dữ liệu, ghi “chưa đủ dữ liệu”. Phản hồi: “…”

Prompt B không hoa mỹ hơn nhiều. Nó có một nhiệm vụ, context, output, rubric và điểm dừng. Bạn có thể so output với từng ô thay vì tranh luận cảm giác “có vẻ chưa ổn”.

Hình 2 — Cùng một case, prompt năm ô cho người dùng cách chấm rõ hơn prompt chỉ nói “xử lý”.

b. Role, constraint và few-shot đặt ở đâu?

Role là góc nhìn hoặc cách làm bạn giao, ví dụ “đóng vai người biên tập rõ ràng”. Role hữu ích khi nó thay đổi thật sự cách xử lý. Nếu nhiệm vụ đã là “liệt kê ba vấn đề được nêu trực tiếp”, thêm “bạn là chuyên gia hàng đầu thế giới” thường không làm tiêu chí rõ hơn.

Constraint là giới hạn: không dùng dữ liệu ngoài đoạn văn, không quá ba bullet, không khẳng định điều chưa có nguồn. Constraint thường nằm cạnh output hoặc rubric vì nó giới hạn kết quả bạn đang chấm. Xem thêm bài Vai trò, Goal và Constraint để tách ba thứ này cho gọn.

Few-shot là đưa một vài mẫu input-output để chỉ kiểu trả lời mong muốn. Nó hữu ích khi format khó mô tả bằng lời, chẳng hạn phân loại câu hỏi theo ba nhãn. Nhưng ví dụ làm prompt dài hơn, có thể kéo model theo lỗi của ví dụ. Bắt đầu zero-shot với năm ô; chỉ thêm few-shot khi bạn biết mẫu nào đang thiếu. Bài Few-shot vs Zero-shot Prompting giải thích kỹ hai cách này.

c. Structured output không thay rubric

Bạn có thể yêu cầu Markdown, JSON hoặc XML để máy khác đọc output. Structured output giúp khuôn dữ liệu nhất quán, nhưng không tự nói nội dung nào là đúng. JSON có ba trường đẹp vẫn có thể chứa ba nhận định sai.

Hãy dùng cấu trúc sau khi bạn đã rõ nhiệm vụ, context và rubric. Nếu cần kỹ hơn, xem Structured Output: Markdown, JSON, XML. Khuôn là cái hộp; rubric là cách bạn kiểm đồ trong hộp.

4. Dùng framework mà vẫn sai: ba giới hạn cần nhớ

a. Dữ liệu thiếu hoặc sai thì prompt không cứu được

Model có thể tóm tắt đoạn văn bạn đưa, nhưng không biết đoạn văn có đúng sự thật hay không. Khi cần thông tin hiện tại, số liệu, luật lệ hoặc quyết định lớn, hãy yêu cầu nguồn cụ thể rồi tự mở nguồn kiểm. Nếu không có nguồn, câu đúng nhất đôi khi là “chưa đủ dữ liệu để kết luận”.

Đây là chỗ hallucination dễ xuất hiện: chi tiết nghe hợp lý nhưng không có dữ liệu hoặc nguồn hỗ trợ. Rủi ro là câu trả lời trôi chảy có thể che phần chưa được kiểm. Đừng đánh giá output chỉ bằng độ mượt của câu.

b. Cùng prompt, model có thể cho kết quả khác

Hành vi prompt có thể thay đổi khi bạn đổi model hoặc snapshot model. OpenAI khuyến nghị ghim phiên bản model khi cần ổn định và dùng eval để kiểm đầu ra, thay vì coi một prompt đã từng tốt là tốt mãi OpenAI.

Nếu xây bằng API và nhà cung cấp cho chọn snapshot, hãy lưu đúng model ID rồi chạy lại eval khi đổi phiên bản. Nếu dùng giao diện chat không cho ghim model, hãy lưu ngày chạy, prompt và test case để phát hiện hành vi đã đổi.

Vì vậy, đừng sửa prompt chỉ dựa vào một lần chạy đẹp. Giữ một vài case đại diện: case bình thường, case thiếu dữ liệu và case dễ gây nhầm. Chạy lại sau khi đổi prompt hoặc đổi model.

c. Eval nhỏ thay cho cảm giác

Eval là cách thử prompt bằng case và tiêu chí cố định. Với người mới, eval nhỏ đủ là bảng bốn tiêu chí: đúng nhiệm vụ, dùng đúng context, đúng format và biết dừng khi thiếu dữ liệu. OpenAI cũng đặt việc xác định tiêu chí thành công và đánh giá output ở trung tâm của quy trình xây ứng dụng AI OpenAI Evals.

Đổi một ô mỗi lượt. Nếu bạn vừa đổi role, thêm ví dụ, đổi format và rút ngắn câu, output tốt hơn cũng không cho biết phần nào có tác dụng. Cách chậm hơn một chút lại giúp bạn giữ được phần sửa có ích.

Hình 3 — Framework hướng bạn sang kiểm dữ liệu và test case khi prompt không còn là chỗ cần sửa.

5. Checklist 60 giây trước khi gửi

a. Rà theo đúng thứ tự

Bạn không cần copy một mẫu prompt dài cho mọi việc. Trước khi gửi, rà năm câu này:

1. Tôi đang giao một nhiệm vụ hay nhồi nhiều việc?
2. Tôi đã đưa context cần thiết chưa, và có dữ liệu nào không nên dán vào chat không?
3. Output cần mấy bullet, bảng gì hoặc độ dài nào?
4. Rubric nào cho biết câu trả lời đạt hay chưa?
5. Khi thiếu dữ liệu hoặc phải kiểm nguồn, model phải dừng và nói gì?

Nếu bạn không trả lời được câu 1, hãy tách task. Nếu không trả lời được câu 2, hãy hỏi người giao việc hoặc tìm tài liệu gốc. Nếu không biết tiêu chí 4, có lẽ bạn chưa xác định “kết quả tốt” nghĩa là gì.

b. Có lúc đừng dùng prompt dài hơn

Đừng thêm role, chain of thought hay ví dụ chỉ vì output chưa vừa ý. Hãy xem lỗi nằm ở ô nào. Prompt tóm tắt một đoạn ngắn có thể chỉ cần nhiệm vụ, đoạn văn và ba bullet. Prompt phân loại nhiều loại hóa đơn có thể cần examples và rubric kỹ hơn.

Google cũng khuyến nghị chỉ dẫn tập trung, rõ ràng, ví dụ khi cần và delimiter để tách phần thông tin; cấu trúc giúp model phân biệt instruction với background Google. Ý chính vẫn là: thêm đúng phần còn thiếu, không thêm trang trí.

Hình 4 — Năm câu rà nhanh giúp bạn nhận ra phải viết lại prompt hay phải quay về bổ sung dữ liệu.

6. Bài tập 15 phút: viết rồi chấm hai prompt

a. Chuẩn bị case giả

Dùng chatbot miễn phí và một đoạn phản hồi giả. Không dùng email khách thật, số điện thoại hay thông tin nội bộ. Mục tiêu không phải tìm “prompt hoàn hảo”; mục tiêu là học cách nhìn khác biệt giữa hai yêu cầu.

Chọn một đoạn phản hồi giả rồi dán nguyên đoạn đó vào cả Prompt A và Prompt B. Trong 5 phút, viết Prompt A chỉ nói: “Xử lý phản hồi dưới đây.” Trong 5 phút tiếp theo, viết Prompt B theo năm ô. Cuối cùng chạy hai prompt với cùng đoạn phản hồi và chấm trong 5 phút.

Mẫu đối chiếu

Sau khi so, hãy ghi một câu: output nào dễ chấm hơn, và vì sao? Nếu Prompt B vẫn tệ, chỉ chọn một ô để sửa. Ví dụ, nếu model trả bốn bullet thay vì ba, hãy kiểm output/constraint trước; đừng đổi cả role và ví dụ.

c. Khi nào chuyển sang phần tiếp theo?

Khi bạn đã viết được prompt năm ô cho vài việc nhỏ, đừng cố nhét toàn bộ tài liệu dài vào prompt. Bước tiếp theo là học cách chọn, nén và đưa đúng thông tin vào context. Đó là chủ đề của Context Engineering ở Phase 2.

7. Tổng kết

a. Năm ý chính

• Framework 80/20 là cách ưu tiên phần làm model bớt phải đoán, không phải tỷ lệ bảo đảm chất lượng.
• Năm ô là một nhiệm vụ, context cần thiết, output mong muốn, rubric và điểm dừng để kiểm.
• Role, constraint và few-shot là phần hỗ trợ; chỉ thêm khi chúng làm rõ một ô đang thiếu.
• Prompt tốt không sửa được dữ liệu thiếu, nguồn sai hoặc tiêu chí chưa rõ; lúc đó phải dừng và kiểm.
• Giữ case, đổi một phần mỗi lượt và dùng eval nhỏ giúp bạn biết prompt tốt hơn ở đâu.

b. Câu hỏi tự kiểm tra

• Vì sao “80/20” trong framework này không phải lời hứa về chất lượng?
• Năm ô nào giúp bạn biến “xử lý phản hồi này” thành nhiệm vụ có thể chấm?
• Rubric khác output ở điểm nào?
• Khi context thiếu dữ liệu, prompt nên yêu cầu model làm gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Đó là cách ưu tiên vài phần hay làm model phải đoán nhất, không phải tỷ lệ thành công cố định. → xem mục 1.

Xem gợi ý câu 2

Một nhiệm vụ, context, output, rubric và điểm dừng để kiểm tạo thành khung cơ bản. → xem mục 2 và 3.

Xem gợi ý câu 3

Output là khuôn trả về; rubric là tiêu chí để chấm nội dung trong khuôn đó. → xem mục 2.

Xem gợi ý câu 4

Yêu cầu ghi “chưa đủ dữ liệu”, hỏi lại hoặc kiểm nguồn; đừng ép model suy đoán. → xem mục 2 và 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• OpenAI Evals
• OpenAI: Backward compatibility
• Google: Prompt design best practices
• Anthropic: Define success

Nội dung này phục vụ mục đích giáo dục. Output AI có thể thiếu hoặc sai; hãy kiểm nguồn, dữ liệu và dùng người có chuyên môn cho quyết định quan trọng.