System Prompt là gì?

Scrapeless MCP Server cung cấp cho các client AI quyền truy cập vào các công cụ web Scrapeless.

System prompt là văn bản hướng dẫn ở cấp ứng dụng được cung cấp cho một hệ thống AI sinh sinh để dẫn dắt hành vi của nó trong một tương tác. Nó có thể mô tả vai trò của trợ lý, phạm vi nhiệm vụ, yêu cầu về phản hồi và cách xử lý các loại đầu vào khác nhau. Vai trò thông điệp và quy tắc ưu tiên cụ thể phụ thuộc vào giao diện mô hình.

Một system prompt hữu ích cung cấp cho mô hình một “hợp đồng” hành vi ổn định. Nó không tự thực thi kiểm soát truy cập, không làm cho các công cụ không tồn tại trở nên khả dụng, và không bảo đảm câu trả lời đúng. Hãy coi hướng dẫn là một phần của ứng dụng, phối hợp với việc kiểm tra đầu vào, giới hạn hành động và kiểm tra đầu ra.

System Prompt Dùng Để Làm Gì

System prompt xác định hành vi nên được áp dụng xuyên suốt các yêu cầu người dùng mà một ứng dụng xử lý. Một trợ lý hỗ trợ có thể được hướng dẫn trả lời trong phạm vi sản phẩm, phân biệt thông tin thiếu với bằng chứng phủ định, và yêu cầu mã định danh tài khoản bắt buộc trước một loại tra cứu cụ thể. Những yêu cầu này nên đủ cụ thể để có thể đánh giá.

Định nghĩa system-prompt mô tả các hướng dẫn cụ thể cho ứng dụng được cung cấp trong ngữ cảnh. Cách đóng khung đó tách các hướng dẫn khỏi tham số đã được mô hình học. Cập nhật system prompt là thay đổi những hướng dẫn được gửi trong khi sử dụng; đó không phải cùng một thao tác với việc huấn luyện mô hình.

Hãy viết yêu cầu dưới dạng hành vi có thể quan sát. Thay vì bảo trợ lý “đáng tin cậy”, hãy chỉ rõ nó phải xử lý một khẳng định không được hỗ trợ hoặc nguồn không đầy đủ như thế nào. Thay vì yêu cầu nó “có trách nhiệm”, hãy định nghĩa những thao tác công cụ nào cần được phê duyệt. Những tuyên bố đó cho người đánh giá một cái gì đó cụ thể để kiểm thử.

Hướng Dẫn Hệ Thống, Yêu Cầu Người Dùng và Nội Dung Nguồn

Hướng dẫn hệ thống mô tả hành vi ứng dụng, trong khi yêu cầu người dùng cung cấp nhiệm vụ hiện tại. Nội dung nguồn được truy xuất là bằng chứng về môi trường nhiệm vụ. Giữ các loại này tách biệt giúp ngăn một tài liệu bên ngoài bị nhầm với hướng dẫn được ứng dụng hoặc người dùng cho phép.

Đối với một trợ lý nghiên cứu giả định, hướng dẫn hệ thống có thể yêu cầu câu trả lời thực tế có nguồn hỗ trợ. Người dùng hỏi về một tính năng sản phẩm. Một trang được truy xuất cung cấp mô tả tính năng liên quan. Nếu trang đó cũng chứa văn bản bảo trợ lý bỏ qua các quy tắc của nó, ứng dụng nên giữ văn bản đó như nội dung nguồn không đáng tin cậy thay vì nâng nó thành hướng dẫn điều khiển.

Nghiên cứu về thứ bậc hướng dẫn được ưu tiên xem xét việc huấn luyện mô hình để ưu tiên hướng dẫn theo thẩm quyền. Đó là một nguyên tắc thiết kế hữu ích, nhưng hỗ trợ và hành vi khác nhau giữa các giao diện. Hãy xác minh ngữ nghĩa vai trò của mô hình đã chọn và kiểm thử xung đột trực tiếp thay vì giả định mọi thông điệp được gắn nhãn system đều có hiệu ứng giống hệt nhau ở mọi nơi.

Viết Hướng Dẫn Xung Quanh Các Quyết Định

Hướng dẫn hiệu quả chỉ rõ cách đưa ra các quyết định lặp lại trong ứng dụng. Hãy định nghĩa chủ đề được phép, cái gì được tính là bằng chứng, khi nào dùng công cụ, và một phản hồi đầy đủ phải bao gồm những gì. Tránh làm đầy prompt bằng các tính từ rộng không giải quyết một quyết định thực tế nào.

