Nếu token là đơn vị tiền tệ mà LLM (large language model) dùng để "tiêu", thì context window chính là cái ví — giới hạn tổng số token mà model có thể nhìn thấy và xử lý trong một lượt suy luận. Với một AI agent làm việc trên codebase thật, context window không chỉ là một con số kỹ thuật ghi trong tài liệu model — nó là ràng buộc cứng quyết định agent có "nhớ" được instruction bạn viết ở đầu conversation không, có tìm đúng function cần sửa trong 40 file đã đọc không, và có trả lời chính xác một con số cấu hình quan trọng đang nằm ở giữa một đoạn log dài không. Hiểu sai về context window là nguyên nhân phổ biến nhất khiến agent "đột nhiên" trở nên ngu ngơ giữa một session dài, dù bạn không đổi gì trong prompt.

Chủ đề này đi từ định nghĩa kỹ thuật của context window, qua hiện tượng "lost in the middle" (thất lạc ở giữa) đã được nghiên cứu và kiểm chứng, đến cách bạn có thể tự thiết kế context và tự benchmark model của mình để biết chính xác nó "nhìn rõ" đến đâu.

Context Window Thực Chất Là Gì

Về mặt kỹ thuật, context window là số lượng token tối đa mà một model có thể xử lý trong một lần gọi (single inference call) — bao gồm toàn bộ input (system prompt, lịch sử hội thoại, tool definitions, tool results, file đã đọc) cộng với phần output mà model sẽ sinh ra. Đây không phải là dung lượng "lưu trữ" kiểu bộ nhớ RAM — model không "ghi nhớ" gì giữa các lần gọi API. Mỗi lần gọi, toàn bộ context phải được gửi lại từ đầu, và model xử lý nó như một chuỗi token liên tục đi qua kiến trúc transformer.

Về cơ chế bên trong, context window bị chi phối bởi cơ chế attention (self-attention) trong transformer: mỗi token trong input có thể "chú ý" (attend) đến mọi token khác trong cùng context để tính ra biểu diễn ngữ nghĩa của nó. Đây là lý do context window có giới hạn — chi phí tính toán của attention tăng theo bậc hai (quadratic) so với độ dài chuỗi trong kiến trúc transformer gốc, dù các kỹ thuật tối ưu hiện đại (sliding window attention, sparse attention, các biến thể FlashAttention...) đã giúp các model thương mại hiện nay hỗ trợ context window từ 128K đến hơn 1 triệu token.

Có ba điều mà kỹ sư xây agent hay hiểu lầm về context window:

1. Context window không đồng nghĩa với "chất lượng đồng đều": Model có context window 200K token không có nghĩa là nó "hiểu" token thứ 150.000 tốt như token thứ 500. Dung lượng tối đa (maximum capacity) và dung lượng hiệu quả (effective capacity) là hai khái niệm khác nhau — phần "Attention Concentration" ở dưới sẽ giải thích rõ hơn.
2. Context window được tính theo token, không theo ký tự hay từ: Một file code 2.000 dòng có thể chiếm 15.000–20.000 token tuỳ ngôn ngữ và độ dài biến, không phải một con số cố định. Bạn không thể ước lượng bằng cách đếm ký tự chia 4 một cách máy móc cho mọi loại nội dung — code, JSON, và văn bản tự nhiên có tỷ lệ token/ký tự khác nhau khá rõ.
3. Input và output chia sẻ cùng một context window: Nếu model có context window 128K và bạn nhồi 127K token input, phần output khả dụng chỉ còn 1K token — không đủ để agent viết một function hoàn chỉnh, chưa nói đến việc giải thích lý do sửa.

Cấu trúc bên trong: token, position, và attention score

Khi bạn gửi context cho model, mỗi token được gán một vị trí (positional encoding) để model biết token nào đứng trước, đứng sau. Trong quá trình suy luận, mỗi token sinh ra một attention score với mọi token khác trong context — điểm số này quyết định token nào "ảnh hưởng" nhiều nhất đến việc sinh token tiếp theo. Về lý thuyết, một token ở đầu context và một token ở cuối context có "quyền" được chú ý ngang nhau. Trên thực tế, quyền đó phân bố không đều — và đó chính là gốc rễ của vấn đề "lost in the middle" ở phần sau.

