System prompt là gì và vì sao nó quyết định hành vi của LLM?

System prompt là bề mặt kiểm soát (control surface) cho phép kỹ sư thiết lập ngữ cảnh, định dạng đầu ra và các rào chắn bảo mật (guardrails) của một mô hình ngôn ngữ lớn (LLM) trước khi người dùng nhập câu lệnh đầu tiên

— và nó giữ hiệu lực xuyên suốt phiên làm việc, kể cả khi người dùng yêu cầu điều ngược lại.

Đây không phải một lời mào đầu, mà là khung xương kỹ thuật quy định cách mô hình xử lý thông tin xuyên suốt toàn bộ cửa sổ ngữ cảnh. Thiếu một system prompt được thiết kế tốt, bạn sẽ phải sống chung với hành vi không xác định (non-deterministic behavior) của mô hình trong môi trường production.

Hiểu đơn giản, bạn đang thiết lập một "hệ điều hành" thu nhỏ cho phiên làm việc của AI. Nếu không có lớp điều khiển này, mô hình sẽ hoàn toàn phụ thuộc vào user prompt, vốn thường lỏng lẻo và dễ bị thao túng. System prompt cung cấp khả năng duy trì kỷ luật cho mô hình, đảm bảo nó không đi chệch khỏi mục tiêu nghiệp vụ ngay cả khi đối mặt với các yêu cầu gây nhiễu hoặc tấn công nghịch thế từ phía người dùng cuối.

Sơ đồ khái niệm system prompt như một lớp chỉ dẫn đặc quyền nằm bên trên mọi lượt hội thoại giữa người dùng và mô hình ngôn ngữ

System prompt là gì và khác gì prompt của người dùng?

Khái niệm đặc quyền. Trong kiến trúc hệ thống LLM hiện đại, system prompt được coi là một cơ chế phân quyền (privilege). Nó nằm ở tầng cao nhất của cấu trúc chỉ dẫn, giám sát toàn bộ cửa sổ ngữ cảnh và chiếm quyền ưu tiên (precedence) so với các tầng thấp hơn. Khi có xung đột chỉ dẫn, mô hình được thiết kế để tuân thủ lớp đặc quyền này thay vì các lệnh từ tầng dưới.

Sơ đồ so sánh lớp chỉ dẫn hệ thống bền vững suốt cả phiên làm việc với các lượt hỏi nhất thời của người dùng

Cơ chế học tập. Bạn cần lưu ý rằng ưu tiên system prompt không phải là kết quả của việc lập trình cứng (hard-coding) mà là sản phẩm của quá trình học có giám sát (Supervised Fine-tuning, SFT) và tối ưu hóa theo sở thích (Preference Optimization, DPO/RLHF). Qua các giai đoạn này, mô hình "học" được rằng các token nằm trong định danh hệ thống có trọng số ảnh hưởng lớn hơn đến xác suất dự đoán token tiếp theo so với user prompt.

Sự khác biệt về phạm vi. User prompt mang tính nhất thời và cục bộ cho từng lượt hội thoại. Ngược lại, system prompt là "luật chơi" của cả phiên làm việc. Ví dụ, nếu bạn đặt quy tắc "luôn trả lời bằng tiếng Anh" trong system prompt, quy tắc này sẽ ghi đè yêu cầu "dịch sang tiếng Pháp" của người dùng. Mô hình sẽ ưu tiên kỷ luật ngôn ngữ đã đặt ra thay vì thực hiện nhiệm vụ dịch thuật nếu hai lệnh loại trừ lẫn nhau.

Bốn việc một system prompt phải làm

Việc thiết lập system prompt trong thực tế đòi hỏi sự chính xác kỹ thuật hơn là văn phong hoa mỹ. Bạn phải thực hiện được bốn nhiệm vụ cốt lõi sau.

Sơ đồ bốn nhiệm vụ của một system prompt: đặt vai trò, ràng buộc hành vi, định dạng đầu ra và rào chắn an toàn

Thiết lập danh tính (Persona) là bước đầu tiên để định hình phương thức xử lý vấn đề. Thay vì để mô hình tự do, bạn ép nó vào một vai trò cụ thể, chẳng hạn kỹ sư hệ thống thực dụng hoặc chuyên gia phân tích dữ liệu. Việc này vừa tạo phong cách, vừa giúp mô hình thu hẹp không gian câu trả lời để tập trung vào các tập dữ liệu liên quan đến vai trò đó.

