Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang trò chuyện với một đồng nghiệp cực kỳ thông minh, nhưng người này có một điểm yếu kỳ lạ: anh ta chỉ nhớ được một lượng thông tin nhất định trong đầu tại mỗi thời điểm. Khi bạn nói quá nhiều, phần đầu câu chuyện bắt đầu bị "rơi ra" khỏi trí nhớ. Đó chính xác là cách một mô hình ngôn ngữ lớn (LLM) như ChatGPT, Claude hay Gemini vận hành. Cái "trí nhớ tạm thời" đó gọi là context window (cửa sổ ngữ cảnh).
Ở những bài trước, bạn đã học cách viết một prompt tốt, cách dùng zero-shot, few-shot, chain-of-thought, cách chỉnh temperature và top_p. Nhưng có một sự thật phũ phàng mà rất nhiều người mới bỏ qua: dù prompt của bạn có hay đến đâu, nếu nó vượt quá giới hạn context window, hoặc nếu bạn không biết quản lý "ngân sách token", thì kết quả sẽ tệ đi một cách khó hiểu — AI quên mất yêu cầu ban đầu, trả lời cụt lủn, hoặc báo lỗi giữa chừng.
Trong môi trường doanh nghiệp, đây không chỉ là chuyện kỹ thuật. Nó liên quan trực tiếp tới chi phí (bạn trả tiền theo token), tới độ chính xác (AI có nhớ đúng dữ liệu bạn đưa không), và tới trải nghiệm của khách hàng khi bạn triển khai chatbot hay công cụ tự động. Bài này sẽ giúp bạn hiểu tường tận context window là gì và — quan trọng hơn — cách quản lý token economy để tiết kiệm tiền, tăng độ chính xác và tránh những cú "gãy" bất ngờ khi vận hành thật.
Khái niệm cốt lõi
Context window là gì
Context window là tổng số token tối đa mà mô hình có thể "nhìn thấy" và xử lý trong một lượt gọi. Nó bao gồm TẤT CẢ mọi thứ trong cuộc hội thoại tại thời điểm đó:
- System prompt — chỉ dẫn nền cho AI (ví dụ: "Bạn là trợ lý chăm sóc khách hàng của Tiki").
- User prompt — câu hỏi/yêu cầu của người dùng.
- Assistant messages — các câu trả lời trước đó của AI trong cùng cuộc trò chuyện.
- Tài liệu đính kèm — file, đoạn văn bản, dữ liệu bạn dán vào.
- Phần AI sắp sinh ra (output/completion) — cũng chiếm chỗ trong cùng ngân sách đó.
Token là gì — và một token đáng giá bao nhiêu
Mô hình không đọc theo "từ" mà theo token — những mảnh nhỏ của văn bản. Một token trung bình:
- Tiếng Anh: khoảng 4 ký tự, tức ~0,75 từ. 1.000 token ≈ 750 từ.
- Tiếng Việt: tốn token hơn đáng kể vì dấu và cách mã hóa Unicode. Một chữ tiếng Việt có dấu (như "nghiêng", "được") có thể bị tách thành 2–4 token. Ước lượng an toàn: 1.000 token ≈ 400–500 từ tiếng Việt.
Các mốc context window phổ biến (2025–2026)
Để bạn có cảm giác về quy mô:
- GPT-4o / GPT-4.1: từ 128.000 token, một số phiên bản lên tới 1 triệu token.
- Claude (dòng Sonnet/Opus): 200.000 token, có cấu hình 1 triệu token cho doanh nghiệp.
- Gemini 1.5/2.x Pro: tới 1–2 triệu token.
Hiện tượng "Lost in the Middle"
Nghiên cứu và kinh nghiệm thực chiến đều cho thấy một hiện tượng gọi là "lost in the middle" (lạc ở giữa). Mô hình có xu hướng chú ý tốt nhất tới thông tin ở đầu và cuối context window, còn thông tin nằm ở giữa một khối văn bản dài dễ bị "chìm" và bỏ sót.
Bài học rút ra: đừng chỉ nghĩ "context còn chỗ là nhét vào được". Vị trí đặt thông tin quan trọng cũng quan trọng như bản thân thông tin đó. Hãy đặt chỉ dẫn then chốt và dữ liệu quan trọng nhất ở đầu và cuối.
Token economy — tư duy "ngân sách"
Hãy coi mỗi lượt gọi API là một chuyến đi với vali có giới hạn cân nặng. Bạn phải quyết định: mang gì theo (đưa dữ liệu nào vào context), bỏ lại gì (cắt bớt lịch sử hội thoại), và chừa bao nhiêu chỗ cho quà mang về (output). Đó là token economy — nghệ thuật phân bổ ngân sách token sao cho vừa đủ chính xác, vừa tiết kiệm chi phí, vừa không tràn giới hạn.
Tình huống thực tế
Ví dụ 1 — Chatbot chăm sóc khách hàng của một sàn TMĐT quên mất khách đang hỏi gì
Một công ty TMĐT tầm trung tại TP.HCM (gọi là ShopViet) xây một chatbot hỗ trợ khách bằng GPT-4o. Họ thiết kế như sau: mỗi lần khách gửi tin, hệ thống gửi lại toàn bộ lịch sử hội thoại kèm một system prompt dài 1.500 token mô tả chính sách đổi trả, danh mục sản phẩm, giọng điệu thương hiệu.
Ban đầu mọi thứ ổn. Nhưng với những khách hỏi dai (30–40 lượt trao đổi), chatbot bắt đầu trả lời lạc đề, quên mất mã đơn hàng khách đã cung cấp ở đầu, thậm chí lặp lại câu hỏi đã hỏi. Đội kỹ thuật đo lại và tá hỏa: một số phiên đã ngốn hơn 100.000 token chỉ riêng phần input, chi phí mỗi cuộc chat đắt gấp 8 lần dự tính.
Diễn giải: Vấn đề là họ nhồi toàn bộ lịch sử vào mỗi lượt. Càng chat dài, context càng phình, chi phí tăng tuyến tính, và những thông tin quan trọng (mã đơn hàng ở tin nhắn đầu) bị đẩy vào vùng "giữa" — nơi mô hình dễ bỏ sót.
Bài học: Không phải lúc nào cũng gửi toàn bộ lịch sử. Giải pháp họ áp dụng: (1) tóm tắt các lượt cũ thành một đoạn "trạng thái hội thoại" ngắn gọn (khách tên gì, mã đơn nào, vấn đề gì), (2) chỉ giữ nguyên văn 5–6 lượt gần nhất, (3) đưa mã đơn hàng vào phần đầu system context cố định. Kết quả: chi phí giảm ~70%, độ chính xác tăng rõ rệt.
Ví dụ 2 — Phòng pháp chế phân tích hợp đồng và hiện tượng "lost in the middle"
Một startup fintech ở Singapore muốn dùng Claude để rà soát các điều khoản rủi ro trong hợp đồng vay. Họ dán trọn một hợp đồng 80 trang (~60.000 token) vào một prompt duy nhất và hỏi: "Liệt kê tất cả điều khoản về lãi suất phạt trả chậm."
AI trả về 3 điều khoản. Nhưng luật sư kiểm tra thủ công thì có tới 5. Hai điều khoản bị bỏ sót đều nằm ở... khoảng giữa tài liệu (trang 40–50).
Diễn giải: Đây là "lost in the middle" kinh điển. Không phải AI "dốt", mà là cách nhồi một khối 60.000 token khiến phần giữa bị chú ý kém.
Bài học: Với tài liệu dài, đừng hỏi kiểu "một phát ăn ngay". Họ chia hợp đồng thành các phần nhỏ (chunk) khoảng 8.000–10.000 token, xử lý từng phần với cùng câu hỏi, rồi tổng hợp kết quả. Đồng thời đặt câu hỏi cả ở đầu và cuối mỗi chunk. Sau khi đổi cách, AI tìm đủ 5/5 điều khoản. (Đây cũng là lý do tại sao kỹ thuật RAG — sẽ học ở Bài 25 — ra đời: để chỉ đưa vào context đúng phần liên quan thay vì cả tài liệu.)
Ví dụ 3 — Team marketing tính sai chi phí vì quên token tiếng Việt
Một agency ở Hà Nội dùng API để tự động sinh mô tả sản phẩm hàng loạt cho khách hàng. Họ ước lượng chi phí dựa trên "số từ tiếng Anh" vì đọc tài liệu OpenAI, rồi báo giá cho khách. Khi triển khai thật bằng tiếng Việt, hóa đơn cuối tháng cao hơn dự toán gần 80%.
Diễn giải: Nội dung tiếng Việt có dấu ngốn token gần gấp đôi tiếng Anh. Ước lượng "1.000 token = 750 từ" chỉ đúng cho tiếng Anh; với tiếng Việt phải tính ~400–500 từ. Họ đã báo giá dựa trên giả định sai.
Bài học: Luôn đo token thực tế bằng công cụ (tokenizer) trước khi báo giá hoặc lên kế hoạch quy mô lớn. Với nội dung tiếng Việt, hãy nhân hệ số an toàn 1,5–2 khi dự toán chi phí.
Hướng dẫn từng bước
Đây là quy trình quản lý token economy bạn có thể áp dụng ngay cho mọi dự án:
Bước 1 — Xác định context window của model bạn dùng. Tra cứu con số cụ thể (128k, 200k, 1M...). Đây là "trần nhà" của bạn. Ghi nhớ: input + output cộng lại không được vượt trần này.
Bước 2 — Ước lượng ngân sách cho từng thành phần. Chia context thành các phần: system prompt (cố định), dữ liệu/tài liệu, lịch sử hội thoại, và chỗ dành cho output. Ví dụ với 128k token: system 2k, tài liệu 40k, lịch sử 20k, chừa ~60k cho câu trả lời và dự phòng.
Bước 3 — Đo token thật, đừng đoán. Dùng tokenizer chính thức (OpenAI có tiktoken, các nền tảng đều có công cụ đếm token) để đo chính xác, đặc biệt với nội dung tiếng Việt. Đừng bao giờ báo giá hay lên kế hoạch dựa trên phỏng đoán bằng mắt.
Bước 4 — Đặt thông tin quan trọng ở đầu và cuối. Chỉ dẫn then chốt (yêu cầu chính, ràng buộc, định dạng output mong muốn) nên nằm ở đầu system prompt và/hoặc nhắc lại ở cuối user prompt, để tránh bẫy "lost in the middle".
Bước 5 — Áp dụng chiến lược nén khi hội thoại dài. Chọn một trong các cách: (a) tóm tắt các lượt cũ thành một đoạn trạng thái ngắn; (b) cửa sổ trượt — chỉ giữ N lượt gần nhất; (c) chỉ giữ điểm mấu chốt — trích ra dữ kiện quan trọng (tên, mã đơn, quyết định) và bỏ phần tán gẫu.
Bước 6 — Chia nhỏ tài liệu lớn (chunking). Nếu dữ liệu vượt quá vài chục nghìn token, đừng nhồi một cục. Chia thành các chunk vừa phải, xử lý từng phần, rồi tổng hợp. Với hệ thống lớn, hãy hướng tới RAG.
Bước 7 — Đặt max_tokens hợp lý cho output. Chừa đủ chỗ cho câu trả lời nhưng đừng để quá thừa (vừa lãng phí vừa dễ khiến AI "dông dài"). Tính ngược từ độ dài output bạn thực sự cần.
Bước 8 — Giám sát và tối ưu liên tục. Log lại số token mỗi lượt gọi trong production. Nếu thấy phiên nào phình bất thường, đó là dấu hiệu cần nén lịch sử hoặc thiết kế lại luồng.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ context window lớn nghĩa là cứ nhét thoải mái. Sai. Nhét nhiều làm tăng chi phí, làm chậm phản hồi, và làm giảm độ chính xác do "lost in the middle". Ít nhưng đúng luôn tốt hơn nhiều nhưng loãng.
Lỗi 2 — Gửi toàn bộ lịch sử hội thoại mỗi lượt. Đây là "sát thủ chi phí" số một trong các chatbot. Chi phí tăng theo cấp số nhân khi hội thoại kéo dài. Luôn có chiến lược nén.
Lỗi 3 — Quên rằng output cũng ăn vào context. Nếu bạn đưa input sát trần, AI sẽ bị cắt câu trả lời giữa chừng hoặc báo lỗi. Luôn chừa chỗ cho output.
Lỗi 4 — Ước lượng token tiếng Việt bằng công thức tiếng Anh. Như ví dụ 3, sai lầm này có thể khiến bạn lỗ vốn khi báo giá.
Mẹo hay:
- Nén system prompt. Viết chỉ dẫn nền súc tích, tránh lặp. Một system prompt 1.500 token dùng cho hàng triệu lượt gọi là khoản chi khổng lồ nếu không tối ưu.
- Dùng prompt caching nếu nền tảng hỗ trợ. Nhiều nhà cung cấp cho phép cache phần system prompt/tài liệu cố định để trả tiền rẻ hơn cho phần lặp lại.
- Ưu tiên tiếng Anh cho phần "máy đọc". Nếu output cuối cần tiếng Việt nhưng chỉ dẫn nội bộ chỉ máy đọc, cân nhắc viết chỉ dẫn bằng tiếng Anh để tiết kiệm token, rồi yêu cầu trả lời bằng tiếng Việt.
- Cắt trước, đo sau. Trước khi gửi, loại bỏ khoảng trắng thừa, HTML rác, phần lặp trong dữ liệu.
Bài tập thực hành
- Đo token: Lấy một mô tả sản phẩm dài khoảng 300 từ tiếng Việt của bạn. Dùng một tokenizer online để đếm token. So sánh với bản dịch tiếng Anh của chính nội dung đó. Ghi lại tỉ lệ chênh lệch — bạn sẽ thấy tận mắt "thuế token tiếng Việt".
- Thiết kế ngân sách: Giả sử bạn xây một chatbot tư vấn bảo hiểm bằng model có context 128k token. Hãy lập bảng phân bổ ngân sách token cho: system prompt, tài liệu chính sách, lịch sử hội thoại, và output. Giải thích lý do cho từng con số.
- Nén hội thoại: Lấy một đoạn hội thoại giả định 15 lượt giữa khách và chatbot. Viết một prompt yêu cầu AI "tóm tắt trạng thái hội thoại thành tối đa 100 token, giữ lại tên khách, vấn đề, và các quyết định đã chốt". Đây chính là kỹ thuật bạn sẽ dùng để nén context trong production.
- Thử nghiệm lost in the middle: Tạo một danh sách 20 điều khoản, giấu một dữ kiện quan trọng ở điều thứ 10 (giữa). Hỏi AI về dữ kiện đó. Sau đó chuyển dữ kiện lên đầu và xuống cuối, hỏi lại. Quan sát sự khác biệt về độ chính xác.
Tóm tắt
Context window là "trí nhớ tạm thời" của mô hình — tổng số token tối đa bao gồm system prompt, user prompt, lịch sử hội thoại, tài liệu và cả phần output. Ba điều cốt lõi cần nhớ:
- Đây là ngân sách chung, có giới hạn. Input và output dùng chung dung tích; luôn chừa chỗ cho câu trả lời.
- Nhiều token không đồng nghĩa với tốt hơn. Chi phí tăng, tốc độ giảm, và hiện tượng "lost in the middle" khiến thông tin ở giữa dễ bị bỏ sót. Hãy nén lịch sử, chia nhỏ tài liệu, và đặt thông tin quan trọng ở đầu/cuối.
- Token tiếng Việt đắt hơn tiếng Anh 1,5–2 lần. Luôn đo bằng tokenizer, đừng đoán, đặc biệt khi báo giá hay lên kế hoạch quy mô lớn.