[Hướng dẫn 4/10] Instruction và role prompting: giao việc rõ ràng, chọn đúng vai

Hướng dẫn Prompt Engineering · Phần 4/10. Phần này tiếp nối Phần 3: Cấu trúc prompt: năm thành phần của một prompt. Bạn mới theo dõi loạt bài? Hãy bắt đầu từ Phần 1: Prompt engineering là gì và vì sao quan trọng.

Phần lớn câu trả lời AI khiến bạn thất vọng không phải do lỗi của mô hình, mà do instruction chưa đủ: prompt bỏ sót đối tượng đọc, độ dài, định dạng hoặc cách xử lý khi thiếu thông tin, nên mô hình tự lấp chỗ trống bằng suy đoán. Instruction prompting và role prompting là hai kỹ thuật lấp những chỗ trống đó, và gộp lại chúng đã bao phủ phần lớn nhu cầu prompt hằng ngày.

Instruction nói cần làm gì. Role nói ai đang phát biểu và nói với ai. Bài này hướng dẫn cách viết cả hai, kèm các mẫu bạn có thể dán nguyên vào ChatGPT, Claude hoặc Gemini. Bài cũng chỉ ra giới hạn mà nhiều tài liệu bỏ qua: role thay đổi cách câu trả lời được diễn đạt, nhưng không làm câu trả lời đúng hơn một cách đáng tin cậy.

Instruction prompting là gì?

Instruction prompting nghĩa là mô tả nhiệm vụ bằng ngôn ngữ thông thường, thay vì huấn luyện mô hình bằng các ví dụ của nhiệm vụ đó. Cách này hiệu quả vì các chat model ngày nay đã được instruction-tune. Bài báo FLAN của Google (Wei và cộng sự, 2021) cho thấy việc fine-tuning mô hình trên nhiều nhiệm vụ được diễn đạt dưới dạng instruction giúp cải thiện hiệu năng zero-shot ở những loại nhiệm vụ mô hình chưa từng thấy. Công trình InstructGPT của OpenAI (Ouyang và cộng sự, 2022) bổ sung phản hồi của con người, và người gán nhãn ưa chuộng đầu ra của mô hình InstructGPT 1,3 tỷ tham số hơn đầu ra của GPT-3 175 tỷ tham số.

Hệ quả thực tế: mô hình có thể làm một việc chưa ai huấn luyện cho nó, chẳng hạn định dạng lại danh sách khách hàng của bạn, miễn là instruction đủ chính xác. Ba mẫu dưới đây là những nhiệm vụ thuộc loại này.

Mẫu 1: chuẩn hóa bản ghi lộn xộn

Làm sạch dữ liệu là bài toán instruction kinh điển. Hãy để ý quy tắc 1 và quy tắc 2: chúng cho mô hình một lối để nói “tôi không chắc” thay vì đoán. Hãy dán bản ghi của bạn vào giữa cặp dấu ba nháy kép.

Chuẩn hóa từng bản ghi khách hàng dưới đây theo đúng định dạng này, mỗi bản ghi một dòng:
Họ, Tên | YYYY-MM-DD | Thành phố, Quốc gia

Quy tắc:
1. Tên: họ đứng trước, viết hoa chữ cái đầu mỗi từ. Nếu không xác định được phần nào là họ, giữ nguyên thứ tự đầu vào và thêm "(cần kiểm tra)" vào cuối dòng.
2. Ngày: đầu vào trộn lẫn định dạng kiểu Mỹ (MM/DD) và định dạng ngày đứng trước. Ngày có tên tháng, hoặc có giá trị ngày lớn hơn 12, thì không mơ hồ. Nếu một ngày dạng số có thể hiểu theo cả hai cách, ghi "????-??-??" và thêm "(cần kiểm tra)".
3. Địa danh: sửa các lỗi chính tả rõ ràng. Ghi tên đầy đủ của quốc gia bằng tiếng Anh. Nếu thiếu quốc gia, ghi "?" và không được đoán.