Mẹo: Khi debug một agent trả lời sai hoặc "quên" instruction, câu hỏi đầu tiên nên là "context hiện tại đang chiếm bao nhiêu token, và instruction quan trọng đang nằm ở vị trí nào trong đó" — trước khi nghi ngờ model "ngu" hoặc đổi sang model khác. Rất nhiều lỗi tưởng là lỗi model thực ra là lỗi context assembly.

Vấn Đề "Lost in the Middle" — Nghiên Cứu và Thực Tế

"Lost in the middle" là hiện tượng model xử lý thông tin ở đầu và cuối context window tốt hơn đáng kể so với thông tin nằm ở giữa. Nghiên cứu "Lost in the Middle: How Language Models Use Long Contexts" của Liu và cộng sự (Nal Kalchbrenner, Percy Liang cùng nhóm tại Stanford/Berkeley, công bố 2023) là công trình đầu tiên định lượng rõ hiện tượng này một cách có hệ thống. Thí nghiệm cốt lõi: đặt một đoạn văn bản chứa câu trả lời đúng (ground-truth document) vào các vị trí khác nhau trong một danh sách document dài (đầu, giữa, cuối), rồi hỏi model một câu hỏi mà câu trả lời chỉ có trong đoạn đó. Kết quả cho thấy độ chính xác tạo ra một đường cong hình chữ U: cao nhất khi câu trả lời nằm ở đầu hoặc cuối context, và giảm rõ rệt — có trường hợp giảm về mức tương đương với việc model hoàn toàn không có context đó — khi câu trả lời nằm ở khoảng giữa. Hiện tượng này xuất hiện nhất quán trên nhiều model khác nhau tại thời điểm nghiên cứu, kể cả những model được quảng cáo hỗ trợ context window rất dài.

Ý nghĩa thực tiễn cho người xây agent là rất trực tiếp: nếu bạn nhồi 30 file code vào context và file quan trọng nhất — file chứa bug — nằm ở vị trí thứ 15 trong 30, khả năng agent "nhìn thấy nhưng không dùng" thông tin đó cao hơn nhiều so với khi file đó nằm ở đầu hoặc cuối. Điều nguy hiểm hơn: agent không báo lỗi, không nói "tôi không thấy thông tin này" — nó vẫn trả lời trôi chảy, chỉ là trả lời sai hoặc bỏ sót, khiến lỗi này rất khó phát hiện nếu bạn không chủ động test.

Ví dụ kiểm tra: truy xuất một giá trị rate limit API quan trọng ở các vị trí khác nhau

Để thấy hiện tượng này bằng số liệu cụ thể trên chính stack của bạn (không chỉ tin vào paper), bạn có thể tự dựng một bài test đơn giản: giấu một giá trị cấu hình quan trọng (ví dụ rate limit của một API) vào các vị trí khác nhau trong một context giả lập gồm nhiều đoạn tài liệu kỹ thuật, rồi hỏi model lấy lại đúng giá trị đó.

import random
import string

def build_filler_doc(topic_id: int, n_sentences: int = 40) -> str:
    """Generate a plausible-looking but irrelevant technical doc block."""
    sentences = [
        f"Service module {topic_id} handles internal caching for subsystem {topic_id}.",
        f"Retry logic for module {topic_id} uses exponential backoff starting at 200ms.",
        f"Module {topic_id} logs are shipped to the central observability pipeline.",
        f"Deployment for module {topic_id} follows the standard blue-green rollout process.",
    ]
    return " ".join(random.choices(sentences, k=n_sentences))

def build_context(target_position: str, target_rate_limit: str = "742 req/min") -> str:
    """
    target_position: "start" | "middle" | "end"
    Returns a context string with the ground-truth fact planted
    at the requested position among 20 filler documents.
    """
    needle = (
        f"\n--- Doc: payments-api-config ---\n"
        f"The Payments API enforces a hard rate limit of {target_rate_limit} "
        f"per API key for the /v2/charges endpoint. Exceeding this returns HTTP 429.\n"
    )

    filler_docs = [
        f"\n--- Doc: internal-module-{i} ---\n{build_filler_doc(i)}\n"
        for i in range(20)
    ]

    if target_position == "start":
        docs = [needle] + filler_docs
    elif target_position == "end":
        docs = filler_docs + [needle]
    else:  # middle
        mid = len(filler_docs) // 2
        docs = filler_docs[:mid] + [needle] + filler_docs[mid:]

    return "\n".join(docs)

QUESTION = (
    "What is the exact rate limit (requests per minute) enforced on the "
    "Payments API /v2/charges endpoint? Answer with only the number and unit."
)

