Đừng tin vào cửa sổ ngữ cảnh lớn
(garrit.xyz)- Cửa sổ ngữ cảnh của LLM có thể được chia thành vùng thông minh, nơi mô hình hoạt động sắc bén, và vùng cùn, nơi khả năng chú ý giảm xuống và bắt đầu quên các chỉ dẫn trước đó
- Điểm phân tách nằm khoảng 100k token, và ngay cả khi kích thước cửa sổ ngữ cảnh được quảng bá lớn hơn thì điều đó cũng không đồng nghĩa với phạm vi làm việc thực tế tăng tương ứng
- Tác nhân lập trình có thể nhanh chóng tiêu tốn token và chạm mốc 100k token chỉ bằng việc đọc file, gỡ lỗi kéo dài và chạy các bộ kiểm thử lớn
- Báo cáo của RULER và Chroma về context rot cho thấy ngữ cảnh hiệu dụng chỉ là một phần của con số được quảng bá, và hiệu năng giảm dần khi cửa sổ bị lấp đầy
- Thay vì tự động tóm tắt các phiên dài, việc để lại thông tin bên ngoài phiên bằng đặc tả do con người tự viết và các đầu ra nhỏ sẽ giúp công việc ở lại trong vùng thông minh
Giới hạn thực tế của cửa sổ ngữ cảnh
- Cửa sổ ngữ cảnh của LLM có thể được chia thành vùng thông minh, nơi mô hình sắc bén, và vùng cùn, nơi khả năng chú ý suy giảm
- Trong vùng cùn, mô hình bắt đầu quên những gì được đưa vào chỉ vài phút trước
- Điểm phân tách nằm quanh mốc 100k token
- Kích thước cửa sổ ngữ cảnh được quảng bá lớn hơn không làm biến mất ranh giới này
- Tác nhân lập trình tiêu tốn token rất nhanh trong cách sử dụng hiện đại
- Chỉ vài lần đọc file, một phiên gỡ lỗi dài và một đợt chạy kiểm thử rộng là đã có thể chạm mốc 100k token
- Các nhà cung cấp quảng bá cửa sổ ngữ cảnh 200k, 1M, 2M, nhưng những con số đó không đồng nghĩa với tập công việc thực sự có thể dùng được
- Cửa sổ ngữ cảnh lớn phần nhiều chỉ là con số marketing
- Kiến trúc phía sau vẫn hoạt động, nhưng nó che phủ những vấn đề mà cơ chế chú ý cơ bản thực ra không giải quyết được
- Con số hiển thị trên sản phẩm tăng qua từng bản phát hành, nhưng phần thật sự hữu dụng không theo kịp với cùng tốc độ
- RULER và báo cáo context rot của Chroma cho thấy ngữ cảnh hiệu dụng chỉ là một phần của con số được quảng bá
- Hiệu năng giảm dần khi bạn lấp đầy cửa sổ ngữ cảnh
Cách làm việc để giữ phiên ngắn
- Các tác nhân mới bắt đầu có tính năng nén tự động để xử lý các phiên dài
- Claude Code thực hiện auto-compact: khi phiên quá dài, nó tóm tắt lịch sử rồi khởi động lại
- Cách này hữu ích, nhưng chỉ hoạt động sau khi đã tiêu tốn thời gian trong vùng cùn
- Bản tóm tắt cũng do chính mô hình đã bị suy giảm hiệu năng tạo ra
- Cách bàn giao tốt hơn là mở một phiên mới và truyền vào đặc tả do con người tự viết
- Đặc tả viết tay là tài liệu bàn giao có tín hiệu mạnh hơn so với tóm tắt tự động
- Vì con người có thể tự quyết định điều gì sẽ quan trọng về sau
- Cách này tương ứng với phương pháp breadcrumb, tức để lại các đầu ra gọn gàng để phiên tiếp theo hoặc người tiếp theo có thể tiếp nhận sạch sẽ
- obra/superpowers và mattpocock/skills tổ chức workflow của tác nhân xoay quanh các đầu ra nhỏ có tên gọi rõ ràng
- PRD, kế hoạch, skill, và tài liệu bàn giao cho tác nhân con đều là những đầu ra như vậy
- Mỗi đầu ra đều chuyển thông tin ra ngoài phiên trực tiếp để phiên sau có thể đọc lại
- Cách này giúp phiên làm việc ở lại trong vùng thông minh
- Cửa sổ ngữ cảnh nên được đối xử như một ngân sách
- Hãy giả định rằng phần thực sự hữu ích chỉ là vài khối ở phía trước
- Thông tin được chuyển từ phiên trực tiếp sang written artifact sẽ giảm bớt những gì mô hình phải tranh giành sự chú ý
1 bình luận
Ý kiến trên Hacker News
Học những điều cơ bản về AI khá thú vị, nhưng tôi không đồng ý với hướng đi hiện tại
Thật khó diễn tả bằng lời việc các bình luận trong những chủ đề như thế này tạo cảm giác bất an đến mức nào. Những chia sẻ thiện chí kiểu “XYZ đã như thế này với tôi” trông giống hệt lời khuyên trong các chủ đề trên Facebook về chăm sóc thú cưng hay nấu ăn
Các nhóm Facebook về in 3D còn tệ hơn nữa; ai vừa in vừa muốn hiểu chuyện gì thực sự đang diễn ra chắc sẽ hiểu tôi muốn nói gì
Trong thế giới LLM, đặc biệt là thế giới LLM đám mây, cảm giác như tính nghiêm ngặt được chia sẻ đã sụp đổ hoàn toàn, và rốt cuộc chỉ còn lại kiểu bắt chước mang màu sắc ma thuật. Không ai còn đúng hay sai hơn người khác nữa
Không khí kiểu như “Bạn đã rửa context bằng nước rửa chén Dawn, để khô rồi quét một lớp keo dán chưa?”
Tôi không muốn nói quá gay gắt với những người đang cố giúp đỡ. Chỉ là nó cho cảm giác quá khác với các chủ đề khác. Bình thường, đề xuất của ai đó sẽ được người khác tranh luận hoặc mài giũa thêm, rồi có người giải thích một thứ như cách chọn lịch sử bash và thế là thay đổi cả cuộc đời; còn những chủ đề kiểu này thì cuối cùng lại trôi về hướng “Chẳng phải lạ sao khi cứ dọa là lại hiệu quả?”
Tính chất tùy hứng và không xác định của quy trình làm việc với LLM thực sự khiến tôi thấy khó chịu. Là người lâu năm ở mảng embedded/hệ thống, tôi luôn ưu tiên tính xác định và khả năng tái lập
Nhưng agent thì rất ấn tượng, và việc trở thành một “người thiết kế quá trình suy nghĩ” cũng rất thú vị. Tôi sẽ không quay lại nữa. Ngay cả khi việc phát triển AI dừng lại hôm nay, sự nghiệp của tôi có lẽ cũng sẽ không còn như trước
Trong ngành công nghệ, kiểu chuyện này đã luôn tồn tại từ rất lâu trước khi có LLM
Tôi đã trải qua quá nhiều cuộc họp mà quyết định được đưa ra không phải bằng tiêu chí khách quan, đo được, mà chỉ vì “một công ty nổi tiếng hơn một chút làm như vậy”. Ngay cả bằng chứng cho thấy công ty đó thực ra không áp dụng cách ấy một cách phổ biến cũng yếu một cách đáng ngạc nhiên
Lời khuyên trong IT vốn dĩ luôn có phần như vậy. Hệ thống và kết quả càng phức tạp thì càng khó định nghĩa rõ ràng thế nào là “tốt hơn” và “tệ hơn”
Cộng thêm việc LLM có tính phi quyết định rất mạnh, lời khuyên về LLM về cơ bản trở thành kiểu lời khuyên làm vườn
Ngay cả “benchmark” phần lớn cũng chỉ gần như là nỗ lực cố kết tinh cảm giác của ai đó thành một thứ có vẻ thành công ở mức nào đó
Tôi rất đồng cảm với sự bức bối này và nhìn chung là đồng ý. Mỗi lần cố gắng hình thức hóa một quy trình làm việc dựa trên LLM, tôi lại thất vọng vì dường như chẳng ai thực sự biết rõ vì sao có thứ hoạt động còn có thứ thì không
Thế là cuối cùng tôi lại quay về với
/planvà bảo nó “hãy ghi lại vào tài liệu Markdown để dùng về sau trước khi lặp lại việc triển khai”, rồi hy vọng khoảng tháng sau sẽ có thứ gì đó nghiêm ngặt hơn và có cơ sở hợp lý hơn xuất hiệnTôi hoàn toàn không dùng keo dán vì không cần. Nhưng Dawn có vẻ khá hiệu quả trong việc làm cho build plate của Bambu bám dính trở lại. Tôi không chủ đích tìm nó để dùng, chỉ là nhà sẵn có để rửa chén. IPA không hiệu quả nên tôi thử Dawn, và nó đã nhiều lần giúp bản in bám dính tốt trở lại. Tôi vẫn chưa đạt đến N=30
Cái gọi là “tính nghiêm ngặt được chia sẻ” trong đầu chúng ta tự thân có thể chỉ là một ảo tưởng, và LLM cùng vấn đề context của nó có lẽ đang phơi bày điều đó
Trong hàng chục năm sống trong ngành công nghệ, tôi không thấy nhiều sự nghiêm ngặt. Công cụ cứ tăng lên, các paradigm sinh ra rồi chết đi rồi lại xuất hiện, và với bất kỳ thước đo nào cũng luôn có những thước đo cạnh tranh khác với đơn vị khác nhau. Vượt ra ngoài vật lý của điện năng và tín hiệu, cùng chi phí chi phối của wafer silicon, thì so với một số ngành học ít ỏi lâu đời hơn nhiều, gần như tất cả chúng ta chỉ là những người thợ vá víu với mức độ lành nghề khác nhau
Giới hạn context thì từ trước đến nay vẫn tương đối dễ xử lý. Chỉ cần xác định đặc tả và giới hạn phạm vi. Để LLM cho ra kết quả tốt thì cần đặc tả rõ ràng và sự dẫn dắt mạnh mẽ
Nhưng ngay cả điều này cũng chỉ là cảm quan thực dụng kiểu chắp vá ở thời điểm hiện tại. Biết đâu 90 ngày nữa ngay cả gánh nặng này cũng biến mất, và chỉ với một prompt đơn giản là có thể tạo ra một hệ điều hành đẳng cấp thế giới cùng một ngôn ngữ lập trình, kèm cả nền tảng hình thức toán học cho cả hai
Tôi tránh vấn đề kích thước ngữ cảnh bằng cách đặt một ràng buộc đơn giản vào vòng lặp agent. Ở luồng hội thoại cấp cao nhất của người dùng, tôi chặn mọi lệnh gọi công cụ. Những việc cần gọi công cụ chỉ diễn ra bên trong các lời gọi đệ quy của agent, rồi chỉ trả kết quả về cho bên gọi
Ngay cả với codebase vượt quá 1 triệu LOC, tôi vẫn có thể duy trì cùng một cuộc trò chuyện cấp cao suốt cả ngày mà không chạm đến giới hạn token có ý nghĩa. Không cần mẹo nén hay tóm tắt nào cả. Dù có đốt 50 triệu token trong lời gọi đệ quy, luồng hội thoại gốc vẫn có thể chưa đụng tới 100 nghìn token
Mỗi lần agent quay xuống Narnia thì đúng là cần làm lại bước “bootstrap”, nhưng vẫn hiệu quả hơn nhiều so với việc luôn mang theo một ngữ cảnh phẳng khổng lồ cố nhét mọi thứ vào
Đệ quy rất hiệu quả để kiểm soát lượng token sử dụng, nhưng cũng có giới hạn. Tôi chưa từng thấy lợi ích nào khi vượt quá độ sâu đệ quy 1. Tôi có thấy agent thử vài lần, nhưng hiệu năng thực tế không ra gì. Có vẻ đệ quy ký hiệu từ bên ngoài không phải thứ mà các mô hình tuyến đầu được huấn luyện cho. Chúng rất giỏi giả lập đệ quy bên trong ngữ cảnh, nhưng nếu mục tiêu là giảm lượng token dùng thì đó lại là hướng không mong muốn
Đến lúc này thì hội thoại chính chỉ còn đóng vai trò điều phối công việc
Tôi thường thấy điều đó trong luồng giải quyết vấn đề hoặc phân tích dữ liệu: nó giao việc thu thập và tổng hợp dữ liệu cho sub-agent, rồi chỉ mang kết quả tóm tắt quay lại
Tương tự, nó cũng có thể để agent chính giữ ngữ cảnh trong tài liệu thiết kế hoặc file Markdown, vừa làm vừa cập nhật. Nhờ vậy lúc nào cũng có thể xóa, khởi động lại hoặc bàn giao
Nói cách khác, nó gần giống đệ quy có tối ưu hóa lời gọi đuôi
Ở một khía cạnh nào đó, đây là sự khái quát hóa của cách tiếp cận hướng đặc tả: ngoài đặc tả hình thức còn có bộ đệm kế thừa được lưu trong bộ nhớ
Ngay cả khi không phải chuyên gia, “mẹo đơn giản” này nghe vẫn như có thể sửa vấn đề ngữ cảnh và cho phép kiểm soát lượng token chặt chẽ hơn nhiều. Cảm ơn vì đã chia sẻ mẹo này trong bình luận HN. Có lẽ từ giờ cách những người hiểu chuyện dùng AI agent sẽ thay đổi. Khó mà theo kịp
Từ khi Anthropic cung cấp cửa sổ ngữ cảnh 1 triệu token trong gói thuê bao, tôi không còn gặp trải nghiệm này với Opus nữa. Bình thường tôi cũng hay vượt 500 nghìn token, thỉnh thoảng gần 800 nghìn mà không thấy vấn đề này
Tôi có thấy đôi chút khi đến gần giới hạn thực sự, trên 900 nghìn token, nhưng không nghiêm trọng như tác giả bài viết nói
Ngay từ đầu thì với một tác vụ đơn lẻ, hoặc một nhóm tác vụ đủ liên quan để giữ cùng một ngữ cảnh, chuyện lấp đầy cửa sổ ngữ cảnh đến mức đó vốn đã hiếm; thường chỉ vào khoảng 200 nghìn đến 600 nghìn
Không phải là không có ai gặp trải nghiệm này, nhưng việc với một số người nó xảy ra thường xuyên đến mức còn được đặt tên thì nghe khá lạ
Cá nhân tôi cho rằng vùng thông minh của Opus là dưới 60 nghìn token. Opus 4.7 và 4.8 còn tệ hơn do tokenizer chi tiết hơn
Chất lượng có vẻ đang theo xu hướng đi lên
Mỗi model và từng phiên bản model dùng kiến trúc attention khác nhau, và điều đó ảnh hưởng đến hiệu năng ngữ cảnh dài. Lượng và kiểu huấn luyện ngữ cảnh dài chắc chắn cũng khác nhau
Mỗi agent cũng khác nhau ở cách xây dựng ngữ cảnh và cách hiện thực nén ngữ cảnh
Nếu không phải cùng model, cùng agent/harness và tác vụ rất giống nhau, thì không có lý do gì để kỳ vọng trải nghiệm về hành vi model liên quan đến kích thước ngữ cảnh sẽ giống nhau
Tùy bài toán thì cửa sổ ngữ cảnh lớn có thể hoạt động, nhưng tôi cảm thấy nghiêng về ngữ cảnh nhỏ hơn, dưới 300 nghìn, sẽ hiệu quả hơn
Opus 4.5 khi tiến gần giới hạn 200 nghìn thì các lệnh gọi công cụ bắt đầu thất bại, Opus 4.6 lên được khoảng 300 nghìn trước khi trở nên rối loạn, Opus 4.7 có thể đẩy đến tầm 400 nghìn nhưng sau đó bước vào vùng ngớ ngẩn. Với Opus 4.8 thì đã có những phiên làm việc vượt 500 nghìn khá thoải mái
Tôi dùng Fable chưa nhiều, nhưng cũng đã có vài phiên lên 800 nghìn đến 900 nghìn mà không gặp trục trặc
Các phiên bản Opus gần đây vẫn ổn khi vượt 100 nghìn, nhưng tôi thường cố giữ dưới 200 nghìn
Vì thế tôi cho rằng cái gọi là hệ thống bộ nhớ phần lớn là một sai lầm khiến model trở nên ngu hơn. Model không có bộ nhớ, nó chỉ có ngữ cảnh; và bạn càng nhồi các dữ kiện không liên quan vào ngữ cảnh, thì càng ít ngữ cảnh còn lại cho vấn đề đang xử lý. Càng ít thứ gây nhiễu thì kết quả càng tốt
Cách để agent “nhớ” thứ gì đó là cho nó tài liệu hóa công việc, giống như khi lập trình viên con người xây một dự án thân thiện cho lập trình viên khác. Tài liệu phát triển tốt có trang chỉ mục và kế hoạch tốt có checklist, được lưu thành các file Markdown ngắn gọn và commit vào repository, chính là loại bộ nhớ lý tưởng cho model, đồng thời cũng là tài liệu lý tưởng để hiểu rốt cuộc model đã làm gì. Nó còn hữu ích khi con người hoặc model khác code review, và không có nhược điểm nào cả
Thế là “hãy nhớ kiểm tra bộ nhớ nhé!” lại tiếp tục được lưu vào bộ nhớ. Rõ ràng đây không phải một hệ thống vận hành tốt
Gần như mọi bình luận ở đây đều đang dựa vào kinh nghiệm cá nhân. Ngược lại, bài gốc dẫn chiếu hai nghiên cứu so sánh hiệu năng trên các bài kiểm tra được chuẩn hóa của nhiều mô hình
Tôi không dám khẳng định các bài kiểm tra đó tốt đến đâu, nhưng chắc cũng không thể tệ hơn bằng chứng giai thoại đối với thứ mơ hồ và mang tính chủ quan như hiệu năng LLM
Trong kết quả của Chroma có Sonnet 4, và theo kinh nghiệm của tôi thì Sonnet 4 cũng rất tệ. Cùng một prompt chạy hoàn hảo trên Sonnet 4.5 lại thất bại thảm hại trên Sonnet 4
Tôi muốn thấy một bài test mới bao gồm cả các mô hình SOTA mới nhất lẫn các mô hình open-weight. Có vẻ các mô hình hàng đầu luôn tuân theo chỉ thị tốt hơn và ít lạc đề hơn, nên sẽ rất hay nếu có dữ liệu chứng minh điều đó
Tôi thấy khá hiệu quả khi bắt nó hành xử như một quản lý sản phẩm cho AI và ép nó viết một PRD ngắn cho từng tính năng cần làm
Làm vậy thì về sau có thể nhìn lại xem đã xây cái gì, và mỗi tính năng cũng ít bị trôi dạt hơn. Tôi giữ cuộc trò chuyện riêng cho từng tính năng
Với tôi, đây là một thỏa hiệp hợp lý: ngăn nó đi chệch hướng nhưng vẫn cho phép tham chiếu lại các quyết định trước đó khi cần. Điểm tôi không thích trong cách của Pocock là viết ít PRD hơn và ưu tiên thảo luận sâu trước để căn chỉnh, nhưng như vậy lại lãng phí quá nhiều phần tốt nhất của lượt qua lại ban đầu
Tôi cũng thường lập kế hoạch trước, nhưng nó chỉ còn lại như một danh sách việc cần làm trong phiên nên sau này khó tham chiếu
Việc soi xem bên trong agent đang xảy ra chuyện gì có lẽ sẽ không còn là một phần lâu dài của phát triển phần mềm
Cá nhân tôi đã xem LLM và agent như hộp đen. Tôi đưa từng yêu cầu tính năng cho nhiều LLM rồi so kết quả. Tôi không tự tay viết “session”; tôi chỉ nhìn vào kết quả. Nếu không ưng, tôi
git reset --hard, đổi prompt rồi bắt đầu lại yêu cầu tính năngTôi lưu log để liên tục nắm bắt agent nào làm tốt nhất, và tính điểm ELO cho agent đáp ứng yêu cầu của tôi tốt nhất. Với tôi, điểm số đó mới quan trọng; agent đạt được nó bằng cách nào thì không quá quan trọng
Tôi đoán kiểu này có thể ổn với các tác vụ frontend không cần quá nhiều kiểm tra về bảo mật hay các xác minh khác
Nhưng với ngành bị quản lý chặt hoặc các công việc đòi hỏi cực kỳ cẩn trọng thì có vẻ không phù hợp
Đúng vậy, quản lý ngữ cảnh mới là cốt lõi
Tôi đã dành rất nhiều thời gian để xây framework riêng và debug vấn đề này, và thứ đáng lo không hẳn là kích thước ngữ cảnh tuyệt đối mà là xác suất trong cửa sổ có rác hoặc các chỉ dẫn sai hướng, khiến chúng lấn át những gì người dùng cho là quan trọng
Điều này thể hiện ở việc LLM cứ tiếp tục lặp lại những thứ đã thất bại trong cách tiếp cận ngay trước đó. Trong cửa sổ ngữ cảnh, thứ gì xuất hiện thường xuyên sẽ có trọng số, kể cả khi nó sai
Cũng có nhiều mẹo như không đưa cho LLM cả đống công cụ, mà đưa cho nó công cụ để tìm kiếm công cụ cần dùng
Nhưng lời giải lớn hơn nằm ở quy trình. Dùng những thứ như superpowers để ép LLM đi theo từng bước và kiểm soát phần ngữ cảnh sẽ được mang tiếp về sau
Tôi đã làm một tiện ích mở rộng cá nhân rất nhỏ cho Pi để thêm lệnh
/last. Nó xóa toàn bộ phiên và chỉ giữ lại tin nhắn đầu ra cuối cùng của agentNhờ đó có thể “nén” thủ công. Về cơ bản tôi bảo agent “hãy tóm tắt kế hoạch đã bàn, kèm tham chiếu tới các file cần chỉnh sửa”, rồi gọi
/last, sau đó mới bảo nó triển khai[1] https://pi.dev/
Tôi không thích kiểu gom tất cả thành “các mô hình” ở đây. Mỗi mô hình có kiến trúc attention khác nhau, nên hành vi với ngữ cảnh dài cũng có thể khác biệt rất lớn
Đúng là ngữ cảnh dài là vấn đề và phần lớn mô hình sẽ bị giảm chất lượng, nhưng tôi sẽ không lấy hành vi của các mô hình cũ rồi khái quát nguyên xi sang các mô hình mới