Bộ nhớ AI cần ngày hết hạn

Databricks giới thiệu Agent Memory ở giai đoạn beta vào ngày 20 tháng 10 năm 2026. Thông báo này là điểm khởi đầu thời sự cho bài viết tuần này.

Nghiên cứu MemCurrent đi kèm tách riêng các phiên nguyên bản và thông tin ghi nhớ đã chắt lọc, được duy trì bằng các cập nhật tức thời và quá trình hợp nhất chạy nền.

Câu hỏi quan trọng hơn về sản phẩm xuất hiện sau đó: điều gì xảy ra khi một điều từng đáng ghi nhớ không còn đúng nữa? Một trợ lý hữu ích cần duy trì sự liên tục, nhưng nếu không có khả năng điều chỉnh, sự liên tục ấy có thể khiến sai lầm của ngày hôm qua tồn tại dai dẳng khác thường. Phần dưới đây là phân tích của chúng tôi về thiết kế, không phải khẳng định rằng bản beta này đã triển khai mọi tính năng được mô tả.

Thông tin ghi nhớ cần nhiều hơn ngày tạo

Hãy xét một trợ lý dự án giả định. Vào thứ Hai, nhóm cho biết họ sẽ ra mắt vào thứ Sáu. Đến thứ Tư, thời điểm ra mắt được chuyển sang tháng sau. Một hệ thống có thể truy xuất hoàn toàn chính xác phát biểu hôm thứ Hai mà vẫn đưa ra câu trả lời sai. Vấn đề không phải là thiếu thông tin. Vấn đề là coi một ghi nhận trong quá khứ như nhận định vẫn đúng ở hiện tại.

Ba mốc thời gian giúp phân biệt những ý nghĩa này. Hệ thống biết thông tin đó khi nào? Thông tin đó dự kiến áp dụng trong khoảng thời gian nào? Khi nào cần kiểm tra lại? Một sở thích khi đi du lịch có thể hữu ích trong nhiều năm, trong khi địa chỉ giao hàng tạm thời nên hết hiệu lực khi chuyến đi kết thúc. Áp dụng cùng một thời hạn lưu giữ cho cả hai sẽ đánh đồng sự thuận tiện trong lưu trữ với cuộc sống thực tế của người dùng.

Vì vậy, việc hết hạn nên làm thay đổi điều kiện để thông tin được sử dụng, chứ không phải lúc nào cũng xóa ngay bản ghi lịch sử. Ngày ra mắt cũ vẫn có thể giải thích vì sao một kế hoạch đã được lập. Nó không nên âm thầm chi phối lại một kế hoạch mới chỉ vì cách diễn đạt của nó tình cờ khớp sát với câu hỏi.

Lời đính chính phải giữ được hiệu lực trước lịch sử của chính nó

Một tình huống giả định thứ hai cho thấy vấn đề rõ hơn. Người dùng nói rằng họ thích họp vào buổi sáng, sau đó đính chính thành buổi chiều trong sáu tuần tiếp theo. Một bộ nhớ hữu ích sẽ giữ đúng phạm vi tạm thời đó, liên kết thay đổi với sở thích trước đây và lên lịch xem xét lại. Nó không gộp hai phát biểu thành một sở thích trung bình, cũng không biến ngoại lệ tạm thời thành vĩnh viễn.

Lời đính chính cũng không nên phụ thuộc vào việc giành chiến thắng trong một cuộc đua về số lượng. Mười bản tóm tắt cũ có thể cùng nhắc lại sở thích họp buổi sáng. Một lời đính chính rõ ràng và phù hợp với tình huống phải được ưu tiên hơn tất cả những bản đó. Sự lặp lại có thể phản ánh số lần hệ thống sao chép một phát biểu, chứ không phải mức độ người dùng tán thành phát biểu ấy.

Điều này gợi ý một mô hình quản lý nhận định theo phiên bản: nhận định đang được sử dụng, khoảng thời gian và bối cảnh áp dụng, cùng mối liên hệ với nhận định mà nó thay thế. Khi khoảng thời gian đó kết thúc, hệ thống nên làm theo phương án tiếp theo mà người dùng đã nêu, hoặc đánh dấu sở thích này là chưa chắc chắn. Sự im lặng là căn cứ yếu để khôi phục một quy tắc cũ.