Bản ghi:
"""
smith, JOHN - sinh 03/04/1990 - london uk
Nguyen Van An; 15 Jan 1988; Ha Noi, Vietnam
maria garcia | 1992-11-30 | Madird, Spain
Tanaka Yuki, 12/25/1985, Osaka
"""

Smith, John | ????-??-?? | London, United Kingdom (cần kiểm tra)
Nguyen, Van An | 1988-01-15 | Hanoi, Vietnam
Garcia, Maria | 1992-11-30 | Madrid, Spain
Tanaka, Yuki | 1985-12-25 | Osaka, ?

Ngày tháng mơ hồ được đánh dấu thay vì bị đoán, và quốc gia còn thiếu vẫn được để trống. Nếu không có hai quy tắc đó, phần lớn mô hình sẽ âm thầm chọn một cách hiểu.

Mẫu 2: ẩn thông tin cá nhân

Yêu cầu placeholder có phân loại và đánh số giúp văn bản đã ẩn thông tin vẫn dễ đọc, còn phần thống kê ở cuối cho phép bạn kiểm tra nhanh kết quả.

Thay mọi thông tin cá nhân trong phiếu hỗ trợ dưới đây bằng một placeholder đặt trong ngoặc vuông, nêu rõ loại thông tin: [NAME], [EMAIL], [PHONE], [ADDRESS], [ACCOUNT_ID], [CARD_NUMBER]. Đánh số các loại lặp lại: [NAME_1], [NAME_2].
Giữ nguyên mọi phần còn lại đúng như đã viết, kể cả lỗi chính tả.
Sau phiếu hỗ trợ, liệt kê từng placeholder bạn đã dùng và số lần xuất hiện của nó.

Phiếu hỗ trợ:
"""
Chào bạn, tôi là Laura Chen ([email protected]). Đồng nghiệp của tôi là Mark Davis
cũng không đăng nhập được. Tài khoản ACC-482913, địa chỉ thanh toán 18 Hill Road, Leeds.
Hãy gọi lại cho tôi theo số +44 7700 900123. 4 số cuối của thẻ: 4417.
"""

Chào bạn, tôi là [NAME_1] ([EMAIL]). Đồng nghiệp của tôi là [NAME_2]
cũng không đăng nhập được. Tài khoản [ACCOUNT_ID], địa chỉ thanh toán [ADDRESS].
Hãy gọi lại cho tôi theo số [PHONE]. 4 số cuối của thẻ: [CARD_NUMBER].

Các placeholder đã dùng:
[NAME_1] x1, [NAME_2] x1, [EMAIL] x1, [ACCOUNT_ID] x1, [ADDRESS] x1, [PHONE] x1, [CARD_NUMBER] x1

Cảnh báo: hãy xem việc LLM ẩn thông tin cá nhân là bước lọc đầu tiên. Mô hình bỏ sót các định dạng bất thường (số ID nằm trong câu, tên trùng với từ thông dụng), và việc dán dữ liệu cá nhân thô vào chatbot của bên thứ ba tự nó đã là một lần chuyển dữ liệu mà chính sách công ty bạn có thể cấm. Với pipeline production, hãy dùng công cụ chuyên dụng như Microsoft Presidio kèm một bước con người rà soát.

Mẫu 3: đánh giá theo rubric

Việc đánh giá trở nên nhất quán khi tiêu chí, thang điểm và bằng chứng đều được nêu rõ. Đặt cột Lý do trước cột Điểm khiến mô hình phải viết phần giải thích trước khi chốt một con số.

Bạn đang rà soát một phản hồi hỗ trợ khách hàng trước khi gửi đi.
Chấm điểm từ 1 (kém) đến 5 (xuất sắc) theo từng tiêu chí dưới đây. Với mỗi tiêu chí, nêu lý do trong một câu và có trích dẫn từ phản hồi.

Tiêu chí:
- Độ chính xác: có trả lời đúng câu hỏi thực sự của khách hàng không?
- Giọng điệu: lịch sự và bình tĩnh, không đổ lỗi cho khách hàng.
- Bước tiếp theo: khách hàng có biết chính xác mình cần làm gì tiếp theo không?
- Độ dài: dưới 120 từ.