Đối với một trợ lý tài liệu giả định, một quy tắc hữu ích có thể yêu cầu kiểm tra phiên bản sản phẩm áp dụng trước khi đưa ra tư vấn cấu hình. Một quy tắc khác có thể yêu cầu nói rõ khi các tài liệu sẵn có không trả lời được câu hỏi. Mỗi quy tắc giải quyết một lỗi cụ thể có thể xuất hiện trong một ca đánh giá.

Tổ chức hướng dẫn sao cho các yêu cầu liên quan được giữ cùng nhau. Tách biệt phạm vi nhiệm vụ, quy tắc về bằng chứng, hành vi công cụ và định dạng phản hồi bằng ngôn ngữ rõ ràng. Nếu hai yêu cầu xung đột, hãy giải quyết xung đột trong thiết kế thay vì yêu cầu mô hình thỏa mãn cả hai. Một prompt vừa yêu cầu trả lời mọi câu hỏi, vừa cấm các phát biểu không có căn cứ thì cần một cách rõ ràng để trả về thông tin không đủ bằng chứng.

Giữ Các Sự Kiện Thay Đổi Liên Tục Ngoài Phần Hướng Dẫn Ổn Định

System prompt thường nên chứa các quy tắc hành vi ổn định, trong khi các sự kiện thay đổi thường xuyên nên đến từ nguồn dữ liệu phù hợp. Đưa giá hiện tại hoặc chi tiết phát hành vào một prompt tồn tại lâu dài sẽ tạo ra một bản sao khác có thể trở nên lỗi thời. Truy xuất hoặc tra cứu có cấu trúc có thể cung cấp những dữ kiện đó tại thời điểm yêu cầu.

Nghiên cứu về cách mô hình sử dụng ngữ cảnh dài cũng cảnh báo việc giả định rằng nhiều văn bản hơn nghĩa là mọi hướng dẫn hoặc sự kiện sẽ được sử dụng một cách đáng tin cậy. Hãy giữ prompt tập trung và kiểm thử cách bố trí thông tin mà ứng dụng của bạn thực sự gửi.

Nếu trợ lý sử dụng các công cụ web, quy trình Scrapeless MCP Server cung cấp kết nối tới các quan sát bên ngoài. System prompt có thể mô tả khi nào cần yêu cầu bằng chứng và cách thảo luận những chỗ thiếu hụt. Định nghĩa công cụ và môi trường runtime vẫn quyết định hành động nào khả dụng và cần thẩm quyền gì để thực thi chúng.

Prompt Không Thay Thế Quyền Chạy (Runtime Permissions)

Quyền chạy (runtime permissions) xác định những hành động nào ứng dụng có thể thực thi, trong khi system prompt mô tả những hành động nào mô hình nên đề xuất. Cả hai đều hữu ích, nhưng là các cơ chế kiểm soát khác nhau. Mô hình vẫn có thể tạo ra một yêu cầu bị cấm ngay cả khi đã được dặn không làm vậy, nên tầng thực thi phải tự kiểm tra yêu cầu một cách độc lập.

Giữ bí mật tránh xa văn bản prompt bất cứ khi nào có thể. Thông tin xác thực nên nằm trong môi trường thực thi hoặc connector được giới hạn phạm vi, thay vì trong các đoạn nguồn mà mô hình có thể lặp lại. Nếu một nhiệm vụ cần một thao tác đặc quyền, hãy định nghĩa kiểm tra ủy quyền và thực thi nó khi thao tác đó chạy.

Dành cho kết nối Scrapeless MCP, xử lý việc thiết lập kết nối và quyền hạn dùng công cụ như cấu hình của ứng dụng. Một câu trong prompt không thể xác lập rằng một thông tin xác thực đang tồn tại, rằng một lần gọi công cụ đã thành công, hoặc rằng một hành động thay đổi trạng thái đã được phê duyệt. Hãy yêu cầu kết quả công cụ có thể quan sát được và các bước kiểm tra chính sách phù hợp cho những kết luận đó.

Kiểm thử một Prompt có Xung đột và Thiếu thông tin

Đánh giá system prompt cần bao gồm những tình huống mà các quy tắc quan trọng nhất. Hãy kiểm thử các yêu cầu mơ hồ, thiếu bằng chứng, hướng dẫn người dùng xung đột, đầu ra công cụ bị lỗi, và văn bản bên ngoài cố gắng chuyển hướng hành vi. Những yêu cầu suôn sẻ thông thường cho thấy rất ít về hiệu quả của một quy tắc ranh giới.

