Càng làm việc với các LLM lâu, tôi càng thấy mình rơi vào cuộc chiến muôn thuở giữa đủ ngữ cảnh, quá nhiều ngữ cảnh, lãng phí token và cuộc chiến nén. Nhìn vào các hệ thống bộ nhớ tác nhân, chúng ta có thể thấy có một số vũ khí mạnh mẽ để hỗ trợ điều này.
Phát hiện liên tục xuất hiện trong 19 hệ thống tôi đã xem xét là các cửa sổ lớn hơn làm trầm trọng thêm vấn đề ngân sách thay vì giải quyết nó. Một cửa sổ 200K token không chú ý đều đến tất cả 200K token đó. Hiệu suất giảm dần rất lâu trước khi cửa sổ đầy. Sự suy giảm này không đồng đều: tài liệu ở giữa một ngữ cảnh dài được chú ý ít hơn đáng tin cậy so với tài liệu ở hai đầu. Và nhiệm vụ thực tế của tác nhân chiếm một phần cố định của cửa sổ bất kể cửa sổ lớn đến đâu, điều đó có nghĩa là mọi thứ khác đều là chi phí chung cạnh tranh cho cùng một ngân sách chú ý.
Các hệ thống xử lý tốt vấn đề này đã hội tụ vào sáu cơ chế. Không có cơ chế nào là kỳ lạ. Một số thậm chí còn đơn giản một cách đáng ngạc nhiên. Nhưng những hệ thống bỏ qua chúng sẽ phải trả giá.
Sáu cơ chế
Các lượt nén
Cơ chế dễ thấy nhất. Bạn lấy một cuộc trò chuyện dài hoặc một đoạn bộ nhớ lớn, tóm tắt nó và thay thế bản gốc bằng bản tóm tắt. MemoryOS thực hiện điều này ở cấp độ phân đoạn: trình tóm tắt phân đoạn của nó kích hoạt khi một phân đoạn hội thoại phát triển vượt quá một ngưỡng, thu gọn nó thành một biểu diễn nhỏ gọn trước khi nó có thể lấn át ngữ cảnh làm việc. Các wiki theo mẫu Karpathy (purpose.md, overview.md) thực hiện một phiên bản của điều này ở cấp độ kiến thức: wiki là dạng nén của mọi thứ tác nhân đã học về một chủ đề, được duy trì qua các phiên.
Sự đánh đổi là mất mát thông tin. Nén là một hoạt động mất mát theo định nghĩa. Bản tóm tắt nắm bắt những gì trình tóm tắt đánh giá là có liên quan tại thời điểm nén. Nếu sau này tác nhân cần một chi tiết không được đánh giá là có liên quan, nó sẽ biến mất. Đây không phải là lý do để tránh nén, nhưng nó là lý do để không coi nó là cơ chế duy nhất.
Có một chi phí thứ hai dễ bị bỏ qua. Nén không miễn phí trong thời gian chạy. MemoryOS có thể trả 20 hoặc nhiều hơn các lệnh gọi LLM trong một tương tác duy nhất để duy trì các bản tóm tắt phân đoạn của nó. Đối với các hệ thống có tần suất tương tác cao, đó là một chi phí vận hành thực sự.
Cắt ngắn xem trước kết quả
Thay vì trả về nội dung bộ nhớ đầy đủ trong mỗi lần truy xuất, hãy trả về một bản xem trước ngắn và để tác nhân quyết định có nên tìm nạp bản ghi đầy đủ hay không. supermemory hiển thị các điều khiển độ dài đoạn trích cho phép người gọi điều chỉnh lượng văn bản trả về cho mỗi kết quả. mem9 đi xa hơn: nó trang trí các lượt nguồn với ba biến môi trường (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT) cho phép người vận hành kiểm soát chính xác số lượng lượt nguồn xuất hiện và ở điểm số liên quan tối thiểu nào.
Sự đánh đổi là một lệnh gọi công cụ bổ sung. Nếu tác nhân cần nội dung đầy đủ, nó phải yêu cầu một cách rõ ràng. Đối với hầu hết các mẫu truy xuất, đây là sự đánh đổi đúng đắn: tác nhân nhận đủ tín hiệu để quyết định xem bản ghi có liên quan hay không trước khi trả chi phí token để đọc toàn bộ nó.
Truy xuất hai bước
Một biến thể cụ thể và quan trọng của cắt ngắn xem trước. Tìm kiếm trả về các định danh và bản xem trước ngắn. Một lệnh gọi GetByID riêng biệt tìm nạp bản ghi đầy đủ khi cần. Giao diện MemoryRepo của mem9 được xây dựng xung quanh mẫu này: tìm kiếm và tìm nạp là các thao tác riêng biệt với dấu chân token riêng biệt.
Các con số cho thấy điều này một cách rõ ràng. Mười kết quả khớp ở 1.500 token mỗi kết quả là 15.000 token được đưa vào ngữ cảnh cho dù tác nhân có sử dụng chúng hay không. Truy xuất hai bước trả về 10 định danh và bản xem trước ngắn với tổng cộng khoảng 450 token, sau đó chỉ tìm nạp các bản ghi mà tác nhân thực sự cần. Qua 20 bước gọi lại trong một phiên, sự khác biệt đó tích lũy thành khoảng 200.000 token được tiết kiệm.
Đây là kỷ luật rẻ nhất bạn có thể áp dụng. Nó không yêu cầu thay đổi kiến trúc đối với kho lưu trữ bộ nhớ, không có thêm lệnh gọi LLM và không mất mát thông tin. Đó là một quyết định về giao diện truy xuất.
Phân rã rồi gọi lại
Thay vì gửi toàn bộ truy vấn người dùng đến lớp truy xuất, hãy phân rã nó thành các truy vấn con trước. Bộ lập kế hoạch truy xuất nhận biết ý định của SimpleMem chia nhỏ các truy vấn đến thành các ý định truy xuất nguyên tử trước khi chạm vào kho lưu trữ bộ nhớ. GitNexus làm điều tương tự với sự phân rã công cụ truy vấn của nó: các truy vấn phức tạp được chia thành các truy vấn con có mục tiêu, mỗi truy vấn truy xuất một lát tập trung của đồ thị bộ nhớ.
Lợi ích là độ chính xác. Một truy vấn được phân rã truy xuất ít tài liệu không liên quan hơn, đồng nghĩa với ít nhiễu hơn trong ngữ cảnh. Sự đánh đổi là độ trễ: phân rã thêm một bước lập kế hoạch trước khi truy xuất bắt đầu. Đối với các tác nhân tương tác, điều này có vấn đề. Đối với các tác nhân hàng loạt hoặc nền, nó thường không.
Lưu trữ phân tầng như bộ lọc ngân sách
Nếu bạn đã xây dựng một kiến trúc bộ nhớ phân tầng (chủ đề của bài viết tuần trước), bạn sẽ nhận được lọc ngân sách như một hiệu ứng phụ. Mô hình ba tầng của supermemory có nghĩa là tài liệu nóng, được truy cập thường xuyên nằm trong một tầng trả về các kết quả nhỏ gọn, có tín hiệu cao. Tài liệu lạnh nằm trong một tầng không được truy vấn theo mặc định. Tầng quan sát của Hindsight hoạt động theo cùng một cách: các quan sát thô không được đưa trực tiếp vào ngữ cảnh; chúng được thăng cấp lên các tầng cao hơn trước khi trở thành ứng viên truy xuất.
Sự đánh đổi là tính đầy đủ của việc gọi lại. Tài liệu chưa được thăng cấp có thể có liên quan nhưng sẽ không xuất hiện trong một lượt truy xuất tiêu chuẩn. Đây là sự đánh đổi tương tự như nén, nhưng chế độ thất bại khác nhau: thay vì mất thông tin thông qua tóm tắt, bạn mất nó thông qua việc giáng cấp.
Phản hồi công cụ tự định hướng
Cơ chế ít được thảo luận nhất và là một trong những cơ chế thú vị hơn. Thay vì để tác nhân quyết định phải làm gì sau một lệnh gọi công cụ, bản thân phản hồi của công cụ bao gồm một gợi ý về việc cần làm tiếp theo. GitNexus thêm một khối ---
**Next:** vào các phản hồi công cụ, gợi ý các hành động tiếp theo. mem9 trang trí các lượt nguồn với siêu dữ liệu có cấu trúc hướng dẫn bước truy xuất tiếp theo của tác nhân.
Hiệu quả là tác nhân dành ít token hơn cho việc lập kế hoạch giữa các lệnh gọi công cụ. Phản hồi của công cụ mang đủ cấu trúc để làm cho bước tiếp theo trở nên rõ ràng. Sự đánh đổi là nỗ lực kỹ thuật prompt: viết các phản hồi tự định hướng tốt đòi hỏi phải biết trước tác nhân có khả năng cần gì tiếp theo, điều này không phải lúc nào cũng có thể.
Trường hợp giới hạn Tolaria
Tolaria đáng được xem xét riêng biệt vì nó đại diện cho điểm kết thúc logic của kỷ luật ngân sách được đưa đến cực điểm. ADR-0009 ghi lại quyết định loại bỏ hoàn toàn các embeddings khỏi hệ thống. Tolaria chỉ sử dụng tìm kiếm chuỗi con. Không có chỉ mục vector, không truy xuất ngữ nghĩa, không có lệnh gọi embedding.
Lý do là trực tiếp: token rẻ nhất là token bạn không bao giờ truy xuất ngay từ đầu. Truy xuất dựa trên embedding trả về các kết quả tương tự về mặt ngữ nghĩa, điều đó có nghĩa là nó trả về các kết quả mà tác nhân không yêu cầu một cách rõ ràng. Một số kết quả đó hữu ích. Nhiều kết quả thì không. Tất cả chúng đều tốn token.
Quan điểm của Tolaria là chi phí của các kết quả không liên quan nhưng tương tự, được tích lũy qua một phiên, vượt quá lợi ích của việc gọi lại ngữ nghĩa cho trường hợp sử dụng của nó. Liệu sự đánh đổi đó có đúng cho hệ thống của bạn hay không phụ thuộc vào hệ thống của bạn dùng để làm gì. Đối với các hệ thống nơi các truy vấn chính xác và có cấu trúc (điều hướng mã, tra cứu tài liệu theo định danh), quan điểm của Tolaria là có thể bảo vệ được. Đối với các hệ thống nơi các truy vấn mơ hồ và mang tính khám phá, việc loại bỏ embeddings phá vỡ khả năng gọi lại theo những cách khó phục hồi.
Giá trị của trường hợp Tolaria không phải là bạn nên sao chép nó. Mà là nó làm cho chi phí của truy xuất ngữ nghĩa trở nên hữu hình theo cách mà hầu hết các hệ thống không làm được.
Trường hợp chống lại các hệ thống chỉ dùng nén
Một số trong 19 hệ thống dựa vào nén như cơ chế ngân sách chính hoặc duy nhất. Các chế độ thất bại đáng được nêu tên.
Đầu tiên là việc tóm tắt làm mất các chi tiết không được đánh giá là có liên quan tại thời điểm nén nhưng sau đó trở nên có liên quan. Đây không phải là giả thuyết: đó là chế độ thất bại tiêu chuẩn của bất kỳ sơ đồ nén mất mát nào được áp dụng cho thông tin mà mức độ liên quan trong tương lai chưa được biết.
Thứ hai là nén là một chi phí trên đường dẫn nóng. MemoryOS trả 20+ lệnh gọi LLM mỗi tương tác không phải là bất thường đối với các hệ thống nặng về nén. Ở quy mô lớn, chi phí đó không hề nhỏ.
Thứ ba, và tinh tế nhất, là nén mà không có cửa thoát hiểm là sự lãng quên chậm chạp. Nếu cách duy nhất để giảm kích thước ngữ cảnh là tóm tắt và các bản tóm tắt bị mất mát, thì hệ thống liên tục loại bỏ thông tin mà không có cách nào để phục hồi nó. Truy xuất hai bước, lưu trữ phân tầng và cắt ngắn xem trước kết quả đều bảo tồn bản ghi gốc. Nén thì không.
Không có điều này có nghĩa là nén là sai. Nó có nghĩa là chỉ nén thôi là không đủ.
Trọng số gần đây và hàng đợi liên tục
Hai cơ chế không phù hợp gọn gàng với sáu danh mục trên đáng được lưu ý.
graymatter sử dụng hợp nhất RRF với tính gần đây ở nửa trọng số. Đây không phải là một cơ chế ngân sách theo nghĩa chặt chẽ, nhưng nó hoạt động như một cơ chế: bằng cách giảm trọng số của tài liệu cũ hơn trong xếp hạng truy xuất, nó làm giảm xác suất các bản ghi cũ, tín hiệu thấp lấn át các bản ghi gần đây, tín hiệu cao. Hiệu quả là phân tầng mềm thông qua trọng số xếp hạng thay vì thăng cấp tầng rõ ràng.
Máy trạng thái hàng đợi nhập 540 dòng của llm-wiki thực hiện một cách tiếp cận khác. Hàng đợi tuần tự hóa các hoạt động nhập và áp dụng một bộ xếp hạng mức độ liên quan bốn tín hiệu trước khi bất cứ thứ gì đi vào kho lưu trữ bộ nhớ. Kiểm soát ngân sách xảy ra tại thời điểm ghi thay vì thời điểm đọc. Tài liệu không vượt qua ngưỡng liên quan sẽ không được lưu trữ, điều đó có nghĩa là nó không thể được truy xuất và không thể tiêu thụ ngữ cảnh. Đây là kiểm soát ngân sách gián tiếp, nhưng nó bền vững: khoản tiết kiệm tích lũy qua mọi phiên trong tương lai.
Điểm chung của các hệ thống được thiết kế tốt
Nhìn vào 19 hệ thống, những hệ thống xử lý tốt ngân sách ngữ cảnh có chung một vài thuộc tính.
Chúng coi truy xuất là một hoạt động hai bước thay vì một bước tiêm. Chúng trả về bản xem trước trước khi có bản ghi đầy đủ. Chúng bảo tồn các bản ghi gốc thay vì thay thế chúng bằng các bản tóm tắt. Chúng cho người vận hành kiểm soát khối lượng truy xuất thông qua các tham số rõ ràng thay vì các giá trị mặc định cứng nhắc. Và chúng nghĩ về ngân sách ở cả thời điểm ghi và thời điểm đọc.
Những hệ thống xử lý kém có xu hướng dựa vào một cơ chế duy nhất, thường là nén, và coi cửa sổ ngữ cảnh như một bộ đệm cần được lấp đầy hơn là một tài nguyên cần được quản lý.
Kết luận cuối cùng từ nghiên cứu rất đơn giản. Các cửa sổ lớn hơn đòi hỏi nhiều kỷ luật hơn, không phải ít hơn. Không phải vì việc lấp đầy chúng là sai về nguyên tắc, mà vì việc lấp đầy chúng bằng tài liệu sai sẽ tốn kém hơn là để trống không gian.
Trong bài viết tiếp theo của tôi, tôi dự định chuyển từ bộ nhớ như tiêm sang bộ nhớ như công cụ, đề cập đến cách 19 hệ thống xử lý ranh giới giữa những gì được đẩy vào ngữ cảnh tự động và những gì tác nhân phải yêu cầu một cách rõ ràng.*
Như mọi khi, nếu bạn thấy điều này thú vị, hữu ích hoặc chỉ muốn giúp lan tỏa kiến thức:
Vui lòng Chia sẻ
