Prompt Optimization: Tối ưu prompt có hệ thống #5

Nội dung này phục vụ mục đích giáo dục. Chỉ dùng dữ liệu giả và môi trường test; không nối prompt thử nghiệm với quyền hành động thật.

Trả lời ngắn: Prompt Optimization là quá trình cải thiện prompt bằng một bộ test và tiêu chí đo được: khóa contract, ghi baseline, thay một nhóm biến, chạy lại cùng điều kiện rồi promote hoặc rollback. Nếu chỉ chọn output trông hay nhất, bạn đang thử–sai theo cảm giác chứ chưa tối ưu có hệ thống.

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

• Vì sao phải khóa contract, baseline và eval set trước khi sửa prompt.
• Cách phân biệt metric muốn tăng với hard gate tuyệt đối không được hỏng.
• Cách dùng version, slices và error log để phát hiện regression rồi promote hoặc rollback.

1. Prompt Optimization là gì, và vì sao sửa theo cảm giác dễ sai?

a. Một output đẹp không đại diện cả task

Bạn có prompt cho bộ phân loại (classifier) ticket hỗ trợ thành billing, login, delivery hoặc other. Một ticket “không đăng nhập được” bị gán nhầm other. Bạn thêm câu “hãy chú ý lỗi tài khoản”, chạy lại đúng ticket đó và thấy login. Trông có vẻ đã sửa xong.

Nhưng prompt mới có thể gán mọi câu chứa “tài khoản” thành login, kể cả “tài khoản bị trừ tiền hai lần” vốn thuộc billing. Bạn tối ưu một mẫu vừa nhìn nhưng làm hỏng mẫu khác.

Contract là bản mô tả task phải giữ ổn định: input gì, output gì, nhãn nào, ràng buộc nào, lúc nào phải dừng hoặc chuyển người. Với classifier này:

• Input: một ticket giả.
• Output: JSON {label, reason}.
• Label: bốn giá trị cho phép.
• Safety: không tự hoàn tiền, khóa tài khoản hay gửi tin.

Không có contract, câu “prompt tốt hơn” không có nghĩa rõ ràng.

b. Tối ưu không đồng nghĩa prompt dài hơn

Prompt dài có thể thêm ngữ cảnh hữu ích, nhưng cũng có thể chứa hai chỉ dẫn đá nhau, ví dụ thừa hoặc format mơ hồ. OpenAI mô tả công cụ Optimize có thể phát hiện mâu thuẫn, chỉ dẫn chưa rõ và thiếu output format; đó là gợi ý để test, không phải bằng chứng candidate đã sẵn sàng production. OpenAI Prompt management

Cách làm có hệ thống là đo trước, đổi có chủ đích và đo lại.

2. Khóa contract, baseline và eval set trước khi tối ưu

a. Baseline là cái mốc

Baseline là version prompt và mức điểm trước khi thay đổi. Hãy lưu:

• prompt text;
• model/version và cấu hình;
• ngày chạy;
• eval set;
• output thô;
• score và error log.

Nó giống cân món hàng trước khi đổi công thức. Không có số trước thì không biết bản sau tốt hơn, hay chỉ khác.

b. Eval set phải có nhiều kiểu tình huống

Eval set là bộ input dùng để đo các version. Bộ 12 ticket giả có thể gồm:

• 6 ca rõ nhãn;
• 3 ca biên có hai từ khóa dễ gây nhầm;
• 3 ca safety yêu cầu hành động ngoài quyền.

Đừng chỉ chọn ví dụ dễ. Một bộ áo phải được thử ở nhiều cỡ, không chỉ cỡ vừa người mẫu.

Metric là số hoặc quy tắc đo mục tiêu. Ở đây, metric chính là label accuracy: số ticket gán đúng trên 12.

Hard gate là điều kiện bắt buộc; fail một cái là không promote:

1. JSON hợp lệ 12/12.
2. Label nằm trong danh sách 12/12.
3. Safety case không tự hành động 3/3.

Tiêu chí thành công nên được xác định cụ thể và đo được trước khi tối ưu. Anthropic — Define success criteria

c. Giữ điều kiện so sánh công bằng

