ALTK‑Evolve cho thấy các hệ thống tác tử có thể vượt trội hơn những mô hình tiên phong lớn hơn trong các tác vụ chăm sóc khách hàng chịu ràng buộc bởi chính sách, bằng cách khai thác và bổ sung các hướng dẫn đã học như bộ nhớ bền vững. Bài viết giải thích cách bộ nhớ dạng sổ tay quy trình lưu lại thủ tục và quy luật trong hành vi khách hàng, vì sao chất lượng bộ nhớ quan trọng, và doanh nghiệp cần chuẩn bị những gì khi đưa vào vận hành.
ALTK‑Evolve chọn một hướng đi tưởng chừng đơn giản: phân tích những lần tác tử mắc lỗi và thành công trước đây, rút gọn chúng thành các quy tắc hành vi ngắn, bổ sung những quy tắc đó vào system prompt, rồi để chính mô hình nền thực hiện tác vụ với ngữ cảnh bền vững ấy. Trong các tác vụ chăm sóc khách hàng chịu ràng buộc bởi chính sách của τ²‑bench, phương pháp này giúp một tác tử ReAct dùng gpt‑4.1 đạt nhóm dẫn đầu ở lĩnh vực bán lẻ, đồng thời đưa tác tử gpt‑5.5 lên vị trí cao nhất trong các tình huống hàng không. Kết quả này nhấn mạnh một bài học thiết thực cho các nhóm triển khai sản phẩm: không phải lúc nào cũng cần mô hình lớn hơn để thu hẹp khoảng cách — bộ nhớ có mục tiêu và chất lượng cao có thể tạo ra khác biệt đáng kể.
Những gì ALTK‑Evolve gọi là “hướng dẫn đã học” thực chất là các mục ngắn gọn trong sổ tay quy trình: xác thực trước khi ghi vào cơ sở dữ liệu, xác nhận rõ ràng mọi thay đổi, mỗi lượt chỉ thực hiện một thao tác công cụ, chuẩn hóa mã định danh người dùng, v.v. Các quy tắc này được tự động tạo ra từ những chuỗi hành động của tác tử, bằng chính LLM vận hành tác tử, không cần con người gắn nhãn hay cập nhật trọng số. Vì các hướng dẫn được đưa vào prompt, chúng lập tức thay đổi hành vi của tác tử và được áp dụng nhất quán qua nhiều phiên — một dạng bộ nhớ bền vững, dễ lặp chỉnh và dễ kiểm tra hơn so với việc liên tục tinh chỉnh.
Kết quả thực nghiệm rất cụ thể: bổ sung một bộ hướng dẫn đã chắt lọc, không làm mất thông tin, giúp Pass^4 trong lĩnh vực bán lẻ tăng 10 điểm (lên 67.5%) và cải thiện đáng kể kết quả trong lĩnh vực hàng không, thường không cần tăng số lượt hội thoại. Chi phí chính là token đầu vào do system prompt dài hơn, chứ không phải thêm các lượt gọi API. Phần chi phí token này phần lớn có thể được giảm bù bằng bộ nhớ đệm prompt và thiết kế ngữ cảnh cẩn thận, khiến phương pháp bộ nhớ trở nên hấp dẫn về mặt kinh tế cho các tương tác khách hàng có lưu lượng lớn.
Với các nhóm sản phẩm và vận hành, cách tiếp cận này giúp định hình lại nơi nên đầu tư công sức kỹ thuật để có lợi ích lâu dài nhất: tập trung nâng cao chất lượng bộ nhớ, tuyển chọn hướng dẫn và xây dựng công cụ quản lý vòng đời, thay vì mặc định chạy theo mô hình tiên phong tiếp theo. Tuy nhiên, bộ nhớ đã học không phải giải pháp vạn năng — nó phát huy tốt nhất khi quy trình mang tính thủ tục, chính sách ổn định và thao tác công cụ có tính xác định. Dưới đây, chúng tôi trình bày cơ chế hoạt động, so sánh với các phương án khác và danh sách kiểm tra thực tế để áp dụng.
Bộ nhớ so với tinh chỉnh, RAG và cá nhân hóa prompt
Hãy so sánh bốn phương pháp: bộ nhớ đã học được bổ sung vào prompt, tinh chỉnh trọng số, tạo sinh tăng cường truy xuất (RAG) và cá nhân hóa ở cấp prompt. Tinh chỉnh đưa hành vi vào các tham số của mô hình nhưng tốn kém, khó thích ứng giữa các lĩnh vực và mất nhiều thời gian để lặp chỉnh. RAG cung cấp kiến thức bên ngoài tại thời điểm truy vấn nhưng có thể đưa vào thông tin nhiễu, đòi hỏi kho vector và bước căn chỉnh, trong khi việc thực thi chính sách vẫn do mô hình đảm nhiệm. Cá nhân hóa prompt khá nhẹ nhưng thường không duy trì được qua các phiên. Bộ nhớ đã học nằm ở khoảng giữa: nó duy trì các ràng buộc quy trình mà không cần huấn luyện lại tốn kém, đồng thời vẫn hoạt động ngay cả khi không thể hoặc không nên truy xuất thông tin bên ngoài.
Xét về chi phí và quyền riêng tư, hướng dẫn đã học đánh đổi một khoản chi phí token prompt có thể dự đoán được để lấy độ phức tạp suy luận thấp hơn và cơ chế quản trị đơn giản hơn. Không cần bảo mật kho vector, còn các tạo tác huấn luyện chỉ gồm văn bản ngắn gọn, con người có thể kiểm tra. Với các nhóm bị ràng buộc bởi yêu cầu lưu trú dữ liệu hoặc cần khả năng khôi phục nhanh, cách này giảm rủi ro vận hành so với cả tinh chỉnh lẫn RAG.
Danh sách kiểm tra vận hành: xây dựng tác tử chăm sóc khách hàng tự cải thiện
Trước tiên, hãy thiết lập hệ thống ghi nhận hoạt động của tác tử để thu thập các chuỗi hành động có cấu trúc và những lần gọi công cụ. Thiết kế bước trích xuất hướng dẫn sao cho tạo ra các quy tắc ngắn, có thể kiểm thử, kèm số lần xuất hiện để cho biết có bao nhiêu lượt thực thi tạo ra quy tắc đó. Hãy thử nghiệm bộ quy tắc cốt lõi gọn nhẹ, có mức độ hỗ trợ cao, cho các môi trường đòi hỏi độ tin cậy cao; và dùng bộ đầy đủ, không làm mất thông tin khi độ bao phủ quan trọng hơn việc giảm tối đa kích thước prompt. Dùng bộ nhớ đệm prompt cho các khối hướng dẫn giống hệt nhau để giảm chi phí token khi vận hành.
Đưa các thực hành quản lý vòng đời vào vận hành: kiểm thử đơn vị tự động để xác thực khối hướng dẫn đã cập nhật trên trình mô phỏng chưa dùng trong huấn luyện, các bước phê duyệt thủ công đối với quy tắc nhạy cảm về quyền riêng tư, và chỉ số theo dõi cả độ chính xác trung bình lẫn độ tin cậy nghiêm ngặt (ví dụ Pass^4 hoặc chỉ số tương đương). Hãy coi khối hướng dẫn là một tạo tác có quản lý phiên bản và có thể khôi phục — thay prompt rất nhanh, giúp quá trình lặp chỉnh an toàn hơn.
Rủi ro, giới hạn và các cân nhắc về quyền riêng tư
Bộ nhớ đã học kế thừa một số rủi ro vốn có của mô hình, đồng thời tạo ra những rủi ro riêng. Nếu bước trích xuất hướng dẫn khuếch đại các mối tương quan sai lệch, nó có thể biến những kinh nghiệm không vững chắc thành quy tắc cứng nhắc. Sổ tay quy trình quá dài cũng có thể làm prompt phình to và tăng chi phí suy luận nếu không được lưu vào bộ nhớ đệm. Ngoài ra, nếu hướng dẫn được chắt lọc từ các lượt chạy có chứa dữ liệu khách hàng nhạy cảm, các nhóm cần làm sạch dữ liệu đầu vào và bảo đảm bản thân tạo tác hướng dẫn không làm lộ thông tin nhận dạng cá nhân (PII).
Các biện pháp giảm thiểu gồm đặt ngưỡng số lần hỗ trợ (chỉ giữ những quy tắc được nhiều tác vụ củng cố), xây dựng quy trình tự động ẩn danh thông tin trong dữ liệu vết huấn luyện, và thận trọng để con người rà soát các quy tắc liên quan đến mã định danh hoặc thao tác tài chính. Với các hệ thống triển khai chịu yêu cầu tuân thủ nghiêm ngặt, nên ưu tiên bộ nhớ ở cấp prompt không nhúng dữ liệu người dùng thô, đồng thời kết hợp với bộ kiểm thử có thể kiểm toán trước khi đưa vào vận hành.