Sử dụng một bộ đánh giá ổn định và xác định hành vi mong đợi cho từng trường hợp. Một số trường hợp nên kết thúc bằng một câu trả lời hữu ích; số khác nên đưa ra một giới hạn rõ ràng hoặc một yêu cầu cung cấp thông tin thiết yếu. Đánh giá xem trợ lý có tuân theo quy tắc liên quan mà không từ bỏ không cần thiết phần còn lại của nhiệm vụ hay không.

Giữ một prompt chuẩn và chỉ thay đổi một tập nhỏ hướng dẫn mỗi lần. Nếu một thay đổi cải thiện một lỗi nhưng tạo ra lỗi khác, hãy kiểm tra các ví dụ trước khi thêm nhiều câu chữ hơn. Độ dài prompt có thể tăng rất nhanh khi mỗi sự cố trở thành một câu mới. Hợp nhất các quy tắc chồng lặp và loại bỏ những hướng dẫn không còn phản ánh hành vi của ứng dụng.

Phiên bản hóa Hướng dẫn cùng với Phần còn lại của Ứng dụng

System prompt là cấu hình ứng dụng và nên được phiên bản hóa cùng với model, định nghĩa công cụ và kết quả đánh giá. Một đánh giá đạt yêu cầu áp dụng cho đúng tổ hợp đó. Nếu một công cụ thay đổi định dạng trả về, các quy tắc diễn giải trong prompt có thể cần được xem xét lại ngay cả khi nội dung prompt không thay đổi.

Ghi lại lý do một hướng dẫn quan trọng tồn tại. Một ghi chú thiết kế ngắn có thể liên kết nó với một yêu cầu hoặc ví dụ lỗi mà không làm lộ dữ liệu sản xuất nhạy cảm. Điều này giúp người bảo trì phân biệt được một ranh giới cần thiết với câu chữ tích lũy trong quá trình thử nghiệm.

Giữ hồ sơ triển khai cụ thể. Xác định phiên bản prompt nào đã phục vụ một yêu cầu và liệu các hướng dẫn bổ sung có được ứng dụng chèn thêm hay không. Chỉ gỡ lỗi dựa trên thông điệp người dùng nhìn thấy có thể bỏ sót điều kiện đã gây ra phản hồi. Sử dụng truy vết với phạm vi phù hợp và cơ chế lưu trữ để việc phân tích prompt không cần thu thập nội dung người dùng không cần thiết.

Tránh Các Lỗi Thường Gặp trong Thiết kế Prompt

Các lỗi thường gặp gồm có quy tắc mâu thuẫn, thuật ngữ không được định nghĩa, tham chiếu đến công cụ không khả dụng, và định dạng phản hồi không thể biểu đạt sự không chắc chắn. Prompt cũng có thể khuyến khích sự chắc chắn không được hỗ trợ bằng cách yêu cầu trả lời bất kể bằng chứng. Hãy cho trợ lý một cách rõ ràng để báo cáo yêu cầu chưa được giải quyết trong khi vẫn hoàn thành những phần nó có thể hỗ trợ.

Đừng coi một mô tả vai trò trau chuốt là thay thế cho đặc tả nhiệm vụ. Mô tả trợ lý là chuyên gia không định nghĩa được nó bao quát phiên bản sản phẩm nào hoặc cách kiểm tra trích dẫn. Hãy nêu trực tiếp những yêu cầu đó. Giữ cho ví dụ đại diện cho các đầu vào thực tế thay vì chỉ hiển thị các trường hợp dễ.

Đối với các ứng dụng có kết nối web, hãy phân biệt hành vi của model với khả năng của hạ tầng. Bề mặt Agent Browser mô tả việc thực thi trên web, trong khi prompt quản lý cách model sử dụng các quan sát. Suy luận của model và Scrapeless service usage cũng có cơ chế tính toán riêng. Một hướng dẫn về việc tiết kiệm tài nguyên nên được hỗ trợ bởi các giới hạn và phép đo thực tế.

Kết luận

System prompt định nghĩa hành vi ứng dụng trong ngữ cảnh. Hãy làm cho các hướng dẫn cụ thể, giải quyết mâu thuẫn và đánh giá các trường hợp nơi ranh giới bị thách thức. Đưa những sự kiện thay đổi thường xuyên vào các nguồn phù hợp và thực thi quyền truy cập trong runtime để ứng dụng vẫn dễ hiểu khi model đề xuất một hành động bất ngờ.