for position in ["start", "middle", "end"]:
    context = build_context(position)
    prompt = f"{context}\n\nQuestion: {QUESTION}"
    # response = call_llm(prompt)  # plug in your model client here
    # print(position, "->", response)

Chạy bài test này với context khoảng 15.000–30.000 token filler (tuỳ context window model bạn test), lặp lại nhiều lần với filler khác nhau để tránh may rủi thống kê, rồi lập bảng độ chính xác theo vị trí. Trong thực tế triển khai ở nhiều team, kết quả thường lặp lại đúng hình chữ U của paper: vị trí "start" và "end" đạt độ chính xác gần như tuyệt đối, còn "middle" có thể tụt xuống rõ rệt, đặc biệt khi tổng context vượt một ngưỡng nào đó (thường là khi context đã lấp đầy phần lớn — không phải toàn bộ — context window công bố của model).

Hệ quả thiết kế agent: đừng đặt system prompt chứa rule quan trọng nhất ở giữa một context dài đã lấp đầy bởi tool results và file content. Đặt các constraint mang tính "phải tuân thủ tuyệt đối" ở đầu (ngay sau system prompt) hoặc lặp lại ở cuối (ngay trước câu hỏi/yêu cầu cuối cùng) — kỹ thuật này thường được gọi là "sandwich prompting" hoặc "recency reinforcement".

Mẹo: Trước khi đổ lỗi cho model vì "bỏ sót" một thông tin rõ ràng có trong context, hãy tự hỏi thông tin đó đang nằm ở vị trí tương đối nào (đầu/giữa/cuối) trong toàn bộ context đã gửi. Nếu nó nằm ở giữa một context lớn, thử di chuyển nó lên gần đầu hoặc lặp lại gần cuối trước khi kết luận model "không đủ khả năng".

Kiến Trúc Context Window — Các Mẫu Thiết Kế Cấu Trúc

Vì attention không phân bố đều, cách bạn tổ chức (assemble) context — không chỉ nội dung gì được đưa vào, mà cả thứ tự và cấu trúc — ảnh hưởng trực tiếp đến chất lượng output của agent. Có bốn nguyên tắc cấu trúc phổ biến nên áp dụng khi thiết kế context cho agent:

1. Instruction ở đầu, task cụ thể ở cuối: System prompt và các rule bắt buộc nên nằm ở phần đầu context (được model chú ý mạnh vì là điểm khởi đầu chuỗi), còn yêu cầu cụ thể của lượt hiện tại nên nằm cuối cùng, ngay trước khi model bắt đầu sinh output (được hưởng lợi từ hiệu ứng "recency" — thông tin gần cuối cũng được chú ý mạnh).
2. Phân đoạn rõ ràng bằng delimiter nhất quán: Dùng heading Markdown, XML tag, hoặc separator cố định (---, ### Doc: ...) để đánh dấu ranh giới giữa các khối nội dung khác nhau (file A, file B, tool result X). Ranh giới rõ giúp model "định vị" thông tin tốt hơn là văn bản liền mạch không dấu hiệu.
3. Thông tin quan trọng nhất không nên "chìm" giữa nhiều khối tương đương: Nếu một file là trọng tâm của task (ví dụ file chứa bug cần sửa), nó nên được đặt gần cuối — ngay trước yêu cầu — thay vì lẫn giữa 10 file phụ trợ khác được đọc "để tham khảo".
4. Tóm tắt trước, chi tiết sau (progressive disclosure): Với codebase lớn, nên đưa summary/outline trước, rồi chỉ đưa full content của phần liên quan trực tiếp đến task — tránh nhồi toàn bộ file khi agent chỉ cần biết một function tồn tại ở đâu.

Ví dụ: lắp context cho một code review agent

Giả sử bạn xây một agent tự động review pull request. Đây là cách lắp context theo đúng các nguyên tắc trên, thay vì nhồi toàn bộ diff và toàn bộ file liên quan theo thứ tự ngẫu nhiên mà git trả về:

def assemble_review_context(pr_diff: str, related_files: list[dict],
                              coding_standards: str, pr_description: str) -> str:
    """
    Build context for a code-review agent following a lost-in-the-middle-aware
    structure: rules first, supporting reference in the middle, the actual
    diff to review placed last (closest to the instruction).
    """
    sections = []

    # 1. Rules/instructions up front — highest attention weight at start.
    sections.append(
        "## Review Standards (MUST enforce)\n"
        f"{coding_standards}\n"
        "Flag any violation explicitly with file:line references.\n"
    )

    # 2. Lower-priority supporting context in the middle — summaries,
    #    not full files, to reduce token cost and reduce mid-context reliance.
    for f in related_files:
        sections.append(
            f"### Reference (summary only): {f['path']}\n"
            f"{f['summary']}\n"
        )

    # 3. PR description — orients the agent on intent before the diff.
    sections.append(f"## PR Description\n{pr_description}\n")

    # 4. The actual diff to review — placed last, right before the task
    #    instruction, to benefit from recency effect.
    sections.append(f"## Diff To Review\n```diff\n{pr_diff}\n```\n")

    # 5. Task instruction — final, most recent token block.
    sections.append(
        "## Task\n"
        "Review the diff above against the Review Standards. "
        "For each violation, cite the exact file and line. "
        "Do not repeat the diff content in your answer."
    )

    return "\n".join(sections)

Chi tiết quan trọng ở đây: related_files chỉ đưa summary, không đưa full source — vì agent review chỉ cần biết ngữ cảnh (ví dụ "function này được gọi ở đâu"), không cần đọc lại toàn bộ implementation của mọi file liên quan. Diff cần review — phần thông tin quan trọng nhất — được đặt gần cuối cùng, sát với instruction, thay vì bị kẹp giữa các phần tham khảo.

Mẹo: Khi review lại một context template đang dùng cho agent, hãy tự vẽ ra một "bản đồ vị trí" — thông tin nào nằm ở đâu theo phần trăm chiều dài context (0%, 30%, 60%, 90%...). Nếu thông tin quan trọng nhất của task đang nằm ở vùng 30–70% (vùng "giữa" theo nghiên cứu), đó là dấu hiệu cần refactor lại cấu trúc context, không phải chờ model "thông minh hơn" để tự khắc phục.

Giới Hạn Context Window và Suy Giảm Có Kiểm Soát

Khi context vượt quá giới hạn công bố của model, điều gì xảy ra phụ thuộc vào cách bạn (hoặc framework agent bạn dùng) xử lý tình huống này — và đây là nơi nhiều agent "sập" một cách khó hiểu nếu không có chiến lược rõ ràng.

Có ba kiểu hành vi khi chạm giới hạn:

1. Reject cứng (hard rejection): API trả lỗi (thường HTTP 400 với message kiểu "context length exceeded"), agent dừng hoàn toàn. Đây là hành vi an toàn nhất về mặt dữ liệu (không có gì bị âm thầm cắt bỏ sai chỗ) nhưng gây gián đoạn UX nếu không được bắt và xử lý.
2. Truncation âm thầm: Một số pipeline tự cắt bớt phần đầu hoặc giữa context để vừa giới hạn trước khi gửi API — nguy hiểm vì có thể vô tình xoá đúng phần chứa instruction quan trọng, và agent sẽ hành xử sai mà không có dấu hiệu lỗi nào để bạn biết chuyện gì đã xảy ra.
3. Suy giảm chất lượng dần (graceful degradation): Cách tiếp cận đúng đắn hơn — chủ động theo dõi token count của context đang tích luỹ, và khi gần chạm ngưỡng, kích hoạt một chiến lược xử lý có kiểm soát: tóm tắt phần hội thoại cũ, loại bỏ tool result không còn liên quan, hoặc tách task thành nhiều lượt nhỏ hơn — trước khi API kịp trả lỗi.

Ngưỡng an toàn thực tế nên thấp hơn giới hạn công bố khá nhiều. Ví dụ model công bố context window 200K token không có nghĩa bạn nên nhồi tới 195K rồi mới lo — vì (a) bạn cần chừa chỗ cho output, (b) như phần trên đã nói, chất lượng suy giảm trước khi chạm giới hạn cứng, không phải đúng lúc chạm giới hạn. Một quy tắc thực dụng nhiều team áp dụng: coi 60–70% context window công bố là "vùng an toàn" cho việc nhồi thông tin thô, phần còn lại dành cho buffer output và biên độ an toàn trước khi chất lượng attention bắt đầu tụt.

Với agent chạy loop nhiều bước (đọc file, gọi tool, lặp lại), context tích luỹ theo cấp số cộng qua từng bước — mỗi tool call, mỗi file đọc thêm đều cộng dồn vào context của bước tiếp theo nếu không có cơ chế dọn dẹp. Nếu không theo dõi sát, một agent có thể "tự ăn hết" context window của chính nó chỉ sau 10–15 bước trên một codebase lớn.

Mẹo: Luôn implement một bộ đếm token chạy trước mỗi lần gọi model (không phải chờ API báo lỗi), và đặt ngưỡng cảnh báo ở khoảng 70% giới hạn công bố để agent tự động kích hoạt tóm tắt hoặc cắt gọn — thay vì để framework/agent tự "truncation âm thầm" theo cách bạn không kiểm soát được.

Attention Concentration — Ảnh Hưởng Của Kích Thước Context Đến Chất Lượng

Đây là hệ quả thực tiễn quan trọng nhất từ toàn bộ nội dung trên: attention là một "tài nguyên" bị chia sẻ, không phải một khả năng vô hạn tăng theo context window. Khi context có 2.000 token, model có thể phân bổ attention đủ sâu cho từng chi tiết. Khi context có 150.000 token, "ngân sách attention" đó bị pha loãng trên một khối lượng token lớn hơn rất nhiều — dẫn đến hiện tượng gọi là attention dilution (pha loãng attention): model vẫn "thấy" mọi token về mặt kỹ thuật, nhưng mức độ chú ý dành cho mỗi token cụ thể giảm đi.

Hệ quả trực tiếp: context window lớn hơn không đồng nghĩa với "an toàn hơn" hay "chất lượng cao hơn" khi bạn nhồi thêm dữ liệu không cần thiết. Rất nhiều kỹ sư có tâm lý "cứ nhồi vào, model xử lý được mà" khi thấy model hỗ trợ context window rất lớn — đây là sai lầm phổ biến làm giảm chất lượng agent một cách âm thầm, vì (a) chi phí token tăng tuyến tính hoặc hơn, và (b) chất lượng attention trên từng phần thông tin cụ thể lại giảm do bị pha loãng, kể cả khi tổng context vẫn nằm trong giới hạn công bố.

Nguyên tắc thiết kế rút ra: mục tiêu không phải là "dùng hết context window có thể", mà là tối thiểu hoá context cần thiết để đạt chất lượng mong muốn — đây chính là tinh thần cốt lõi của context engineering sẽ được đào sâu ở Module 2 của khoá học này. Với một agentic workflow, câu hỏi đúng không phải "context window model này bao lớn" mà là "task này thực sự cần bao nhiêu token context để làm đúng, và tôi có thể cắt bớt phần nào mà không mất thông tin quan trọng".

Một hệ quả thứ hai ít được nói tới: khi context chứa nhiều thông tin tương tự nhau (ví dụ 20 file có cấu trúc gần giống nhau), model có xu hướng "trộn lẫn" chi tiết giữa các nguồn — một dạng nhiễu attention (attention interference) — dẫn đến việc agent trích dẫn sai file, nhớ nhầm biến giữa hai module tương tự, hoặc áp dụng logic của file A vào file B. Vấn đề này càng rõ khi các block nội dung có cấu trúc/format giống nhau và không được đánh dấu ranh giới rõ (xem lại nguyên tắc số 2 ở phần kiến trúc context).

Mẹo: Khi agent bắt đầu có dấu hiệu "lẫn lộn" thông tin giữa các file/nguồn tương tự nhau, đừng vội tăng context window hoặc đổi model lớn hơn — hãy thử giảm số lượng nguồn tương tự đưa vào cùng một context, hoặc tăng độ tương phản về định dạng/nhãn giữa chúng trước.

Benchmark Context Window — Đo Phạm Vi Hiệu Quả Thực Tế Của Model

Vì dung lượng công bố (advertised capacity) và dung lượng hiệu quả (effective capacity) là hai con số khác nhau, đội ngũ engineering nên tự benchmark model đang dùng cho agent của mình, thay vì tin tưởng tuyệt đối vào số liệu marketing. Cách phổ biến và đáng tin cậy nhất để làm điều này là biến thể của kỹ thuật "needle in a haystack" (kim trong đống rơm) — đúng ý tưởng của thí nghiệm trong ví dụ rate limit ở phần trên, nhưng mở rộng có hệ thống trên nhiều độ dài context và nhiều vị trí khác nhau, rồi tổng hợp thành một ma trận kết quả.

Quy trình benchmark gồm các bước:

1. Chọn một tập các độ dài context để test (ví dụ: 1K, 4K, 16K, 32K, 64K, 100K token — tăng dần tới gần giới hạn công bố của model).
2. Với mỗi độ dài, chọn một tập các vị trí tương đối để đặt "needle" (ví dụ 0%, 10%, 25%, 50%, 75%, 90%, 100% chiều dài context).
3. Với mỗi cặp (độ dài, vị trí), chạy nhiều lần với nội dung filler khác nhau để có kết quả đáng tin cậy về thống kê, không phải may rủi của một lần chạy.
4. Ghi lại tỷ lệ trả lời đúng cho từng cặp, tổng hợp thành heatmap độ dài × vị trí.

import itertools
import json

CONTEXT_LENGTHS = [1_000, 4_000, 16_000, 32_000, 64_000, 100_000]  # in tokens
RELATIVE_POSITIONS = [0.0, 0.10, 0.25, 0.50, 0.75, 0.90, 1.0]
TRIALS_PER_CELL = 5

def run_benchmark(call_model_fn, tokenizer_encode_fn):
    """
    call_model_fn(prompt: str) -> str
    tokenizer_encode_fn(text: str) -> list[int]  (used to size filler precisely)
    Returns a results matrix: {(length, position): accuracy}
    """
    results = {}

    for length, position in itertools.product(CONTEXT_LENGTHS, RELATIVE_POSITIONS):
        correct = 0
        for trial in range(TRIALS_PER_CELL):
            ground_truth = f"XK-{length}-{int(position*100)}-{trial}"
            context = build_padded_context(
                length_tokens=length,
                position=position,
                needle_value=ground_truth,
                tokenizer_encode_fn=tokenizer_encode_fn,
            )
            question = (
                "There is a unique code embedded in the text above in the "
                "format XK-####-##-#. Return only that code, nothing else."
            )
            answer = call_model_fn(f"{context}\n\nQuestion: {question}")
            if ground_truth in answer:
                correct += 1

        accuracy = correct / TRIALS_PER_CELL
        results[(length, position)] = accuracy
        print(f"len={length:>7} pos={position:.2f} -> accuracy={accuracy:.0%}")

    return results


def build_padded_context(length_tokens, position, needle_value, tokenizer_encode_fn):
    needle = f"\n[FACT] The unique reference code for this section is {needle_value}.\n"
    filler_unit = "The quarterly infrastructure review covered scaling, cost, and reliability topics. "
    filler = ""
    while len(tokenizer_encode_fn(filler)) < length_tokens:
        filler += filler_unit

    insert_at = int(len(filler) * position)
    return filler[:insert_at] + needle + filler[insert_at:]


if __name__ == "__main__":
    # Plug in your actual model client + tokenizer before running.
    # results = run_benchmark(call_model_fn=my_llm_client.complete,
    #                          tokenizer_encode_fn=my_tokenizer.encode)
    # with open("context_benchmark_results.json", "w") as f:
    #     json.dump({f"{k[0]}_{k[1]}": v for k, v in results.items()}, f, indent=2)
    print("Configure call_model_fn and tokenizer_encode_fn, then run_benchmark(...)")

Chạy script trên (điền call_model_fn và tokenizer_encode_fn phù hợp với model/SDK bạn dùng, ví dụ Anthropic SDK hoặc OpenAI SDK), bạn sẽ có một ma trận độ chính xác theo độ dài × vị trí cho đúng model, đúng loại nội dung (code, log, văn bản tự nhiên...) mà agent của bạn thực tế xử lý — chính xác hơn nhiều so với việc suy diễn từ benchmark công khai của nhà cung cấp model, vì benchmark công khai thường dùng nội dung và câu hỏi khác với use case thực tế của bạn.

Từ kết quả benchmark, bạn rút ra được "phạm vi hiệu quả" (effective range) thực tế — ví dụ có thể phát hiện model công bố 200K token context window nhưng độ chính xác truy xuất bắt đầu giảm rõ rệt sau mốc 60K token ở vị trí giữa, dù vẫn giữ ổn định ở đầu/cuối. Con số này — không phải con số công bố — nên là cơ sở để bạn đặt ngưỡng thực tế cho việc chia nhỏ task, tóm tắt context, hoặc chọn model khác cho các task cần xử lý context rất dài.

Mẹo: Chạy lại benchmark này mỗi khi đổi model hoặc đổi version model (ví dụ nâng cấp từ một bản model sang bản mới hơn) — phạm vi hiệu quả có thể thay đổi đáng kể giữa các version, kể cả khi context window công bố giữ nguyên hoặc tăng lên. Đừng giả định phiên bản mới luôn có phạm vi hiệu quả tốt hơn ở mọi vị trí.