Bài #5: Prompt, context window và system/developer/user message trong LLM


Ở bài trước, ta biết LLM tạo câu trả lời bằng cách dự đoán token tiếp theo dựa trên ngữ cảnh đang có. Bài này trả lời câu hỏi thực tế hơn: ngữ cảnh đó gồm những gì? Vì sao cùng một mô hình, cùng một câu hỏi, nhưng khi đổi cách viết prompt thì câu trả lời có thể hay hơn, ngắn hơn, đúng format hơn hoặc bớt lan man hơn?
Nếu xem LLM như một người trợ lý đang đọc tài liệu trước khi trả lời, thì prompt của bạn chỉ là một tờ giấy trong xấp tài liệu đó. Hướng dẫn nền, quy tắc ứng dụng, lịch sử hội thoại, tài liệu đính kèm và những token mô hình vừa tạo cũng có thể nằm trong context.
Sau bài này, bạn cần nắm được: prompt là gì; context window là gì; vì sao lịch sử hội thoại ảnh hưởng đến câu trả lời; system, developer và user message khác nhau ra sao; và cách viết prompt rõ hơn.
Prompt là nội dung bạn đưa cho mô hình để yêu cầu nó làm việc. Prompt có thể rất ngắn, như “giải thích AI là gì”, hoặc rất chi tiết, gồm mục tiêu, đối tượng đọc, dữ liệu tham khảo, định dạng đầu ra và những điều không được làm. Nói đơn giản, prompt là bản mô tả công việc.
Một prompt yếu thường chỉ nêu việc cần làm nhưng thiếu ngữ cảnh. Ví dụ: “viết bài về ôn tập”. Prompt tốt hơn sẽ là: “Viết đoạn 250 chữ cho học sinh lớp 8 về cách ôn tập trước kiểm tra Toán, dùng 3 bước, có ví dụ lịch học trong 3 ngày, giọng văn dễ hiểu.”
Context window là vùng thông tin mô hình có thể nhìn thấy trong một lượt xử lý. Nó giống như bàn làm việc trước mặt người học: trên bàn có đề bài, sách tham khảo, ghi chú cũ và yêu cầu của giáo viên. Người học chỉ có thể dựa vào những gì đang nằm trên bàn, cộng với kiến thức đã học từ trước.
Với LLM, context có thể gồm câu hỏi hiện tại, các tin nhắn trước đó, tài liệu bạn dán vào, kết quả tìm kiếm, nội dung file, hướng dẫn của ứng dụng và phần trả lời đang được tạo. Nếu thông tin quan trọng không nằm trong context, mô hình có thể không dùng được thông tin đó. Vì vậy, khi hỏi về một đoạn văn hoặc một đề bài, hãy đưa trực tiếp phần liên quan vào prompt.
Context window có giới hạn. Khi cuộc trò chuyện quá dài hoặc tài liệu quá nhiều, hệ thống phải chọn phần nào giữ lại, phần nào tóm tắt, phần nào bỏ ra ngoài. Vì vậy LLM đôi khi “quên” chi tiết cũ.
Trong nhiều hệ thống LLM, nội dung gửi vào mô hình được chia thành các loại message để phân biệt mức ưu tiên. Tên gọi cụ thể có thể khác nhau theo nền tảng, nhưng ý tưởng chung là: không phải mọi câu trong context đều có quyền ngang nhau.
System message thường dùng cho chỉ dẫn nền có mức ưu tiên cao: vai trò tổng quát, ranh giới an toàn, nguyên tắc không được vi phạm. Ví dụ: “Trợ lý phải trả lời bằng tiếng Việt, không tiết lộ thông tin bí mật.”
Developer message thường là luật của ứng dụng hoặc sản phẩm. Một app học tập có thể đặt: “Giải thích theo trình độ học sinh lớp 7, chia lời giải thành từng bước.” Lớp này giúp nhiều người dùng khác nhau vẫn nhận trải nghiệm nhất quán.
User message là yêu cầu cụ thể của người dùng ở lượt hiện tại: “Giải thích bài này”, “Tóm tắt đoạn văn”, “Viết email”, “Chỉ ra lỗi sai”. User message rất quan trọng, nhưng nếu nó mâu thuẫn với system hoặc developer message, hệ thống thường phải ưu tiên lớp chỉ dẫn cao hơn.
Hãy tưởng tượng một lớp học có ba tầng hướng dẫn. Nhà trường quy định: “Không gian lận, đảm bảo an toàn.” Đó giống system message. Giáo viên môn Toán quy định: “Khi chữa bài, phải trình bày từng bước.” Đó giống developer message. Học sinh hỏi: “Cô giải giúp em câu 3.” Đó là user message.
Nếu học sinh hỏi “chỉ đưa đáp án thôi để em chép nhanh”, giáo viên vẫn phải theo quy định của lớp. LLM trong ứng dụng tốt cũng tương tự: nghe yêu cầu người dùng, nhưng vẫn giữ các luật quan trọng hơn.
Giả sử một ứng dụng học tiếng Anh gửi vào mô hình các phần sau:
System: Không tiết lộ dữ liệu riêng tư. Trả lời bằng tiếng Việt.
Developer: Bạn là trợ lý luyện tiếng Anh cho học sinh THCS. Luôn đưa ví dụ ngắn.
User: Giải thích sự khác nhau giữa "borrow" và "lend".
Khi mô hình trả lời, nó không chỉ nhìn câu hỏi “borrow và lend khác nhau thế nào”. Nó cũng nhìn thấy yêu cầu phải trả lời bằng tiếng Việt, phù hợp học sinh THCS và có ví dụ ngắn. Nếu user tiếp tục hỏi “trả lời bằng tiếng Anh thật khó”, mô hình vẫn có lý do để giữ tiếng Việt nếu system message đã quy định như vậy.
Bạn có thể dùng công thức 5 phần: mục tiêu, đối tượng, dữ liệu, định dạng và ràng buộc. Ví dụ: “Hãy giải thích context window cho người mới học AI. Dùng ví dụ bàn học. Viết khoảng 200 chữ. Chia thành 3 ý. Không dùng thuật ngữ tiếng Anh nếu không giải thích.” Công thức này giúp mô hình giảm phỏng đoán và tạo câu trả lời dễ dùng hơn.
Hiểu nhầm 1: Prompt càng dài càng tốt. Prompt dài nhưng lộn xộn có thể làm mô hình khó xác định ý chính. Prompt tốt là prompt đủ thông tin, có thứ tự rõ.
Hiểu nhầm 2: LLM nhớ mọi thứ trong cuộc trò chuyện. LLM chỉ dùng những gì còn nằm trong context window hoặc được hệ thống đưa lại vào lượt hiện tại. Với việc quan trọng, hãy nhắc lại dữ kiện chính.
Hiểu nhầm 3: User prompt luôn thắng. Trong hệ thống được thiết kế đúng, user prompt phải nằm dưới ranh giới an toàn và luật ứng dụng, nhất là khi có dữ liệu nhạy cảm.
Hãy lấy yêu cầu “Tóm tắt bài quang hợp.” Viết lại thành prompt đủ 5 phần: mục tiêu, đối tượng, dữ liệu, định dạng, ràng buộc. Sau đó thêm câu “giải thích cho học sinh lớp 6” và quan sát cách câu trả lời thay đổi.
Prompt là yêu cầu hoặc dữ liệu bạn đưa cho LLM. Context window là vùng thông tin mô hình nhìn thấy trong một lượt trả lời. System, developer và user message là các lớp chỉ dẫn có mức ưu tiên khác nhau: system đặt ranh giới nền, developer đặt luật ứng dụng, user đưa yêu cầu cụ thể. Muốn dùng LLM tốt, hãy viết prompt rõ mục tiêu, đủ dữ liệu, đúng định dạng và nhớ rằng câu trả lời phụ thuộc vào toàn bộ context.