- Mô hình ngôn ngữ lớn (LLM) có một chiến lược suy luận mới là RLM (Recursive Language Model) được đề xuất để có thể xử lý các prompt đầu vào rất dài
- RLM coi các prompt dài là một phần của môi trường bên ngoài, cho phép mô hình khám phá, phân rã và gọi đệ quy chúng theo cách lập trình được
- Cách làm này vượt qua giới hạn cửa sổ ngữ cảnh hiện có, xử lý đầu vào ở quy mô tới hàng chục triệu token, đồng thời cải thiện chất lượng đáng kể so với LLM truyền thống
- Kết quả thực nghiệm cho thấy RLM dựa trên GPT-5 và Qwen3-Coder có mức cải thiện hiệu năng hai chữ số trên nhiều bài toán văn bản dài, trong khi chi phí tương đương hoặc thấp hơn
- Đây được đánh giá là một cách tiếp cận tổng quát có thể mở rộng mạnh mẽ năng lực suy luận của LLM bằng cách vượt qua giới hạn xử lý ngữ cảnh dài
Tổng quan về RLM
- Recursive Language Model (RLM) được thiết kế để LLM không đưa trực tiếp đầu vào dài vào mạng nơ-ron, mà coi nó như một biến trong môi trường bên ngoài để tương tác
- Prompt đầu vào P được nạp vào một biến trong môi trường Python REPL, và LLM sẽ dùng mã để khám phá, phân rã và gọi đệ quy trên đó
- LLM nhận biết trạng thái của môi trường REPL (ví dụ: độ dài chuỗi), quan sát tác dụng phụ của việc thực thi mã và giải bài toán theo cách dần dần
- Cấu trúc này giải quyết vấn đề mất chi tiết của các phương pháp nén ngữ cảnh (compaction) hoặc dựa trên tóm tắt truyền thống
- RLM được đưa ra như một mô hình suy luận tổng quát có thể mở rộng cả độ dài đầu vào lẫn đầu ra
Giới hạn của các cách tiếp cận hiện có
- LLM truyền thống gặp hiện tượng context rot, tức hiệu năng suy giảm mạnh trên đầu vào dài do giới hạn cửa sổ ngữ cảnh
- Các kỹ thuật nén ngữ cảnh (compaction) sẽ lặp lại việc tóm tắt khi vượt quá một độ dài nhất định, nhưng không phù hợp với các tác vụ cần truy cập thông tin chi tiết
- RLM xử lý prompt như một đối tượng bên ngoài, nhờ đó có thể mở rộng kích thước đầu vào vượt quá giới hạn của mô hình
Thiết lập thực nghiệm
- Mô hình đánh giá: GPT-5 (OpenAI, 2025) và Qwen3-Coder-480B-A35B (Team, 2025)
- Các đối tượng so sánh:
- Gọi trực tiếp LLM cơ bản
- Summary agent
- Tác tử truy xuất dựa trên CodeAct + BM25
- RLM (bao gồm môi trường REPL) và RLM (REPL, không gọi đệ quy)
- Trong thực nghiệm với GPT-5, GPT-5-mini được dùng cho các lời gọi đệ quy, còn GPT-5 làm mô hình gốc để cân bằng giữa hiệu năng và chi phí
Các bài toán đánh giá
- S-NIAH: bài toán ‘needle-in-a-haystack’ đơn lẻ, chi phí xử lý không đổi theo độ dài đầu vào
- BrowseComp-Plus: bài toán hỏi đáp multi-hop đi qua nhiều tài liệu, trong đó đáp án nằm trong 1000 tài liệu
- OOLONG: bài toán suy luận văn bản dài yêu cầu biến đổi và tích hợp gần như toàn bộ các mục trong đầu vào theo ngữ nghĩa; chi phí xử lý tăng tuyến tính theo độ dài đầu vào
- OOLONG-Pairs: biến thể của OOLONG, yêu cầu kết hợp thông tin theo từng cặp, với chi phí xử lý tăng theo bình phương độ dài đầu vào
- LongBench-v2 CodeQA: bài toán trắc nghiệm đòi hỏi hiểu kho mã nguồn, vẫn là một vấn đề khó ngay cả với các mô hình mới nhất
Kết quả chính
- RLM hầu như không bị suy giảm hiệu năng trên ngữ cảnh dài so với GPT-5
- GPT-5 suy giảm hiệu năng mạnh khi độ dài đầu vào và độ phức tạp bài toán tăng lên
- RLM xử lý hiệu quả cả đầu vào vượt quá giới hạn 272K token (tối đa hơn 10M token)
- Trên mọi bài toán văn bản dài, RLM đều cho mức cải thiện hiệu năng hai chữ số so với các phương pháp khác
- Hiệu quả chi phí cũng được duy trì, với chi phí trên mỗi truy vấn tương đương hoặc thấp hơn các cách tiếp cận hiện có
Phân tích độ phức tạp của bài toán văn bản dài
- Cửa sổ ngữ cảnh thực tế của LLM có thể ngắn hơn giới hạn vật lý tùy theo độ phức tạp của bài toán
- Bài toán NIAH đơn giản có thể được giải ngay cả ở mức 1M+ token
- Các bài toán phức tạp kiểu OOLONG lại bắt đầu suy giảm hiệu năng ở độ dài ngắn hơn nhiều
- Vì vậy cần xem xét đồng thời mật độ thông tin của bài toán và mối tương quan với độ dài đầu vào
Kết luận
- RLM mở rộng năng lực suy luận của LLM theo cách đệ quy, cho phép xử lý đầu vào siêu dài mà các mô hình hiện có không thể làm được
- Thiết kế coi prompt như một đối tượng trong môi trường là đổi mới cốt lõi, giúp giải quyết giới hạn cấu trúc trong xử lý văn bản dài
- Nó được trình bày như một khung suy luận tổng quát đạt được sự cân bằng giữa hiệu năng, chi phí và khả năng mở rộng trên nhiều mô hình và bài toán khác nhau
1 bình luận
Ý kiến trên Hacker News
Cái này trông đơn giản giống khái niệm subagent
Tức là gọi một LLM khác để đọc file và trích xuất thông tin cần thiết, nhằm tránh làm ngữ cảnh chính trở nên quá phức tạp
Ý tưởng thì ổn nhưng không hoàn toàn mới
Hiện tôi đang thử nghiệm trong dự án Scope để các subagent có thể quan sát được phân rã công việc một cách đệ quy
Tuy vậy, tôi chưa biết phải cải thiện việc đánh giá giai đoạn lập kế hoạch này như thế nào
Tôi ghi lại heuristic trong các file Markdown, nhưng cấu trúc lỏng lẻo nên rất khó đo lường
Nếu ai biết tài liệu hay dự án liên quan thì rất mong được chia sẻ
RLM không phải agent cũng không phải tóm tắt
Việc dùng nhiều lần gọi LM trong một hệ thống không phải khái niệm mới, và đó là điều mà phần lớn agentic scaffold đang làm
Ví dụ gần nhất là ROMA agent, nơi vấn đề được phân rã và giải bằng nhiều sub-agent
Ngoài ra, các trợ lý code như Cursor hay Claude Code cũng tóm tắt hoặc cắt tỉa khi ngữ cảnh trở nên quá dài
Các cách tiếp cận như vậy thường phân rã theo đơn vị công việc, còn RLM nhấn mạnh phân rã theo đơn vị ngữ cảnh, và cho rằng LM phải tự quyết định lựa chọn đó
Insight cốt lõi là không nên đưa prompt dài trực tiếp vào mạng nơ-ron (Transformer), mà nên xem nó như một phần của môi trường mà LLM có thể tương tác theo kiểu biểu tượng
Nhưng tôi thắc mắc điều này khác RAG về bản chất ở điểm nào
Nhìn hình 4 thì có vẻ khác biệt là thay vì con người, chính LLM tự triển khai cơ chế retrieval
1️⃣ RAG gần với workflow hơn, còn cái này mang tính agentic hơn
2️⃣ Nó có cấu trúc đệ quy
Trong workflow, con người thiết kế luồng theo từng bước; còn trong cách tiếp cận agentic, agent tự quyết định sẽ tìm gì, gọi bao nhiêu lần và khi nào trả lời
Ví dụ như Claude Code hay Codex sẽ khám phá codebase, đọc file và chạy ripgrep
Những thử nghiệm đệ quy kiểu này từng có từ trước (ví dụ: babyagi, khoảng năm 2023), nhưng khi đó mô hình chưa đủ mạnh nên cần rất nhiều glue code
Giờ thì mô hình đã đủ mạnh để cấu trúc như vậy thực sự hoạt động
Giống như câu đùa “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down”, nó gợi ý một cấu trúc trong đó LLM liên tục gọi LLM không có hồi kết
Có một phiên bản bài viết dễ đọc hơn: bài blog của alexzhang13
Điều tôi mong vào năm 2026 là Anthropic hoặc OpenAI công khai cho những người làm plugin CLI biết “compaction được thực thi như thế nào”
Kỹ thuật này có thể thay thế tính năng tích hợp sẵn trong Claude Code, nhưng hiện tại chưa có hook hay chức năng phù hợp nào được lộ ra
Tôi đã xem source của Gemini, và khi cửa sổ ngữ cảnh đầy thì nó dùng một cấu trúc prompt đơn giản để tóm tắt toàn bộ
Có vẻ giống với bài báo này: arXiv:2510.14826