Cách AI hiểu bối cảnh 1M token

Trong vài năm qua, các mô hình ngôn ngữ lớn (LLM) đã mở rộng cửa sổ ngữ cảnh (context window) của mình từ vài nghìn token lên đến hàng triệu vào năm 2025. Điều này giúp chúng có thể xử lý toàn bộ sách, các codebase khổng lồ, hoặc hàng giờ video trong một lần. Tuy nhiên, con số thô này có thể gây hiểu lầm. Điều quan trọng không phải là mô hình có thể chấp nhận bao nhiêu token; mà là kiến trúc của nó xử lý chúng như thế nào.

Khi mìnhbắt đầu xây dựng các pipeline RAG vào năm 2023, những mối quan tâm ban đầu của mình là: tốc độ/giá token đầu ra, độ dài cửa sổ ngữ cảnh. Các hành vi kỳ lạ của mô hình là điều mình ít quan tâm nhất, vì cho rằng khả năng tư duy, suy luận của mô hình quan trọng hơn cách nó đọc hiểu hiểu ngữ cảnh.

Tuy nhiên, đây là một cái bẫy nguy hiểm của giả định.

Cho dù bạn sử dụng các kỹ thuật context engineering như chunking, retrieval (RAG) hay instruction tuning, thì việc hiểu cơ chế vận hành trong long context window vẫn rất quan trọng trong việc lựa chọn mô hình phù hợp cho nhu cầu sử dụng.

Các benchmark cụ thể đã chỉ ra rằng các lựa chọn kiến trúc trong cơ chế attention, mã hóa vị trí (positional encodings) và hệ thống bộ nhớ quyết định cách mô hình trọng số hóa các token, cách nó “quên”, và cách nó tổng hợp thông tin.

1. Bức tranh tổng quát về kiến trúc context window mở rộng

Đến cuối năm 2025, cửa sổ ngữ cảnh đã ổn định ở mức từ 128k đến 2M token đối với hầu hết các mô hình hàng đầu. Tuy nhiên, các benchmark như LongBench và RULER liên tục cho thấy ngữ cảnh hiệu quả của một mô hình, tức là điểm mà tại đó khả năng truy hồi và suy luận vẫn đáng tin cậy, thường chỉ bằng một nửa so với mức tối đa được quảng cáo. Khoảng cách này là kết quả trực tiếp của các triết lý kiến trúc khác nhau.

Hệ sinh thái hiện đại của các mô hình lớn đã phân mảnh thành các dòng kiến trúc riêng biệt, mỗi dòng có những đánh đổi độc đáo giữa chiều sâu suy luận, khả năng ghi nhớ bền vững và hiệu quả tính toán. Bảng dưới đây tóm tắt các họ mô hình chủ đạo và những dấu hiệu hành vi mà các nhà phát triển thấy trong sản xuất.

Mô hình	Ngữ cảnh điển hình	Đặc điểm kiến trúc
OpenAI GPT-5	~400k cho Pro tiers, đầu vào điển hình 272k	Dense Transformer với RoPE tinh chỉnh và bộ định tuyến chế độ “suy nghĩ”
Claude Sonnet 4.5	200k tiêu chuẩn, lên đến 1M cho doanh nghiệp	Hybrid attention với nén ngữ cảnh và công cụ bộ nhớ rõ ràng
Gemini 2.5 Pro	~1M tiêu chuẩn, lên đến 2M trong các chương trình doanh nghiệp	Multimodal Transformer với Ring Attention phân tán
Meta Llama 4 Scout	Lên đến 10M token (nghiên cứu)	Mixture-of-Experts (MoE) với ALiBi để xử lý ngữ cảnh dài.
Qwen 2.5	Lên đến 1M token	Sparse Attention + MoE với pretraining theo giai đoạn.
Mistral Large (2025)	Thường 128k-256k	Dense Transformer với FlashAttention-3.
Mamba (Gu & Dao, 2024)	Hơn 1M hiệu quả	Selective State Space Model (SSM) thay thế self-attention
Granite 4.0	512k được huấn luyện, 128k ổn định	Hybrid Mamba + Transformer với định tuyến bộ nhớ thích ứng