Giao diện quan trọng chính là cuộc trò chuyện thông thường tiếp theo. Nếu người dùng phải mở lại bảng cài đặt sau mỗi lần đính chính, bộ nhớ đã đẩy công việc bảo trì trở lại cho người mà nó được tạo ra để hỗ trợ.

Có người chịu trách nhiệm nghĩa là có người giải quyết được bất đồng

Ở đây, quyền làm chủ được hiểu là trách nhiệm thực tế, không phải một tuyên bố về quyền sở hữu pháp lý. Một người có thể sửa lại sở thích của chính mình. Người phụ trách dự án có thể điều chỉnh những giả định vận hành của dự án. Suy luận của trợ lý phải được thể hiện sao cho dễ phân biệt với cả hai loại thông tin đó. Đây là những loại nhận định khác nhau, ngay cả khi được lưu trong cùng một cơ sở dữ liệu.

Hãy hình dung một trợ lý suy ra rằng người dùng không thích các buổi workshop vì họ đã từ chối hai lời mời. Đó vẫn chỉ là một cách diễn giải sơ bộ. Nó không nên trở thành một đặc điểm cá nhân lâu dài chỉ vì một hệ thống tóm tắt về sau viết lại điều đó với giọng chắc chắn hơn. Người chịu trách nhiệm về thông tin này cần có cách dễ dàng bác bỏ suy luận mà không phải phủ nhận những sự việc làm cơ sở cho nó.

Vì thế, giao diện bộ nhớ nên hỗ trợ một số lựa chọn dễ hiểu: giữ lại thông tin này, dùng đến một ngày nhất định, thay thế thông tin này và ngừng sử dụng thông tin này. Dữ liệu xuất ra cũng cần giữ được ý nghĩa, không chỉ phần văn bản. Chuyển một nhận định cũ sang trợ lý mới mà không kèm trạng thái đã bị thay thế có thể làm sống lại điều người dùng đã đính chính.

Lưu giữ kéo theo chi phí bảo trì

Bài toán chi phí không chỉ nằm ở số byte. Mỗi nhận định được giữ lại có thể đòi hỏi việc truy xuất, xử lý mâu thuẫn, xem xét lại và sự chú ý của người dùng trong tương lai. Kho dữ liệu ngày càng lớn có thể tạo ra chi phí ngay cả khi bản thân việc lưu trữ không đắt. Đây là những cân nhắc về thiết kế, không phải kết quả đo lường của một sản phẩm cụ thể.

Một câu hỏi hữu ích khi phân bổ nguồn lực là: thông tin ghi nhớ này giúp giảm công việc nào trong tương lai, và có thể tạo ra những sai lầm nào? Một chỉ dẫn liên tục ngăn được cùng một lỗi biên tập có thể xứng đáng được giữ lại. Một gợi ý nhà hàng chỉ dùng một lần chưa chắc cần trở thành sở thích lâu dài. Giữ lại bằng chứng cho một công việc đã hoàn thành và nạp bằng chứng ấy vào mọi công việc sau này là hai quyết định riêng biệt.

Các nhóm có thể phân biệt thông tin ghi nhớ đang có hiệu lực, bối cảnh lịch sử và những nhận định đã ngừng sử dụng. Phần đang có hiệu lực nên gồm một tập thông tin nhỏ, được duy trì cẩn thận. Bối cảnh lịch sử vẫn sẵn có khi câu hỏi thực sự đề cập đến quá khứ. Những nhận định đã ngừng sử dụng không được quay lại luồng truy xuất thông thường chỉ vì một tiến trình nền xây dựng lại chỉ mục.

