Biến SOP của khách thành prompt: viết bộ test trước, viết prompt sau

Tài liệu API của OpenAI có một câu đáng dán lên màn hình của mọi FDE: output của LLM không tất định, và hành vi của model thay đổi giữa các snapshot và các họ model. Một prompt demo trơn tru cho khách hôm nay có thể trả lời lệch vào tháng sau dù không ai sửa chữ nào.

Khi làm với khách, nguồn chỉ dẫn tốt nhất thường đã nằm sẵn trong tay họ: tài liệu quy trình chuẩn, hay SOP. Nhân viên mới đọc nó để biết cách xử lý một yêu cầu hoàn tiền hay phân loại một khiếu nại. Việc của bạn là biến chính tài liệu đó thành prompt mà model làm theo ổn định, và chứng minh được là nó ổn định.

Bài này đi qua một ví dụ giả định từ đầu đến cuối. Khung chính lấy từ năm bước trong khóa Prompting Essentials của Google (task, context, references, evaluate, iterate). Phần chi tiết lấy từ hướng dẫn viết prompt của Anthropic.

Bạn sẽ dựng gì, và cần chuẩn bị gì?

Thử hình dung khách là một sàn thương mại điện tử có SOP xử lý yêu cầu hoàn tiền. Bạn cần làm ra hai thứ. Thứ nhất là một prompt nhận yêu cầu của người mua và trả về quyết định: duyệt, từ chối hoặc chuyển cho người xử lý, kèm lý do. Thứ hai là một bộ ca kiểm thử để chấm prompt đó.

Bạn cần chuẩn bị bản SOP mới nhất và một loạt ca cũ mà nhân viên đã xử lý, có ghi quyết định đúng. Bạn cũng cần quyền gọi một model, và một đồng nghiệp chưa từng đọc SOP này. Đừng bỏ qua người đồng nghiệp: đến bước 6 bạn sẽ cần họ.

Bước 1: Viết bộ test trước khi viết prompt

Phản xạ tự nhiên là mở editor ra và viết prompt ngay. Hãy làm ngược lại. OpenAI khuyên bắt đầu bằng eval đo output của model để có baseline, sau đó mới lặp lại vòng sửa prompt rồi đo lại. Với SOP, bạn dựng eval từ các ca lịch sử của khách; con số baseline sẽ có ở bước 2, khi bạn chạy prompt đầu tiên qua bộ test này.

Định dạng dưới đây chỉ là một cách tổ chức đơn giản để minh họa, không phải chuẩn bắt buộc:

{"id": "c01", "input": "Đơn giao trễ 6 ngày, người mua xin hoàn tiền", "expected": "duyet"}
{"id": "c02", "input": "Người mua đã dùng sản phẩm, xin hoàn vì đổi ý", "expected": "tu_choi"}
{"id": "c03", "input": "Đơn giá trị cao, ảnh chứng minh hàng lỗi bị mờ", "expected": "chuyen_nguoi"}

Kiểm tra: mỗi ca phải có đáp án được trưởng nhóm vận hành của khách xác nhận, không phải đáp án do bạn tự đoán. Bộ test cũng phải có các ca khó, nơi chính nhân viên từng phải hỏi lại cấp trên. Một bộ test toàn ca dễ sẽ cho điểm đẹp mà không nói lên điều gì.

Bước 2: Một câu vai trò, một câu nhiệm vụ

Anthropic cho rằng đặt vai trò trong system prompt giúp model tập trung đúng hành vi và giọng điệu cho use case của bạn, và chỉ một câu cũng đã tạo khác biệt. Bước này tốn rất ít công. Tiếp theo là phần task trong khung của Google: một câu nói rõ đầu ra là gì.

Bạn là nhân viên xử lý hoàn tiền của sàn, làm đúng theo quy trình nội bộ.
Nhiệm vụ: đọc yêu cầu trong thẻ request và trả về một quyết định
(duyet / tu_choi / chuyen_nguoi) cùng lý do ngắn, viện dẫn bước SOP liên quan.

Kiểm tra: chạy bộ test ở bước 1 ngay với phiên bản sơ sài này. Con số bạn ghi lại lúc này chính là baseline, mốc để so mọi lần sửa về sau.

Bước 3: Giữ thứ tự của SOP, thêm chữ “vì”

SOP thường đã viết theo dạng bước 1, bước 2, bước 3, và điều này có lợi cho bạn. Anthropic khuyên dùng danh sách đánh số khi thứ tự hoặc việc làm đủ các bước là quan trọng, đồng thời nói rõ định dạng đầu ra và các ràng buộc. Vì thế, đừng gộp các bước lại thành một đoạn văn.

Nhưng chỉ chép lại luật thì chưa đủ. Theo Anthropic, giải thích lý do đằng sau chỉ dẫn giúp model hiểu mục tiêu của bạn. Hãy so hai cách viết sau:

Trước: Đơn trên ngưỡng giá trị cao thì chuyển người xử lý.

Sau:  Đơn trên ngưỡng giá trị cao thì chuyển người xử lý,
      vì một quyết định sai ở nhóm đơn này gây thiệt hại lớn
      và cần người có thẩm quyền ký duyệt.

Bản thứ hai cho model biết luật này tồn tại để làm gì. Nhờ vậy, khi gặp một ca SOP không lường trước, chẳng hạn đơn giá trị thấp nhưng có dấu hiệu gian lận, model có cơ sở để chọn chuyển cho người xử lý thay vì đoán.

Lý do của từng luật thường không nằm trong tài liệu mà nằm trong đầu người vận hành, nên bạn phải hỏi họ.