2. Cách các mô hình thực sự sử dụng ngữ cảnh

Để hiểu những hành vi này, chúng ta cần xem xét sâu hơn bên trong. Hiệu suất của một mô hình không phải là phép màu; đó là hệ quả trực tiếp của các đánh đổi kỹ thuật được thực hiện để giải quyết các thách thức mở rộng quy mô cơ bản.

Các cơ chế attention tối ưu bộ nhớ

Với cách thiết kế cơ chế self-attention ban đầu, việc cho phép mỗi token nhìn vào mọi token khác, khiến độ phức tạp của bài toán mở rộng theo cấp số nhân (O(n²)) với độ dài chuỗi. Điều này làm cho các ngữ cảnh vượt quá vài nghìn token trở nên cực kỳ đắt đỏ. Các kiến trúc hiện đại khắc phục điều này theo một số cách như:

Tối ưu hóa attention chính xác: thay vì đổi thuật toán attention,  các mô hình như Mistral và GPT-5 sử dụng các nhân tối ưu hóa như FlashAttention-3. Kỹ thuật này sử dụng “tiling” để giảm đáng kể số lượng các hoạt động đọc/ghi chậm vào bộ nhớ băng thông cao của GPU, giúp tính toán chính xác attention khả thi cho các chuỗi lên đến 256k token và hơn thế nữa

Sparse hoặc hybrid attention: Các kiến trúc này nén hoặc tóm tắt các phần của ngữ cảnh một cách động để kiểm soát sự tăng trưởng bộ nhớ. Dựa vào những gì được công bố, có thể đoán rằng Claude và Gemini sử dụng kiến trúc này. Nghiên cứu như Longformer cho thấy sparse hoặc hybrid attention cho phép các mô hình duy trì sự mạch lạc về mặt chủ đề và giảm chi phí tính toán bằng cách loại bỏ hoặc tổng hợp thông tin ít nổi bật hơn khi chuỗi tăng lên.

Kiến trúc sparse attention này khá hữu ích trong việc thiết kế các workflow, pipeline mang tính agentic bởi các agent sẽ được chia xử lý từng phần context cho phù hợp, tránh nhiễu trong các tác vụ tư duy nhiều bước. Nó cho phép các coding agent có thể phân tích codebase đồ sộ mà không phải nạp lại context cho mỗi agent

Attention phân tán: Đối với một hệ thống có khả năng mở rộng, Ring Attention (Liu, 2023) có thể song song hóa khối lượng công việc trên một cụm bộ tăng tốc. Mỗi thiết bị tính toán attention cho một lát cắt của chuỗi và chuyển kết quả cho thiết bị tiếp theo trong một vòng, cho phép tính toán chính xác attention trên hàng triệu token. Google Gemini 1.5 được cho là sử dụng phương pháp này, nhưng chúng ta không biết chắc chắn vì họ không công bố kiến trúc độc quyền của mình. Một tính năng thú vị của kiến trúc này trong sản xuất là nó hỗ trợ chế độ tính toán xác định, có thể giúp các nhà phát triển đảm bảo tính nhất quán cao hơn

Tác động là một sự đánh đổi rõ ràng: các mô hình exact attention mang lại độ chính xác cao nhất cho các tác vụ cần chính xác về mặt từ ngữ như đánh giá pháp lý, trong khi các mô hình phân tán mở khóa khả năng mở rộng chưa từng có để phân tích hàng loạt các tệp phương tiện lớn.

Mã hóa vị trí mở rộng (Extended Positional Encodings)

Kiến trúc transformers không có khái niệm nội tại về trật tự token. Mã hóa vị trí cho mô hình biết mỗi token ở đâu, nhưng phương pháp được chọn tạo ra các sai lệch mạnh mẽ, có thể dự đoán được.

