Prompt engineering cơ bản: cách viết prompt tốt

Vì sao cách diễn đạt prompt quan trọng

Mô hình ngôn ngữ không biết hoàn cảnh của bạn. Nó chỉ thấy văn bản bạn gửi. Khi prompt mơ hồ, mô hình lấp chỗ trống bằng câu trả lời phổ biến nhất, thường chung chung, quá dài hoặc nhắm sai người đọc. Prompt engineering phần lớn là việc loại bỏ những chỗ phải đoán.

Một phép thử hữu ích: một đồng nghiệp mới thông minh, chưa từng gặp bạn, có làm tốt việc này chỉ từ tin nhắn của bạn không? Nếu họ phải hỏi lại ba câu trước, thì mô hình cũng cần những câu trả lời đó. Hướng dẫn chính thức của OpenAI, Anthropic và Google đưa ra cùng lời khuyên cốt lõi bằng những cách nói khác nhau: rõ ràng và cụ thể, đưa ngữ cảnh, cho ví dụ, nói rõ định dạng bạn muốn.

Sáu phần của một prompt tốt

Không phải prompt nào cũng cần đủ sáu phần, nhưng đối chiếu danh sách này sẽ sửa được hầu hết prompt yếu.

Hãy đặt tài liệu đầu vào dài giữa các dấu phân cách rõ ràng, như thẻ kiểu XML hoặc ba dấu ngoặc kép, để mô hình phân biệt được chỉ dẫn của bạn với văn bản cần xử lý. Cách này cũng giảm nguy cơ làm theo nhầm chỉ dẫn ẩn trong đầu vào, ví dụ trong một trang web được dán vào.

Viết lại: trước và sau

Đây là một prompt yếu điển hình:

Summarize this article.

Mô hình sẽ tạo ra bản tóm tắt, nhưng dài bao nhiêu, cho ai, dưới dạng nào? Đây là cùng yêu cầu đó khi đã lấp các chỗ trống:

You are helping a busy product manager decide whether to read a research article.

Summarize the article below for that reader.
- Start with one sentence: the main finding.
- Then 3 bullet points: method, key number, main limitation.
- Use plain English. Explain any technical term in a few words.
- Under 100 words in total.
- If the article does not state a limitation, write "No limitation stated".

<article>
{paste the article here}
</article>

Mỗi phần làm gì:

• Dòng đầu đặt đối tượng và mục đích. Giờ mô hình biết vì sao cần bản tóm tắt, nên biết cần giữ gì.
• Cấu trúc gạch đầu dòng cố định định dạng, nên mọi bản tóm tắt trông giống nhau và dễ so sánh.
• Giới hạn số từ ngăn mô hình viết độn.
• Quy tắc cho trường hợp thiếu hạn chế cho mô hình biết phải làm gì ở tình huống biên, thay vì tự bịa ra.
• Các thẻ tách bài viết ra khỏi chỉ dẫn.

Cho ví dụ khi lời nói chưa đủ

Một số yêu cầu khó mô tả nhưng dễ cho xem: giọng điệu, cách gắn nhãn, một phong cách đầu ra cụ thể. Thêm vài ví dụ minh họa gọi là few-shot prompting. Một ví dụ (one-shot) thường đã giúp nhiều. Hai đến năm ví dụ đa dạng thường bao quát được các trường hợp chính.

Classify each support message as BILLING, SHIPPING, PRODUCT or OTHER.
Reply with the label only.

Message: I was charged twice for order 5521.
Label: BILLING

Message: The handle on my mug cracked after one week.
Label: PRODUCT

Message: Do you have a shop in Osaka?
Label: OTHER

Message: {new message}
Label:

Hãy làm cho các ví dụ khác nhau. Nếu tất cả đều ngắn và lịch sự, mô hình có thể xử lý kém một tin nhắn dài và giận dữ. Cũng cần kiểm tra ví dụ khớp với quy tắc: mô hình bắt chước ví dụ mạnh hơn là làm theo chỉ dẫn viết ra.

