Context window — bộ nhớ làm việc hữu hạn

TL;DR: Context window là "bộ nhớ làm việc" của model trong một request — dung lượng cố định đo bằng token (bài trước), không phải ký tự hay số lượt hội thoại. Hết chỗ, model không "nhớ kém" dần đi — hệ thống buộc phải cắt bớt token cũ nhất để nhét phần mới vào, và phần bị cắt biến mất hoàn toàn khỏi request kế tiếp. Vì đơn vị là token, tiếng Việt — tốn token hơn tiếng Anh cho cùng nội dung (bài 02) — lấp đầy context nhanh hơn. Chi phí và tốc độ sinh cũng tính theo đúng số token đó: context càng dài, hoá đơn và độ trễ càng tăng.

Một chatbot hỗ trợ nội bộ chạy production vài tuần. Ở tin nhắn đầu, user dặn: "trả lời ngắn gọn, không dùng thuật ngữ tiếng Anh". Hội thoại càng dài, model càng phớt lờ yêu cầu đó — tới tin nhắn 40 thì coi như chưa từng được dặn. Team dev nghi model "yếu dần", rồi thử cách tốn kém: nhắc lại constraint ở mọi tin nhắn.

Cùng lúc, một bot khác trả lời sai một câu hỏi tra cứu policy — dù đáp án đã được dán nguyên văn vào prompt, không hề bị cắt bớt. Câu hỏi để cuối bài: sao thông tin có mặt trong context mà model vẫn bỏ sót?

Cả hai cùng gốc: context window là tài nguyên hữu hạn, và cách model "dùng" nó không đều — không chỉ là chuyện còn chỗ hay hết chỗ.

1. Analogy — sổ tay có số trang cố định

Bạn ghi chép cuộc họp dài vào một cuốn sổ tay in sẵn số trang — hết trang là hết, không thể viết thêm vào cuốn cũ. Cuộc họp càng dài, bạn càng phải xé bớt trang đầu tiên (ghi chép cũ nhất) để có chỗ viết tiếp trang mới. Người đọc lại sổ sau này chỉ thấy phần còn nguyên trang — phần đã bị xé thì mất hẳn, không phải "mờ đi".

2. Context window là gì

Context window là số token tối đa model có thể "nhìn thấy" trong một lần gọi: system prompt, toàn bộ lịch sử hội thoại đã đưa vào, câu hỏi mới nhất, và cả token model đang sinh ra — tất cả cộng chung vào một giới hạn cố định của model đó.

Vài điểm cần khớp với bài trước để không hiểu sai:

• Đơn vị là token, không phải ký tự hay từ. Cùng giới hạn token, văn bản tiếng Việt chứa được ít câu hơn tiếng Anh — vì mỗi câu tiếng Việt đã tốn nhiều token hơn (bài 02).
• Giới hạn khác nhau giữa các model, và đổi theo thời gian khi nhà cung cấp nâng cấp — đừng nhớ một con số cố định; tra tài liệu chính chủ tại đúng thời điểm build, kiểm luôn tokenizer có đổi không (bài 02).
• Context không phải bộ nhớ giữa các request. Cảm giác "model nhớ cuộc trò chuyện" là do ứng dụng chủ động gửi lại lịch sử vào context của request mới — cho tới khi lịch sử đó quá dài để nhét vừa.

3. Đầy thì model cắt cái gì trước?

Khi tổng token (system + lịch sử + input mới) vượt giới hạn, ứng dụng phía trên model phải quyết định bỏ bớt gì trước khi gửi request. Cách phổ biến nhất: giữ input mới nhất, lùi dần về lịch sử cũ hơn, dừng ngay khi vừa đủ chỗ — token của những lượt cũ nhất bị loại hẳn khỏi request đó.

function build_request(history, current_input):
    total <- đếm_token(system_prompt) + đếm_token(current_input)
    included <- []
    for luot in đảo_ngược(history):     -- duyệt từ MỚI NHẤT lùi về CŨ NHẤT
        if total + đếm_token(luot) > token_limit:
            break                        -- hết chỗ: DỪNG
        included.add(luot)
        total <- total + đếm_token(luot)
    -- lượt CŨ NHẤT chưa được add khi chạm break — mất hẳn khỏi request này
    return system_prompt + đảo_ngược(included) + current_input

Đây là cơ chế đứng sau sự cố mở bài: constraint dặn ở tin nhắn 1 không bị model "quên" theo nghĩa suy giảm năng lực — nó bị cắt khỏi request một cách cơ học khi hội thoại đủ dài. Tiếng Việt tốn token hơn (bài 02) nên cửa sổ đầy nhanh hơn — constraint bị "quên" sớm hơn so với cùng hội thoại bằng tiếng Anh.

