Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa ra mắt một chatbot hỗ trợ khách hàng cho một sàn thương mại điện tử Việt Nam. Mọi thứ chạy mượt trong demo. Nhưng đến khi lên production, hóa đơn từ nhà cung cấp mô hình tăng vọt gấp ba lần dự kiến, người dùng phàn nàn bot trả lời chậm, và tệ hơn, bot bắt đầu "quên" những gì khách vừa nói ở đầu cuộc hội thoại. Cả ba vấn đề này — chi phí, độ trễ và chất lượng — đều quy về một thứ duy nhất mà nhiều AI Product Manager bỏ qua: cách bạn quản lý context window.
Context window là "bộ nhớ làm việc" của một mô hình ngôn ngữ lớn (LLM) — tức là toàn bộ lượng văn bản (tính bằng token) mà mô hình có thể "nhìn thấy" và xử lý trong một lần gọi. Mọi thứ bạn nhồi vào: system prompt, lịch sử hội thoại, tài liệu tham khảo, câu hỏi của người dùng, và cả phần trả lời mà mô hình sinh ra — tất cả đều nằm trong cái cửa sổ giới hạn này.
Với vai trò AI PM, bạn không cần viết code để tối ưu context, nhưng bạn PHẢI hiểu nó đủ sâu để ra quyết định về kiến trúc, chi phí và trải nghiệm người dùng. Đây chính là điểm khác biệt giữa một AI PM nói chuyện được với kỹ sư và một người chỉ biết vẽ wireframe. Bài này tập trung riêng vào nghệ thuật quản lý context window — một kỹ năng nền tảng mà gần như mọi tính năng AI bạn xây dựng sau này đều phụ thuộc vào.
Khái niệm cốt lõi
Token và context window là gì
Token là đơn vị nhỏ nhất mà mô hình "đọc". Một token không phải một từ, mà thường là một mẩu từ. Với tiếng Anh, trung bình một token tương đương khoảng 4 ký tự hoặc 0,75 từ. Với tiếng Việt thì tệ hơn nhiều: do có dấu và cấu trúc âm tiết, tiếng Việt thường tốn nhiều token hơn cho cùng một lượng nội dung — một câu tiếng Việt có thể tốn gấp 1,5 đến 2 lần số token so với câu tiếng Anh tương đương. Đây là điều cực kỳ quan trọng với sản phẩm phục vụ người dùng Việt, vì nó ảnh hưởng trực tiếp tới chi phí.
Context window là tổng số token tối đa cho một lần gọi mô hình. Các mô hình năm 2026 có cửa sổ rất khác nhau: từ vài nghìn token cho các mô hình nhỏ chạy on-device, tới 128K, 200K, thậm chí 1 triệu token với các foundation model lớn. Nhưng — và đây là điều mọi PM cần khắc cốt ghi tâm — có context window lớn không có nghĩa là bạn nên dùng hết nó.
Ba lý do khiến quản lý context trở thành bài toán sống còn
Thứ nhất: Chi phí tỉ lệ thuận với số token. Hầu hết nhà cung cấp mô hình tính tiền theo token đầu vào (input) và token đầu ra (output). Mỗi lần bạn nhồi thêm tài liệu, lịch sử hội thoại, ví dụ minh họa vào prompt, bạn đang trả tiền cho từng token đó — ở MỌI lần gọi. Nếu chatbot của bạn gửi lại toàn bộ lịch sử 50 lượt hội thoại mỗi khi người dùng gõ một câu mới, chi phí sẽ phình ra theo cấp số nhân theo độ dài cuộc trò chuyện.
Thứ hai: Độ trễ (latency) tăng theo context dài. Mô hình phải xử lý toàn bộ token đầu vào trước khi sinh ra token đầu tiên. Context càng dài, thời gian "đọc" càng lâu, và người dùng càng phải chờ. Một prompt 100K token có thể khiến thời gian phản hồi đầu tiên (time-to-first-token) chậm hơn vài giây so với prompt 5K token. Trong sản phẩm thực, vài giây đó là khoảng cách giữa "mượt" và "khách bỏ đi".
Thứ ba: Chất lượng giảm khi context quá dài — hiện tượng "lost in the middle". Đây là điều phản trực giác nhất. Nghiên cứu cho thấy LLM không chú ý đều khắp toàn bộ context. Mô hình ghi nhớ tốt phần đầu và phần cuối của context, nhưng thông tin nằm ở GIỮA một context dài thường bị "bỏ quên". Nếu bạn nhồi 50 tài liệu vào prompt và câu trả lời đúng nằm ở tài liệu thứ 27, khả năng cao mô hình sẽ bỏ sót nó. Nhiều context không đồng nghĩa với câu trả lời tốt hơn — đôi khi ngược lại.
Cấu trúc một context điển hình
Để quản lý tốt, bạn cần hiểu một context window thường gồm những "tầng" nào:
- System prompt: hướng dẫn vai trò, quy tắc, định dạng đầu ra. Phần này cố định, lặp lại mỗi lần gọi.
- Lịch sử hội thoại: các lượt trao đổi trước đó. Phần này phình to dần theo thời gian.
- Tài liệu/ngữ cảnh truy xuất: nội dung lấy từ knowledge base (thường qua RAG, sẽ học ở các bài sau).
- Câu hỏi hiện tại của người dùng.
- Khoảng dành cho output: bạn phải chừa chỗ cho phần mô hình sinh ra. Nếu input chiếm hết cửa sổ, mô hình không còn chỗ để trả lời.
Tình huống thực tế
Tình huống 1: Chatbot CSKH của một sàn TMĐT và cái bẫy "gửi lại toàn bộ lịch sử"
Một startup fintech tại TP.HCM xây chatbot hỗ trợ thanh toán. Phiên bản đầu, đội kỹ sư chọn cách đơn giản nhất: mỗi lượt người dùng nhắn, hệ thống gửi lại TOÀN BỘ lịch sử hội thoại từ đầu phiên cho mô hình. Trong demo với 3-4 câu, không ai để ý. Nhưng khách hàng thật thường trò chuyện 30-40 lượt khi gặp sự cố thanh toán phức tạp.
Hậu quả: tới lượt thứ 30, mỗi lần gọi mô hình tiêu tốn khoảng 18.000 token chỉ riêng phần lịch sử (do tiếng Việt ngốn token), trong khi câu hỏi mới chỉ có 20 token. Chi phí cho một phiên hội thoại dài đội lên gần 12 lần so với ước tính ban đầu, và time-to-first-token tăng từ 0,8 giây lên hơn 4 giây.
Đội PM xử lý bằng hai động tác: (1) chỉ giữ lại 8 lượt hội thoại gần nhất nguyên văn, (2) tóm tắt các lượt cũ hơn thành một đoạn "bối cảnh" ngắn 200 token do chính mô hình sinh ra. Kết quả: chi phí mỗi phiên giảm khoảng 70%, độ trễ về lại dưới 1,5 giây, và chất lượng trả lời gần như không đổi vì các thông tin quan trọng đã được cô đọng trong bản tóm tắt.
Bài học: Đừng bao giờ mặc định "gửi hết cho an toàn". Lịch sử hội thoại là tầng phình to nhanh nhất và là nơi tối ưu mang lại lợi ích lớn nhất.
Tình huống 2: Trợ lý pháp lý nhồi quá nhiều tài liệu và bị "lost in the middle"
Một công ty legaltech ở Hà Nội xây trợ lý tra cứu văn bản luật. Để "chắc ăn", họ truy xuất 30 đoạn văn bản liên quan nhất và nhồi tất cả vào context cho mỗi câu hỏi. Trên giấy tờ, mô hình có thừa thông tin để trả lời. Nhưng đội QA phát hiện một mẫu hình kỳ lạ: với những câu hỏi mà điều khoản đúng nằm ở đoạn tài liệu thứ 15-22 (tức là phần giữa), tỉ lệ trả lời đúng chỉ khoảng 60%. Trong khi nếu đúng đoạn đó được đặt ở đầu hoặc cuối, tỉ lệ lên tới 90%.
Đây chính là "lost in the middle" trong thực tế. Giải pháp của họ không phải nhồi NHIỀU hơn, mà nhồi ÍT và THÔNG MINH hơn: giảm từ 30 đoạn xuống 6 đoạn liên quan nhất, đồng thời sắp xếp lại thứ tự — đặt đoạn được chấm điểm liên quan cao nhất ở cuối context (ngay sát câu hỏi), những đoạn liên quan vừa ở giữa. Tỉ lệ trả lời đúng tổng thể tăng lên 88%, đồng thời chi phí giảm vì context ngắn hơn.
Bài học: Vị trí của thông tin trong context quan trọng không kém nội dung. "Ít mà đúng chỗ" đánh bại "nhiều mà lộn xộn".
Tình huống 3: Tính năng tóm tắt tài liệu vượt giới hạn cửa sổ
Một sản phẩm SaaS Đông Nam Á cho phép người dùng upload báo cáo PDF dài để AI tóm tắt. Vấn đề: nhiều báo cáo dài 300 trang, tương đương khoảng 250.000 token — vượt quá context window của mô hình họ đang dùng (128K token). Nếu cứ gửi nguyên, hệ thống báo lỗi.
Đội ngũ áp dụng kỹ thuật chunking + tóm tắt phân tầng (hierarchical summarization): chia tài liệu thành các đoạn vừa với cửa sổ, tóm tắt từng đoạn, rồi tóm tắt các bản tóm tắt đó thành bản tổng cuối cùng. Cách này không chỉ giải quyết giới hạn kỹ thuật mà còn cho ra bản tóm tắt mạch lạc hơn, vì mô hình không bị "lost in the middle" với một khối văn bản khổng lồ.
Bài học: Khi nội dung vượt cửa sổ, đừng tìm mô hình có cửa sổ to hơn rồi nhồi tất cả vào. Hãy chia nhỏ và xử lý phân tầng — vừa rẻ hơn, vừa chất lượng hơn.
Hướng dẫn từng bước
Đây là quy trình để bạn — với vai trò AI PM — định hình chiến lược quản lý context cho một tính năng AI:
Bước 1 — Lập "ngân sách token" (token budget). Trước khi build, hãy phân bổ rõ context window cho từng tầng. Ví dụ với cửa sổ 32K: dành 2K cho system prompt, 8K cho tài liệu truy xuất, 6K cho lịch sử hội thoại, 1K cho câu hỏi, và chừa 4K cho output. Tổng phải nhỏ hơn cửa sổ, có biên an toàn. Đây là tài liệu thiết kế mà bạn nên làm cùng kỹ sư.
Bước 2 — Đo lượng token thực tế với tiếng Việt. Đừng ước lượng theo số liệu tiếng Anh. Lấy mẫu hội thoại thật của người Việt, dùng công cụ đếm token (tokenizer) của nhà cung cấp để đo chính xác. Bạn sẽ thường bất ngờ vì con số cao hơn dự kiến.
Bước 3 — Chọn chiến lược xử lý lịch sử hội thoại. Ba lựa chọn phổ biến: (a) cửa sổ trượt — chỉ giữ N lượt gần nhất; (b) tóm tắt — nén các lượt cũ thành bản tổng hợp; (c) kết hợp — giữ nguyên văn vài lượt gần nhất và tóm tắt phần còn lại. Lựa chọn (c) thường là điểm cân bằng tốt nhất cho chatbot.
Bước 4 — Quyết định bao nhiêu tài liệu được đưa vào. Với phần ngữ cảnh truy xuất, hãy ưu tiên chất lượng hơn số lượng. Đặt giới hạn cứng số đoạn tài liệu, và cân nhắc sắp xếp lại thứ tự để né "lost in the middle".
Bước 5 — Luôn chừa chỗ cho output và xử lý tràn cửa sổ. Thiết kế cơ chế dự phòng (fallback) cho trường hợp input vượt giới hạn: cắt bớt, tóm tắt động, hoặc chuyển sang xử lý phân tầng. Sản phẩm không bao giờ được "vỡ" chỉ vì người dùng nhập nhiều.
Bước 6 — Giám sát và lặp. Theo dõi số token trung bình mỗi request, chi phí mỗi phiên, và độ trễ trong production. Đây là các chỉ số bạn phải đưa vào dashboard và xem hàng tuần.
Lỗi thường gặp & mẹo
Lỗi 1: Cho rằng "cửa sổ lớn = cứ nhồi đầy". Như đã thấy, nhồi đầy làm tăng chi phí, tăng độ trễ và giảm chất lượng. Cửa sổ lớn là để bạn CÓ ĐỦ CHỖ khi cần, không phải để bạn luôn dùng hết.
Lỗi 2: Bỏ qua đặc thù token tiếng Việt. Nhiều đội dùng số liệu tiếng Anh để ước tính chi phí rồi vỡ kế hoạch ngân sách. Luôn đo với dữ liệu tiếng Việt thật.
Lỗi 3: Gửi lại toàn bộ lịch sử hội thoại. Đây là lỗi tốn kém phổ biến nhất. Hãy nén hoặc cắt từ ngày đầu.
Lỗi 4: Quên chừa chỗ cho output. Nếu input chiếm gần hết cửa sổ, mô hình bị cụt câu trả lời hoặc báo lỗi. Luôn để biên an toàn.
Mẹo 1: Tận dụng prompt caching. Nhiều nhà cung cấp năm 2026 cho phép cache phần context lặp lại (như system prompt dài). Nếu phần đầu prompt của bạn cố định, caching có thể giảm đáng kể chi phí và độ trễ. Hãy thiết kế prompt sao cho phần tĩnh nằm ở đầu.
Mẹo 2: Đặt thông tin quan trọng ở đầu hoặc cuối context. Né vùng "giữa" cho những dữ kiện then chốt.
Mẹo 3: Đo trước, tối ưu sau. Đừng tối ưu sớm dựa trên cảm tính. Hãy đo token và chi phí thực tế, xác định tầng nào ngốn nhiều nhất, rồi mới tối ưu đúng chỗ.
Bài tập thực hành
- Lập ngân sách token: Chọn một tính năng AI giả định (ví dụ: chatbot tư vấn khóa học). Với cửa sổ 16K token, hãy phân bổ token cho từng tầng (system prompt, lịch sử, tài liệu, câu hỏi, output). Viết rõ con số và lý do.
- Phân tích chi phí: Giả sử một phiên hội thoại trung bình 20 lượt, mỗi lượt người dùng 30 token, mô hình trả lời 150 token. So sánh tổng token tiêu thụ giữa hai chiến lược: (a) gửi lại toàn bộ lịch sử mỗi lượt, và (b) chỉ giữ 6 lượt gần nhất. Ước tính phần trăm tiết kiệm.
- Thiết kế chống "lost in the middle": Bạn có 10 đoạn tài liệu được chấm điểm liên quan. Hãy mô tả thứ tự bạn sẽ sắp xếp chúng trong context và giải thích tại sao.
- Kịch bản tràn cửa sổ: Người dùng dán vào một tài liệu 200K token nhưng mô hình chỉ có cửa sổ 128K. Viết 3 phương án xử lý fallback mà bạn sẽ đề xuất cho đội kỹ sư.
Tóm tắt
Context window là bộ nhớ làm việc giới hạn của LLM, và cách bạn quản lý nó quyết định trực tiếp ba yếu tố sống còn của sản phẩm AI: chi phí (tỉ lệ thuận với token), độ trễ (tăng theo context dài), và chất lượng (giảm khi context quá dài do "lost in the middle"). Với người dùng Việt, đặc thù tốn token của tiếng Việt khiến việc đo đạc và tối ưu càng quan trọng.
Là AI PM, bạn không cần code, nhưng phải biết lập ngân sách token, chọn chiến lược nén lịch sử hội thoại, giới hạn tài liệu đưa vào, chừa chỗ cho output, và giám sát chỉ số trong production. Nguyên tắc vàng: ít mà đúng chỗ luôn thắng nhiều mà lộn xộn. Cửa sổ lớn cho bạn không gian, nhưng kỷ luật quản lý context mới là thứ tạo nên sản phẩm AI vừa rẻ, vừa nhanh, vừa đáng tin cậy.