Áp đặt ràng buộc hành vi (Constraints) tạo ra các quy tắc kiểm chứng được đúng/sai bằng tiêu chí khách quan. Ví dụ, bạn có thể cấm mô hình thảo luận về chính trị hoặc sử dụng các từ khóa cấm trong lĩnh vực tài chính. Đây là lớp lọc hành vi giúp giảm thiểu rủi ro pháp lý và đảm bảo mô hình đi đúng luồng nghiệp vụ. Điểm mấu chốt là một guardrail phải kiểm chứng được: "hãy hữu ích" là mong muốn, còn "chỉ trả lời bằng tiếng Việt" mới là ràng buộc. Cách viết từng loại ràng buộc cho chặt là một chủ đề riêng, xem constraining prompt.

Định dạng đầu ra (Output Formatting) là yếu tố sống còn khi tích hợp LLM vào hệ thống backend. Bạn phải chỉ dẫn mô hình cách ép dữ liệu vào các thẻ XML, cấu trúc JSON hoặc Markdown. Việc này giúp các parser tự động bóc tách dữ liệu mà không bị nhiễu bởi những đoạn văn bản giải thích thừa từ phía trợ lý.

Thiết lập rào chắn an toàn (Safety Guardrails) là nhiệm vụ nặng ký nhất. Kỹ sư phải tích hợp các hướng dẫn ngăn chặn việc tạo ra mã độc hoặc hỗ trợ chế tạo vũ khí hóa học, sinh học, phóng xạ và hạt nhân (CBRN). Một system prompt mạnh sẽ từ chối cung cấp bất kỳ hỗ trợ có ý nghĩa (uplift) nào cho việc chế tạo vũ khí, bất kể người dùng ngụy trang yêu cầu dưới dạng kịch bản giả tưởng hay nghiên cứu học thuật.

Thang bậc thẩm quyền: root, system, developer, user

Kiến trúc chỉ dẫn hiện nay phân cấp thẩm quyền thành năm tầng rõ rệt để giải quyết xung đột logic. Tầng Root là tầng gốc của nhà phát hành, chứa các quy tắc an toàn cốt lõi không thể ghi đè bằng bất kỳ thông điệp nào. Tiếp theo là tầng System (do nhà phát hành đặt qua system message), tầng Developer (kỹ sư xây dựng ứng dụng qua API), tầng User (người dùng cuối) và cuối cùng là Guideline, tức các mặc định mềm mà người dùng hoặc lập trình viên đều có thể ghi đè.

Sơ đồ thang bậc thẩm quyền năm tầng xếp chồng từ trên xuống: root, system, developer, user và guideline, tầng trên ghi đè tầng dưới

Logic xử lý xung đột dựa trên trọng số ưu tiên: tầng trên luôn ghi đè tầng dưới. Nếu người dùng cố tình đưa ra lệnh "Ignore previous instructions", mô hình sẽ đối chiếu với tầng System và Developer, nhận diện yêu cầu đó là một nỗ lực vi phạm đặc quyền, và giữ vững kỷ luật từ tầng cao hơn. Một chỉ dẫn bị coi là lệch chuẩn khi nó mâu thuẫn với câu chữ hoặc với ý định đằng sau một chỉ dẫn ở tầng cao hơn.

Đối với các hệ thống có sử dụng công cụ, dữ liệu trả về từ công cụ (tool output) mặc định được coi là không có thẩm quyền. Đây là biện pháp phòng vệ quan trọng trước các cuộc tấn công gián tiếp: nếu một kết quả tìm kiếm web chứa lệnh điều khiển ẩn, hệ thống sẽ giữ đúng kỷ luật đã đặt trong system prompt thay vì thi hành dữ liệu ngoại lai đó. Thẩm quyền chỉ được trao cho nội dung ngoại lai khi tầng trên chủ động ủy quyền.

Về mặt kỹ thuật, việc phân lớp này nhằm tách biệt dữ liệu (data) và lệnh điều khiển (control). Cấu trúc phân tầng giúp mô hình phân biệt đâu là "luật" phải tuân theo và đâu là "thông tin" cần xử lý, từ đó giảm rủi ro từ các kỹ thuật thao túng ngôn ngữ.

Bên trong một system prompt đang chạy production

Trong môi trường thực tế, một system prompt không phải là văn bản sạch sẽ được viết mới hoàn toàn. Nó thường là một tập hợp các bản vá (patchwork) đầy nợ kỹ thuật. Một phân tích công bố tháng 7/2025 trên hai thế hệ Claude 3.7 và Claude 4.0 cho thấy các prompt trong production tích lũy dần những đoạn lệnh nhỏ nhằm xử lý các lỗi hành vi cụ thể phát sinh khi vận hành, và khi thế hệ mô hình kế tiếp được huấn luyện để tự tránh lỗi đó, đoạn lệnh vá lại được gỡ ra.

