Tweet
TÌM HIỂU VỀ PROMPT ENGINEERING THEO KHUNG RGICO-T
Tóm tắt. Báo cáo này trình bày một khung làm việc tối giản cho Prompt Engineering mang tên RGICO-T, gồm sáu thành phần: Role (vai trò), Goal (mục tiêu), Input (dữ liệu vào), Constraints (ràng buộc), Output (định dạng đầu ra) và Technique (kỹ thuật thực hiện). Mục tiêu là giúp người học viết prompt ngắn gọn nhưng nhất quán, dễ chấm và dễ tái lập. Em minh họa cách áp dụng khung vào một tác vụ gần với thực tế: tạo checklist công việc để nhập Trello. Qua các thử nghiệm nhỏ, việc làm rõ mục tiêu thành một câu đo được, dùng delimiter bao dữ liệu đầu vào, và cố định định dạng đầu ra bằng bảng hoặc JSON giúp giảm lỗi định dạng và hạn chế suy đoán ngoài nguồn.
1. Giới thiệu.
Sự mạnh mẽ của các mô hình ngôn ngữ lớn đi kèm độ nhạy cao với cách đặt câu hỏi. Người mới thường bắt đầu bằng các mẹo rời rạc, dẫn tới kết quả thiếu ổn định. Hôm nay ta cùng tìm hiểu prompt engineering, chọn hướng tiếp cận cấu trúc hóa: thay vì “viết hay”, hãy “viết có khung”. Trong phạm vi báo cáo, ta tìm hiểu một khung dễ nhớ RGICO-T.
2. Khung RGICO-T
Role giúp “khóa” lăng kính trả lời của mô hình: ai đang nói, nói theo phong cách nào và ở mức chi tiết nào. Hãy chỉ định vai trò cụ thể (biên tập viên kỹ thuật, PM Agile, kiểm toán viên…), đặt giọng điệu (trung tính, hướng dẫn, thuyết phục) và nêu thứ tự ưu tiên (độ chính xác > ngắn gọn > sáng tạo…). Điều này giảm sai lệch ngữ điệu và nội dung. Mẫu gợi ý: “Bạn là biên tập viên kỹ thuật; giọng điệu trung tính; mức chi tiết nâng cao; ưu tiên độ chính xác rồi mới đến ngắn gọn.”
Goal phải gọn 1 câu và có thước đo rõ ràng để chấm: số mục, giới hạn từ/ký tự, định dạng, yêu cầu có/không trích dẫn. Tránh “làm mọi thứ”; nếu có nhiều đích, tách thành nhiều yêu cầu. Ví dụ tốt: “Tóm tắt thành đúng 5 gạch đầu dòng, tổng ≤120 từ, chỉ dùng thông tin trong Input.” hoặc “Sinh 8 nhiệm vụ, mỗi nhiệm vụ có Owner và ETA định dạng dd/mm.” Goal càng cụ thể, xác suất mô hình lệch yêu cầu càng thấp.
Input quy định mô hình được phép dựa vào nguồn nào. Luôn bao dữ liệu giữa dấu phân cách rõ ràng để tạo “hàng rào tri thức”: <<<INPUT>>> … <<<END>>>. Nói thẳng quy tắc: “Chỉ dùng thông tin trong Input; nếu thiếu, ghi ‘không đủ dữ liệu’.” Khi có nhiều nguồn, đặt nhãn (<<<DOC>>>, <<<TABLE>>>…) để mô hình tham chiếu chính xác. Cách này giảm “bịa” và giúp bạn tái lập kết quả khi thay dữ liệu.
Constraints là tập luật vận hành: ngôn ngữ (vi/en), giới hạn độ dài, phong cách, định dạng ngày (dd/mm), đơn vị (SI), múi giờ (Asia/Ho_Chi_Minh), và quy tắc trung thực. Gợi ý quy tắc trung thực: “không bịa; thiếu dữ liệu thì nêu rõ; nếu phải suy luận, đánh dấu ‘(giả định)’.” Với nhiệm vụ có rủi ro format, bổ sung: “không thêm văn bản ngoài khuôn đầu ra”, “không chèn giải thích.”
Output phải có khuôn cụ thể để máy/ người dễ chấm: bullet cố định số dòng; bảng Markdown với tên và thứ tự cột; hoặc JSON “chỉ trả JSON hợp lệ”, kèm pattern nếu cần (ví dụ regex cho dd/mm). Technique là “cách làm” thật ngắn để ổn định hành vi: “1) hiểu yêu cầu 2) trích thông tin bắt buộc 3) xuất đầu ra đúng khuôn.” Khi nhiệm vụ nhạy định dạng, thêm 1 ví dụ mẫu ngắn (few-shot) trước Input. Sự kết hợp Output rõ + Technique ngắn giúp giảm vỡ format và tăng tỷ lệ đáp trúng Goal.
3. Ví dụ – Tạo checklist công việc để nhập Trello
Để rõ ràng hơn thì ta sẽ lấy một ví dụ tạo check list công việc để nhập trên Trello. Ta áp dụng kĩ thuật prompt trên theo công thức
| [Role] Bạn là PM tạo checklist hành động. [Goal] Sinh 8 đầu việc hành động từ mô tả dự án. [Input] Chỉ dùng thông tin giữa <<<INPUT>>> và <<<END>>>. <<<INPUT>>> {Mô tả dự án 5–10 dòng: mục tiêu, người phụ trách, mốc thời gian} <<<END>>> [Constraints] - Mỗi task bắt đầu bằng động từ; phải có Owner & ETA (dd/mm) - Nếu thiếu Owner/ETA trong Input, suy luận hợp lý và đánh dấu "(giả định)" [Output] Bảng Markdown 3 cột: Task | Owner | ETA [Technique] 1) Tách mục tiêu/đầu việc 2) Gán Owner/ETA 3) Xuất bảng. |
Nhận xét
- Format bảng đúng, số mục đủ, rõ vai trò & ngày; chỗ suy luận được đánh dấu (giả định) để minh bạch.
Khung RGICO-T giúp người mới tiếp cận Prompt Engineering theo lối “kỹ thuật hóa” thay vì cảm tính. Trong thực hành, chỉ cần vài phút để biến yêu cầu mơ hồ thành prompt có cấu trúc với mục tiêu rõ, dữ liệu ràng buộc và đầu ra kiểm soát được. Để nâng cao hơn, tôi kiến nghị bổ sung một “bộ kiểm thử nhanh” 10–20 mẫu cho mỗi tác vụ để đo tỷ lệ tuân thủ định dạng và mức đạt mục tiêu; song song, có thể mở rộng dần sang structured output bằng JSON và áp dụng few-shot tối thiểu cho các quy ước định dạng khó. Về dài hạn, người viết nên lưu phiên bản prompt, ghi lại siêu tham số suy luận, và duy trì một checklist nhỏ trước khi triển khai: mục tiêu đã đo được chưa; dữ liệu đã được bao bằng delimiter chưa; ràng buộc và khuôn đầu ra đã đủ cụ thể chưa; và cuối cùng, có cơ chế gắn nhãn “giả định” khi buộc phải suy luận hay không. Với những thói quen này, chất lượng phản hồi sẽ ổn định, chi phí hiệu chỉnh giảm, và việc cộng tác/đánh giá sẽ trở nên dễ dàng hơn.