Câu lệnh hệ thống (system prompt) của một chatbot trong sản phẩm nên trả lời đủ bảy câu: trợ lý là ai, phục vụ ai, được trả lời những gì, được dùng dữ liệu nào, nói bằng giọng nào, trình bày ra sao, và gặp câu hỏi ngoài phạm vi thì làm gì. Viết đủ bảy phần đó bằng câu ngắn, cụ thể, có ví dụ, thì trợ lý ổn định hơn nhiều so với một đoạn văn chung chung kiểu “bạn là trợ lý thân thiện, hữu ích”.
Bài này dành cho lập trình viên hoặc người làm sản phẩm phải tự viết câu lệnh hệ thống cho trợ lý chăm sóc khách hàng, trợ lý hướng dẫn dùng phần mềm hay trợ lý tra cứu nội bộ. Bạn sẽ có khung bảy phần, một ví dụ giả định đầy đủ, những lỗi hay gặp và cách quản lý câu lệnh như quản lý mã nguồn.
Câu lệnh hệ thống khác câu lệnh bạn gõ trong khung chat ở đâu
Khi tự dùng chatbot, bạn gõ một yêu cầu, đọc kết quả, thấy sai thì hỏi lại. Câu lệnh hệ thống trong sản phẩm thì khác: bạn viết một lần, nó chạy với hàng nghìn người dùng bạn không gặp, hỏi những câu bạn không đoán trước, và bạn không có mặt để chữa lại. Nó giống bản mô tả công việc giao cho một nhân viên mới làm ca đêm một mình hơn là một câu hỏi.
Vì vậy nó phải bao quát ca thường lẫn ca khó. Ca thường là câu hỏi đúng phạm vi, đủ thông tin. Ca khó là câu hỏi mập mờ, câu hỏi ngoài phạm vi, người dùng bực bội, người dùng cố tình bắt trợ lý nói điều không nên nói, và câu hỏi mà dữ liệu bạn cung cấp không có câu trả lời. Một câu lệnh hệ thống chỉ mô tả ca thường sẽ cho trải nghiệm tốt trong buổi trình diễn và lộn xộn ngay tuần đầu chạy thật.
Một điểm kỹ thuật cần nhớ: câu lệnh hệ thống được gửi kèm trong mỗi lần gọi, nên nó tính vào số token đầu vào mỗi lần. Câu lệnh dài ba nghìn token với một trăm nghìn lượt hỏi mỗi tháng là một khoản đáng kể. Viết đủ nhưng gọn, và tìm hiểu tính năng lưu đệm phần đầu câu lệnh nếu nhà cung cấp của bạn có hỗ trợ.
Khung bảy phần của câu lệnh hệ thống
Thứ tự dưới đây đi từ cái chung tới cái cụ thể. Mỗi phần chỉ cần vài câu; phần phạm vi và cách từ chối thường đáng viết dài nhất.
| Phần | Trả lời câu hỏi | Ví dụ giả định cho phần mềm bán hàng |
|---|---|---|
| 1. Vai trò | Trợ lý là ai, thuộc sản phẩm nào | Bạn là trợ lý hướng dẫn sử dụng của một phần mềm quản lý bán hàng cho cửa hàng nhỏ |
| 2. Người dùng | Ai đang hỏi, trình độ thế nào | Người hỏi là chủ cửa hàng và nhân viên thu ngân, phần lớn không rành công nghệ, hay dùng điện thoại |
| 3. Phạm vi | Được trả lời gì, không trả lời gì | Chỉ hướng dẫn thao tác trong phần mềm; không tư vấn thuế, không bàn giá gói, không nói về đối thủ |
| 4. Nguồn dữ liệu | Dựa vào đâu để trả lời | Chỉ dựa vào tài liệu hướng dẫn được đưa trong thẻ tai_lieu; không có thì nói không có |
| 5. Giọng văn | Xưng hô, độ trang trọng | Xưng “mình”, gọi “bạn”, câu ngắn, không dùng thuật ngữ tiếng Anh nếu có từ Việt |
| 6. Định dạng | Trình bày câu trả lời | Thao tác viết thành các bước đánh số, mỗi bước một hành động, tối đa tám bước |
| 7. Ca khó | Ngoài phạm vi, mập mờ, bực bội | Ngoài phạm vi thì nói rõ không hỗ trợ và chỉ chỗ liên hệ bộ phận hỗ trợ; mập mờ thì hỏi lại một câu |
Bạn sẽ để ý phần một và hai rất ngắn. Nhiều người viết rất dài ở phần vai trò, kiểu ca ngợi trợ lý là chuyên gia hàng đầu, nhưng phần đó ảnh hưởng ít tới hành vi. Thứ thật sự quyết định là phạm vi, nguồn dữ liệu và cách xử lý ca khó, vì đó là nơi trợ lý phải tự quyết định khi bạn không có mặt.
Viết phạm vi và cách từ chối cho rõ ràng
Phạm vi nên viết bằng danh sách cụ thể thay vì tính từ. “Chỉ trả lời câu hỏi liên quan” là quá mơ hồ, vì người dùng hỏi “làm sao xuất hoá đơn điện tử” thì có liên quan không, khi phần mềm có nút xuất nhưng quy định hoá đơn là chuyện thuế? Viết rõ: hướng dẫn bấm nút xuất thì trả lời; câu hỏi về nghĩa vụ hoá đơn, mức thuế thì không trả lời và đề nghị hỏi kế toán hoặc cơ quan thuế. Ranh giới càng gần với câu hỏi thật, trợ lý càng ít lúng túng.
Cách từ chối cũng cần mẫu. Trợ lý không có hướng dẫn thường từ chối theo hai kiểu xấu: hoặc lạnh lùng một câu, hoặc từ chối mà vẫn trả lời nửa vời. Hãy viết sẵn: nói ngắn rằng câu này nằm ngoài phần trợ lý hỗ trợ, nêu lý do trong một vế, chỉ ra người hay nơi phù hợp hơn, và mời hỏi tiếp về phần mềm. Ví dụ câu mẫu trong câu lệnh: Câu này liên quan tới quy định thuế nên mình không trả lời được chính xác. Bạn nên hỏi kế toán của cửa hàng. Nếu bạn cần biết nút xuất hoá đơn nằm ở đâu, mình chỉ ngay.
Một nguyên tắc nữa đáng ghi thẳng vào câu lệnh: khi tài liệu không có câu trả lời thì nói không biết, không đoán. Với trợ lý hướng dẫn phần mềm, một câu trả lời bịa ra tên nút không tồn tại tệ hơn nhiều so với câu “mình chưa tìm thấy hướng dẫn cho việc này”. Hãy cho trợ lý một câu cụ thể để nói trong trường hợp đó, để nó không phải tự xoay.
Những lỗi hay gặp khi viết câu lệnh hệ thống
Dưới đây là các lỗi xuất hiện nhiều ở những câu lệnh hệ thống viết vội. Mỗi lỗi đều có cách sửa đơn giản.
- Toàn chữ “không”. Một danh sách dài những điều cấm mà không nói nên làm gì thay thế. Mô hình làm theo chỉ dẫn tích cực tốt hơn: thay “không trả lời dài” bằng “trả lời tối đa năm câu, trừ khi người dùng xin chi tiết”.
- Viết hoa, nhấn mạnh tràn lan. Mọi dòng đều QUAN TRỌNG thì không dòng nào quan trọng. Chỉ nhấn mạnh một hai quy tắc thật sự sống còn.
- Mâu thuẫn ngầm. Đầu câu lệnh bảo “trả lời ngắn gọn”, cuối lại bảo “luôn giải thích đầy đủ lý do”. Mô hình sẽ chọn ngẫu nhiên giữa hai, và kết quả trông thất thường.
- Dữ liệu trộn lẫn chỉ dẫn. Dán tài liệu hướng dẫn thẳng vào giữa các quy tắc. Nên đặt tài liệu trong một khối có ranh giới rõ, ví dụ bọc trong thẻ tự đặt tên, và nói rõ đó là dữ liệu tham khảo.
- Không có ví dụ. Hai ba cặp hỏi đáp mẫu thể hiện giọng văn và định dạng hiệu quả hơn nhiều đoạn mô tả. Chọn ví dụ đa dạng để mô hình không bắt chước y nguyên một câu.
- Nhét bí mật vào câu lệnh. Khoá, mật khẩu, thông tin nội bộ nhạy cảm không bao giờ nên nằm trong câu lệnh hệ thống, vì người dùng có thể dùng nhiều cách để khiến trợ lý nhắc lại nội dung đó.
Lỗi cuối cùng đáng nhấn thêm: hãy coi như câu lệnh hệ thống có ngày sẽ bị người dùng đọc được. Viết sao cho nếu nó lộ ra thì cũng không hại gì ngoài việc đối thủ biết cách bạn viết câu lệnh.
Thử câu lệnh hệ thống trước khi đưa lên thật
Câu lệnh hệ thống là mã, và mã thì phải thử. Quy trình gọn sau đủ cho nhóm nhỏ:
- Gom khoảng ba mươi câu hỏi thật hoặc gần thật, chia ba nhóm: câu thường, câu ngoài phạm vi, câu cố tình phá như yêu cầu bỏ qua chỉ dẫn hay nói về đối thủ.
- Ghi trước cho mỗi câu hành vi mong muốn bằng một dòng: trả lời theo bước, từ chối và chỉ chỗ hỏi, hay hỏi lại cho rõ.
- Chạy cả ba mươi câu qua câu lệnh mới bằng một đoạn mã nhỏ gọi đúng hàm mà sản phẩm dùng, lưu kết quả ra tệp.
- Đọc từng kết quả, đánh dấu đạt hay không theo dòng mong muốn. Đếm tỉ lệ đạt theo từng nhóm.
- Sửa câu lệnh nhắm vào nhóm yếu nhất, chạy lại toàn bộ để chắc bản sửa không làm hỏng nhóm khác.
- Chỉ đưa lên thật khi tỉ lệ đạt không thấp hơn bản đang chạy; lưu lại bộ câu hỏi để dùng cho lần sửa sau.
Bộ ba mươi câu này sẽ lớn dần theo thời gian: mỗi lần người dùng gặp một câu trả lời tệ, thêm câu đó vào bộ. Bài về đánh giá chất lượng câu trả lời trong cùng danh mục đi sâu hơn vào cách chấm và so phiên bản.
Quản lý câu lệnh hệ thống như quản lý mã nguồn
Đừng để câu lệnh hệ thống nằm trong bảng cài đặt mà ai cũng sửa được trực tiếp trên môi trường thật. Hãy lưu nó trong kho mã, ở một tệp riêng, có lịch sử thay đổi, có người duyệt như mọi thay đổi mã khác. Khi khách báo trợ lý trả lời lạ từ hôm thứ Ba, bạn cần biết hôm thứ Ba ai đã sửa câu nào.
Gắn số phiên bản cho câu lệnh và ghi số đó vào nhật ký mỗi lần gọi. Nhờ vậy khi đọc một câu trả lời tệ trong nhật ký, bạn biết ngay nó sinh ra từ phiên bản câu lệnh nào. Nếu sản phẩm có nhiều trợ lý cho nhiều việc, đặt tên tệp theo việc để không ai sửa nhầm.
Cuối cùng, ghi chú trong tệp vì sao có từng quy tắc lạ. Một dòng như “không gợi ý khách gọi điện, vì tổng đài chỉ làm giờ hành chính” sẽ cứu người sửa sau khỏi việc xoá nó đi rồi gặp lại đúng lỗi cũ. Câu lệnh hệ thống tích luỹ kinh nghiệm vận hành theo thời gian, và kinh nghiệm đó chỉ còn giá trị nếu được giải thích.
Câu hỏi thường gặp
Câu lệnh hệ thống nên viết bằng tiếng Việt hay tiếng Anh?
Với sản phẩm cho người Việt, viết bằng tiếng Việt thường cho giọng văn tự nhiên hơn và đỡ lẫn thuật ngữ. Một số nhóm viết quy tắc bằng tiếng Anh và ví dụ bằng tiếng Việt. Hãy thử cả hai trên cùng bộ câu hỏi kiểm và chọn theo kết quả, không theo cảm giác.
Câu lệnh hệ thống dài bao nhiêu là vừa?
Không có con số chung. Bắt đầu ngắn, chỉ thêm quy tắc khi bộ kiểm cho thấy cần. Câu lệnh phình to vì ai cũng chêm thêm một dòng thường chứa mâu thuẫn. Định kỳ đọc lại và xoá những dòng không còn tác dụng.
Người dùng có đọc được câu lệnh hệ thống không?
Bạn nên giả định là có. Người dùng có thể dùng nhiều cách hỏi vòng để trợ lý nhắc lại chỉ dẫn. Vì vậy không đặt bí mật, khoá hay thông tin nội bộ nhạy cảm vào đó, và kiểm soát quyền thật sự ở mã máy chủ chứ không ở câu lệnh.
Có nên cho trợ lý một cái tên và tính cách không?
Có thể, nếu hợp thương hiệu, nhưng đừng để tính cách lấn át việc chính. Một câu mô tả giọng văn và hai ví dụ là đủ. Nhớ cho trợ lý nói rõ mình là trợ lý tự động khi được hỏi, để người dùng không tưởng đang nói chuyện với nhân viên.
Đổi mô hình có phải viết lại câu lệnh hệ thống không?
Thường không phải viết lại, nhưng phải chạy lại bộ câu hỏi kiểm. Mỗi mô hình phản ứng hơi khác với cùng chỉ dẫn, có mô hình nghe lời định dạng chặt hơn, có mô hình dài dòng hơn. Sửa nhỏ theo kết quả kiểm là đủ.
Làm sao để trợ lý không trả lời sai thông tin về sản phẩm?
Đưa tài liệu chính xác vào câu lệnh hoặc qua cơ chế tìm kiếm tài liệu, yêu cầu chỉ trả lời dựa trên đó, và cho một câu cụ thể để nói khi không tìm thấy. Vẫn phải đọc nhật ký định kỳ, vì không cách nào loại hẳn được câu trả lời sai.