ACE là gì? Tối ưu hóa mô hình ngôn ngữ với ít token hơn

Quay lại các bài viết

ALTK-Evolve và ACE đều cho phép một tác nhân (agent) học hỏi từ chính các quỹ đạo (trajectories) của 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 hóa đơn token.

Hãy đưa 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 soát đơ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ắm vững 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 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 tại thời điểm suy luận (inference), không cần cập nhật trọng số, không cần nhãn từ con người. Chúng thậm chí đồng thuận về phần khó nhất. Điểm khác biệt nằm ở cách phân phối.

Một lưu ý về thuật ngữ, vì hai hệ thống đặt tên khác nhau: chúng tôi sẽ gọi thứ thô mà tác nhân học được là "bài học" (lesson). ACE tổ chức các bài học của mình thành một cuốn cẩm nang (playbook) toàn diện, không ngừng 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 (guidelines) 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 tôi đồng thuận

Cả hai hệ thống đều từ chối việc nén dữ liệu.

ACE gọi tên các kiểu thất bại một cách chính xác: thiên kiến ngắn gọn (brevity bias) — tối ưu hóa dẫn đến các hướng dẫn ngắ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 sẽ tóm tắt làm mất đi các chi tiết. Giải pháp của nó là duy trì một cuốn cẩm nang phong phú, 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 tại thời điểm đọc.

Chúng tôi đi đến cùng một kết luận từ hướng ngược lại. Mỗi hướng dẫn riêng biệt đều giữ một số lượng hỗ trợ (support count) — số lượng các tập (episodes) độ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 được rút ra từ năm nhiệm vụ khác nhau là một đối tượng khác với 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 bạn 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 nén chúng. Các 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 tôi khác biệt

Có hai điểm: cách bộ nhớ được xây dựng và cách nó được phân phối — và chính sự khác biệt trong phân phối mới là thứ hiển thị trên hóa đơn token.

Hợp nhất (cách xây dựng kho lưu trữ). ACE phát triển một cuốn cẩm nang thông qua vòng lặp Generator → Reflector → Curator, áp dụng các cập nhật delta tăng dần và khử trùng lặp bằng embedding. Chúng tôi phân cụm các bài học gần giống nhau và hợp nhất trong một cụm, bảo toàn số lượng hỗ trợ — khi nhiều bài học hợp nhất, bài học sống sót sẽ kế thừa tổng số lượng của chúng, vì vậy kho lưu trữ thu nhỏ lại mà không làm mất đi hồ sơ về mức độ kinh nghiệm hỗ trợ cho 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ự quy kết nguyên nhân và nguồn gốc quay lại quỹ đạo gốc, và ở mức độ chi tiết của tác vụ phụ, để một bài học học được trên ứng dụng này có thể chuyển giao sang ứng dụng khác.

Phân phối (những gì đến được với 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ộ cuốn cẩm nang vào mỗi bước, theo cùng một cách bất kể mô hình hay nhiệm vụ. Chúng tôi coi việc phân phối như một nút xoay, không phải hằng số: một lõi cố định nhỏ gồm các hướng dẫn có độ hỗ trợ cao, được mở rộng theo từng nhiệm vụ với một vài hướng dẫn được chọn cho nhiệm vụ hiện tại (theo cosine hoặc hướng dẫn bởi LLM, ưu tiên theo trọng số) — hoặc, khi mô hình có đủ không gian để sử dụng, là toàn bộ tập hợp đã hợp nhất. Cùng một bài học khả dụng cho cả hai tác nhân; sự khác biệt là ACE luôn gửi tất cả, còn chúng tôi gửi bao nhiêu tùy mức 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ộ:

Trên mô hình mạnh, chúng tôi tốt hơn ở cả hai chỉ số với khoảng 40% chi phí suy luận của ACE. Trên mô hình yếu, chúng tôi vượt ACE với tỷ số 56,0 so với 54,8 — đủ gần để coi là 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, khớp gần như chính xác với ACE, nằm trong phạm vi nhiễu giữa các lần chạy của benchmark này) — với chi phí chỉ bằng khoảng một phần bảy.

Một lời 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 trên một trục khác — phục vụ nó. Truy xuất một vài hướng dẫn cho mỗi nhiệm vụ thay vì đưa toàn bộ cuốn cẩm nang vào mỗi bước là nơi các token được tiêu tốn, 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 nhiệm vụ sau khi có bộ nhớ theo độ khó, của chúng tôi so với ACE. Trên DeepSeek-V3.2 (phải), chúng tôi thắng ở các mức Dễ, Khó và Tổng thể; ACE chỉ nhỉnh hơn ở mức Trung bình. Trên gpt-oss-120b (trái), ACE dẫn đầu ở mức Dễ và Trung bình, nhưng việc lựa chọn theo nhiệm vụ lại thắng ở các nhiệm vụ Khó — và cả tổng thể. Mỗi hệ thống đều cải thiện so với đường cơ sở không có bộ nhớ của chính nó (xem các bảng tham chiếu theo độ khó trong phần Ghi chú phương pháp bên dưới).