Xuất một bảng với các cột Tiêu chí | Lý do | Điểm, rồi thêm một dòng: Kết luận: SEND, EDIT hoặc REWRITE, kèm lý do ngắn.

Câu hỏi của khách hàng: "Tôi bị trừ tiền hai lần cho hóa đơn tháng 3. Bên bạn hoàn lại giúp tôi một khoản được không?"
Bản nháp phản hồi: "Chào bạn, cảm ơn bạn đã liên hệ! Việc bị trừ tiền hai lần thường xảy ra khi giao dịch thẻ được thử lại. Bạn vui lòng kiểm tra lại sao kê ngân hàng, vì một khoản có thể là giao dịch đang chờ xử lý và sẽ tự biến mất. Nếu còn thắc mắc nào khác, hãy báo cho chúng tôi nhé!"

| Tiêu chí | Lý do | Điểm |
|---|---|---|
| Độ chính xác | Nêu một nguyên nhân có thể có nhưng không nói liệu có hoàn tiền hay không ("một khoản có thể là giao dịch đang chờ xử lý"). | 2 |
| Giọng điệu | Thân thiện ("cảm ơn bạn đã liên hệ"), dù "kiểm tra lại sao kê ngân hàng" có thể nghe như nghi ngờ khách hàng. | 4 |
| Bước tiếp theo | "Nếu còn thắc mắc nào khác" không cho biết phải làm gì nếu cả hai khoản đều đã được ghi nhận chính thức. | 2 |
| Độ dài | Khoảng 60 từ, thấp hơn nhiều so với giới hạn. | 5 |

Kết luận: EDIT. Xác nhận khoản thứ hai có phải giao dịch đang chờ xử lý hay không, và nếu không, nêu rõ quy trình hoàn tiền cùng thời hạn.

Cách viết instruction hiệu quả: bảy quy tắc

Theo hướng dẫn prompting của Anthropic, mô hình giống như “một nhân viên mới xuất sắc nhưng chưa nắm các quy chuẩn và quy trình làm việc của bạn”. Các quy tắc dưới đây chính là điều bạn sẽ dặn nhân viên mới đó. Cùng tài liệu này cũng lưu ý rằng các mô hình gần đây làm theo instruction sát nghĩa hơn, nên một chỗ hổng trong instruction giờ đây hiện ngay thành chỗ hổng trong đầu ra.

Quy tắc 4 đáng được chú ý. Ví dụ của Anthropic thay câu “KHÔNG BAO GIỜ dùng dấu ba chấm” bằng lý do: câu trả lời sẽ được một công cụ text-to-speech đọc to và công cụ này không đọc được dấu ba chấm. Khi có lý do, mô hình còn tránh luôn những thứ khác khiến công cụ đọc bị vấp. Quy tắc 7 được trình bày sâu trong Phần 3: Cấu trúc prompt: năm thành phần của một prompt.

Xếp lớp instruction: nhiệm vụ, đối tượng, định dạng, ràng buộc

Hiếm khi bạn viết được instruction hoàn hảo ngay lần đầu. Hãy bắt đầu từ nhiệm vụ trần và thêm từng lớp một. Mẫu dưới đây là kết quả hoàn chỉnh của quá trình đó, dùng để biến changelog nội bộ thành release notes cho khách hàng. Hãy thay changelog bằng nội dung của bạn.

Viết lại changelog kỹ thuật dưới đây thành release notes cho khách hàng.

Đối tượng: quản trị viên không chuyên kỹ thuật của phần mềm nhân sự của chúng tôi.
Định dạng: một tiêu đề, sau đó 3 đến 5 gạch đầu dòng. Mỗi gạch đầu dòng bắt đầu bằng lợi ích, rồi đến thay đổi.
Ràng buộc:
- Tổng cộng dưới 100 từ.
- Bỏ các mã ticket và công việc refactor. Khách hàng không thấy chúng, và chúng chỉ gây nhiễu.
- Nếu một thay đổi cần quản trị viên thao tác, kết thúc gạch đầu dòng đó bằng "Cần thực hiện:" và bước cần làm.

