Thực hànhTrung cấp

Quản lý bộ nhớ hội thoại mà không giữ mọi thứ

Tách lịch sử, trạng thái công việc và sở thích lâu dài để hội thoại AI giữ đúng thông tin cần thiết khi kéo dài.

Trong bài viết này

Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.

Ở đầu cuộc chat, người dùng chọn workshop sáng. Sau đó họ đổi sang chiều. Khi hội thoại dài lên, hệ thống tóm tắt rằng “người dùng muốn học buổi sáng” và tiếp tục đặt lịch theo lựa chọn đã bị thay thế. Vấn đề nằm ở cách lưu trạng thái, không chỉ ở kích thước cửa sổ ngữ cảnh.

Bộ nhớ tốt cần giữ quyết định hiện hành, bằng chứng và khả năng sửa sai. Lưu toàn bộ lịch sử chưa tự giải quyết được ba việc ấy.

Tách ba loại thông tin

Lịch sử hội thoại là những gì đã được nói. Trạng thái công việc là những gì đang có hiệu lực. Sở thích lâu dài là thông tin có thể hữu ích cho công việc sau, nếu người dùng muốn hệ thống nhớ.

Trong tình huống giả định trên, lịch sử giữ cả lựa chọn sáng và chiều; trạng thái chỉ ghi ca hiện tại là chiều; sở thích không nên vội suy ra “luôn thích học chiều” từ một lần đổi lịch.

Tài liệu context windows của Anthropic mô tả ngữ cảnh là phần thông tin mô hình có thể tham chiếu khi sinh câu trả lời, khác với dữ liệu huấn luyện. Vì thế, một bản ghi nằm trong cơ sở dữ liệu nhưng chưa được truy xuất vào yêu cầu không tự trở thành điều mô hình đang biết.

Tóm tắt theo trạng thái có bằng chứng

Một bản ghi công việc có thể có hình dạng sau; đây là thiết kế minh họa, không phải schema API:

Mục tiêu: đăng ký workshop
Lựa chọn hiện tại: ca chiều
Bằng chứng: tin nhắn người dùng đổi ca
Ngày: chưa xác định
Việc còn chờ: người dùng chọn ngày
Lựa chọn đã hủy: ca sáng

Tách “chưa xác định” khỏi “đã từ chối”. Nếu bản tóm tắt bỏ sự khác biệt này, bước tiếp theo có thể hỏi lại điều người dùng đã bác bỏ hoặc tự điền một lựa chọn chưa được chốt.

Khi cập nhật, cho quyết định mới thay thế quyết định cũ có cùng phạm vi. Tuy nhiên, giữ dấu vết nguồn để có thể kiểm tra. Không cần đưa mọi dấu vết vào mỗi lần gọi mô hình; lưu riêng và truy xuất khi có tranh chấp hoặc yêu cầu giải thích.

Nhìn để hiểuMột câu trả lời lớn lên từng token

Mô hình tự hồi quy tính xác suất token tiếp theo từ ngữ cảnh hiện có, chọn một token rồi nối vào chuỗi. Chuỗi mới trở thành ngữ cảnh cho lượt tiếp theo.

Sinh văn bản bằng cách nối tiếp tokenSơ đồ dùng các từ Hôm, nay, trời, đẹp làm token giả định để dễ quan sát. Token thật có thể nhỏ hơn một từ. Mô hình dùng chuỗi hiện có để dự đoán token kế tiếp, chọn một token rồi lặp lại; các thanh xác suất chỉ mang tính minh họa.CHUỖI HIỆN CÓHômnayTOKEN CÓ THỂ TIẾP THEOtrờitôicótrờiChọn một tokenvà ghép vào chuỗiđẹp…Ngữ cảnh được nối dàiLặp lại cho token kế tiếpTách theo từ ở đây chỉ để minh họa.

↔ Vuốt ngang để xem toàn bộ sơ đồ.

  1. 01 / Đọc ngữ cảnh

    Mô hình xử lý các token của yêu cầu và phần trả lời đã có.

  2. 02 / Tính xác suất

    Từ ngữ cảnh đó, mô hình tính phân bố xác suất cho những token có thể xuất hiện tiếp theo.

  3. 03 / Chọn token

    Cách giải mã quyết định token được chọn; không phải lúc nào cũng lấy token có xác suất cao nhất.

  4. 04 / Nối và lặp

    Token được nối vào chuỗi để tạo ngữ cảnh mới. Quá trình lặp đến điều kiện dừng.

Các ô dùng từ nguyên vẹn để dễ quan sát; đây không phải kết quả của một tokenizer cụ thể. Token thực tế có thể chỉ là một phần của từ.

Dành ngân sách ngữ cảnh cho việc hiện tại

Giả sử bạn dành một phần ngân sách cho hướng dẫn hệ thống, một phần cho trạng thái, phần còn lại cho hội thoại gần đây và tài liệu liên quan. Đây là cách phân bổ theo chức năng, không phải tỷ lệ cố định áp dụng cho mọi ứng dụng.

Trước khi cắt bớt, hỏi nội dung nào cần để hoàn thành lượt hiện tại. Với câu “đổi ca đó sang chiều”, tin nhắn ngay trước có thể quan trọng hơn một bản hồ sơ sở thích dài. Với câu “so sánh quyết định hôm trước”, lịch sử cũ lại cần được truy xuất.

Tóm tắt tiết kiệm không gian nhưng có thể làm mất sắc thái. Giữ nguyên trích đoạn cho dữ kiện nhạy với câu chữ như điều kiện, phủ định và lựa chọn cuối cùng. Tránh tóm tắt nhiều tầng liên tục mà không đối chiếu với nguồn gốc.

Cho phép sửa và quên

Nếu hệ thống lưu “thích phản hồi ngắn”, người dùng cần có cách đổi lựa chọn đó. Một thông tin sai nhưng được chèn lặp lại vào mỗi prompt sẽ trở thành nguồn lỗi bền vững.

Đặt phạm vi cho mỗi bản ghi: chỉ cuộc chat này, chỉ dự án này hoặc dùng giữa các cuộc chat. Thông tin về một dự án không nên tự trở thành quy tắc toàn tài khoản. Khi xóa bộ nhớ, cần xử lý cả chỉ mục tìm kiếm và các bản tóm tắt dẫn xuất liên quan theo thiết kế lưu trữ của ứng dụng.

Lỗi thường gặp là lưu kết luận do trợ lý tự suy ra như lời người dùng xác nhận. Gắn loại nguồn cho bản ghi giúp hệ thống phân biệt điều được nói trực tiếp với giả thuyết đang chờ kiểm tra.

Bài tập: kiểm tra một lần đổi ý

Viết hội thoại giả định gồm chọn sáng, hỏi địa điểm, đổi sang chiều và cuối cùng hỏi “tôi đã chốt gì?”. Tạo bản tóm tắt ở giữa rồi trả lời chỉ dựa trên trạng thái được dựng lại.

Tiêu chí đạt: trả đúng ca chiều, vẫn biết ngày chưa chốt, không biến ca chiều thành sở thích lâu dài và truy được câu đổi ý. Thử tiếp yêu cầu “quên lựa chọn ca học”; dữ liệu bị quên không được âm thầm xuất hiện lại từ bản tóm tắt cũ.

Bạn muốn hiểu điều gì?

Khám phá tất cả bài viết esc để đóng