Hai mô hình kể những câu chuyện khác nhau. Trên gpt-oss-120b, cuốn cẩm nang đầy đủ của ACE có lợi thế ở mức Dễ và Trung bình — có đủ nhiệm vụ được giải quyết bằng việc tuân thủ hướng dẫn chung để một lời nhắc toàn diện giúp ích nhiều hơn là gây xao nhãng. Nhưng ở các nhiệm vụ Khó, nơi mô hình phải chọn đúng bài học thay vì phải lội qua tất cả, việc truy xuất có chọn lọc sẽ vượt lên — và đó là cấp độ quyết định tổng thể. Trên DeepSeek-V3.2, câu chuyện đảo ngược: mô hình mạnh hơn hấp thụ tốt cuốn cẩm nang đầy đủ của ACE để vượt chúng tôi ở mức Trung bình, nhưng chúng tôi dẫn đầu ở mức Dễ, Khó và Tổng thể — với nhiều năng lực dự phòng hơn, nhiều bài học hơn (được phân phối theo cách của chúng tôi) tiếp tục giúp ích thay vì lấn át lẫn nhau.

Chúng tôi cung cấp cho mỗi mô hình cấu hình tốt nhất của nó — tập hợp hợp nhất đầy đủ cho mô hình mạnh, truy xuất có chọn lọc cho mô hình yếu hơn, bởi vì một ngữ cảnh lớn sẽ làm quá tải mô hình yếu hơn thay vì giúp ích cho nó. (Chính xác là nên đưa vào bao nhiêu, và nó mở rộng như thế nào trên phổ năng lực, là chủ đề của bài viết tiếp theo.)

Cùng bài học, cách phân phối khác nhau

Cả hai hệ thống đều từ chối nén kinh nghiệm khó khăn của tác nhân thành một bản tóm tắt gọn gàng — phần đó, chúng tôi đồng ý. Sự khác biệt nằm ở chỗ việc phân phối là cố định hay được hiệu chỉnh: ACE gửi toàn bộ cuốn cẩm nang mỗi bước bất kể thế nào; chúng tôi gửi bao nhiêu tùy mức mà một mô hình nhất định thực sự có thể sử dụng. Sự hiệu chỉnh đó là thứ mang lại các con số trên — độ chính xác tương đương hoặc tốt hơn với chi phí suy luận chỉ bằng một phần nhỏ của ACE — và trên mô hình yếu hơn, đó là sự khác biệt giữa hướng dẫn giúp ích và hướng dẫn gây cản trở.

Hãy thử thư viện ALTK-Evolve — bao gồm quy trình trích xuất, hợp nhất và truy xuất được sử dụng ở đây — hoặc đọc báo cáo kỹ thuật đầy đủ để biết phương pháp hoàn chỉnh và các thử nghiệm cắt bỏ (ablations).

Các tài liệu/tham chiếu liên kết

Ghi chú phương pháp

AppWorld test_normal, 168 nhiệm vụ. Một tác nhân mã nguồn ReAct (mỗi bước viết Python; môi trường trả về đầu ra). TGC = Hoàn thành mục tiêu nhiệm vụ; SGC = Hoàn thành mục tiêu kịch bản, yêu cầu mọi biến thể của một kịch bản phải vượt qua. Bộ nhớ chỉ được khai thác từ tập train/dev; kết quả là các lần chạy đơn lẻ (pass@1), như tiêu chuẩn trên benchmark này.

Các con số của ACE là các lần chạy tác nhân ACE của chúng tôi, được đánh giá nội bộ trên cùng các phân đoạn AppWorld và cùng các mô hình cơ sở như ALTK-Evolve (DeepSeek-V3.2 và gpt-oss-120b). Bài báo về ACE báo cáo trên một mô hình cơ sở khác (DeepSeek-V3.1), vì vậy việc tự chạy giúp kiểm soát so sánh về mô hình và khung đánh giá. Cả hai hệ thống đều là cùng một tác nhân ReAct và chỉ khác nhau ở mẫu lời nhắc (prompt template) — đó là lý do tại sao hai đường cơ sở không bộ nhớ khác nhau (72,0 so với 79,8 TGC); chúng tôi không dựa vào khoảng cách đường cơ sở đó để so sánh, mà chỉ dựa vào các khẳng định mà một tinh chỉnh lời nhắc không thể tác động: độ chính xác tương đương hoặc tốt hơn với số lượng token ít hơn.

Bảng tham chiếu

DeepSeek-V3.2 — test_normal (168 nhiệm vụ):

gpt-oss-120b — test_normal:

gpt-oss-120b — theo độ khó (TGC):

DeepSeek-V3.2 — theo độ khó (đường cơ sở → +bộ nhớ): hai hệ thống bắt đầu từ các đường cơ sở không bộ nhớ khác nhau (79,8 so với 72,0 TGC tổng thể) do sự khác biệt về mẫu lời nhắc nêu trên.