Mô hình, ngữ cảnh và câu trả lời sai

Phân biệt năng lực với thông tin sẵn có

Mô hình ngôn ngữ sử dụng các mẫu đã học và thông tin được cung cấp trong tác vụ. Mô hình hiện đại có thể suy luận đáng kể và thực hiện công việc phần mềm hữu ích. Chúng cũng có thể tạo câu trả lời chi tiết dựa trên giả định sai.

“Frontier model” mô tả một mức năng lực thay đổi theo thời gian. Thuật ngữ này không chứng minh mô hình đã đọc repository của bạn. Nó không cho thấy mô hình biết phiên bản dependency hay quy tắc kinh doanh chưa được ghi lại. Môi trường tác vụ phải cung cấp những thông tin đó.

Agent có công cụ phù hợp có thể truy xuất thông tin. Phiên chat không có quyền truy cập không thể kiểm tra repository. Khi câu trả lời có vẻ sai, hãy hỏi hai câu. Mô hình có giải được vấn đề này nếu có thông tin đúng không? Mô hình đã nhận được thông tin đó chưa?

Mô hình khác có thể giúp với vấn đề thứ nhất. Bổ sung chính sách còn thiếu hoặc kiểm tra dependency có thể giải quyết vấn đề thứ hai.

Xác định ngữ cảnh cho tác vụ này

Ngữ cảnh là thông tin sẵn có cho câu trả lời hiện tại. Nó gồm hướng dẫn, tệp được cung cấp, hội thoại liên quan và kết quả công cụ. Các sản phẩm lựa chọn và giữ thông tin này theo cách khác nhau. Chúng cũng có thể tóm tắt nội dung trước đó.

Không mặc định mô hình đọc mọi tệp trong thư mục được tải lên. Không mặc định hướng dẫn ban đầu vẫn sẵn có trong suốt phiên dài. Yêu cầu công cụ nêu các tệp và hướng dẫn đã dùng.

Thêm ngữ cảnh không phải lúc nào cũng cải thiện câu trả lời. Quyết định kiến trúc hiện hành có thể hữu ích hơn các tệp mã không liên quan. Hướng dẫn migration lỗi thời có thể dẫn đến câu trả lời sai vì có vẻ là nguồn có thẩm quyền.

Xét tính năng cài đặt tài khoản giả định. Cung cấp route, middleware phân quyền, mô hình dữ liệu liên quan và test hiện có. Thêm ràng buộc cụ thể: “Thành viên có thể đổi tên hiển thị. Thành viên không thể đổi vai trò của mình trong tổ chức.” Mô hình giờ có quy tắc rõ ràng cần giữ.

Kiểm tra các nhận định trong lời giải thích

Câu trả lời có thể khẳng định endpoint an toàn vì middleware kiểm tra quyền sở hữu. Xác minh từng phần của nhận định này.

1. Kiểm tra endpoint có dùng middleware được nêu không.
2. Kiểm tra middleware xác minh quyền sở hữu, không chỉ xác thực danh tính.
3. Xác định nguồn danh tính người dùng.
4. Chạy test kiểm tra việc từ chối truy cập với một người dùng khác.

Tham chiếu repository cho biết nơi cần xem. Tham chiếu không chứng minh lời giải thích phù hợp với mã.

Áp dụng cùng phương pháp cho đề xuất API. Mã được sinh có thể gọi method mà package đã cài không export. Kiểm tra phiên bản package và tài liệu chính thức trước khi thay dependency. Nếu không, giả định thiếu căn cứ có thể dẫn đến migration không cần thiết.

Chuyển điều chưa chắc chắn thành kiểm tra

“Hãy chính xác” không phải kế hoạch xác minh. Xác định giả định, bằng chứng cần có và hậu quả của kết quả sai.

Ví dụ: “Chúng ta chưa xác minh việc cô lập tenant cho endpoint này. Kiểm tra request handler. Thêm test trong đó người dùng từ tenant khác yêu cầu cùng bản ghi.” Hướng dẫn này giao cho agent cuộc điều tra cụ thể với kết quả quan sát được.

Với câu hỏi về cách hiện thực hóa, kiểm tra phiên bản hệ thống thực tế. Tài liệu có thể mô tả hành vi dự kiến. Kiểm tra mã và test giúp xác định hành vi hiện tại. Nếu chúng không khớp, ghi lại khác biệt cho đến khi người phụ trách giải quyết. Không âm thầm chọn câu trả lời thuận tiện hơn.

Quản lý có thể dùng phương pháp này mà không cần đọc từng thay đổi mã. Hỏi nhóm đã kiểm tra giả định nào. Xác định các giả định còn bỏ ngỏ và người phụ trách. Thông tin này hỗ trợ quyết định phát hành trực tiếp hơn tên mô hình.