Changelog:
"""
- PAY-2231 thêm nhập hàng loạt từ CSV cho số dư ngày nghỉ của nhân viên
- refactor auth middleware (không ảnh hưởng người dùng)
- fix: lỗi múi giờ khiến giờ ca làm hiển thị chậm 1 giờ với người dùng UTC+7
- PAY-2240 SSO: hỗ trợ Okta SCIM provisioning; quản trị viên phải bật tại Settings > Security
"""

Có gì mới trong bản phát hành này

- Thiết lập nhanh hơn: nhập số dư ngày nghỉ của toàn bộ nhân viên cùng lúc từ một tệp CSV.
- Hiển thị đúng giờ ca làm: chúng tôi đã sửa lỗi khiến giờ ca làm hiển thị chậm một giờ với người dùng ở UTC+7.
- Quản lý người dùng tự động: người dùng Okta nay có thể được thêm và xóa thông qua SCIM provisioning. Cần thực hiện: bật tính năng này tại Settings > Security.

Mỗi dòng của instruction đều thể hiện trong đầu ra: mục refactor đã bị bỏ, mỗi gạch đầu dòng mở đầu bằng lợi ích, và thay đổi duy nhất cần quản trị viên thao tác có nói rõ điều đó.

Completion, câu hỏi hay instruction: chọn dạng phù hợp

Cùng một yêu cầu có thể diễn đạt theo ba dạng, và mỗi dạng cho ra một kiểu câu trả lời khác nhau. Các chat model hiện nay xử lý được cả ba, nhưng chúng không cho bạn mức kiểm soát như nhau.

Viết chính sách hoàn tiền một câu cho một sản phẩm SaaS.
Điều khoản: hoàn tiền toàn bộ trong vòng 14 ngày kể từ ngày mua, sau đó không hoàn tiền.
Giọng điệu: giản dị và thân thiện. Không dùng thuật ngữ pháp lý.

Nếu chưa hài lòng với sản phẩm đã mua, bạn có thể được hoàn tiền toàn bộ trong vòng 14 ngày; sau thời hạn đó, chúng tôi rất tiếc không thể hoàn tiền.

Mẹo: khi còn đang khám phá, hãy hỏi một câu hỏi trước, rồi biến ý tưởng hay nhất trong câu trả lời thành một instruction.

Role prompting là gì, và nó thay đổi được điều gì?

Role prompting gán cho mô hình một persona, thường dưới dạng “Bạn là một …”. Role thay đổi văn phong: từ vựng, giọng điệu, mức độ chi tiết, điều mô hình chú ý trước và cách nó cấu trúc câu trả lời. Hướng dẫn hiện hành của Anthropic mô tả đúng như vậy: đặt role trong system prompt sẽ “tập trung hành vi và giọng điệu của Claude cho trường hợp sử dụng của bạn”.

Điều role không thay đổi một cách đáng tin cậy là độ chính xác về dữ kiện. Zheng và cộng sự (Findings of EMNLP 2024) đã thử 162 persona thuộc 6 loại quan hệ giữa người với người và 8 lĩnh vực chuyên môn, trên 4 họ mô hình và 2.410 câu hỏi dữ kiện. Việc thêm persona vào system prompt không cải thiện hiệu năng so với không có persona, và tác động của từng persona riêng lẻ “phần lớn là ngẫu nhiên”. Nói với mô hình rằng nó là bác sĩ đẳng cấp thế giới không cho nó kiến thức y khoa mà nó đang thiếu.

Vì vậy, hãy dùng role để điều khiển cách câu trả lời được viết, và dùng tài liệu nguồn, ví dụ và bước kiểm chứng để điều khiển việc nó có đúng hay không. Mẫu dưới đây minh họa điều đó: dữ kiện cố định, chỉ role thay đổi. Hãy thay {role} và {audience} bằng từng cặp trong bảng.

Bạn là {role}.
Viết một thông điệp về sự cố dưới đây cho {audience}. Giữ dưới 90 từ.