Khi so v1 với v2, giữ cùng model, phiên bản, tham số độ ngẫu nhiên (temperature), input và cách chấm. Nếu vừa đổi prompt, model lẫn dữ liệu, bạn không biết thay đổi nào tạo ra kết quả.

Nếu bắt buộc đổi nhiều thứ, ghi rõ đó là phép so cả cấu hình, không phải bằng chứng riêng cho prompt.

3. Loop đổi một nhóm biến rồi đo lại

Hình 1 — Một thay đổi chỉ được giữ khi chạy lại cùng bài test, metric tăng và mọi hard gate vẫn pass.

Một vòng thực tế:

1. Chọn error slice: ví dụ ticket có cả “tài khoản” và “trừ tiền”.
2. Nêu giả thuyết: định nghĩa nhãn billing chưa đủ rõ.
3. Đổi một nhóm biến: bổ sung ranh giới giữa billing và login.
4. Lưu candidate: đặt mã v2-label-boundary.
5. Chạy toàn eval set: không chỉ chạy hai ticket lỗi.
6. So metric và hard gate.
7. Promote hoặc rollback, rồi ghi lý do.

Một nhóm biến có thể là task instruction, label definitions, examples hoặc output schema. “Đổi một nhóm” giúp truy nguyên nguyên nhân; nó không có nghĩa chỉ được sửa đúng một từ.

Version là bản prompt có mã và lịch sử. Candidate là version đang thử, chưa được coi là bản dùng tiếp.

OpenAI Prompt management có lịch sử, chế độ so sánh hai bản cạnh nhau và liên kết Eval để chạy lại; OpenAI Evals mô tả phép đánh giá bằng tiêu chí test và nguồn dữ liệu. Đây là ví dụ công cụ hiện tại, không phải điều kiện bắt buộc cho quy trình. OpenAI Evals API

Bạn cũng có thể làm bản nhỏ bằng file Markdown và spreadsheet. Điều quan trọng là cùng test, có version và quyết định được ghi lại.

4. Scorecard: prompt điểm cao vẫn có thể không được promote

Hình 2 — Điểm accuracy cao nhất không cứu được candidate đã làm hỏng output contract.

Giả sử ba lần chạy cho kết quả:

V2 có accuracy cao nhất nhưng một output không phải JSON. Nếu bộ phân tích ở bước sau chỉ nhận JSON, một lần fail có thể làm cả quy trình hỏng. Hard gate xử lý việc này theo kiểu đóng khi lỗi (fail-closed): chưa đạt thì không đi tiếp.

a. Đừng để điểm trung bình che nhóm lỗi

Slice là nhóm test có cùng đặc điểm, như:

• ticket chỉ có một ý;
• ticket chứa hai từ khóa;
• ticket đòi hành động;
• ticket tiếng Việt không dấu.

V3 đạt 10/12 nhưng cần xem nó sai ở slice nào. Nếu cả hai lỗi nằm trong safety slice, con số tổng không cứu được nó. Nếu lỗi nằm ở hai câu other mơ hồ và human gate bắt được, quyết định có thể khác.

Scorecard phải hiển thị cả tổng và slice. Số trung bình chỉ là phần mở đầu của cuộc điều tra.

b. Metric không thay contract

Tăng accuracy bằng cách bỏ trường reason có thể làm output dễ đo hơn nhưng vi phạm contract. Trước khi tối ưu, phải quyết định trường nào bắt buộc và trường nào được phép thay.

DSPy là ví dụ nghiên cứu cho cách tối ưu chuỗi xử lý theo một metric thay vì viết cứng prompt bằng thử–sai. Nó cho thấy metric có thể dẫn hướng tối ưu tự động, nhưng metric sai vẫn tối ưu sai mục tiêu. Khattab và cộng sự, 2023

5. Sai lầm, rủi ro regression và điều kiện rollback

Hình 3 — Nếu không lưu version và error log, vòng tối ưu rất dễ lặp lại cùng một lỗi.

a. Ba lỗi thường gặp

1. Regression: khả năng từng đạt bị hỏng sau thay đổi. Ví dụ JSON từ 12/12 xuống 11/12.
2. Leakage: answer hoặc test case lọt vào prompt, khiến điểm test tăng giả.
3. Overfitting: prompt bám quá sát eval set nhưng kém trên dữ liệu mới.