Rotary Position Embeddings (RoPE): Được sử dụng bởi Llama 4, RoPE mã hóa các vị trí một cách tương đối. Để xử lý các chuỗi dài hơn dữ liệu huấn luyện của chúng, chúng sử dụng RoPE scaling, “kéo dài” các giá trị vị trí. Mặc dù điều này ngăn mô hình bị nhầm lẫn và “cuộn tròn”, nó làm giảm độ phân giải giữa các token xa, góp phần trực tiếp vào vấn đề “mất ở giữa” (lost in the middle) khi các chi tiết giữa ngữ cảnh thường bị bỏ qua hoặc nhớ sai.

Attention with Linear Biases (ALiBi): Ban đầu được giới thiệu như một hình phạt tuyến tính đơn giản trên điểm attention theo khoảng cách token, ALiBi đã trở thành một lược đồ vị trí phổ biến. Nó mã hóa cứng một thiên vị gần đây, làm cho mô hình tự nhiên ưu tiên các token mới hơn trong khi vẫn cho phép ngoại suy mượt mà sang các chuỗi dài hơn. Điều này đã được triển khai trong các mô hình Mistral, cùng với thư viện FlashAttention.

Điều này giải thích tại sao, trong một tác vụ Q&A dài, GPT-5 (dense attention) có thể kết nối chính xác hai sự kiện xa nhau nhưng lại gây ảo giác một sự kiện thứ ba từ giữa, trong khi một biến thể Llama có thể bỏ qua hoàn toàn phần đầu của prompt để ưu tiên phần cuối.

State space model: giải pháp mới cho kiến trúc transformer?

Một lớp kiến trúc mới đang phá vỡ hoàn toàn mô hình attention. Nổi bật nhất là Mamba (Gu & Dao, 2024), giới thiệu Selective State Space Model (SSM) thay thế self-attention. Thay vì so sánh mọi cặp token, Mamba duy trì một trạng thái ẩn đang phát triển hoạt động như một bộ nhớ nén của các token trong quá khứ. Nó cập nhật trạng thái này một cách có chọn lọc, học cách ghi đè và khi nào giữ lại thông tin.

Cách tiếp cận này cho phép xử lý thời gian tuyến tính, trong đó mỗi token được xử lý trong thời gian không đổi, mang lại cho Mamba khả năng mở rộng hiệu quả O(n). Nói một cách thực tế, nó có thể xử lý hàng triệu token với việc sử dụng bộ nhớ nhất quán, điều mà ngay cả các Transformer tối ưu hóa như GPT-5 hoặc Gemini cũng gặp khó khăn.

Không giống như attention, vốn tính toán rõ ràng các mối quan hệ giữa các token, cơ chế quét chọn lọc của Mamba hoạt động giống như một bộ lọc động hơn, quyết định thông tin nào trong quá khứ sẽ được truyền tiếp. Nó không lưu trữ một bản đồ rõ ràng về tất cả các mối quan hệ, mà là một bộ nhớ liên tục, nén của chuỗi. Thiết kế này mang lại cho Mamba hiệu suất vượt trội trong các tác vụ như truy xuất “kim trong đống rơm”, dữ liệu luồng và QA tuần tự, nơi khả năng truy hồi bền vững quan trọng hơn suy luận quan hệ chi tiết.

Tuy nhiên, điểm mạnh của nó đi kèm với những đánh đổi. Vì trạng thái nội bộ của nó được nén, Mamba đôi khi có thể mất chi tiết tinh tế và gặp khó khăn với suy luận đa bước phức tạp. Các kiến trúc lai mới nổi, như Granite 4.0 của IBM (và có thể là Gemini 2.5 Pro), đang khám phá cách hợp nhất bộ nhớ đệ quy giống Mamba với các lớp suy luận Transformer, đạt được cả sự ổn định truy hồi và chiều sâu logic.
Các mô hình lai của Granite 4.0 thực sự sử dụng tỷ lệ 9:1 giữa các khối Mamba-2 và các khối Transformer. Ý tưởng là Mamba xử lý ngữ cảnh rộng và bộ nhớ tầm xa một cách nhẹ nhàng, hiệu quả, trong khi các lớp Transformer định kỳ can thiệp để quản lý suy luận quan hệ chi tiết.