Việc xóa đặt ra một phép thử vận hành có liên quan. Nếu người dùng xóa một sở thích do hệ thống suy ra, liệu một cuộc trò chuyện cũ có thể tự động tái tạo sở thích đó vào ngày mai không? Sản phẩm cần có câu trả lời rõ ràng. Ngăn việc trích xuất trong tương lai và xóa toàn bộ các bản ghi làm cơ sở là hai yêu cầu khác nhau, không nên âm thầm thay thế yêu cầu này bằng yêu cầu kia.

Kiểm thử sự thay đổi, không chỉ khả năng nhớ lại

LongMemEval có các hạng mục đánh giá về suy luận thời gian, cập nhật kiến thức và không đưa ra câu trả lời. Bài nghiên cứu của Zep vào tháng 1 năm 2025 đề xuất một đồ thị tri thức theo thời gian lưu giữ các mối quan hệ trong quá khứ. Không tài liệu nào trong hai tài liệu này tự thân kiểm chứng bản beta mới của Databricks; chúng cung cấp bối cảnh nghiên cứu riêng biệt.

Với bên mua và bên xây dựng sản phẩm, một bộ kiểm thử vòng đời ngắn gọn có thể giúp cuộc thảo luận trở nên cụ thể. Tất cả các mục dưới đây là những phép thử giả định được đề xuất, không phải các sự cố khách hàng đã được ghi nhận:

• Thay đổi một thời hạn sau khi nó đã xuất hiện trong nhiều bản tóm tắt. Kế hoạch tiếp theo phải dùng ngày đã sửa mà không xóa mất lý do của những quyết định trước đó.
• Thêm một sở thích tạm thời có ngày kết thúc. Sau thời điểm đó, trợ lý nên làm theo phương án tiếp theo đã được nêu rõ hoặc hỏi lại, thay vì tự quyết định rằng sở thích này là vĩnh viễn hay phải quay về trạng thái cũ.
• Trực tiếp đính chính một sở thích do hệ thống suy ra. Lời đính chính phải được ưu tiên hơn các bản sao của suy luận ban đầu, kể cả những bản sao được tạo về sau từ tài liệu cũ.
• Hỏi tháng trước hệ thống đã coi điều gì là đúng và hiện tại đang coi điều gì là đúng. Câu trả lời phải khác nhau ở những điểm bản ghi đã thay đổi, đồng thời thể hiện rõ sự chưa chắc chắn.
• Ngừng sử dụng một thông tin ghi nhớ, xây dựng lại chỉ mục tìm kiếm và nhập một bản xuất dữ liệu cũ. Không thao tác nào được âm thầm kích hoạt lại nhận định đã ngừng sử dụng.
• Để một thông tin có hệ quả lớn chưa được xác minh quá ngày cần xem xét lại. Trợ lý nên xác minh hoặc nêu rõ khoảng trống đó, thay vì thể hiện một điều quen thuộc như thể đó là thông tin mới được cập nhật.

Những phép thử này cần các thước đo ngoài độ chính xác truy xuất: độ trễ khi áp dụng đính chính, việc sử dụng thông tin đã hết hạn, sự xuất hiện trở lại sau khi ngừng sử dụng và những câu hỏi không cần thiết do quên quá nhiều. Một thiết kế yêu cầu người dùng xác nhận lại mọi thứ có thể tránh được các khẳng định lỗi thời, nhưng đồng thời cũng làm mất lợi ích của bộ nhớ.

Cam kết hữu ích nằm ở khả năng điều chỉnh

Bộ nhớ lâu dài có giá trị nhất khi giúp người dùng không phải lặp lại chính mình mà không mắc kẹt trong một phiên bản cũ của cuộc sống. Cam kết của sản phẩm cần dễ hiểu: đây là điều tôi hiện coi là đúng, đây là thời điểm và hoàn cảnh áp dụng, và đây là cách lời đính chính của bạn thay đổi những gì diễn ra tiếp theo.

Khi bộ nhớ của tác tử trở thành hạ tầng, khía cạnh đáng so sánh là khả năng duy trì một tập thông tin làm việc nhỏ, có thể điều chỉnh một cách đáng tin cậy. Chỉ riêng dung lượng lưu trữ không thể cho biết liệu lời đính chính có còn chi phối quyết định tiếp theo hay không.