Bài 4. Tối ưu context window

1. Đặt vấn đề

Context window là số lượng token mà model có thể tiếp nhận trong một lần gọi, bao gồm system prompt, lịch sử hội thoại, câu hỏi người dùng, tài liệu RAG và yêu cầu định dạng. Nhiều người nghĩ context càng lớn càng tốt, vì có thể đưa nhiều tài liệu hơn. Nhưng trong thực tế vận hành AI local, context lớn làm tăng thời gian xử lý, tăng tiêu thụ VRAM/RAM và có thể làm câu trả lời nhiễu hơn.

Tối ưu context window là một trong những kỹ thuật quan trọng để Ollama phản hồi nhanh và ổn định trong bệnh viện.

2. Context window là gì?

Context window là “vùng nhớ ngắn hạn” của model trong một request. Model chỉ biết những gì nằm trong context hiện tại và kiến thức đã học sẵn. Với RAG, tài liệu liên quan được đưa vào context để model trả lời có căn cứ.

Context bao gồm:

• System prompt.
• Developer/role instruction nếu có.
• Lịch sử hội thoại.
• Câu hỏi hiện tại.
• Chunk tài liệu.
• Metadata nguồn.
• Yêu cầu định dạng.

3. Context lớn ảnh hưởng thế nào đến tốc độ?

Context càng dài:

• Thời gian xử lý prompt càng lâu.
• Thời gian đến token đầu tiên càng lâu.
• VRAM/RAM sử dụng càng nhiều.
• Khả năng phục vụ đồng thời giảm.
• Chi phí tính toán tăng.
• Model dễ bị nhiễu nếu có nhiều nội dung không liên quan.

Vì vậy, không nên tăng num_ctx quá cao nếu không cần.

4. Khi nào cần context lớn?

Cần context lớn khi:

• Tóm tắt tài liệu dài.
• Viết báo cáo dựa trên nhiều đoạn nguồn.
• Phân tích đề án dài.
• Hội thoại cần nhớ nhiều bước.
• RAG cần đưa nhiều nguồn.
• So sánh nhiều văn bản.

Nhưng nhiều tác vụ không cần context lớn, ví dụ hỏi biểu mẫu, tra cứu quy trình ngắn, viết thông báo, tạo checklist từ một đoạn văn.

5. Tối ưu context cho RAG

Trong RAG, không nên đưa quá nhiều chunk. Cần:

• Truy xuất đúng chunk.
• Rerank nếu cần.
• Chỉ đưa 3–5 chunk tốt nhất.
• Ưu tiên chunk có nguồn rõ.
• Loại chunk trùng lặp.
• Tóm tắt nguồn dài trước khi đưa vào prompt nếu cần.
• Không đưa toàn bộ tài liệu khi chỉ cần một mục.

RAG tốt là chọn đúng nguồn, không phải nhồi nhiều nguồn.

6. Tối ưu lịch sử hội thoại

Lịch sử dài làm chậm. Có thể tối ưu bằng:

• Chỉ gửi vài lượt gần nhất.
• Tóm tắt lịch sử khi dài.
• Tách phiên theo chủ đề.
• Không đưa lịch sử không liên quan.
• Không đưa file cũ vào mọi request.
• Cho phép “bắt đầu cuộc trò chuyện mới”.

Trong bệnh viện, lịch sử còn có rủi ro dữ liệu nhạy cảm, nên càng cần kiểm soát.

7. Tối ưu system prompt

System prompt quá dài làm mọi request đều chậm. Nên:

• Viết ngắn gọn, rõ nguyên tắc chính.
• Tách prompt theo vai trò.
• Không nhồi toàn bộ quy chế vào system prompt.
• Dùng RAG cho tài liệu thay vì system prompt dài.
• Chỉ thêm hướng dẫn định dạng khi cần.

Ví dụ chatbot QLCL có prompt riêng; chatbot CNTT có prompt riêng; chatbot người bệnh có prompt riêng.

8. Chia tác vụ dài thành nhiều bước

Thay vì đưa 100 trang tài liệu vào một prompt, có thể:

1. Tóm tắt từng phần.
2. Lưu tóm tắt trung gian.
3. Tổng hợp các tóm tắt.
4. Viết báo cáo cuối.

Cách này ổn định hơn và ít vượt context.

9. Giới hạn output

Context không chỉ là input; output dài cũng ảnh hưởng tổng tài nguyên. Có thể giới hạn:

• Trả lời ngắn trước.
• Yêu cầu người dùng bấm “viết chi tiết”.
• Với báo cáo dài, chia thành phần.
• Với bài học dài, viết từng bài.
• Với bảng lớn, xuất file hoặc xử lý batch.

Trong chatbot tương tác, câu trả lời vừa đủ thường tốt hơn câu trả lời quá dài.

10. Cấu hình num_ctx

Trong Modelfile hoặc cấu hình model, có thể đặt context. Không nên đặt quá cao mặc định. Có thể có nhiều model/cấu hình:

• fast: context nhỏ, trả lời nhanh.
• rag: context vừa, dùng cho tra cứu.
• long: context lớn, dùng cho tài liệu dài.

Người dùng thường không cần biết, API trung gian có thể chọn theo tác vụ.

11. Kết luận

Tối ưu context window là cân bằng giữa đủ thông tin và tốc độ. Context càng lớn không đồng nghĩa câu trả lời càng tốt. Trong bệnh viện, nên dùng RAG để chọn đúng đoạn, giới hạn lịch sử, system prompt ngắn, chia tác vụ dài và cấu hình context theo nhóm tác vụ. Context tối ưu giúp Ollama nhanh hơn, tiết kiệm VRAM hơn và phục vụ nhiều người dùng ổn định hơn.