3. Các dấu hiệu sụp đổ có thể dự báo trước

Vấn đề “mất ở giữa” (lost in the middle) nổi tiếng chỉ là một triệu chứng của những lựa chọn thiết kế này. Mỗi kiến trúc đều có chế độ thất bại đặc trưng riêng khi bị đẩy đến giới hạn của nó.

Nghiên cứu đã nhiều lần xác nhận rằng độ dài ngữ cảnh dài một mình không đảm bảo suy luận ổn định. Liu et al. (2023) đã chứng minh hiệu ứng “mất ở giữa”: đó là một đường cong truy hồi hình chữ U, nơi các mô hình quá nhấn mạnh các token gần đây và sớm trong khi bỏ qua thông tin ở giữa một prompt. Hiện tượng này, sau này được gọi là “context rot”, vẫn tồn tại ngay cả trong các kiến trúc năm 2025, mặc dù các biện pháp giảm thiểu đã phát triển. Các mô hình Granite 4.0 của IBM (IBM, 2025) đã tích hợp định tuyến bộ nhớ phân cấp và các lớp attention lai duy trì rõ ràng sự nổi bật của token trên các ngữ cảnh vài trăm nghìn token, cho thấy những dấu hiệu ổn định sớm vượt xa những gì các transformer tiêu chuẩn đạt được.

• Dense Transformers như GPT-5 và Mistral vẫn có thể thất bại một cách tinh tế, không phải hoàn toàn. Vì chúng tính toán attention đầy đủ, chúng hiếm khi bị hỏng hoàn toàn. Tuy nhiên, lỗi của chúng biểu hiện dưới dạng ảo giác thực tế tinh vi, nơi một chi tiết từ token 50.000 được truy hồi gần như chính xác, nhưng với một con số hoặc tên quan trọng bị sai.
• Compression-Hybrids như Claude 4.5 thất bại vì quá thận trọng. Điểm mạnh của chúng là duy trì sự mạch lạc về mặt chủ đề. Điểm yếu của chúng là việc điều chỉnh căn chỉnh có thể phân loại sai một lượng lớn văn bản do người dùng cung cấp (như một cuốn tiểu thuyết) là tài liệu có bản quyền, dẫn đến một lời từ chối lịch sự.
• Sparse và Multimodal models như Gemini 2.5 có khả năng truy hồi thực tế gần như hoàn hảo. Điểm thất bại chính của chúng thường là cấu trúc hỗ trợ xung quanh mô hình. Với hàng triệu token đa phương thức cần xử lý, chúng có nhiều khả năng bị gián đoạn phản hồi bởi một bộ lọc an toàn quá nhạy cảm tìm thấy một lỗi dương tính giả trong nhiễu, dẫn đến thất bại trong một trong các bước suy luận
• Mixture-of-Experts models như Llama 4 và Qwen có thể thất bại thông qua sự trôi dạt hướng dẫn hoặc lặp lại. Nếu một truy vấn phức tạp bị đẩy đến giới hạn ngữ cảnh của mô hình, cơ chế định tuyến chuyên gia có thể bắt đầu hỏng, khiến mô hình “mất vị trí” và mặc định trả về đầu ra chung chung hoặc lặp lại.
• State-Space Models (ví dụ: Mamba): Mamba giới thiệu một loại hồ sơ thất bại mới. Vì nó lưu trữ thông tin dưới dạng các trạng thái nội bộ liên tục, lỗi có xu hướng biểu hiện dưới dạng mất mát nén thông tin hơn là ảo giác hoàn toàn. Mô hình có thể nhớ đúng rằng một sự kiện tồn tại sớm hơn trong chuỗi nhưng diễn giải lại hoặc đơn giản hóa nó không chính xác. Hành vi này làm cho nó cực kỳ ổn định trong các ngữ cảnh cực dài nhưng đôi khi không chính xác trong suy luận phân tích chi tiết, đặc biệt khi cần phân biệt nhạy cảm theo ngữ cảnh.
  IBM’s Granite 4.0 đại diện cho một kiến trúc “lai dày đặc-thưa thớt” (hybrid dense-sparse) kết hợp các khía cạnh của Mixture-of-Experts với nén thích ứng. Thay vì định tuyến token hoàn toàn đến các chuyên gia riêng biệt, nó sử dụng tổng hợp phân cấp và các lớp bộ nhớ dài hạn giúp giảm suy giảm gradient theo khoảng cách.

