Bài tập skill và agent
Trang này đi sâu vào hai chủ đề của buổi 3 tới buổi 5: đóng gói skill và vận hành agent an toàn. Mỗi bài là một nhiệm vụ thiết kế, bạn tự làm rồi đối chiếu với gợi ý. Không có máy chấm, thước đo nằm ở chỗ skill có bật đúng lúc và agent có dừng lại đúng chỗ hay không. Các bài ở đây không trùng với trang bài tập thực hành, hãy làm cả hai trang để đủ.
Bài 1: đóng gói một quy trình báo lỗi thành skill
Trong nhóm của bạn, mỗi lần báo một lỗi phần mềm mọi người lại viết một kiểu, người thiếu bước tái hiện, người quên phiên bản, người không nói kết quả mong đợi. Bạn muốn đóng gói việc này thành một skill để lần nào cũng ra cùng một khuôn báo lỗi. Hãy viết phần mô tả kích hoạt và phần chỉ dẫn của skill đó.
Gợi ý
Skill về bản chất là một prompt tái dùng được đặt tên, kèm mô tả để mô hình tự biết khi nào nên dùng và chỉ dẫn để biết bật rồi thì làm gì. Chỉ dẫn nên cố định đúng khuôn báo lỗi bạn muốn: các mục bắt buộc theo thứ tự, không cho thêm bớt tuỳ hứng. Mô tả kích hoạt phải bám ý định báo lỗi chứ không bám một câu chữ cứng. Tiêu chí đạt: chỉ dẫn tạo ra cùng một cấu trúc mỗi lần, và mô tả kích hoạt bao được nhiều cách người dùng mở lời báo lỗi.
Tên skill: bao-loi-phan-mem
Kích hoạt: khi người dùng muốn ghi lại một lỗi phần mềm để gửi cho nhóm phát triển.
Chỉ dẫn: xuất đúng năm mục theo thứ tự: (1) Tiêu đề ngắn, (2) Các bước tái hiện
đánh số, (3) Kết quả mong đợi, (4) Kết quả thực tế, (5) Môi trường (phiên bản, hệ
điều hành). Nếu người dùng thiếu mục nào, hỏi lại đúng mục đó, không tự bịa.
Xem lại bài Từ prompt tới skill.
Bài 2: viết mô tả kích hoạt cho đúng phạm vi
Bạn có một skill chuyển đổi ngày tháng sang định dạng chuẩn của trường (ví dụ dạng
YYYY-MM-DD). Hãy viết ba mô tả kích hoạt cho nó: một bản quá rộng, một bản quá hẹp, và
một bản vừa đúng. Với mỗi bản, ghi một tình huống cho thấy nó bật sai hoặc bật đúng.
Gợi ý
Mô tả kích hoạt là thứ quyết định skill có bật đúng lúc hay không, nên nó đáng viết cẩn thận ngang phần chỉ dẫn. Bản quá rộng bắt cả những tin nhắn không liên quan, ví dụ "khi người dùng nhắc tới thời gian" sẽ bật cả lúc người ta chỉ kể hôm qua đi đâu. Bản quá hẹp khoá vào một câu chính xác, ví dụ "khi người dùng gõ đúng: đổi ngày sang chuẩn" thì thêm một chữ là trượt. Bản vừa đúng mô tả theo ý định: khi người dùng đưa một hoặc nhiều ngày tháng và muốn đưa về định dạng chuẩn của trường. Tiêu chí đạt: bản vừa đúng loại được tình huống nhiễu mà vẫn bao nhiều cách diễn đạt cùng một ý định.
Xem lại bài Từ prompt tới skill.
Bài 3: sửa một mô tả kích hoạt hỏng
Một bạn viết skill kiểm tra định dạng tài liệu học vụ, nhưng đặt mô tả kích hoạt như dưới đây. Kết quả là skill bật gần như trong mọi cuộc trò chuyện, kể cả khi người dùng chỉ chào hỏi. Hãy chỉ ra vì sao nó hỏng và viết lại một mô tả kích hoạt lành mạnh.
Kích hoạt: khi người dùng gửi bất kỳ nội dung nào có chữ trong đó.
Gợi ý
Mô tả này hỏng vì nó rộng tới mức vô nghĩa: gần như mọi tin nhắn đều "có chữ", nên điều kiện luôn đúng và skill bật vô tội vạ. Một mô tả lành mạnh phải nêu được ba thứ: loại đầu vào (một tài liệu học vụ), ý định (muốn kiểm tra định dạng), và nên loại trừ những gì rõ ràng không liên quan. Viết lại theo ý định thay vì theo sự có mặt của chữ. Tiêu chí đạt: mô tả mới không còn bật khi người dùng chỉ chào hỏi hay hỏi việc khác, nhưng vẫn bật khi người dùng thực sự đưa một tài liệu học vụ để soát định dạng.
Kích hoạt: khi người dùng đưa một tài liệu học vụ (đơn từ, biểu mẫu, quyết định)
và muốn kiểm tra xem nó có đúng định dạng quy định hay chưa. Không bật cho chào
hỏi, câu hỏi chung, hay nội dung không phải tài liệu học vụ.
Xem lại bài Meta-prompting và thử lỗi skill.
Bài 4: quản lý phiên bản của một skill
Skill báo lỗi ở bài 1 đã dùng được vài tháng. Nay nhóm muốn đổi: thêm một mục mức độ ưu tiên, và đổi thứ tự để môi trường lên đầu. Có người lo đổi xong các báo lỗi cũ sẽ đọc khác kiểu. Hãy đề xuất một cách quản lý phiên bản cho skill này: ghi gì lại, khi nào nên tăng phiên bản, và làm sao để thay đổi không âm thầm phá thói quen cũ.
Gợi ý
Skill là văn bản sống, nó sẽ được sửa nhiều lần, nên cần quản lý phiên bản như quản lý mã nguồn. Mỗi lần sửa nên ghi lại: đổi cái gì, vì sao, ngày nào, ai đổi, đó là nhật ký thay đổi. Nên phân biệt sửa nhỏ (chỉnh câu chữ, không đổi đầu ra) với sửa lớn (thêm hoặc bớt mục, đổi thứ tự, đổi mô tả kích hoạt); sửa lớn thì tăng phiên bản chính vì nó làm đầu ra khác đi và có thể phá thói quen người dùng đang quen. Thay đổi không nên âm thầm: báo cho người dùng biết bản mới khác bản cũ ở đâu, và nếu cần thì giữ bản cũ lại một thời gian để ai chưa sẵn sàng vẫn dùng được. Tiêu chí đạt: nhìn vào nhật ký là biết được vì sao đầu ra hôm nay khác hôm qua, và không ai bị bất ngờ vì skill đột nhiên đổi khuôn.
Xem lại bài Từ prompt tới skill.
Bài 5: phân nhóm công cụ của agent theo mức nguy hiểm
Bạn dựng một agent trợ lý học vụ được cấp các công cụ sau: đọc file, tìm kiếm web, gửi email thay bạn, xoá file trên máy, tạo bản nháp tài liệu, chuyển tiền học phí, ghi chú vào lịch. Hãy xếp các công cụ này thành các nhóm theo mức nguy hiểm và nói rõ mỗi nhóm được đối xử ra sao (tự chạy, hay phải dừng xin phép).
Gợi ý
Agent khác chatbot ở chỗ nó hành động thật, nên không phải công cụ nào cũng nên có cùng quyền. Cách phân nhóm hữu ích dựa trên hai câu hỏi: hành động này có ra ngoài máy và tác động tới người khác không, và có hoàn tác được không. Nhóm chỉ đọc hoặc tạo bản nháp (đọc file, tìm kiếm web, tạo bản nháp, ghi chú lịch) rủi ro thấp, có thể cho tự chạy. Nhóm tác động ra ngoài (gửi email thay bạn) đã chạm tới người khác, nên cần duyệt. Nhóm phá huỷ hoặc không hoàn tác được (xoá file, chuyển tiền học phí) là nguy hiểm nhất, bắt buộc dừng và xin phê duyệt từng lần. Tiêu chí đạt: mỗi công cụ được gán một mức, và mức đó phản ánh đúng hậu quả nếu agent làm sai, không phải phản ánh việc nó tiện tới đâu.
Xem lại bài An toàn, đạo đức và đồ án cuối khoá.
Bài 6: thiết kế quy tắc phê duyệt đọc lệnh thật
Cho nhóm nguy hiểm ở bài 5 (xoá file, chuyển tiền, gửi email), bạn phải thiết kế bước phê duyệt. Một bạn đề xuất: agent tự tóm tắt việc nó sắp làm thành một câu, con người đọc câu đó rồi bấm đồng ý. Hãy chỉ ra lỗ hổng của cách này và thiết kế lại bước phê duyệt cho an toàn.
Gợi ý
Lỗ hổng nằm ở chỗ con người duyệt trên lời tóm tắt chứ không phải trên lệnh thật. Bản tóm tắt có thể êm tai ("tôi sẽ dọn vài file thừa cho gọn") trong khi lệnh thật lại xoá nhầm cả thư mục quan trọng, hoặc chuyển tiền tới một tài khoản khác con số. Bản tóm tắt do chính agent viết, mà agent lại là thứ ta đang cần kiểm, nên để nó tự mô tả việc mình sắp làm là tin vào chính cái đang nghi ngờ. Thiết kế lại: đưa ra duyệt phải là lệnh nguyên văn agent sắp chạy, gồm đường dẫn cụ thể, danh sách file cụ thể, số tài khoản và số tiền cụ thể, người nhận email cụ thể. Con người đọc đúng những dòng đó rồi mới đồng ý. Nhớ thêm: dù duyệt hay không, trách nhiệm cuối cùng vẫn thuộc người vận hành, nên cái đưa ra duyệt phải đủ để một người chịu trách nhiệm được. Tiêu chí đạt: mỗi hành động nguy hiểm có một điểm dừng, và thứ đưa ra duyệt là lệnh nguyên văn chứ không phải bản diễn giải.
Xem lại bài An toàn, đạo đức và đồ án cuối khoá.
Bài 7: đặt trần vòng lặp, trần chi phí và xử lý dữ liệu nhạy cảm
Agent trợ lý học vụ của bạn chạy theo vòng: nghĩ, gọi công cụ, đọc kết quả, nghĩ tiếp. Có lần nó kẹt trong một vòng lặp thử đi thử lại một việc bất khả và tiêu rất nhiều lượt gọi. Ngoài ra nó cần tra cứu hồ sơ sinh viên có số căn cước và điểm. Hãy thiết kế trần vòng lặp, trần chi phí, và quy tắc xử lý dữ liệu nhạy cảm cho agent này.
Gợi ý
Agent chạy theo vòng nên có thể kẹt: lặp mãi một hành động không dẫn tới đâu, hoặc gọi công cụ liên tục và đốt chi phí. Vì thế cần trần cứng: giới hạn số vòng tối đa cho một nhiệm vụ, giới hạn tổng số lần gọi công cụ, và một trần chi phí, chạm trần thì dừng và báo người chứ không cố tiếp. Nên có thêm điều kiện thoát khi không tiến triển: nếu vài vòng liền không tới gần đích thì dừng thay vì lặp vô hạn. Về dữ liệu nhạy cảm: số căn cước, điểm, thông tin cá nhân không nên bị đẩy ra các công cụ ngoài (tìm kiếm web, dịch vụ bên thứ ba), vì đẩy ra là mất kiểm soát nó đi đâu; chỉ giữ trong phạm vi cần thiết, và che bớt phần không cần lộ. Tiêu chí đạt: agent luôn có điểm dừng dù nhiệm vụ trục trặc, chi phí có trần trên, và không có dữ liệu nhạy cảm nào rời khỏi hệ thống ra một công cụ ngoài mà không có lý do rõ ràng.
Xem lại bài An toàn, đạo đức và đồ án cuối khoá.
Câu hỏi tự kiểm
- 1Skill về bản chất là gì?
- 2Một mô tả kích hoạt skill viết quá hẹp, khoá vào một câu chính xác, sẽ dẫn tới điều gì?
- 3Khi phê duyệt một hành động nguy hiểm của agent, con người nên đọc cái gì?
- 4Vì sao agent chạy theo vòng cần một trần vòng lặp và trần chi phí?