Cấu trúc thực tế thường dùng các thẻ XML để phân đoạn, giúp mô hình không bị nhầm lẫn khi ngữ cảnh quá dài. Thẻ <claude_behavior> dùng để định nghĩa hành vi tổng quát, <refusal_handling> chứa logic từ chối, còn <tone_and_formatting> quy định giọng văn và cách trình bày:

xml

<tone_and_formatting>
Claude keeps responses focused, brief, and concise to avoid overwhelming the person.
Claude uses lists and bullet points when asked to or when the content is multifaceted
enough that they help with clarity.
Claude avoids saying "genuinely", "honestly", or "straightforward".
</tone_and_formatting>

Một cơ chế phức tạp hơn là safeguards routing (tự động chuyển yêu cầu rủi ro sang một mô hình khác). Khi một yêu cầu gửi đến Claude Fable 5 chạm ngưỡng rủi ro trong lĩnh vực an ninh mạng hoặc sinh học, hệ thống sẽ tự động điều hướng sang Claude Opus 5. Các rào chắn này được đặt bảo thủ và trung bình kích hoạt trong dưới 5% số phiên làm việc, tức là chấp nhận một tỷ lệ báo động giả nhất định để đổi lấy độ an toàn.

System prompt cũng là nơi khai báo giới hạn thời gian của mô hình. Nó nêu rõ mốc cắt tri thức và hướng dẫn mô hình cách xử lý câu hỏi về những sự kiện nằm sau mốc đó, thường bằng cách nói thẳng là mình không chắc và đề nghị tìm kiếm. Chi phí của tất cả những thứ này là có thật: mọi ký tự trong system prompt đều chiếm chỗ trong cùng một cửa sổ ngữ cảnh mà cuộc hội thoại phải chia nhau.

Ràng buộc định dạng đầu ra: prompt hay schema?

Việc ép mô hình trả về định dạng mong muốn có hai cách tiếp cận chính. Cách truyền thống là mô tả bằng lời văn trong system prompt, yêu cầu mô hình dùng JSON hoặc XML. Tuy nhiên, cách này vẫn có rủi ro mô hình thêm thắt các đoạn hội thoại thừa ("Dưới đây là kết quả...") làm hỏng hệ thống tự động hóa phía sau.

Sơ đồ so sánh hai cách ép định dạng đầu ra: mô tả bằng lời trong prompt không có bảo đảm, so với ép schema ở tầng API luôn khớp cấu trúc

Hướng đi hiện nay là dùng Structured Outputs (ép đầu ra khớp một schema khai báo sẵn) với JSON Schema qua API. Cách này đảm bảo phản hồi luôn khớp schema bạn cung cấp, nên bạn không còn phải lo mô hình bỏ sót một khóa bắt buộc hay bịa ra một giá trị enum không hợp lệ. Nói cách khác, bạn đổi những câu lệnh nhấn mạnh trong prompt lấy một bảo đảm ở tầng API, và bỏ luôn được bước kiểm tra rồi thử lại khi định dạng sai.

