Một hệ thống AI được thiết kế để phân tích dữ liệu, nhưng lại bị chính dữ liệu đó làm cho tê liệt. Đó không phải một nghịch lý kỳ quặc, mà là vấn đề thực tế mà hầu hết những người xây dựng AI agent đang gặp phải. Sally-Ann Delucia, trưởng bộ phận sản phẩm tại Arise, đã chia sẻ câu chuyện một năm đấu tranh với vòng lặp tệ hại này—và cách nhóm cô thoát ra.
▶ Xem video: Prompt không quan trọng, Context mới quyết định chất lượng AI Agent
Vì sao "nhồi càng nhiều thông tin càng tốt" là chiến lược sai
Arises là nền tảng giúp người dùng theo dõi và phân tích dữ liệu từ các ứng dụng AI. Khi nhóm Sally-Ann xây dựng Alex—một agent để giúp phân tích những traces và spans (nhật ký của mỗi bước AI)—họ gặp phải vấn đề cơ bản: dữ liệu quá lớn.
Một trace đơn lẻ chứa input của người dùng, các bước xử lý, metadata, kết quả trung gian. Khi người dùng muốn xem không phải một mà hàng trăm traces, dữ liệu cứ nhân lên. Alex cố đọc hết, bị quá tải, thất bại. Nhóm thêm dữ liệu vào để Alex hiểu hơn. Thế là Alex lại thất bại. Vòng lặp này tiếp diễn không ngôi.
Sally-Ann mô tả tình huống một cách sắc sảo: "Hệ thống dùng để phân tích dữ liệu, lại bị chính dữ liệu đó làm cho tê liệt." Đây không phải vấn đề riêng của Arise. Bất kỳ chatbot hỗ trợ khách hàng nào cũng bị ngập trong lịch sử hội thoại. Một agent phân tích tài chính bị choáng bởi số liệu. Trợ lý AI trong ứng dụng giáo dục mất dần khả năng nhớ bài đã học.
Giải pháp đầu tiên mà nhóm thử là cắt bớt: lấy 100 ký tự đầu, bỏ phần còn lại. Đơn giản, dễ làm. Nhưng khi người dùng hỏi thêm, Alex không nhớ gì về câu hỏi trước. Mỗi câu hỏi tiếp theo giống như một cuộc trò chuyện hoàn toàn mới—không thể sử dụng được.
Giải pháp thứ hai là tóm tắt: dùng AI để nén context thành đoạn ngắn hơn. Nghe hợp lý, nhưng vấn đề là AI tóm tắt không ai kiểm soát được. Đôi khi nó giữ thứ không quan trọng. Đôi khi nó bỏ đi thứ rất quan trọng. Kết quả không ổn định. Bài học đầu tiên: giao quyền quyết định hoàn toàn cho AI mà không có cấu trúc rõ ràng, thì kết quả sẽ không thể dự đoán.
Smart Truncation Memory: Cách không phí phạm gì
Thay vì để AI tóm tắt, hoặc cắt cộc lốc, nhóm Arise xây dựng "smart truncation memory"—bộ nhớ cắt tỉa thông minh. Ý tưởng rất đơn giản nhưng hiệu quả:
- Giữ lại 100 ký tự đầu của context
- Giữ lại 100 ký tự cuối
- Phần giữa được cắt ra nhưng lưu vào một kho riêng
- Với các công cụ được gọi nhiều lần, chỉ giữ kết quả mới nhất, không giữ tất cả các lần gọi cũ
- System prompt (hướng dẫn cốt lõi) không bao giờ bị xóa hay thay thế
Thực tế, đây chính là cách não người làm việc. Bạn không nhớ từng chi tiết của một cuộc họp ba tiếng. Bạn nhớ phần mở đầu, những thứ mới nhất, và ghi chép lại những điểm quan trọng ở giữa để khi cần thì lật ra. Alex giờ cũng làm vậy.
Điều thú vị là sau này, khi Anthropic công bố cách Claude Code hoạt động, nhóm Sally-Ann phát hiện ra Claude đang dùng chiến lược tương tự—kết hợp cắt tỉa và nén dữ liệu. Khi hai nhóm độc lập, xây dựng hoàn toàn tách biệt, lại đi đến cùng một kết luận, đó thường là dấu hiệu cho thấy đây là hướng đúng.
Phát hiện lỗi âm thầm: Long Session Evaluations
Alex hoạt động tốt hơn. Nhưng người dùng không tắt chat. Họ cứ nói chuyện mãi trong một phiên duy nhất, hỏi thêm, hỏi thêm. Đến câu hỏi thứ hai mươi hay ba mươi, Alex bắt đầu sai—không sai rõ ràng, mà sai âm thầm ở cuối khi không ai còn để ý kỹ.
Nhóm phát hiện điều này theo cách tệ nhất: người dùng phàn nàn, hoặc Sally-Ann ngồi xem lại data và thấy Alex quên thông tin từ đầu buổi.
Giải pháp là xây dựng "long session evals" (kiểm thử phiên dài). Cách làm cụ thể: nạp vào mười lượt hội thoại, rồi kiểm tra lượt thứ mười một xem context có còn chính xác không. Bây giờ lỗi có thể tái hiện được, đo lường được, và sửa được—thay vì chờ người dùng phàn nàn.
Bài học thứ hai: lỗi xuất hiện muộn trong một quy trình dài thường là lỗi nguy hiểm nhất, vì chúng không bị phát hiện sớm. Giải pháp không chỉ là cố gắng làm hệ thống không lỗi, mà thiết kế cách để lỗi có thể bộc lộ sớm hơn, rõ ràng hơn.
Kiến trúc Multi-Agent: Tách ra, không phải làm hết
Kể cả với smart truncation và long session evals, vẫn còn những tác vụ mà Alex không xử lý tốt. Đó là lúc cần tìm kiếm trong hàng trăm traces, chạy nhiều truy vấn song song, và thực hiện rất nhiều bước suy luận trung gian—tất cả đó nằm trong một context duy nhất của một agent duy nhất. Context bị ngập trong dữ liệu tạm thời.
Sally-Ann mô tả giải pháp như sau: thay vì một agent làm tất cả, bạn tách ra. Có một main agent lo việc hội thoại với người dùng, chỉ giữ context nhẹ. Khi cần làm việc nặng—tìm kiếm dữ liệu, phân tích phức tạp—main agent giao việc cho sub-agent (agent phụ). Sub-agent làm xong, trả kết quả về. Main agent không cần biết sub-agent làm gì bên trong, chỉ cần biết kết quả.
Đây là điểm quan trọng nhất trong toàn bộ câu chuyện—không phải vì nó là kỹ thuật mới, mà vì nó phản ánh một nguyên tắc cũ: phân chia trách nhiệm. Trong một tổ chức làm việc tốt, bạn không để một người làm tất cả. Bạn có người lo chiến lược, người lo vận hành, người lo chi tiết kỹ thuật. Mỗi người chỉ cần biết những gì liên quan đến vai trò của mình.
Tương tự ở Việt Nam, trong nhiều doanh nghiệp vừa và nhỏ, vẫn có thói quen để một người làm tất cả hoặc một cuộc họp giải quyết mọi thứ. Kết quả là mọi người biết mọi thứ, không ai tập trung vào việc của mình, và "thông tin" thực ra là nhiễu.
Kiến trúc sub-agent mà Sally-Ann mô tả là phiên bản kỹ thuật của việc thiết kế tổ chức rõ ràng. Main agent chỉ biết những gì cần để nói chuyện. Sub-agent chỉ biết những gì cần để hoàn thành nhiệm vụ cụ thể. Ranh giới rõ ràng. Context sạch. Kết quả tốt hơn.
Đây cũng là hướng mà ngành AI agent đang đi rất nhanh: không phải một AI làm tất cả, mà là nhiều AI nhỏ mỗi cái làm một việc, phối hợp với nhau. Multi-agent system (hệ thống đa tác nhân) đang từ từ trở thành cách mặc định để xây dựng ứng dụng AI phức tạp.
Điều chưa giải quyết được
Sally-Ann nói thẳng về những gì nhóm cô vẫn chưa giải quyết. Cô không kết bằng một slide tổng kết đẹp đẽ kiểu "chúng tôi đã giải quyết tất cả". Long-term memory vẫn còn khó. Người dùng bắt đầu chat mới, Alex không nhớ gì từ phiên trước. Nếu bạn nói chuyện với Alex hôm qua về một vấn đề, hôm nay mở chat mới, bạn phải giải thích lại từ đầu.
Và context selection vẫn còn là heuristic—quy tắc kinh nghiệm chứ chưa phải nguyên tắc có cơ sở rõ ràng. Lấy 100 ký tự đầu, 100 ký tự cuối là con số họ chọn vì nó có vẻ hoạt động, chứ không phải vì có lý thuyết chứng minh đó là con số tối ưu.
Thực tế, đây là tình trạng chung của toàn ngành. Rất nhiều thứ trong AI agent hiện nay hoạt động được vì người ta thử đi thử lại và tìm ra cái gì ổn, chứ không phải vì có nền tảng lý thuyết vững chắc. Đây không phải điều xấu—đây là giai đoạn mà những người thực hành đang đi nhanh hơn lý thuyết. Nhưng nó cũng có nghĩa là bạn không nên tin vào bất kỳ giải pháp nào một cách tuyệt đối, kể cả giải pháp của Arise.
Q: Tại sao context lại quan trọng hơn prompt?
Agents không thất bại vì bạn viết prompt chưa hay. Chúng thất bại vì chúng nhìn thấy thông tin sai, quá nhiều, hoặc không đúng lúc. Đây là sự thay đổi tư duy cơ bản mà bất kỳ ai xây dựng ứng dụng AI cũng cần nhận ra.
Q: Nên cắt bớt hay tóm tắt context?
Cắt bớt cộc lốc thì mất trí nhớ. Tóm tắt nghe hay nhưng không kiểm soát được. Cái hoạt động là cắt tỉa có chọn lọc (giữ đầu và cuối, cắt giữa), kết hợp với lưu trữ để lấy lại khi cần, và có cách kiểm thử những lỗi xuất hiện muộn.
Q: Khi nào nên chia agent thành nhiều agent nhỏ?
Khi một agent phải xử lý quá nhiều tác vụ nặng song song, hoặc khi cần giữ context sạch để hội thoại suôn sẻ. Tách main agent (hội thoại) và sub-agent (tác vụ nặng) giúp ranh giới rõ ràng, context sạch, kết quả tốt hơn.