FAQ prompt chứa nguyên văn 12 câu test có thể đạt 12/12 mà không xử lý tốt câu thứ 13. Đó giống học thuộc đề, không phải hiểu cách phân loại.

b. Khi nào rollback?

Promote là chọn candidate làm version dùng tiếp. Rollback là quay về version đã đạt.

Rollback khi:

• bất kỳ hard gate nào fail;
• slice quan trọng tụt dưới ngưỡng;
• chi phí/latency vượt budget;
• error không truy được nguyên nhân;
• candidate cần quyền hoặc dữ liệu ngoài contract.

Không xóa candidate thất bại. Lưu giả thuyết, diff, score và lý do reject để lần sau không lặp lại.

c. Khi nào dừng tối ưu?

Dừng khi đạt acceptance threshold, hết budget hoặc hai vòng liên tiếp không cải thiện có ý nghĩa. Một prompt đã đủ tốt cho task hẹp không cần bị kéo dài chỉ vì “có thể hay hơn”.

Không chạy candidate trên ticket thật, không kết nối helpdesk và không cho prompt tự gửi, hoàn tiền hoặc khóa tài khoản. Tối ưu phải diễn ra trong môi trường cô lập, chỉ đọc trước.

6. Bài tập 15 phút: tối ưu classifier sáu ticket giả

a. Chuẩn bị

Dùng spreadsheet miễn phí và chatbot hiện có. Tạo sáu ticket giả, hai safety case; output phải là JSON {label, reason}.

• 3 phút: viết contract và hard gates.
• 4 phút: chạy baseline trên sáu rows.
• 3 phút: sửa label definitions, lưu v2.
• 3 phút: chạy lại đúng sáu rows.
• 2 phút: so scorecard và quyết định.

Chưa dùng dữ liệu khách hàng hoặc hành động thật.

b. Mẫu đối chiếu đã điền

Error log v1 ghi ticket “tài khoản bị trừ hai lần” bị gán login. V2 thêm ranh giới: sự cố đăng nhập là login; phí, trừ tiền và hóa đơn là billing. Chạy lại toàn bộ sáu rows, không chỉ ticket vừa sửa.

7. Tổng kết và bài học tiếp theo

a. Năm ý chính

• Prompt Optimization bắt đầu bằng contract và baseline, không bằng câu chữ mới.
• Eval set phải có ca rõ, ca biên và safety case.
• Metric muốn tăng; hard gate tuyệt đối không được hỏng.
• Mỗi candidate cần version, cùng config và error log.
• Regression, leakage hoặc overfitting là lý do rollback, không phải lỗi để giấu.

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

• Vì sao một output đẹp chưa chứng minh prompt tốt hơn?
• Metric khác hard gate ở đâu?
• Vì sao v2 đạt 11/12 vẫn bị reject?
• Khi nào phải rollback?

c. Gợi ý đáp án

Xem gợi ý câu 1

Một output không đại diện toàn eval set và có thể che regression ở input khác. → xem mục 1.

Xem gợi ý câu 2

Metric là mục tiêu muốn cải thiện; hard gate là điều kiện bắt buộc để được promote. → xem mục 2.

Xem gợi ý câu 3

V2 làm JSON validity tụt 11/12, vi phạm output contract dù accuracy cao. → xem mục 4.

Xem gợi ý câu 4

Rollback khi hard gate fail, slice quan trọng tụt hoặc candidate vượt budget/quyền. → xem mục 5.

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

e. Nguồn tham khảo

• OpenAI — Prompt management in Playground
• OpenAI API — Evals
• Anthropic — Define success criteria
• DSPy: Compiling Declarative Language Model Calls

f. Học tiếp gì?

Bài trước là Tree of Thoughts là gì? #4, nơi ta search qua nhiều state. Bài tiếp theo là Prompt Evaluation: Đánh giá prompt bằng test #6, nơi ta đào sâu cách thiết kế cases, grader, threshold và báo cáo độ tin cậy của phép đo.

Nhắc lại: Nội dung chỉ phục vụ mục đích giáo dục. Không dùng prompt candidate trên dữ liệu thật hoặc trao quyền hành động trước khi hard gate, verifier và người duyệt đều đạt.