Nghĩ về ACE? Chúng ta có thể thực hiện điều đó với ít token hơn.

Quay lại các bài viết Nghĩ về ACE? Chúng ta có thể thực hiện với ít token hơn Bài viết doanh nghiệp được xuất bản Ngày 11/8/2026 Bình chọn 14 +8 Vatche Isahagian Vatche Theo dõi ibm-research Jayaram Radhakrishnan jayaramkr Theo dõi ibm-research Vinod Muthusamy vinodmut Theo dõi ibm-research Gaodan Fang gaodan-fang Theo dõi ibm-research Punleuk Oum illeatmyhat Theo dõi ibm-research G Thomas gsthomasx Theo dõi ibm-research Ashwath Vaithinathan Aravindan ashwath-vaithina Theo dõi ibm-research Evelyn Duesterwald evduester Theo dõi ibm-research Merve Unuvar mrvnvr Theo dõi ibm-research Những điểm chúng ta đồng ý Những điểm chúng ta khác biệt Tại sao điều đó quan trọng Cùng một bài học, cách truyền tải khác nhau Các tạo tác/tài liệu tham khảo liên kết Ghi chú phương pháp Bảng tham chiếu ALTK-Evolve và ACE đều cho phép một tác nhân (agent) học hỏi từ các quỹ đạo của chính nó. Sự khác biệt nằm ở cách chúng xử lý những gì đã học – và điều đó quyết định chi phí token. Khi giao cho một tác nhân LLM một nhiệm vụ đa bước thực tế – chia hóa đơn, tìm một bài hát, đối chiếu đơn hàng trên chín ứng dụng mô phỏng – và khi nó thất bại, thường không phải do thiếu kiến thức. Nó phân trang API sai, xác định nhầm người, hoặc trả về một giá trị khi không được yêu cầu. Mô hình biết các API; điều nó chưa nội hóa là cách sử dụng chúng một cách đáng tin cậy. Điều đó có thể học được từ lịch sử của chính tác nhân. Hai hệ thống gần đây thực hiện chính xác điều này, trên cùng một loại tác nhân: ACE (Agentic Context Engineering) và ALTK-Evolve của chúng tôi (được giới thiệu tại đây). Cả hai đều là một dạng bộ nhớ tác nhân – biến các quỹ đạo trong quá khứ của tác nhân thành các bài học có thể tái sử dụng và đưa chúng trở lại trong quá trình suy luận, không cần cập nhật trọng số, không cần nhãn thủ công. Chúng thậm chí còn đồng ý về phần khó. Điểm khác biệt nằm ở cách truyền tải. Một lưu ý về từ ngữ, vì hai hệ thống đặt tên khác nhau: chúng tôi sẽ gọi thứ mà tác nhân học được là một bài học. ACE tổ chức các bài học của mình thành một sổ tay toàn diện, liên tục phát triển; chúng tôi hợp nhất các bài học của mình thành các hướng dẫn có thể truy xuất riêng lẻ. Cùng một bài học, hai cách chứa đựng. Những điểm chúng ta đồng ý Cả hai hệ thống đều từ chối nén. ACE đặt tên chính xác các chế độ thất bại: thiên vị ngắn gọn (brevity bias) – tối ưu hóa hướng tới các hướng dẫn ngắn gọn, chung chung – và sụp đổ ngữ cảnh (context collapse) – một mô hình được yêu cầu viết lại toàn bộ ngữ cảnh của nó ở mỗi bước, tóm tắt chi tiết. Giải pháp của nó là giữ một sổ tay phong phú, được liệt kê chi tiết, với bộ đếm hữu ích/có hại trên mỗi gạch đầu dòng, và để mô hình chắt lọc sự liên quan khi đọc. Chúng tôi đi đến cùng một kết luận từ hướng khác. Mỗi hướng dẫn riêng biệt giữ một số lượng hỗ trợ – có bao nhiêu tập độc lập đã tạo ra nó – và chúng tôi không bao giờ tóm tắt kho lưu trữ thành một vài quy tắc. Một bài học mà năm nhiệm vụ khác nhau đã khám phá là một đối tượng khác với một bài học chỉ xuất hiện một lần, và cả hai đều đáng giữ lại. Vì vậy, về câu hỏi cốt lõi – liệu có nên nén các bài học khó khăn của tác nhân thành một bản tóm tắt gọn gàng không? – ACE và ALTK-Evolve đưa ra cùng một câu trả lời: không. Hãy đếm chúng, đừng làm sụp đổ chúng. Bộ đếm trên mỗi gạch đầu dòng của ACE và số lượng hỗ trợ của chúng tôi là hai cách diễn đạt cho cùng một ý tưởng. Những điểm chúng ta khác biệt Hai điểm: cách bộ nhớ được xây dựng và cách nó được truyền tải – và chính sự khác biệt trong cách truyền tải này thể hiện ở chi phí token. **Hợp nhất** (cách kho dữ liệu được xây dựng). ACE phát triển một bộ quy tắc duy nhất thông qua vòng lặp Generator → Reflector → Curator, áp dụng các bản cập nhật gia tăng và loại bỏ trùng lặp bằng cách nhúng (embedding). Chúng tôi nhóm các bài học gần giống nhau và hợp nhất chúng trong cùng một nhóm, bảo toàn hỗ trợ — khi một số bài học được hợp nhất, bài học còn lại sẽ kế thừa tổng số lượng của chúng, do đó kho dữ liệu thu gọn mà không làm mất đi hồ sơ về mức độ kinh nghiệm hỗ trợ mỗi hướng dẫn. Chúng tôi cũng trích xuất các hướng dẫn được phân loại — chiến lược, phục hồi và tối ưu hóa — với sự phân bổ nguyên nhân và nguồn gốc trở lại quỹ đạo ban đầu, và ở mức độ chi tiết của tác vụ con, để một bài học học được trên một ứng dụng có thể chuyển sang ứng dụng khác. **Phân phối** (những gì đến mô hình tại thời điểm suy luận). Đây là yếu tố thúc đẩy các con số. ACE đưa toàn bộ bộ quy tắc vào mỗi bước, theo cùng một cách bất kể mô hình hay tác vụ. Chúng tôi coi việc phân phối là một công tắc điều chỉnh, không phải là một hằng số: một tập hợp cốt lõi nhỏ, cố định gồm các hướng dẫn có mức độ hỗ trợ cao, được mở rộng cho từng tác vụ với một vài hướng dẫn được chọn lọc cho tác vụ cụ thể (dựa trên cosine hoặc được LLM hướng dẫn, có trọng số ưu tiên) — hoặc, khi một mô hình có đủ khả năng để sử dụng, toàn bộ tập hợp đã được hợp nhất. Các bài học tương tự đều có sẵn cho cả hai tác nhân; sự khác biệt là ACE luôn gửi tất cả chúng, và chúng tôi gửi số lượng mà một mô hình nhất định thực sự có thể sử dụng. **Tại sao điều này quan trọng** Trên AppWorld, với cùng một tác nhân ReAct cơ bản, chạy cả hai hệ thống nội bộ: | Mô hình | TGC / SGC | Tokens/tác vụ | |---|---|---| | DeepSeek-V3.2 ACE | 80.4 / 73.2 | 634K | | ALTK-Evolve | 89.3 / 80.4 | 263K | | gpt-oss-120b ACE | 54.8 / 35.7 | 777K | | ALTK-Evolve | 56.0 / 37.5 | 116K | Với mô hình mạnh, chúng tôi tốt hơn ở cả hai chỉ số với chi phí suy luận khoảng 40% so với ACE. Với mô hình yếu, chúng tôi vượt ACE từ 56.0 lên 54.8 — đủ gần để coi đó là một kết quả hòa về độ chính xác (một lần chạy lặp lại của chúng tôi đạt 54.8, gần như khớp chính xác với ACE, nằm trong giới hạn nhiễu giữa các lần chạy của điểm chuẩn này) — với chi phí chỉ bằng khoảng một phần bảy. Một nhận xét công bằng về chi phí: câu chuyện hiệu quả của ACE là về việc xây dựng ngữ cảnh của nó một cách rẻ tiền. Câu chuyện của chúng tôi nằm ở một khía cạnh khác — phục vụ nó. Việc truy xuất một vài hướng dẫn cho mỗi tác vụ thay vì đưa toàn bộ bộ quy tắc vào mỗi bước là nơi các token được sử dụng, và đó là hệ quả trực tiếp của sự khác biệt trong phân phối nêu trên. Độ chính xác đến từ đâu? Phân tích theo độ khó kể hai câu chuyện khác nhau: Hình 1. Hoàn thành mục tiêu tác vụ sau bộ nhớ theo độ khó, của chúng tôi so với ACE. Trên DeepSeek-V3.2 (bên phải), chúng tôi thắng ở mức độ Dễ, Khó và Tổng thể; ACE chỉ nhỉnh hơn ở mức độ Trung bình. Trên gpt-oss-120b (bên trái), ACE dẫn đầu ở mức độ dễ và trung bình, nhưng việc lựa chọn theo từng tác vụ đã thắng các tác vụ khó — và tổng hợp. Mỗi hệ thống đều cải thiện so với đường cơ sở không bộ nhớ của riêng mình (xem các bảng tham chiếu theo độ khó trong phần Ghi chú phương pháp dưới đây). Hai mô hình kể những câu chuyện khác nhau. Trên gpt-oss-120b, bộ quy tắc đầy đủ của ACE có lợi thế ở mức độ Dễ và Trung bình — có đủ thông tin về tác vụ để