Kỹ thuật Quyền quyết định: Xác định những gì tác nhân AI của bạn được phép quyết định

Kỹ thuật phân định quyền hạn. Nguồn: do tác giả tạo bằng công cụ tạo ảnh OpenAI. Kỹ thuật nhắc lệnh (prompt engineering), kỹ thuật ngữ cảnh (context engineering), kỹ thuật điều khiển (harness engineering), cùng với các khái niệm mới hơn về vòng lặp (loops) và đồ thị (graphs), đều dịch chuyển một ranh giới: giữa những gì mô hình quyết định và những gì mã lệnh xác định (deterministic code) thực hiện. Đây là một khuôn khổ dành cho người thực hành. Trong một thời gian, tôi đã xem kỹ thuật nhắc lệnh, kỹ thuật ngữ cảnh, kỹ thuật điều khiển, và những thảo luận mới hơn về vòng lặp và đồ thị là các lĩnh vực riêng biệt. Mỗi lĩnh vực đều có vốn từ vựng riêng, và trong vài tháng, mỗi lĩnh vực dường như là điều quan trọng nhất. Sự phân biệt này bắt đầu mất đi ý nghĩa đối với tôi khi tôi ngừng hỏi tên gọi của từng lĩnh vực và bắt đầu hỏi mỗi lĩnh vực thực sự kiểm soát điều gì trong một hệ thống đang hoạt động. Dưới những tên gọi khác nhau, tất cả chúng đều thay đổi cùng một thứ. Chúng dịch chuyển ranh giới giữa những gì mô hình quyết định và những gì phần mềm xác định quyết định. Vấn đề kỹ thuật khó khăn hơn là quyết định ranh giới đó nên đặt ở đâu. Nhắc lệnh, ngữ cảnh, công cụ, đồ thị, điều khiển và bảo vệ là những cách khác nhau để đặt ranh giới này. Nhắc lệnh kiểm soát cách mô hình suy luận. Ngữ cảnh kiểm soát bằng chứng mà mô hình suy luận dựa trên. Công cụ kiểm soát những hành động tồn tại. Điều khiển kiểm soát môi trường thực thi xung quanh mỗi lời gọi. Bảo vệ và bộ đánh giá kiểm soát liệu một quyết định của mô hình có được phép trở thành một hành động thực sự hay không. Đồ thị kiểm soát cấu trúc liên kết của quá trình ra quyết định, những chuyển đổi nào vẫn mang tính xác định và nơi nào các quyết định được phép xảy ra. Không có khái niệm nào trong số này là một thế hệ thay thế khái niệm trước đó. Trong một tác nhân thực tế, người ta sử dụng tất cả chúng cùng một lúc và không có khái niệm nào bị loại bỏ. Chúng là những đòn bẩy khác nhau, và mỗi đòn bẩy dịch chuyển ranh giới giữa mô hình và phần mềm tại một điểm khác nhau trong hệ thống. Nhắc lệnh, ngữ cảnh, công cụ, đồ thị, điều khiển, bảo vệ, bộ đánh giá và vòng lặp dịch chuyển các phần khác nhau của ranh giới quyền hạn của tác nhân. Nguồn: do tác giả tạo bằng công cụ tạo ảnh OpenAI. Khi mọi người tranh luận về việc kỹ thuật ngữ cảnh hay kỹ thuật điều khiển quan trọng hơn, họ thường tranh luận về việc nên sử dụng đòn bẩy nào. Câu hỏi hữu ích là những quyết định nào trong hệ thống này nên thuộc về mô hình. Tôi đã bắt đầu coi câu hỏi đó là kỹ thuật phân định quyền hạn, và tôi nghĩ đó là trọng tâm mà các thuật ngữ khác đã xoay quanh. Quyền hạn có hai chiều, không phải một chiều Cách hình dung ranh giới rõ ràng nhất là một thanh trượt duy nhất, mô hình ở một đầu và mã lệnh xác định ở đầu kia, và người ta quyết định đẩy nó đi bao xa. Hình ảnh đó đã khiến tôi, trong một thời gian, cho rằng việc đẩy mọi thứ về phía mã lệnh là mặc định an toàn. Điều đó không đúng, và lý do là "mô hình hay mã lệnh" không phải là câu hỏi cần đặt ra đầu tiên. Hai yếu tố thực sự quyết định nơi một quyết định cụ thể thuộc về, và chúng độc lập với nhau. Thứ nhất là sự mơ hồ. Quyết định này đòi hỏi mức độ diễn giải đến đâu. Việc diễn giải lại một truy vấn tìm kiếm mơ hồ là rất mơ hồ. Việc kiểm tra xem một lần ghi trước đó đã được cam kết hay chưa thì hoàn toàn không mơ hồ. Thứ hai là hậu quả. Điều gì sẽ xảy ra nếu quyết định này sai. Việc chọn một đường dẫn truy xuất kém tối ưu một chút thì sai lầm ít tốn kém. Việc ủy quyền một khoản thanh toán không đáng có thì không. Tôi sử dụng khái niệm hậu quả một cách rộng rãi ở đây. Nó bao gồm phạm vi ảnh hưởng, khả năng đảo ngược, tác dụng phụ bên ngoài và chi phí để sửa chữa một quyết định sai lầm sau khi nó đã được thực thi. Một cách thực tế để đặt ranh giới quyền hạn: đánh giá mỗi quyết định dựa trên mức độ phán đoán mà nó yêu cầu và điều gì sẽ xảy ra nếu nó sai. Nguồn: do tác giả tạo bằng công cụ tạo ảnh OpenAI. Khi đã tách hai trục này, quy tắc thiết kế thay vì do sở thích: Độ mơ hồ thấp, hậu quả cao: giữ tính xác định. Không có phán đoán nào cần thêm vào và có nhiều thứ để mất. Quyền ủy quyền nằm ở đây. Độ mơ hồ cao, hậu quả thấp: giao cho mô hình. Đây là sự linh hoạt mà bạn đã áp dụng mô hình để đạt được. Việc diễn giải và tái cấu trúc truy vấn nằm ở đây. Độ mơ hồ cao, hậu quả cao: mô hình đề xuất, chính sách xác định giới hạn những gì được phép, và một yếu tố độc lập xác minh kết quả. Đây là góc phần tư thú vị, và hầu hết các quyết định khó khăn đều nằm trong đó. Độ mơ hồ thấp, hậu quả thấp: sử dụng phương án nào rẻ hơn để xây dựng và duy trì. Không đáng để băn khoăn. Vấn đề là bạn không còn hỏi liệu mô hình hay mã code nên xử lý một quyết định. Bạn đang hỏi mức độ mơ hồ của quyết định và cái giá phải trả nếu mắc lỗi, và góc phần tư sẽ cho bạn biết hình dạng của câu trả lời. Các quyết định nơi quyền tự quyết thực sự tồn tại Việc đặt các quyết định lên bản đồ đó chỉ hữu ích nếu bạn đã liệt kê các quyết định ngay từ đầu, và đây là một bước dễ bỏ qua khi thiết kế một tác nhân bắt đầu bằng các lời nhắc (prompts), công cụ (tools) hoặc cấu trúc đồ thị (graph structure). Đây không phải là một phân loại ngành và tôi sẽ không trình bày nó như vậy, nhưng trong các hệ thống tôi đã làm việc, tôi thường tìm thấy khoảng tám điểm quyết định nơi ranh giới được đặt ra, dù tốt hay xấu: diễn giải, lập kế hoạch, lựa chọn công cụ, ủy quyền, thực thi, phục hồi, xác minh và chấm dứt. Danh sách chính xác ít quan trọng hơn thói quen ghi lại các quyết định trước khi chọn bất kỳ kỹ thuật nào. Ba trong số chúng nằm ở những vị trí rất khác nhau trên bản đồ, và việc xem xét ba vị trí đó là đủ để cho thấy cách khung hoạt động. Diễn giải và lập kế hoạch là trường hợp rõ ràng nhất cho quyền tự quyết của mô hình, mặc dù không phải vì những lý do giống hệt nhau. Diễn giải, hiểu tín hiệu đầu vào thực sự yêu cầu điều gì, có độ mơ hồ cao và thường có hậu quả thấp nếu đứng một mình, đó chính xác là phán đoán bạn đã tìm kiếm ở một mô hình. Cố gắng làm cho nó có tính xác định thường có nghĩa là xây dựng lại bộ phân loại ý định dễ hỏng mà bạn đã áp dụng một LLM để loại bỏ. Lập kế hoạch cũng rất mơ hồ, nhưng hậu quả của nó không cố định. Một kế hoạch thừa hưởng hậu quả từ những gì các bước của nó thực sự có thể gây ra. Một kế hoạch nghiên cứu chỉ đọc và tóm tắt có thể chấp nhận quyền tự quyết rộng rãi của mô hình. Một kế hoạch có thể chuyển tiền hoặc thay đổi cơ sở hạ tầng sản xuất thì không thể, bởi vì sự mơ hồ giờ đây gắn liền với các hành động mà việc mắc lỗi sẽ rất tốn kém. Vì vậy, lập kế hoạch không nằm trong