Memoryfields: Giải pháp bộ nhớ cho AI dưới dạng tệp tin đơn giản

Tháng 8 năm 2026

Memoryfields - một cách đơn giản hơn nhiều để thực hiện bộ nhớ cho tác nhân (agent)

Nhiều tiêu chuẩn đánh giá (benchmark) mô hình bắt đầu từ một cửa sổ ngữ cảnh trống rỗng. Đó là "tờ giấy trắng" của AI. Ở một mức độ nào đó, điều này là hợp lý để giữ cho các bài đánh giá được công bằng.

Nhưng các tác nhân thực tế không bao giờ nên bắt đầu từ một cửa sổ ngữ cảnh trống rỗng. Chúng nên bắt đầu với càng nhiều thông tin liên quan càng tốt. Các tác nhân AI của bạn nên bắt đầu với những ký ức.

Tại sao các hệ thống bộ nhớ tác nhân hiện tại dường như không hiệu quả

Vấn đề là, rất nhiều hệ thống bộ nhớ tác nhân thực sự khá tệ. Tôi nghĩ hiện tại có khoảng ba loại hệ thống bộ nhớ phổ biến, và mỗi loại đều có những khiếm khuyết riêng.

Loại đầu tiên là những hệ thống cố tình trói buộc bạn vào một khung công cụ (harness) cụ thể - thường do chính phòng thí nghiệm cho bạn thuê khung công cụ đó viết ra. Phòng thí nghiệm này đang rất muốn chuyển dịch từ "kinh doanh API" (vốn cạnh tranh khốc liệt) sang "kinh doanh nền tảng" (mang lại lợi nhuận cao hơn nhiều). Hệ thống dạng này thường hoạt động bằng cách khai thác thông tin từ lịch sử trò chuyện của bạn, dẫn đến kết quả là hầu hết các ký ức đều chỉ xoay quanh bạn, mặc dù thông tin về thế giới thường hữu ích hơn nhiều.

Một loại khác thì phức tạp một cách lố bịch. Tôi biết một hệ thống nổi bật cần đến pgvector, cơ sở dữ liệu đồ thị Neo4j và cả một LLM riêng chỉ để quyết định điều gì đáng ghi nhớ. Sự phức tạp này không chỉ khó quản lý mà còn gây nhiễu cho chính các mô hình, vì những lý do tôi sẽ giải thích sau. Chúng cũng không thể mở rộng theo sự phát triển của các mô hình tiên tiến.

Loại cuối cùng là kiểu "High Modernist" (Hiện đại cao cấp), vốn tưởng tượng ra một dạng bộ nhớ lý tưởng hóa và duy lý. Không thể tránh khỏi, loại này liên quan đến đồ thị và đôi khi cả các mệnh đề logic. Cách này tách biệt thông tin khỏi ngữ cảnh một cách có hệ thống, khiến nó trở nên cô lập và vô nghĩa đối với tác nhân (và cả bạn). Suy cho cùng, một danh sách đơn giản gồm các "sự thật được chắt lọc" thì hữu ích đến mức nào?

Điểm chung của chúng là coi bộ nhớ như một quy trình. Nhưng bộ nhớ - đặc biệt là đối với một mô hình - được thể hiện dưới dạng dữ liệu sẽ tốt hơn nhiều.

Bộ nhớ nên là một định dạng dữ liệu, không phải là một đường ống (pipeline) đa giai đoạn

Brooks đã nói:

Hãy cho tôi xem các lưu đồ của bạn và giấu đi các bảng dữ liệu, tôi sẽ vẫn thấy khó hiểu. Hãy cho tôi xem các bảng dữ liệu, tôi thường sẽ không cần đến lưu đồ của bạn nữa; chúng sẽ trở nên hiển nhiên.

Vì vậy, đây là định dạng tệp bộ nhớ di động "memoryfield":

Một memoryfield là:

Các tác nhân hoạt động tốt nhất với các tệp tin. Hãy để tôi giải thích.

Quyết định thiết kế 1: sử dụng văn xuôi, không dùng các đoạn nhỏ (chunks) hay "sự thật" rời rạc

