Cùng một bộ nguyên tắc hành vi, khi đưa cho gpt-oss-120b thì tỷ lệ hoàn thành tác vụ của nó tăng 16.1 điểm phần trăm, nhưng đưa cho GLM-5 thì gần như không đổi. Trong loạt thí nghiệm công bố ngày 18 tháng 8, IBM Research đã thử nghiệm trên tám mô hình và rút ra một kết luận chung: liều lượng bộ nhớ phù hợp phụ thuộc vào việc bản thân mô hình còn bao nhiêu dư địa.
Thí nghiệm sử dụng benchmark AppWorld, gồm 585 tác vụ nhiều bước, trong đó 168 tác vụ ở độ khó thông thường và 417 tác vụ ở độ khó cao, trải trên 9 ứng dụng mô phỏng như lịch, tin nhắn, thanh toán.
Phương pháp không phức tạp: trước tiên để agent chạy thử các tác vụ, từ những quỹ đạo thành công và thất bại chắt lọc ra các nguyên tắc hướng dẫn ở cấp độ hành vi, gom thành một tập hợp có thể tái sử dụng; đến lúc suy luận thì đưa các nguyên tắc này trở lại vào ngữ cảnh. Có hai cách đưa vào: nạp toàn bộ nguyên tắc ở mỗi bước, hoặc giữ một lõi tinh gọn cố định và truy xuất tập con liên quan theo từng tác vụ. Cùng một bộ nguyên tắc, hai cách nạp khác nhau, được đối chiếu song song.
Ba tầng mô hình, ba lời giải tối ưu khác nhau
Chạy qua tám mô hình, sự phân tầng hiện ra rất rõ.
Tầng dư địa dồi dào gồm DeepSeek-V3.2 (671B MoE), Claude Opus 4.6 và GPT-5.5, nạp toàn bộ nguyên tắc cho hiệu quả tốt nhất. Tỷ lệ hoàn thành tác vụ của DeepSeek-V3.2 tăng 9.5 điểm phần trăm, tỷ lệ hoàn thành kịch bản tăng 16.1 điểm phần trăm; Claude Opus 4.6 là 4.1 và 7.1; GPT-5.5 là 2.9 và 7.2.
Tầng dung lượng eo hẹp chỉ có gpt-oss-120b (117B MoE). Nạp toàn bộ nguyên tắc sẽ nhấn chìm nó, nhưng chuyển sang truy xuất chọn lọc thì cả hai chỉ số đều tăng 16.1 điểm phần trăm, mức tăng lớn nhất trong tám mô hình.
GLM-5 (745B MoE) được xếp vào tầng bão hòa, vốn đã áp sát trần trên bộ tác vụ này, nên có thêm bộ nhớ hay không thì cả hai chỉ số đều không đổi, 0.0 điểm phần trăm.
Hai chỉ số cần nhìn tách biệt
TGC (tỷ lệ hoàn thành tác vụ) đo tỷ lệ agent hoàn thành trọn vẹn, chính xác từng tác vụ đơn lẻ. SGC (tỷ lệ hoàn thành kịch bản) khắt khe hơn: một kịch bản gồm nhiều biến thể của cùng một tác vụ — đổi dữ liệu, đổi cách diễn đạt, đổi điều kiện biên — chỉ khi mọi biến thể đều đạt thì kịch bản đó mới được tính là qua.
Giá trị của việc tách hai chỉ số nằm ngay trong các con số: TGC của DeepSeek-V3.2 chỉ tăng 9.5 điểm, trong khi SGC tăng tới 16.1 điểm. Hiện tượng tương tự cũng đúng với Claude Opus 4.6 (4.1 so với 7.1) và GPT-5.5 (2.9 so với 7.2). Lợi ích của bộ nhớ nằm nhiều hơn ở việc "cùng một loại tác vụ nhưng đổi cách diễn đạt vẫn làm đúng", chứ không phải "làm thêm được nhiều bài mới". Với người xây dựng hệ thống sản xuất, loại lợi ích đầu hiếm hơn nhiều so với loại sau.
Cái giá nằm ở token
Mục chi phí là phần thực dụng nhất của báo cáo. DeepSeek-V3.2 khi nạp toàn bộ, lượng token tiêu tốn mỗi tác vụ tăng từ 148,000 lên 263,000, tăng 78%. gpt-oss-120b cũng nạp toàn bộ, tăng từ 110,000 lên 166,000, tăng 51%. Chuyển sang truy xuất chọn lọc, lượng tiêu tốn của gpt-oss-120b chỉ còn 116,000, tăng 5%, nhưng đổi lại được 16.1 điểm phần trăm.
Đặt hai bộ số cạnh nhau để tính nhanh hiệu suất chi phí: gpt-oss-120b dùng thêm 5% token để đổi lấy 16.1 điểm, DeepSeek-V3.2 dùng thêm 78% token để đổi lấy 9.5 điểm (theo TGC). Mỗi 1% token tăng thêm, bên đầu tương ứng khoảng 3.2 điểm phần trăm, bên sau chỉ khoảng 0.12 điểm, chênh nhau hơn hai mươi lần. Với các dịch vụ tính phí theo token, khoảng cách này đủ để biến việc "nạp toàn bộ bộ nhớ cho mô hình mạnh" thành một bài toán không đáng làm.
Việc học diễn ra bên ngoài mô hình
Các tác giả có thêm một câu chỉ ra ranh giới của phương pháp này:
Learning happens around the model, not inside it.
Việc học diễn ra xung quanh mô hình, chứ không phải bên trong mô hình.
Các nguyên tắc hướng dẫn thay đổi môi trường ngữ cảnh của agent, còn trọng số mô hình không hề động đến. Điểm lợi là có thể thêm bớt bất cứ lúc nào, có thể kiểm toán, đổi mô hình thì đổi bộ nguyên tắc khác; nhưng giới hạn cũng nằm ở đây — mọi lợi ích đều bị ràng buộc bởi cửa sổ ngữ cảnh và chi phí suy luận, thêm đến một mức nào đó sẽ phản tác dụng, như trường hợp gpt-oss-120b bị nhấn chìm khi nạp toàn bộ nguyên tắc.
Công trình này thuộc về IBM Research, đứng tên mười tác giả, trong đó có Vatche Isahagian, Evelyn Duesterwald, Vinod Muthusamy, mã nguồn và phương pháp được công bố dưới tên ALTK-Evolve.
Với các nhóm đang bổ sung bộ nhớ cho agent, thứ tự thao tác mà bộ số liệu này gợi ý còn thiết thực hơn cả kết luận: trước tiên đo dư địa cơ sở của mô hình trên tác vụ mục tiêu; dư địa hẹp thì dùng truy xuất chọn lọc; dư địa rộng thì có thể cân nhắc nạp toàn bộ; còn mô hình đã áp sát trần thì để dành số token đó, đem đi cải thiện chỗ khác.
Nguồn tham khảo: blog kỹ thuật của IBM Research và Hugging Face, CocoLoop; cơ cấu 585 tác vụ của AppWorld, mức thay đổi điểm phần trăm TGC/SGC của tám mô hình và chi phí token từng cấu hình đều đã được đối chiếu theo dữ liệu thí nghiệm công bố.