Một kỹ thuật bổ trợ từng rất phổ biến là prefilling, tức điền trước phần đầu câu trả lời của trợ lý, chẳng hạn một dấu { để ép mô hình viết tiếp JSON. Từ Claude 4.6 trở đi, prefilling không còn được hỗ trợ. Thay vào đó, bạn dùng Structured Outputs trên các mô hình có hỗ trợ, hoặc quay lại chỉ dẫn trực tiếp trong system prompt kèm ví dụ mẫu.

Lựa chọn giữa prompt và schema phụ thuộc vào mục tiêu. Schema xử lý tính toàn vẹn của dữ liệu; nó không diễn đạt được giọng văn hay sắc thái. Vì vậy cách dùng đúng thường là kết hợp: schema cho cấu trúc, và lời văn trong system prompt cho những gì schema không mô tả nổi.

Vì sao system prompt không phải là biên giới bảo mật

System prompt tuyệt đối không được coi là lớp bảo mật duy nhất. Rủi ro tiêm lệnh (prompt injection: chèn chỉ dẫn lạ vào phần đầu vào để mô hình hiểu nhầm đó là lệnh của bạn) luôn hiện hữu dưới hai hình thức: trực tiếp (người dùng cố tình chèn lệnh) và gián tiếp (dữ liệu độc hại từ nguồn ngoài như RAG hoặc web search). Lỗ hổng cố hữu nằm ở chỗ mô hình không thể phân tách hoàn toàn giữa chỉ dẫn và dữ liệu, vì cả hai đều đến dưới cùng một định dạng.

Sơ đồ hai đường tấn công chèn lệnh trực tiếp và gián tiếp, cùng các lớp phòng thủ chiều sâu bao quanh system prompt

Bẻ khóa (jailbreaking) là dạng tấn công nghịch thế phức tạp hơn, nơi kẻ tấn công ép mô hình bỏ qua quy tắc an toàn. Dù bạn viết system prompt chặt chẽ đến đâu, bản chất của LLM vẫn là dự đoán ngôn ngữ, và các chuỗi token được thiết kế khéo léo vẫn có thể vượt qua bộ lọc từ chối.

Ngay cả khi bạn dùng RAG để cung cấp ngữ cảnh tin cậy hay tinh chỉnh mô hình, các lỗ hổng injection vẫn tồn tại. Kẻ tấn công có thể chèn lệnh ẩn vào tài liệu RAG để chiếm quyền điều khiển trợ lý ngay khi nó truy xuất dữ liệu đó. Không tồn tại một biện pháp phòng ngừa tuyệt đối, vì đây là hệ quả của chính cách AI tạo sinh vận hành.

Do đó, kỹ sư hệ thống phải áp dụng chiến lược phòng thủ chiều sâu (defense-in-depth). System prompt chỉ là một lớp lọc hành vi; bảo mật thực sự nằm ở việc tách bạch và đánh dấu rõ nội dung không tin cậy, kiểm soát input/output, cấp quyền tối thiểu cho từng công cụ, bắt buộc con người phê duyệt các hành động rủi ro cao, và kiểm thử đối kháng định kỳ.

Mô hình tuân thủ được bao nhiêu ràng buộc?

Có một trần trên số ràng buộc mà mô hình thực sự giữ được, và nó thấp hơn bạn tưởng. Trong một bài kiểm tra áp lực mang tên "Monkey Island", tỷ lệ tuân thủ của các mô hình giảm dần về gần 0 khi số lượng guardrails tăng từ 1 lên 20. Nhồi nhét quá nhiều quy tắc vào system prompt sẽ làm quá tải khả năng theo dõi của mô hình, dẫn đến việc nó lờ đi chính những chỉ dẫn quan trọng nhất.

Biểu đồ đường đi xuống cho thấy mức tuân thủ của mô hình giảm dần về gần 0 khi số ràng buộc tăng từ 1 lên 20, với mốc trung bình thực tế khoảng 5 ràng buộc

Đối chiếu con số đó với thực tế: các system prompt ngoài đời trung bình chỉ chứa khoảng 5,1 guardrails. Ngay ở mức đó, các mô hình vẫn thất bại trong những tình huống hoàn toàn không có tính đối kháng, nghĩa là chúng quên xét một guardrail có liên quan, hoặc không giải quyết được hai yêu cầu mâu thuẫn nhau. Theo tôi, đây là con số đáng để dán lên tường: khoảng cách giữa 5 và 20 hẹp hơn nhiều so với những gì một bản system prompt dài vài nghìn chữ ngầm hứa hẹn.

Có sự khác biệt rõ giữa các dòng mô hình. Các mô hình lý giải (reasoning models) như o3-mini duy trì độ bền cao hơn đáng kể so với mô hình tiêu chuẩn khi bị dồn nhiều ràng buộc cùng lúc, đặc biệt với ngữ cảnh dài và prompt phức tạp. Chúng có ưu thế trong việc truy xuất thông tin nằm sớm trong ngữ cảnh và bỏ qua các yếu tố gây nhiễu.

Dù vậy, kết quả vẫn không đồng nhất giữa các bộ benchmark, và kết luận chung của các nghiên cứu hiện nay là kỹ thuật hiện tại chưa đủ để đảm bảo độ bền của system prompt. Về mặt thực hành, điều đó có nghĩa là bạn nên ưu tiên vài guardrail cốt lõi thay vì cố kiểm soát mọi tình huống biên bằng lời văn, hoặc chia nhỏ tác vụ để giảm tải cho mỗi lượt xử lý.

Viết system prompt đầu tiên: bắt đầu từ đâu?

Bắt đầu bằng việc xác lập vai trò rõ ràng, rồi nêu định dạng mong muốn, cung cấp hai đến ba ví dụ mẫu, và cuối cùng đặt các rào chắn an toàn. Ưu tiên các câu lệnh trực diện và định lượng; nếu ứng dụng của bạn cần mô hình giữ nhiều hơn năm ràng buộc phức tạp cùng lúc, đó là tín hiệu nên chuyển phần cứng rắn nhất sang schema hoặc sang tinh chỉnh mô hình, thay vì viết thêm một đoạn văn nữa.

Và hãy coi system prompt là một thực thể sống. Bạn không viết một lần rồi dùng mãi: nó cần được kiểm thử bằng chính những tin nhắn cố tình mâu thuẫn với nó, cắt bỏ nợ kỹ thuật, và cập nhật theo từng thế hệ mô hình.