Giữ thông tin quan trọng trong cuộc trò chuyện dài

Context là toàn bộ những gì Claude thấy trong một lần gọi: system prompt, lịch sử trò chuyện, kết quả tool. Cuộc trò chuyện càng dài, context càng đầy, và những chi tiết quan trọng dễ bị chìm hoặc mất khi bạn rút gọn.

Bài này giúp bạn trả lời: trong một cuộc trò chuyện dài, làm sao để Claude vẫn nhớ đúng số tiền, mã đơn, lời hứa với khách?

Ví dụ xuyên suốt: agent hỗ trợ của cửa hàng đồ gia dụng online

Một cửa hàng đồ gia dụng online dùng agent hỗ trợ khách qua chat. Một khách nhắn suốt 40 phút về hai chuyện: máy xay sinh tố mua ngày 03/10 (đơn DH-58213, 1.290.000 đồng) bị nứt cối, muốn đổi; và nồi chiên không dầu (đơn DH-58977) giao thiếu khay, muốn hoàn 150.000 đồng. Khách còn dặn "đổi máy thì giao trước thứ Bảy giúp tôi".

Để cuộc trò chuyện không quá dài, hệ thống tóm tắt các lượt cũ. Sau vài lần tóm tắt:

1. Bản tóm tắt chỉ còn "khách có vấn đề với hai đơn hàng, đang xử lý đổi trả". Mất số tiền, mất mã đơn, mất lời dặn giao trước thứ Bảy.
2. Mỗi lần gọi tra_don_hang, tool trả về hơn 40 trường: kho xuất, mã vận đơn, mã khuyến mãi, lịch sử trạng thái… Context đầy những thứ không dùng tới.
3. Một bản thử nghiệm quên gửi lịch sử, nên tới lượt sau agent hỏi lại khách "anh cho em xin mã đơn".

Tóm tắt dần làm mất chi tiết

Rút gọn các lượt cũ thành bản tóm tắt (progressive summarization) là cách phổ biến để cuộc trò chuyện dài không tràn context. Rủi ro là bản tóm tắt hay biến số liệu, phần trăm, ngày tháng và kỳ vọng khách đã nói thành những câu chung chung. "1.290.000 đồng" thành "một khoản tiền", "giao trước thứ Bảy" biến mất.

Cách sửa: tách các sự thật giao dịch ra khỏi phần được tóm tắt, giữ chúng trong một khối riêng (case facts block) và gửi kèm ở mỗi lượt:

<case_facts>
Đơn DH-58213: máy xay, 1.290.000đ, mua 03/10, nứt cối. Đổi máy mới. Khách muốn giao trước thứ Bảy.
Đơn DH-58977: nồi chiên, giao thiếu khay. Hoàn 150.000đ. Đã duyệt, chưa chuyển tiền.
</case_facts>

Phần trò chuyện chung có thể tóm tắt thoải mái; khối này thì không bao giờ bị tóm tắt, chỉ được cập nhật khi có thay đổi. Khi khách có nhiều vấn đề trong một phiên, hãy giữ dữ liệu từng vấn đề (mã đơn, số tiền, trạng thái) có cấu trúc trong một lớp context riêng như trên, mỗi vấn đề một mục.

Kết quả tool chiếm context

Vấn đề 2: 40 trường mỗi lần tra đơn, trong khi việc đổi trả chỉ cần khoảng 5 trường (mã đơn, ngày mua, sản phẩm, số tiền, trạng thái). Gọi tool vài lần là context đã chứa hàng trăm trường thừa. Kết quả tool dồn lại trong context và tốn token nhiều hơn hẳn mức hữu ích của chúng.

Cách sửa là cắt bớt kết quả tool trước khi đưa vào context: chỉ giữ các trường liên quan tới đổi trả. Bài viết của Anthropic về thiết kế tool cũng khuyên tool chỉ nên trả về thông tin thật sự hữu ích cho agent, và dùng phân trang, lọc hoặc cắt bớt cho những kết quả có thể rất dài.

Thông tin ở giữa dễ bị bỏ sót

Đề thi nhắc tới hiện tượng lost in the middle: với đầu vào dài, model xử lý tốt thông tin ở đầu và cuối, nhưng có thể bỏ sót phát hiện nằm ở giữa. Tài liệu Claude API mô tả hiện tượng chung là context càng nhiều token thì độ chính xác và khả năng nhớ lại càng giảm, gọi là context rot, nên chọn lọc cái gì vào context cũng quan trọng như context rộng bao nhiêu.

Giả sử cửa hàng chạy một agent tổng hợp phản hồi của 300 khách trong tháng, gộp kết quả của nhiều subagent thành một đầu vào dài. Để giảm bỏ sót:

• Đặt bản tóm tắt các phát hiện chính ở đầu đầu vào.
• Chia phần chi tiết thành các mục có tiêu đề rõ ràng ("Lỗi sản phẩm", "Giao hàng", "Chăm sóc khách").

Tài liệu prompt của Anthropic cũng khuyên với tài liệu dài, đặt tài liệu ở đầu prompt và câu hỏi ở cuối, bọc mỗi tài liệu trong thẻ kèm thông tin nguồn.

Khi subagent gửi kết quả cho agent khác, còn hai điều nên làm: bắt subagent ghi kèm thông tin phụ (ngày, vị trí trong nguồn, cách thu thập) để bước tổng hợp hiểu đúng; và khi agent phía sau có ít chỗ trong context, sửa agent phía trước để trả dữ liệu có cấu trúc (sự thật chính, trích dẫn, điểm liên quan) thay vì cả đoạn văn dài kèm lập luận.

Gửi đủ lịch sử mỗi lần gọi

Vấn đề 3 là lỗi cơ bản nhưng hay gặp. Mỗi lần gọi Messages API, Claude chỉ thấy những gì có trong yêu cầu đó. Tài liệu Claude API mô tả đầu vào của mỗi lượt gồm toàn bộ lịch sử trò chuyện trước đó cộng tin nhắn mới. Không gửi lịch sử thì Claude không biết khách đã nói gì, nên hỏi lại mã đơn như thể mới gặp.