Bước 4: Dùng thẻ để tách luật, tài liệu và đầu vào

Một prompt SOP thật thường chứa nhiều thứ cùng lúc: quy trình chính, phụ lục chính sách, ví dụ và yêu cầu cần xử lý. Anthropic khuyên lồng các thẻ XML vào nhau khi nội dung có thứ bậc tự nhiên, ví dụ các tài liệu nằm trong một thẻ documents và mỗi tài liệu nằm trong một thẻ document có thuộc tính index.

Các khối mẫu từ đây dùng ngoặc vuông thay ngoặc nhọn của thẻ XML cho dễ hiển thị; trong prompt thật, bạn dùng ngoặc nhọn.

[documents]
  [document index="1"] SOP hoàn tiền, các bước đánh số kèm lý do [/document]
  [document index="2"] Phụ lục: danh mục hàng không được hoàn [/document]
[/documents]
[examples]
  ... xem bước 5 ...
[/examples]
[request]
  ... yêu cầu của người mua ...
[/request]

Kiểm tra: đọc lại prompt và tự hỏi xem có câu nào nằm ngoài thẻ mà model có thể nhầm là dữ liệu đầu vào không. Nếu có, hãy chuyển câu đó vào đúng chỗ.

Bước 5: Biến ngoại lệ trong SOP thành ví dụ

Anthropic gọi ví dụ là một trong những cách đáng tin cậy nhất để điều khiển định dạng, giọng điệu và cấu trúc của output. Ví dụ tốt phải sát với use case và phải đủ đa dạng: chúng cần bao cả ca biên và khác nhau đủ nhiều để model không học nhầm những quy luật bạn không định dạy.

Phần “lưu ý” và “trường hợp đặc biệt” trong SOP chính là nguồn ví dụ có sẵn. Hãy lấy chúng từ các ca lịch sử thật, và bọc mỗi ví dụ trong một thẻ example để model phân biệt được ví dụ với chỉ dẫn:

[example]
  [request] Đơn giá trị thấp, người mua gửi 3 yêu cầu hoàn trong một tuần [/request]
  [decision] chuyen_nguoi [/decision]
  [reason] Bước 5: tần suất yêu cầu bất thường cần người kiểm tra. [/reason]
[/example]

Lỗi hay gặp: cả ba ví dụ đều ra kết quả “duyệt”. Model có thể hiểu rằng duyệt là câu trả lời an toàn. Hãy phân bổ ví dụ đều cho các nhánh quyết định. Ngoài ra, đừng dùng lại chính các ca trong bộ test làm ví dụ, vì như vậy điểm số sẽ cao một cách ảo.

Bước 6: Đưa cho đồng nghiệp đọc trước khi đưa cho model

Anthropic có một “quy tắc vàng”: đưa prompt cho một đồng nghiệp gần như không biết gì về nhiệm vụ và nhờ họ làm theo. Nếu họ bối rối thì model cũng sẽ bối rối. Phép thử này hợp với SOP vì SOP thường ngầm giả định người đọc đã thấm văn hóa nội bộ của công ty.

Thử hình dung đồng nghiệp hỏi: “Ngưỡng giá trị cao là bao nhiêu?” Đó là một con số khách chưa ghi vào SOP. Hãy hỏi khách, ghi con số đó vào prompt, rồi bổ sung một ca kiểm thử nằm ngay sát ngưỡng.

Bước 7: Đo, sửa, và đo lại khi model đổi

Khóa học của Google coi việc đánh giá output và chỉnh lại prompt là chìa khóa để nhận được kết quả mong muốn. Nói cách khác, prompt SOP không phải thứ viết một lần là xong. Mỗi lần sửa, hãy chạy lại toàn bộ test và so với baseline ở bước 2.

Nên chỉ đổi một thứ mỗi lần để biết chính xác thay đổi nào làm điểm tăng hay giảm.

Sau khi bàn giao, công việc vẫn chưa kết thúc. Vì hành vi của model đổi theo snapshot, mỗi lần khách nâng cấp model, bộ test của bạn trở thành bộ kiểm tra hồi quy. Hãy thống nhất với khách ngay từ đầu rằng không ai đổi model trên production trước khi bộ test chạy xanh.

Vì sao phần khó nhất lại nằm ở phía khách?

Nhìn lại bảy bước, phần lớn nguyên liệu đều nằm ở phía khách: lý do của từng luật, các ca cũ có đáp án, những ngưỡng chưa được ghi lại. Vì thế, khi lên kế hoạch cho một dự án thật, bạn nên dành nhiều thời gian ngồi với người vận hành hơn là ngồi viết câu chữ.

Prompt chỉ là phần ghi lại những gì bạn đã hiểu được về quy trình của khách.

Một gợi ý khi đọc mô tả công việc FDE: dòng nào nhắc đến eval, làm việc cùng đội vận hành hay chuyển quy trình nghiệp vụ thành hệ thống chạy được, thì đó là chỗ kỹ năng này được đem ra dùng. Trong CV, đừng viết “thành thạo prompt engineering”.

Hãy mô tả cụ thể: đã dựng bộ eval từ bao nhiêu ca lịch sử, độ chính xác tăng từ baseline lên mức nào, và đã phát hiện hồi quy khi đổi model ra sao.

Khách sẽ không nhớ prompt của bạn viết hay đến đâu. Họ sẽ nhớ hôm nhà cung cấp tung model mới, bộ test của bạn bắt được lỗi trước khi lỗi đó đến tay người mua.