Dữ kiện (chỉ dùng những dữ kiện này):
- Payment API ngừng hoạt động ngày 14 tháng 10, từ 09:12 đến 10:03 UTC (51 phút).
- Nguyên nhân: chứng chỉ TLS trên payment gateway đã hết hạn.
- Khoảng 3% lượt thanh toán thất bại. Không mất dữ liệu và không thẻ nào bị trừ tiền hai lần.
- Cách khắc phục: đã gia hạn chứng chỉ; đã thêm cảnh báo hết hạn tự động.

Trưởng nhóm SRE, kênh kỹ thuật:

Sự cố: payment API, 14/10 09:12-10:03 UTC (51 phút).
Nguyên nhân gốc: chứng chỉ TLS trên payment gateway hết hạn; handshake thất bại và khoảng 3% lượt thanh toán báo lỗi.
Tác động: không mất dữ liệu, không trừ tiền hai lần.
Khắc phục: đã gia hạn chứng chỉ; đã có cảnh báo hết hạn tự động.

Quản lý hỗ trợ khách hàng, email gửi khách:

Tiêu đề: Sự cố thanh toán ngày 14 tháng 10, nay đã được khắc phục

Ngày 14 tháng 10, từ 09:12 đến 10:03 UTC, một số giao dịch thanh toán không thể hoàn tất. Dữ liệu của bạn vẫn an toàn và không có thẻ nào bị trừ tiền hai lần. Nếu thanh toán của bạn chưa thành công, vui lòng thử lại; hệ thống thanh toán hiện đã hoạt động bình thường. Chúng tôi đã khắc phục nguyên nhân và bổ sung cảnh báo để sự cố không lặp lại. Chúng tôi xin lỗi vì sự bất tiện này.

Trưởng bộ phận vận hành, bản tóm tắt cho ban điều hành:

Sự cố thanh toán kéo dài 51 phút ngày 14/10 (09:12-10:03 UTC), do chứng chỉ bảo mật hết hạn. Khoảng 3% lượt thanh toán thất bại; không mất dữ liệu, không trừ tiền hai lần. Đã xử lý xong ngay trong buổi sáng. Ngày hết hạn chứng chỉ nay được giám sát tự động, nên lỗi dạng này sẽ không còn xảy ra.

Cách viết role prompt hiệu quả

“Bạn là một chuyên gia marketing” là một role yếu: nó chỉ đặt ra giọng điệu mơ hồ và không gì khác. Một role hữu ích trả lời bốn câu hỏi: ai đang phát biểu, nói với ai, nhằm mục đích gì, và trong những giới hạn nào. Đối tượng và ràng buộc thường làm được nhiều việc hơn chức danh.

Role dưới đây được viết cho một trợ lý IT helpdesk. Hãy dán nó vào system prompt, hoặc vào custom instructions của ChatGPT, phần hướng dẫn của một Claude Project hay một Gemini Gem, để nó áp dụng cho mọi tin nhắn trong cuộc hội thoại.

Bạn là một kỹ sư IT helpdesk cấp cao tại một công ty 200 người.
Đối tượng: nhân viên không chuyên kỹ thuật và thường đang vội.
Mục tiêu: giúp họ làm việc lại được với số bước ít nhất có thể.
Ràng buộc:
- Đưa ra các bước đánh số, mỗi bước một thao tác, tối đa 6 bước.
- Dùng đúng tên nút và menu mà họ sẽ thấy trên màn hình.
- Nếu một bước cần quyền admin, ghi "Hãy nhờ bộ phận IT thực hiện bước này" thay vì giải thích.
- Nếu bạn không chắc họ dùng thiết bị hoặc phiên bản ứng dụng nào, hãy hỏi một câu ngắn trước.

Sau đó người dùng viết: “Từ sáng nay Outlook cứ liên tục hỏi mật khẩu của tôi.”

Hỏi nhanh một câu trước: bạn đang dùng Outlook trên máy tính Windows, trên Mac, hay trong trình duyệt web?

Sau khi người dùng trả lời “Windows”:

1. Đóng hoàn toàn Outlook.
2. Mở menu Start, gõ "Credential Manager" rồi mở nó.
3. Nhấp vào "Windows Credentials".
4. Tìm từng mục có chứa "MicrosoftOffice", nhấp vào mục đó và chọn "Remove".
5. Mở lại Outlook và đăng nhập bằng email và mật khẩu công việc của bạn.
6. Nếu vẫn bị hỏi liên tục, có thể mật khẩu của bạn đã hết hạn. Hãy nhờ bộ phận IT thực hiện bước này.

Mọi ràng buộc đều thể hiện trong hành vi: một câu hỏi làm rõ, sáu bước, đúng tên các nút và menu của Windows, và việc bàn giao cho quản trị viên ở bước cần quyền admin. Nếu bạn gọi mô hình qua API, role nằm trong tham số system. Ví dụ Python này dùng Anthropic SDK; mọi chat model có system prompt đều hoạt động theo cách tương tự.

# pip install anthropic   (and set the ANTHROPIC_API_KEY environment variable)
import anthropic

ROLE = """You are a senior IT helpdesk engineer at a 200-person company.
Audience: employees who are not technical and are often in a hurry.
Goal: get them working again in as few steps as possible.
Constraints:
- Give numbered steps, one action per step, at most 6 steps.
- Use the exact button and menu names they will see on screen.
- If a step needs admin rights, write "Ask IT to do this step" instead of explaining it.
- If you are not sure which device or app version they use, ask one short question first."""

client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=ROLE,  # the role applies to every turn of the conversation
    messages=[
        {"role": "user", "content": "Outlook keeps asking for my password since this morning."}
    ],
)
# Text blocks only: newer models may return a thinking block first.
print("".join(b.text for b in message.content if b.type == "text"))

Kết hợp role và instruction trong một prompt

Hầu hết prompt thực tế dùng cả hai: role định giọng điệu, instruction định nhiệm vụ và hình thức kết quả. Template dưới đây tách chúng thành các khối riêng có nhãn để bạn đổi khối này mà không làm hỏng khối kia. Hãy điền vào mọi {placeholder}.

# Vai trò
Bạn là {người đang phát biểu}, viết cho {đối tượng}.

# Nhiệm vụ
{Động từ hành động} {nội dung}, để {mục đích}.

# Quy tắc
1. {Một ràng buộc đo lường được, ví dụ "Dưới 120 từ"}
2. {Điều cần làm thay cho điều cần tránh}
3. Nếu {một trường hợp biên}, {cách xử lý thay vì đoán}.

# Đầu vào
"""
{văn bản, dữ liệu hoặc code của bạn}
"""

Đây là template đã điền cho một bản giải thích code review. Role đặt giọng hướng dẫn; các quy tắc giữ câu trả lời tập trung vào một thay đổi.

# Vai trò
Bạn là một kỹ sư backend cấp cao đang kèm cặp một lập trình viên mới vào nghề.

# Nhiệm vụ
Giải thích câu truy vấn MySQL 8 này làm gì và một thay đổi duy nhất giúp cải thiện hiệu năng nhiều nhất, để lập trình viên hiểu nguyên lý chứ không chỉ biết cách sửa.

# Quy tắc
1. Dưới 150 từ.
2. Hiển thị phần truy vấn đã viết lại.
3. Nếu có nhiều hơn một thay đổi quan trọng, nhắc đến thay đổi thứ hai trong một dòng "Tiếp theo nên học:".

# Đầu vào
"""
SELECT *
FROM orders
WHERE YEAR(created_at) = 2025
  AND status = 'paid'
ORDER BY created_at DESC;
"""

Câu truy vấn làm gì: trả về mọi đơn hàng đã thanh toán được tạo trong năm 2025, mới nhất trước, với tất cả các cột.

Thay đổi duy nhất: viết lại bộ lọc ngày thành một khoảng.

WHERE created_at >= '2025-01-01'
  AND created_at <  '2026-01-01'
  AND status = 'paid'

Lý do: bọc created_at trong YEAR() khiến MySQL phải tính hàm đó trên từng dòng, nên không dùng được index trên created_at. Một khoảng đơn giản trên chính cột đó có thể dùng index và chỉ đọc các dòng của năm 2025. Với bảng orders lớn, đó thường là khác biệt giữa quét toàn bộ bảng và quét theo khoảng index.