Lý do chính khiến các đường ống RAG (Retrieval-Augmented Generation) trở nên rất phức tạp là vì chúng cố gắng làm cho một khối lượng lớn các tài liệu hiện có do con người viết trở nên dễ đọc đối với một tác nhân AI. Thông thường, các tài liệu này rất khó để tác nhân đọc trực tiếp, ví dụ: vì chúng là các tệp PDF lớn.

Nhưng bộ nhớ của tác nhân không phải là các tài liệu cũ phức tạp. Một ký ức, tại thời điểm được hình thành, đang xảy ra trực tiếp với một tác nhân AI vốn hoàn toàn có khả năng viết văn xuôi. Văn xuôi đó không cần phải chia nhỏ, làm giàu, tóm tắt hai lần hay xử lý cơ học theo bất kỳ cách nào khác: chỉ cần để tác nhân viết ký ức trực tiếp bằng định dạng ưa thích của nó (đó là Markdown).

Một trang memoryfield trông như thế này:

Phải thừa nhận rằng, một hạn chế là trang đó phải đủ ngắn để vừa với một vector embedding: vì vậy có một giới hạn mềm khoảng 8kb (~2000 token).

Nhưng trong thực tế, đây là một hạn chế rất có lợi: 8.000 ký tự tương đương khoảng 1.300 từ, hoặc độ dài của một bài báo tạp chí cỡ trung bình. Trên thực tế, đó là một hạn chế hợp lý để áp dụng. Để thêm chi tiết, hãy thêm các trang khác - các tác nhân không gặp khó khăn gì khi làm việc này.

Quyết định thiết kế 2: nhảy vọt ngữ nghĩa (semantic jump), không duyệt đồ thị (graph walking)

Một tiền lệ quan trọng là Karpathy wikis. Karpathy wikis được định hướng xung quanh các tệp Markdown có siêu liên kết: mô phỏng theo những tệp được sử dụng bởi Roam hoặc Obsidian. Ý tưởng là tác nhân sẽ duyệt qua "đồ thị tri thức" để tìm các trang liên quan.

Nhưng trong thực tế, việc để một tác nhân AI duyệt qua đồ thị tri thức vừa chậm vừa không đáng tin cậy - đồng thời gây bối rối cho tác nhân.

Việc duyệt qua rất chậm vì mô hình cần thường xuyên dừng lại để thực hiện các lệnh gọi công cụ (tool calls) tuần tự nhằm đọc các trang kế tiếp.

Thuật toán thô để một tác nhân duyệt đồ thị tri thức:

Nếu thông tin liên quan nằm sâu N bước trong đồ thị tri thức, cần N+1 lệnh gọi công cụ để truy xuất nó. Điều này rất chậm, vì mô hình LLM trị giá hàng tỷ (nghìn tỷ?) đô la của bạn phải tạm dừng cho mỗi lệnh gọi công cụ, mỗi lệnh mất khoảng 2-3 giây. Nó cũng gây bất lợi lớn cho các đồ thị tri thức có cấu trúc lồng sâu, điều mà thẳng thắn mà nói, đi ngược lại toàn bộ mục đích của chúng.

Các đồ thị tri thức cũng không đáng tin cậy. Vì AI chỉ có thể biết liệu tài liệu có liên quan hay không bằng cách nhìn vào văn bản liên kết, hoặc có thể là tiêu đề trang nếu nó được ngoại hóa theo cách nào đó. Điều đó gây áp lực lớn lên tác nhân trong việc thực hiện các thủ thuật hack metadata trang kiểu SEO những năm 1990 để đảm bảo văn bản liên kết/tiêu đề/chú thích của mỗi trang phải ngắn gọn và chính xác. Làm như vậy sẽ trừng phạt sự lạc đề, việc ghi chú các chi tiết bên lề và kiểu kiến thức ngầm vốn vừa phổ biến vừa rất hữu ích trong các kho văn bản lớn hơn.

Trong thực tế, thông tin liên quan thường bị bỏ lỡ trong Karpathy wikis vì nó không được đặt tiêu đề hoặc chú thích theo cách đủ hấp dẫn đối với tác nhân đang tìm kiếm.