Kỹ thuật giúp ích trong từng trường hợp

• Yêu cầu các bước trước khi trả lời. Với toán, logic hoặc quyết định nhiều phần, yêu cầu mô hình giải từng bước trước khi đưa đáp án cuối giúp tăng độ chính xác. Đây gọi là chain-of-thought prompting. Nhiều mô hình hiện nay làm việc này ngầm bên trong (thường gọi là chế độ suy luận hay suy nghĩ), nên một yêu cầu thông thường về câu trả lời cẩn thận có thể là đủ.
• Chia nhỏ việc lớn. Thay vì “nghiên cứu, lập dàn ý và viết báo cáo” trong một prompt, hãy chạy ba prompt và kiểm tra từng kết quả. Cách này gọi là prompt chaining.
• Chỉ gán vai khi nó thêm thông tin. “Bạn là kế toán thuế tại Việt Nam” làm thay đổi cách chọn từ và các giả định. “Bạn là thiên tài đẳng cấp thế giới” thì chẳng thêm gì.
• Nói cần làm gì, không chỉ điều cần tránh. “Hãy viết câu ngắn” hiệu quả hơn “Đừng dài dòng”.
• Cho phép trả lời “tôi không biết”. Hãy nói với mô hình rằng nó được phép báo là thiếu thông tin. Cách này giảm sự kiện bịa, dù không loại bỏ hết.
• Yêu cầu định dạng máy đọc được khi mã sẽ đọc kết quả, ví dụ JSON với các trường có tên. Hầu hết API cũng có thể ép buộc một lược đồ JSON trực tiếp.

Kiểm thử prompt như kiểm thử mã

Một prompt chạy tốt trên một ví dụ có thể hỏng ở ví dụ sau. Nếu prompt sẽ được dùng lại, hoặc bởi người khác, hãy kiểm thử nó:

1. Viết ra kết quả tốt trông thế nào: độ dài, định dạng, những sự kiện bắt buộc đúng.
2. Thu thập 10 đến 20 đầu vào thật, kể cả loại khó: rất ngắn, rất dài, lạc đề, ngôn ngữ khác.
3. Chạy prompt trên tất cả và đọc từng kết quả.
4. Mỗi lần chỉ đổi một thứ và chạy lại cả bộ, để biết thay đổi nào có tác dụng.
5. Giữ prompt cuối cùng cùng với bộ kiểm thử. Khi đổi mô hình hoặc mô hình được cập nhật, hãy chạy lại bộ này.

Bước cuối này quan trọng vì cùng một prompt có thể hoạt động khác nhau trên các mô hình khác nhau, và trên các phiên bản mới của cùng một mô hình. Vì lý do đó, hướng dẫn prompt engineering từ các hãng mô hình thay đổi theo thời gian.

Những lỗi thường gặp

• Quá nhiều mục tiêu trong một prompt. Mười quy tắc có trọng số ngang nhau sẽ bị bỏ qua một phần. Đặt quy tắc quan trọng nhất lên đầu và giữ danh sách ngắn.
• Mâu thuẫn, như “hãy chi tiết” và “dưới 50 từ”. Mô hình sẽ thỏa mãn một và phá vỡ cái kia.
• Dựa vào chữ in hoa hay lời đe dọa (“YOU MUST”) thay vì một lý do rõ ràng. Giải thích ngắn gọn vì sao có quy tắc đó thường hiệu quả hơn.
• Không tách đầu vào khỏi chỉ dẫn, khiến mô hình coi một phần tài liệu của bạn là mệnh lệnh.
• Tin các sự kiện trong kết quả. Prompt viết tốt vẫn cho ra lỗi nói với vẻ chắc chắn. Hãy kiểm tra tên, số liệu, trích dẫn và liên kết.