4. Thử đoán: vị trí nào trong context dễ bị bỏ sót

Sự cố thứ hai ở đầu bài chưa được giải thích: đáp án nằm nguyên trong context, không hề bị cắt — vậy vì sao model vẫn trả lời sai?

Liu và cộng sự đo đúng hiện tượng này trên nhiều model ngôn ngữ dài context (Lost in the Middle: How Language Models Use Long Contexts, arXiv:2307.03172): hiệu năng truy xuất cao nhất khi thông tin cần thiết nằm ở đầu hoặc cuối context, và giảm rõ rệt khi nó nằm ở giữa — dù thông tin đó chưa bao giờ bị cắt, chỉ là bị đặt "chôn" giữa một khối văn bản dài. Hiện tượng này được chính paper gọi tên: lost-in-the-middle.

Nói cách khác: "còn trong context" và "model chắc chắn dùng được" là hai chuyện khác nhau. Cửa sổ đủ rộng để chứa một tài liệu không có nghĩa mọi phần của tài liệu đó được model "chú ý" như nhau.

5. Hệ quả dây chuyền — không chỉ là chuyện "nhớ"

Token trong context là đơn vị bạn trả giá trên ba trục cùng lúc:

6. Pitfall tổng hợp

❌ Nhầm 1 — nghĩ model "yếu trí nhớ" khi hội thoại dài, cách sửa là đổi model "thông minh hơn":

✅ Đây là giới hạn kiến trúc, không phải năng lực. Đổi model không giải quyết gốc nếu context window mới vẫn hữu hạn — đúng chỗ cần sửa là ứng dụng: tóm tắt lịch sử cũ, hoặc chủ động nhắc lại constraint quan trọng gần cuối prompt thay vì chỉ ở đầu.

❌ Nhầm 2 — "còn chỗ trống trong context là an toàn, nhét bao nhiêu tài liệu cũng được":

✅ Còn chỗ chỉ đảm bảo không bị cắt, không đảm bảo model dùng đều. Fact quan trọng chôn giữa một tài liệu dài có nguy cơ bị bỏ sót (mục 4) dù nó chưa từng rời khỏi context. Muốn chắc model dùng một thông tin then chốt, đặt nó gần đầu hoặc gần cuối prompt.

❌ Nhầm 3 — chỉ đếm token phần mình gõ, quên phần model sinh ra cũng ăn vào cùng ngân sách:

✅ Kiến trúc autoregressive (bài 01) tính cả token vừa sinh vào chuỗi đang được model xử lý tiếp — input càng dài, chỗ còn lại cho output càng hẹp. Ước lượng ngân sách phải cộng cả hai chiều, và nhớ tiếng Việt tốn token hơn ở cả hai chiều đó.

7. 📚 Deep Dive

8. Liên hệ các bài khác

• Bài 01 — Dự đoán token kế tiếp — vòng lặp autoregressive dựa trên "toàn bộ token đứng trước"; context window là giới hạn của chính "toàn bộ" đó.
• Bài 02 — Tokenization — đơn vị đo context là token; tiếng Việt tốn token hơn nên lấp đầy cửa sổ nhanh hơn, ở cả input lẫn output.
• Bài 04 — Sampling: temperature và top-p — bước kế tiếp trong vòng lặp sinh: sau khi context quyết định model "thấy" gì, sampling quyết định model "chọn" token nào.
• Mini-challenge — đọc log ba sự cố — một trong ba sự cố là bot quên yêu cầu đầu hội thoại; đúng cơ chế mục 3 của bài này.

9. Tóm tắt

• Context window là giới hạn token cố định cho một request — bao gồm system prompt, lịch sử hội thoại, input mới và cả token đang được sinh.
• Đầy thì hệ thống cắt bớt token cũ nhất để nhét phần mới vào; phần bị cắt biến mất khỏi request, không phải model suy giảm năng lực.
• Đơn vị luôn là token — tiếng Việt tốn token hơn nên lấp đầy context nhanh hơn, giữ được ít lượt hội thoại hơn cho cùng độ dài văn bản.
• Còn chỗ trong context không đồng nghĩa model dùng đều mọi phần: thông tin nằm giữa một context dài dễ bị bỏ sót hơn thông tin ở đầu/cuối (lost-in-the-middle), dù không hề bị cắt.
• Token input và output cùng tính vào một ngân sách — prompt dài kéo theo chi phí cao hơn và độ trễ lớn hơn.

10. Tự kiểm tra

Bài tiếp theo: Sampling — temperature và top-p