Tiếp theo nên học: chỉ chọn những cột bạn cần thay vì SELECT *.

Khi chỉ dùng instruction thì không mô tả được định dạng bạn cần, hãy thêm ví dụ thay vì thêm lời. Đó là nội dung của Phần 5: Zero-shot, one-shot và few-shot prompting. Để role và quy tắc luôn có hiệu lực xuyên suốt một cuộc hội thoại dài, xem Phần 6: Kết hợp kỹ thuật, priming và vòng lặp cải tiến.

Những lỗi thường gặp với instruction và role

Câu hỏi thường gặp

Instruction prompting và role prompting khác nhau thế nào?

Instruction prompting cho mô hình biết cần làm gì: nhiệm vụ, định dạng và ràng buộc. Role prompting cho nó biết ai đang phát biểu và nói với ai, chủ yếu thay đổi giọng điệu, từ vựng và độ sâu. Hầu hết prompt tốt dùng kết hợp một role ngắn với một instruction chính xác.

“Bạn là một chuyên gia” có làm câu trả lời của AI chính xác hơn không?

Không một cách đáng tin cậy. Một nghiên cứu với 162 persona trên 2.410 câu hỏi dữ kiện không thấy cải thiện nào so với prompt không có persona. Role hữu ích cho văn phong và sự tập trung; độ chính xác đến từ tài liệu nguồn tốt, instruction rõ ràng và việc kiểm tra đầu ra.

Nên đặt role trong system prompt hay trong tin nhắn của người dùng?

Role bạn muốn áp dụng cho cả cuộc hội thoại nên đặt trong system prompt, hoặc trong custom instructions hay phần cài đặt project của chatbot. Instruction riêng cho từng nhiệm vụ nên đặt trong tin nhắn của người dùng, nơi bạn có thể chỉnh theo từng lượt.

Một instruction nên dài bao nhiêu?

Đủ dài để loại bỏ sự phỏng đoán, và không hơn. Với việc đơn giản, một yêu cầu một dòng là ổn; một workflow dùng lại nhiều lần có thể cần mười quy tắc đánh số. Nếu xóa một quy tắc mà đầu ra không đổi, hãy xóa nó.

Nguồn và tài liệu đọc thêm

• Learn Prompting: Instructions in Prompts
• Learn Prompting: Roles in Prompts
• Learn Prompting: Tips for Writing Better Prompts
• Wei et al. (2021), Finetuned Language Models Are Zero-Shot Learners (FLAN)
• Ouyang et al. (2022), Training language models to follow instructions with human feedback
• Zheng et al. (2024), When “A Helpful Assistant” Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models
• Anthropic: Prompting best practices
• Microsoft Presidio: PII detection and anonymization

Hướng dẫn Prompt Engineering: tất cả các phần

← Trước: Phần 3: Cấu trúc prompt: năm thành phần của một prompt · Tiếp theo: Phần 5: Zero-shot, one-shot và few-shot prompting →

Hãy đọc Phần 1–6 theo thứ tự: mỗi phần dựa trên phần trước. Phần 7–10 là các ứng dụng và có thể đọc theo bất kỳ thứ tự nào khi bạn đã nắm vững kiến thức nền.

• Phần 1: Prompt engineering là gì và vì sao quan trọng
• Phần 2: LLM hoạt động thế nào: kiến thức nền về generative AI
• Phần 3: Cấu trúc prompt: năm thành phần của một prompt
• Phần 4: Instruction và role prompting (bạn đang ở đây)
• Phần 5: Zero-shot, one-shot và few-shot prompting
• Phần 6: Kết hợp kỹ thuật, priming và vòng lặp cải tiến
• Phần 7: Prompt cho tóm tắt, bảng biểu và phân tích tài liệu
• Phần 8: Prompt cho email, bài blog và marketing
• Phần 9: Prompt cho trợ lý lập trình
• Phần 10: Xây dựng chatbot cơ sở tri thức (RAG)