Chúng tôi đã cho các agent một triệu token trong cửa sổ ngữ cảnh, nhưng chúng vẫn không hoạt động.
Hãy lưu lại bài viết này nhé :)
Bạn cung cấp cho một mô hình mạnh mẽ một số công cụ và một tác vụ dài. Trong mười lăm bước đầu tiên, nó hoạt động xuất sắc. Tập trung và chính xác. Trả lời các câu hỏi và đặt câu hỏi cho người dùng rất tốt.
Tuy nhiên, khi các cuộc hội thoại bắt đầu mở rộng, agent bắt đầu đi chệch hướng. Agent bắt đầu mâu thuẫn với các quyết định mà nó đã đưa ra mười bước trước đó. Nó bắt đầu làm ô nhiễm cửa sổ ngữ cảnh bằng những thông tin bịa đặt. Nó biết rằng có tồn tại các tùy chọn của người dùng, nhưng không thể truy xuất chúng một cách đáng tin cậy. Tất cả trong khi bạn phải vật lộn để tìm ra lý do tại sao mọi thứ bị hỏng.
Vì vậy, bạn bắt đầu tìm kiếm thêm. Một mô hình có cửa sổ ngữ cảnh lớn hơn để giữ tác vụ lâu hơn. Cố gắng tối ưu hóa pipeline RAG. Lùng sục trên internet để tìm giải pháp bộ nhớ cho agent.
Và không có thứ nào hoạt động như bạn mong đợi.
Hiểu được nguyên nhân đằng sau điều này sẽ chỉ cho chúng ta thẳng đến lớp quan trọng nhất, ít được hiểu nhất trong toàn bộ stack agent.
Sự Thất Bại Là Một Vòng Lặp
Lý do agent suy giảm hiệu suất không phải do thiếu năng lực. Đó là một vòng lặp phản hồi, và nó có bốn mắt xích. Một khi bạn thấy cả bốn, những cách khắc phục thông thường không còn giống như giải pháp nữa.
Mắt xích một: một mô hình không thể sử dụng toàn bộ ngữ cảnh của nó một cách đồng đều, và điều này càng trở nên tồi tệ hơn khi ngữ cảnh đầy dần.
Đây là phần mà hầu hết mọi người không bao giờ nắm được. Khả năng sử dụng thông tin của một mô hình không đồng nhất trên toàn bộ cửa sổ ngữ cảnh của nó. Các mô hình sử dụng một cách đáng tin cậy những gì nằm ở đầu và cuối cùng, và chúng có xu hướng ít chú ý đến phần giữa một cách có hệ thống, ngay cả khi chúng được xây dựng đặc biệt cho các đầu vào dài. Nhồi thêm nhiều hơn vào, và độ tin cậy giảm mạnh. Điều này thậm chí còn xuất hiện trong các tác vụ nhỏ nhặt như lặp lại một danh sách từ. Thêm một yếu tố gây xao nhãng duy nhất, và hiệu suất giảm một cách đáng kể. Thêm một vài yếu tố kết hợp với nhau.
Vì vậy, ngữ cảnh hiệu quả, phần mà mô hình thực sự có thể suy luận một cách đáng tin cậy, nhỏ hơn nhiều so với con số trên vỏ hộp. Và nó co lại khi bạn nhồi thêm nhiều hơn.
Bây giờ hãy nghĩ về những gì một agent làm. Nó tích lũy. Mọi kết quả công cụ, mọi bước lịch sử, mọi ghi chú cho bản thân đều được thêm vào ngữ cảnh. Điều đó có nghĩa là agent đang dần dần làm giảm chất lượng của mọi bước mà nó thực hiện. Ngữ cảnh đang phát triển đang tạo ra các lỗi cho từng bước.
Mắt xích hai: những lỗi theo từng bước này không cộng lại. Chúng nhân lên.
Một chút lỗi theo từng bước sẽ ổn nếu agent chỉ thực hiện một vài bước. Chúng thực hiện hàng chục bước. Và những thất bại kết hợp lại hơn là tích lũy. Một agent có độ tin cậy 95% ở năm bước sẽ không duy trì được 95% trong suốt một tác vụ 20 bước. Chạy đủ số bước, và bạn tiếp tục tiến gần hơn đến một lần tung đồng xu.
Nó còn tệ hơn thế, bởi vì các lỗi là tự củng cố. Một lời gọi công cụ hơi chệch hướng làm cho lời gọi tiếp theo có nhiều khả năng chệch hướng hơn. Chồng chất điều đó lên trên mắt xích một, nơi mà tỷ lệ lỗi cơ bản tự nó đang leo thang khi cửa sổ đầy dần, và bạn sẽ có được chế độ thất bại đặc trưng của các agent có tầm nhìn xa. Chúng không suy giảm một cách duyên dáng. Chúng cầm cự và sau đó đột ngột rơi tự do.
Mắt xích ba: tác vụ dài, mô hình không có trạng thái, vì vậy bạn đặt trạng thái ở đâu đó bên ngoài mô hình.
Các mô hình ngôn ngữ không lưu giữ bất cứ điều gì giữa các lần gọi. Mỗi lần gọi bắt đầu với một bảng trắng. Điều duy nhất một mô hình biết là những gì bạn đưa trở lại vào nó. Vì vậy, đối với bất kỳ tác vụ dài nào, bạn phải ngoại hóa trạng thái. Vùng nháp. Tệp tiến độ. Điểm kiểm tra. Kho vector. Các lớp bộ nhớ chuyên dụng trích xuất sự kiện và phục vụ lại chúng qua các phiên.
Điều này là đúng và cần thiết. Và nó trông giống như một cách khắc phục sạch sẽ. Agent không quên bất cứ điều gì quan trọng, bởi vì mọi thứ quan trọng đều sống trong bộ nhớ lâu dài.
Mắt xích bốn: bộ nhớ được lưu trữ là trơ, và việc kéo nó trở lại sẽ nuôi dưỡng chính vấn đề mà nó được cho là để giải quyết.
Đây là nơi vòng lặp khép lại. Một mô hình không thể suy luận trên một cơ sở dữ liệu. Nó chỉ có thể suy luận trên những gì nằm trong cửa sổ ngữ cảnh của nó. Vì vậy, bộ nhớ chỉ hữu ích tại thời điểm nó được kéo trở lại. Và mỗi lần truy xuất đều thêm token. Mỗi bản tóm tắt mà agent viết để theo dõi tiến độ là một token mà nó phải đọc lại sau đó. Mỗi bước nén lại lịch sử để tạo không gian đều có mất mát, và chi tiết mà nó vứt bỏ thường là chi tiết tinh tế mà tầm quan trọng của nó chỉ trở nên rõ ràng sau này.
Vì vậy, hệ thống bộ nhớ bạn xây dựng để đánh bại giới hạn ngữ cảnh cuối cùng lại nuôi dưỡng nó. Nhiều bộ nhớ hơn có nghĩa là nhiều truy xuất hơn, đồng nghĩa với nhiều nhiễu hơn trong cửa sổ, dẫn đến nhiều lỗi theo từng bước hơn, nhân lên, chính là thứ đã đưa bạn đi tìm bộ nhớ ngay từ đầu.
Vòng lặp là có thật. Và nó không quan tâm cửa sổ ngữ cảnh của bạn lớn đến mức nào.
Dung Lượng Chưa Bao Giờ Là Trục Quan Trọng
Một khi bạn thấy vòng lặp, sự vô ích của các cách khắc phục tiêu chuẩn trở nên rõ ràng.
Một cửa sổ ngữ cảnh lớn hơn không phá vỡ nó. Nó chỉ nâng cao trần nhà về lượng mục nát bạn có thể tích lũy trước khi rơi tự do. Trong khi đó, mọi nghiên cứu về ngữ cảnh hiệu quả vẫn tiếp tục chỉ ra một điều: phần trăm có thể sử dụng một cách đáng tin cậy phát triển chậm hơn nhiều so với con số được quảng cáo. Bạn đang mua dung lượng mà bạn không thể thực sự sử dụng.
Bộ nhớ nhiều hơn không phá vỡ nó. Nó làm tăng khối lượng tài liệu cạnh tranh để tái nhập vào một cửa sổ vốn đã không thể chứa mọi thứ trong đó.
Kiến trúc tiếp theo cũng sẽ không phá vỡ nó. Những kẻ thách thức xếp hàng chống lại attention, các mô hình không gian trạng thái như Mamba và các mô hình lai của nó, giành chiến thắng bằng cách nén quá khứ thành một trạng thái có kích thước cố định thay vì giữ mọi token có thể truy cập. Điều đó mua được suy luận thời gian tuyến tính và dấu chân bộ nhớ không phát triển theo chuỗi. Nó không thể mua được khả năng thu hồi. Một trạng thái có kích thước cố định không thể giữ mọi thứ, vì vậy nó quên theo thiết kế. Ở quy mô lớn, các mô hình không gian trạng thái thuần túy tụt hậu so với transformers ở chính điều mà bộ nhớ bên ngoài tồn tại để cung cấp: kéo một sự kiện cụ thể trở lại từ một điểm tùy ý trước đó trong chuỗi. Đây là lý do tại sao các nỗ lực nghiêm túc sau-attention là các mô hình lai giữ một số lượng nhỏ các lớp attention để thực hiện việc thu hồi, điều mà một mô hình trạng thái không thể làm. Bức tường không di chuyển khi bạn thay đổi kiến trúc. Bạn chỉ chạm tới nó từ phía bên kia.
Vì vậy, bài học không phải là "chọn một con số lớn hơn." Đó là dung lượng chưa bao giờ là ràng buộc chính.
Ràng buộc chính là chất lượng của quyết định về token nào chiếm giữ cửa sổ tại mỗi bước.
Đó là toàn bộ trò chơi. Không phải là ngữ cảnh lớn nhất có sẵn, mà là ngữ cảnh đủ nhỏ nhất. Mức độ liên quan hơn là thu hồi. Quên có chủ đích như một hoạt động hạng nhất thay vì một tai nạn của việc cắt ngắn. Nghiên cứu ủng hộ trực tiếp điều này: truy xuất bảo toàn thứ tự của một vài nghìn token được chọn lọc tốt sẽ đánh bại việc đổ toàn bộ cửa sổ 128K vào mô hình. Lợi thế nằm ở việc chọn những gì đi vào, không phải ở lượng bao nhiêu có thể.
Và đây là cái bẫy mà hầu hết các nhóm mắc phải, bởi vì công cụ họ với tới để thực hiện việc chọn lọc có hình dạng sai.
Tương Đồng Không Phải Là Mức Độ Liên Quan
Cách mặc định để quyết định ngữ cảnh nào cần kéo trở lại là tìm kiếm tương đồng. Nhúng mọi thứ, và khi agent cần ngữ cảnh, truy xuất các vector gần nhất với truy vấn hiện tại.
Nhưng tương đồng trả lời sai câu hỏi. Nó trả về những gì gần, không phải những gì liên quan. Và đó là hai điều rất khác nhau.
Câu hỏi mà agent thực sự cần được trả lời không bao giờ là "cái gì tương tự với cái này." Nó là "với tác vụ này và trạng thái này ngay bây giờ, cái gì kết nối đến cái gì quan trọng." Đó là một câu hỏi quan hệ. Nó nói về các phụ thuộc, nguồn gốc, cái gì thay thế cái gì, và quyết định nào gây ra kết quả nào. Một kho dữ liệu được điều chỉnh để truy xuất các vector tương tự đưa cho mô hình một đống các thứ gần đúng. Và các thứ gần đúng chính xác là các yếu tố gây xao nhãng từ mắt xích một, những thứ làm tăng lỗi theo từng bước kết hợp thành sự rơi tự do.
Đây là lý do tại sao cách khắc phục không thể là một bộ đệm mỏng phía trước một kho embedding. Sự thông minh không nằm trong việc tra cứu. Nó nằm trong cấu trúc.
Lớp Mà Không Ai Định Giá
Lớp quan trọng nhất để nắm bắt trong stack agent không phải là mô hình, và cũng không phải là kho dữ liệu. Nó là lớp ở giữa. Lớp quyết định mô hình chú ý đến điều gì.
Và để thực sự làm công việc đó, nó phải có ba điều.
Nó phải trung lập. Các phần bên trong liên tục thay đổi dưới chân mọi người. Transformer đến không gian trạng thái đến lai. Từ một mô hình tiên tiến này đến mô hình tiếp theo, với một nhà lãnh đạo giá-hiệu suất mới sau mỗi vài tháng. Một chiến lược ngữ cảnh gắn liền với một mô hình duy nhất là một canh bạc vào một mục tiêu di động. Thứ mà tổ chức của bạn thực sự tích lũy giá trị là ngữ cảnh của nó, bản ghi có cấu trúc khó giành được về những gì các agent của bạn biết và đã làm. Khóa điều đó vào các tính năng bộ nhớ của một nhà cung cấp duy nhất, và bạn đã biến tài sản bền vững nhất của mình thành con tin cho một lộ trình không phải của bạn. Một lớp lựa chọn sống bên ngoài bất kỳ mô hình đơn lẻ nào cho phép cùng một ngữ cảnh có tổ chức phục vụ mọi mô hình bạn chạy, và cả mô hình tiếp theo bạn chưa áp dụng.
Nó phải nằm ngang. Điểm kiểm tra của một framework biết về một lần chạy. Bộ nhớ tích hợp của một mô hình biết về các cuộc hội thoại của một mô hình. Một chỉ mục vector biết về một kho ngữ liệu. Không cái nào nắm giữ bức tranh thực sự quan trọng một khi bạn đang chạy các khối lượng công việc thực tế: nhiều agent, nhiều phiên, nhiều mô hình, tất cả đều cần một cái nhìn ngữ cảnh mạch lạc, có thể truy vấn. Vai trò hệ thống kỷ lục đó không phải là thứ mà một ứng dụng hay framework hay phòng thí nghiệm được định hình để nắm giữ, bởi vì mỗi cái chỉ thấy lát cắt của riêng nó. Đó là một lớp của riêng nó, nằm ngang trên tất cả chúng.
Nó phải có cấu trúc. Đây là điều phân biệt nó với "chỉ là một cơ sở dữ liệu tốt hơn." Lựa chọn là một vấn đề về mức độ liên quan, và mức độ liên quan là quan hệ. Cấu trúc trên ngữ cảnh, các mối quan hệ và phụ thuộc, nguồn gốc và sự thay thế, là điều biến truy xuất thành lựa chọn. Đó là một nguyên thủy hoàn toàn khác so với lưu trữ, và nó là nguyên thủy mà vòng lặp đòi hỏi.
"Các Phòng Thí Nghiệm Sẽ Không Chỉ Gửi Tính Năng Này Sao?"
Phản đối rõ ràng là các phòng thí nghiệm mô hình sẽ hấp thụ điều này. Họ liên tục gửi các tính năng bộ nhớ và ngữ cảnh, và họ có quyền truy cập đặc quyền vào attention của riêng mô hình.
Họ sẽ làm, và phản đối đó đúng một nửa. Đối với một mô hình đơn lẻ bao bọc một ứng dụng đơn lẻ, để phòng thí nghiệm xử lý nó thường là đủ. Điều đó ổn.
Nhưng động lực của các phòng thí nghiệm là làm cho mô hình của riêng họ trở nên dính hơn. Đó là điều ngược lại với tính di động. Việc quản lý gắn liền với nội bộ của một mô hình không thể phục vụ cho trường hợp đa mô hình, toàn tổ chức. Một lớp nền ngữ cảnh thực sự không cạnh tranh trực diện với các tính năng đó. Nó tồn tại cho tình huống mà các phòng thí nghiệm về mặt cấu trúc không có khuynh hướng phục vụ: tình huống bạn chạy nhiều mô hình trên nhiều agent và nhóm, và bạn từ chối để lớp quyết định những gì các agent của bạn nghĩ về được sở hữu bởi nhà cung cấp mà mô hình của họ tình cờ chạy hôm nay.
Và xu hướng chỉ làm sắc nét điều này. Các mô hình càng có năng lực, chúng càng được sử dụng nhiều. Chúng càng được sử dụng nhiều, một tổ chức chạy càng nhiều agent. Nó chạy càng nhiều agent, một lớp lựa chọn trung lập, nằm ngang, có cấu trúc càng có giá trị.
Ai Đang Xây Dựng Điều Này?
Đây là lúc Hydradb xuất hiện. Trung lập, nằm ngang và có cấu trúc. Nó nắm giữ các mối quan hệ, phụ thuộc, nguồn gốc và sự thay thế mà tìm kiếm tương đồng làm phẳng mất. Nó được phân phiên bản theo thời gian và nhận biết tùy chọn, và do đó biết không chỉ điều gì là đúng mà còn điều gì đã thay thế nó. Nó mở khóa khả năng hiển thị về những gì một agent cụ thể đã học được theo thời gian. Cấu trúc đó là điều biến truy xuất thành lựa chọn.
Bên dưới, HydraDB chạy trên bộ nhớ phân tầng: một bộ đệm trong bộ nhớ nóng cho ngữ cảnh hoạt động, NVMe cho ấm, và lưu trữ đối tượng cho lạnh. Ngữ cảnh được thăng cấp và giáng cấp bởi tính mới và tầm quan trọng, để bộ làm việc mà mô hình suy luận trên vẫn nhỏ một cách có chủ đích. Giữa mô hình và tất cả những gì nó có thể biết.
Câu Hỏi Mà Mọi Agent Phải Trả Lời
Loại bỏ các cuộc tranh luận về kiến trúc, các sản phẩm bộ nhớ, cuộc chạy đua vũ trang về cửa sổ ngữ cảnh. Bên dưới tất cả, mọi agent chạy dài đều trả lời cùng một câu hỏi trên mỗi bước.
Trong tất cả những gì nó biết, nó nên nghĩ về điều gì ngay bây giờ?
Một cửa sổ lớn hơn không trả lời điều đó. Nó chỉ cho agent nhiều thứ hơn để bỏ qua. Vòng lặp là có thật, nó là vĩnh viễn, và không có lượng dung lượng nào đóng được nó.
Ngành công nghiệp vẫn đang cố gắng mua đường thoát bằng dung lượng. Nó không thể. Các nhóm nội hóa rằng đó luôn là một vấn đề lựa chọn sẽ gửi các agent hoạt động, trong khi những người khác gửi các agent mà gần như hoạt động.
Điều này chưa bao giờ là một giới hạn thuần túy của các mô hình. Bất cứ thứ gì hoạt động dưới một ngân sách hữu hạn đều phải chọn những gì nó chú ý đến. Lựa chọn không phải là một giải pháp thay thế cho các giới hạn ngày nay. Nó là thứ mà suy luận dưới các giới hạn luôn yêu cầu.
Nếu bạn thấy bài viết này hữu ích, hãy theo dõi tôi @eng_khairallah1 để có thêm nội dung AI như thế này. Tôi đăng các bài phân tích, khóa học và công cụ mỗi tuần.
hy vọng điều này hữu ích cho bạn, Khairallah ❤️