4. Sự cộng sinh cần thiết của RAG và ngữ cảnh dài

Đến cuối năm 2025, việc cân nhắc về hạn chế cứng của cửa sổ ngữ cảnh của các mô hình LLM là gần như không còn cần thiết. Rõ ràng cửa sổ ở phân khúc 100k token là quá đủ cho hầu hết các tác vụ thông thường. Chỉ có các tác vụ coding, với codebase lớn thì context window dài mới trở nên thực sự hữu dụng.

Tuy vậy, việc truy hồi thông tin vẫn vô cùng cần thiết để tránh sự lạc đề của các agent trong workflow.

• Cần độ chính xác không thỏa hiệp như phân tích pháp lý: Truy xuất 10-15 điều khoản liên quan nhất từ thư viện tài liệu, sau đó sử dụng mô hình attention dày đặc như GPT-5 để suy luận trên chúng trong cửa sổ ngữ cảnh 128k.
• Cần tổng hợp dữ liệu khổng lồ, đa dạng hoặc đa phương thức?  Chọn một sparse hoặc multimodal hybrid như Gemini 2.5 Pro hoặc Qwen 2.5 để đặt câu hỏi về các sự kiện trong bản ghi. kéo dài hàng giờ, một tác vụ không thể thực hiện được với RAG chỉ dựa trên văn bản.
• Đối với các agent: Tận dụng context windows dài để cho phép một tác nhân hiểu được bối cảnh tổng quát của workflow, sau đó sử dụng RAG để kéo thêm kiến thức bên ngoài mới khi cần.

Mặc dù bạn có thể dễ dàng đưa hàng trăm trang văn bản hoặc mã vào một prompt duy nhất, nhưng nếu bạn làm như vậy thường xuyên, bạn có thể đang làm việc không hiệu quả. Các pipeline truy xuất và dựa trên đồ thị hiện đại — RAG và DAG — vẫn rất cần thiết, không chỉ cho độ chính xác suy luận mà còn để kiểm soát chi phí. Chính kiến trúc mới là yếu tố quyết định cách mô hình hiểu, nhớ và suy luận.

Sai lầm lớn nhất mà một nhà phát triển có thể mắc phải không phải là kỹ thuật ngữ cảnh chưa đủ tốt – mà là giả định rằng tất cả các kiến trúc đều sử dụng ngữ cảnh theo cùng một cách. Trên thực tế, thiết kế của mô hình định hình cuộc hội thoại nhiều như chính các token vậy.

---

References

Gu, A., & Dao, T. (2024). Mamba: Linear-time sequence modeling with selective state spaces. arXiv:2312.00752.

Liu, N. F., Röttger, P., Misra, K., Yu, J., & Levy, O. (2023). Lost in the middle: How language models use long contexts. arXiv:2307.03172

International Business Machines Corporation. (2025, October 2). IBM Granite 4.0: Hyper-efficient, high-performance hybrid models. IBM Newsroom. Retrieved from https://www.ibm.com/new/announcements/ibm-granite-4-0-hyper-efficient-high-performance-hybrid-models