Và các đồ thị tri thức cũng gây bối rối cho tác nhân vì chúng thường phải nghiền ngẫm rất nhiều thông tin không liên quan khi di chuyển quanh đồ thị. Việc vô tình đọc phải thông tin không liên quan (trang chủ thường là thủ phạm chính) tạo ra một đống nhiễu trong cửa sổ ngữ cảnh của mô hình, làm giảm chất lượng đầu ra và khiến chúng trông như bị ám ảnh bởi những thứ kỳ lạ.

Tất cả những điều này được giải quyết bằng cách sử dụng tìm kiếm ngữ nghĩa để nhảy trực tiếp đến tất cả các trang liên quan (dựa trên nội dung thực tế của chúng, không phải metadata trang) và để tác nhân đọc tất cả các trang liên quan cùng lúc, song song - điều mà đại đa số chúng hiện nay đều làm được. Vì vậy, trong một memoryfield, tối đa chỉ cần 2 lệnh gọi công cụ (#1 để tìm kiếm, #2 để đọc song song). Những thứ liên quan thực sự được tìm thấy và các token đầu vào không liên quan được giảm thiểu.

Quyết định thiết kế 3: Thêm mô hình, bớt cơ chế

Một trong những vấn đề do các hệ thống bộ nhớ "nhiều cơ chế" đặt ra - loại bao gồm rất nhiều API hoặc cơ sở dữ liệu được chế tạo đặc biệt - là để sử dụng chúng, các tác nhân phải điều hướng qua một mê cung giao diện để đạt được mục tiêu. Nếu giao diện lớn, bạn đang tải rất nhiều openapi.json vào ngữ cảnh. Nếu giao diện nhỏ, nó sẽ bị hạn chế. Ngay cả khi sự cân bằng là đúng, thường thì API vẫn sai: hãy nhớ lại những lần bạn phải sử dụng một API do người khác viết mà họ không lường trước được nhu cầu của bạn. Bạn có thích trải nghiệm đó không?

Do đó, Memoryfields là một hệ thống "ít cơ chế" (chỉ là một định dạng tệp), mang lại cho các tác nhân phạm vi rộng hơn nhiều để tự phát minh ra các kiểu truy cập của riêng chúng. Mặc dù một số công cụ hỗ trợ (hy vọng là hữu ích) được cung cấp, các tác nhân hoàn toàn tự do sử dụng bất kỳ kiểu truy cập nào chúng thích. Ví dụ: sử dụng perl để tìm-và-thay thế trên toàn bộ kho dữ liệu, hoặc đặt các tệp CSV nội dòng bên trong các ký ức mà sau đó chúng truy vấn bằng SQLite (cả hai đều là ví dụ thực tế mà tôi đã tận mắt chứng kiến).

Là hệ thống "ít cơ chế" cũng có nghĩa là memoryfields mở rộng theo sự phát triển của các mô hình tiên tiến. Khi các mô hình trở nên tốt hơn, các tác nhân nghĩ ra nhiều thứ để làm hơn. Một trong những bước đột phá gần đây là các mô hình vô tình rất giỏi về bash. Chúng cũng giỏi về Markdown. Và SQLite. Một trong những lý do khiến tôi nghĩ memoryfields hoạt động tốt bên trong các tác nhân thực tế là vì các tác nhân về cơ bản có thể "hiểu" những gì đang diễn ra từ dữ liệu huấn luyện của chúng (thứ duy nhất bạn có cho đến khi bạn có thể đọc ký ức của mình) theo cách mà một lệnh gọi LLM tách rời bên trong một "đường ống bộ nhớ" không thể làm được.

Khi các mô hình trở nên tốt hơn, chúng tự động bắt đầu viết các ký ức thông minh hơn một chút. Các hệ thống bộ nhớ kiểu "gắn thêm vào" hiếm khi làm được điều này. Có rất ít cách để sử dụng một tập hợp các điểm cuối API cố định một cách sáng tạo hơn. Memoryfields sẽ mở rộng cùng với sự phát triển của các mô hình tiên tiến.

Quyết định thiết kế 4: Định dạng mở, có thể hoán đổi, bất biến khi vận chuyển

Khi bộ sưu tập ký ức của bạn được xây dựng, chúng bắt đầu trở nên quý giá. Kho báu về những bài học đã học và những sự thật khó khăn mới có được của bạn. Bạn không muốn bị khóa vào một khung công cụ, mô hình hoặc tác nhân cụ thể nào.