Tối ưu hóa context window trong hội thoại dài – Giải pháp nâng cao chất lượng phản hồi của LLM

Khi làm việc với các mô hình ngôn ngữ lớn (LLM) trong các đoạn hội thoại kéo dài hoặc các tài liệu nhiều trang, chúng ta thường gặp một vấn đề quen thuộc: mô hình bỏ sót thông tin quan trọng nằm giữa tài liệu. Hiện tượng này thường được gọi là “lost in the middle”.

Bài viết sau sẽ phân tích vì sao điều này xảy ra, và trình bày cách sử dụng kỹ thuật re-ranking kết hợp với các chiến lược xử lý ngữ cảnh khác để tận dụng tốt hơn context window của mô hình.

Context window là gì và tại sao nó là điểm nghẽn?

Mỗi LLM đều chỉ có thể xử lý một lượng thông tin đầu vào tối đa trong một lần suy luận. Vùng dữ liệu đó gọi là context window.

Context window thường được đo bằng token. Ví dụ, các phiên bản của GPT-4 có thể xử lý khoảng vài nghìn đến hàng trăm nghìn token tùy cấu hình.

Về lý thuyết, nếu ta đưa toàn bộ lịch sử hội thoại, tài liệu hoặc báo cáo vào input thì mô hình sẽ “biết hết mọi thứ” và trả lời chính xác. Thực tế không đơn giản như vậy.

Khi lượng thông tin quá lớn (ví dụ một cuộc trò chuyện kéo dài, hay một báo cáo 30-40 trang), mô hình không phân bổ sự chú ý đồng đều cho toàn bộ nội dung. Thường xảy ra các hiện tượng sau:

• Phần mở đầu ngữ cảnh (đầu context) được ưu tiên vì nó xuất hiện sớm và định hướng vai trò.
• Phần gần cuối (cuối context) cũng được ưu tiên vì đó là vùng ngay trước khi mô hình sinh câu trả lời.
• Phần ở giữa dễ bị xem nhẹ.

Kết quả: thông tin quan trọng nằm giữa tài liệu có thể bị “tr tr” hoặc bị mô hình suy luận sai, dù nội dung đó đã được cung cấp vào prompt.

Hiện tượng này chính là lost in the middle, một hạn chế quan trọng khi triển khai LLM vào các bài toán thực tế như tư vấn pháp lý, phân tích tài chính, chăm sóc khách hàng nhiều lượt trao đổi, tra cứu tri thức nội bộ, v.v.

Hệ quả thực tế của “lost in the middle”

Giả sử bạn tải lên một file báo cáo tài chính dài 30 trang và hỏi: “Lợi nhuận ròng quý II nằm ở mức bao nhiêu, và nguyên nhân chính của biến động là gì?”

Nếu số liệu nằm ở phần giữa tài liệu, mô hình có khả năng trả lời thiếu chính xác hoặc trả lời chung chung kiểu suy đoán. Lý do không phải vì mô hình “kém thông minh”, mà vì thông tin quan trọng không được mô hình “ưu tiên chú ý” trong lúc suy luận.

Trong môi trường doanh nghiệp, vấn đề này gây ra các rủi ro:

• Trả lời nhầm điều khoản trong hợp đồng.
• Tư vấn sai chính sách đổi trả cho khách hàng.
• Tự tin đưa ra con số tài chính không tồn tại trong tài liệu.
• Tạo ra nội dung “ảo giác” (hallucination) làm giảm niềm tin của người dùng cuối.

Do đó, chỉ đơn giản “nhồi thêm token” vào prompt không phải là chiến lược bền vững.

Re-ranking – Bước sàng lọc thông tin trước khi đưa vào LLM

Để tránh việc gửi cả đống dữ liệu vào context window một cách mù quáng, ta có thể áp dụng một quy trình chọn lọc có kiểm soát. Trọng tâm của quy trình đó là re-ranking. Quy trình tổng quát như sau:

1. Nhận câu hỏi người dùng (Query): Người dùng đặt câu hỏi hoặc đưa yêu cầu phân tích.
2. Biểu diễn câu hỏi thành vector (Embedding): Câu hỏi được chuyển sang embedding thông qua một mô hình nhúng (embedding model).
3. Tìm kiếm ngữ nghĩa trong kho dữ liệu (Retrieval): Dùng vector của câu hỏi để tìm các đoạn nội dung (chunk) có liên quan nhất trong cơ sở tri thức được lưu trữ dưới dạng vector trong một vector database (ví dụ: Chroma, Pinecone, Milvus…). Thường ta lấy ra top-k đoạn ứng viên.
4. Re-ranking (xếp hạng lại): Thay vì tin tưởng ngay vào kết quả top-k này, ta dùng một mô hình đánh giá mức độ liên quan chi tiết hơn (ví dụ Cross-Encoder). Mục tiêu của bước này là:

• Sắp xếp các đoạn theo độ phù hợp thực sự với câu hỏi, không chỉ theo độ tương đồng thô giữa vector.
• Đẩy các đoạn thực sự quan trọng lên trên, kể cả khi chúng nằm ở phần giữa tài liệu gốc.

5. Lắp ghép lại context cuối cùng: Chỉ những đoạn có mức độ liên quan cao nhất (ví dụ top 3 – top 5 sau re-ranking) mới được đưa vào prompt gửi LLM.

Với cách làm này, mô hình sẽ được thực hiện đúng mạch thông tin, thay vì một tập dữ liệu dàn trải nhưng loãng. Điều này trực tiếp giảm hiện tượng lost in the middle.

Các kỹ thuật hỗ trợ tối ưu context window (bên cạnh re-ranking)

Re-ranking là bước xếp hạng lại độ liên quan. Tuy nhiên, để tối ưu tổng thể cho hội thoại dài và tài liệu lớn, thông thường hệ thống còn kết hợp một số chiến lược khác:

Chia khối nội dung theo ý nghĩa (Semantic Chunking)

Không chia văn bản một cách cơ học theo số token cố định, mà tách theo logic nội dung: theo tiêu đề con, theo mục, theo đoạn có tính khép kín.

Lợi ích:

• Mỗi chunk mang trọn một ý.
• Giảm rủi ro “đứt câu”, “mất ngữ cảnh”.

Sliding Window (cửa sổ trượt)

Với các phần nội dung dài và liên quan, có thể quét một “cửa sổ trượt” quanh vị trí nghi ngờ chứa thông tin quan trọng để lấy vùng lân cận.

Ứng dụng tốt trong tình huống đoạn văn trả lời nằm giữa hai phần, hoặc số liệu tài chính phụ thuộc cả phần trước và phần sau.

Hybrid Retrieval (kết hợp nhiều phương pháp tìm kiếm)

• Tìm kiếm theo embedding để hiểu ngữ nghĩa (“khách muốn hỏi về bảo hành pin?”).
• Tìm kiếm theo từ khóa để không bỏ sót ký hiệu kỹ thuật, mã đơn hàng, chỉ tiêu tài chính có định dạng cố định.

Chiến lược này rất quan trọng trong các ngữ cảnh có số liệu cụ thể hoặc thuật ngữ chuyên ngành.

Memory Caching (bộ nhớ hội thoại)

Trong hội thoại nhiều lượt, có thể lưu tạm các đoạn ngữ cảnh quan trọng từ các lượt trước nhằm:

• Tránh phải truy vấn lại toàn bộ dữ liệu từ đầu.
• Rút ngắn độ trễ.
• Duy trì mạch hội thoại cho người dùng.

Tình huống áp dụng trong thực tế

Các kỹ thuật trên không chỉ mang tính học thuật. Chúng là điều kiện bắt buộc để đưa LLM vào môi trường sản phẩm:

• Chăm sóc khách hàng đa kênh: Người dùng có thể đặt 5–10 câu hỏi xoay quanh cùng một vấn đề. Re-ranking giúp hệ thống giữ đúng ngữ cảnh quan trọng thay vì “trôi mạch” giữa cuộc trò chuyện.
• Tư vấn pháp lý / hợp đồng: Các điều khoản pháp lý thường rải rác trong tài liệu dài. Hệ thống cần trích đúng điều khoản liên quan để tránh rủi ro trả lời sai chính sách.
• Hỗ trợ nội bộ doanh nghiệp: Doanh nghiệp thường có kho tài liệu đào tạo, hướng dẫn vận hành, SOP… rất đồ sộ. Thay vì trả lời dài dòng bằng cách dán nguyên văn tài liệu, hệ thống sẽ trích đúng các đoạn phù hợp nhất với câu hỏi của nhân sự.
• Phân tích số liệu tài chính và vận hành: Khi được hỏi về chỉ số cụ thể, mô hình phải tìm đúng con số, đúng giai đoạn, đúng điều kiện tính toán, không được suy diễn. Việc chọn đúng đoạn chứa số liệu quyết định độ tin cậy của câu trả lời.

Ảnh hưởng tới chi phí, tốc độ và trải nghiệm người dùng

Việc đưa thêm bước re-ranking và retrieval rõ ràng làm pipeline phức tạp hơn so với cách “gửi nguyên văn tất cả vào model”. Tuy nhiên, lợi ích rất rõ:

• Độ chính xác tăng lên: Hệ thống ít trả lời mơ hồ hoặc bịa đặt → tăng độ tin cậy.
• Giảm lãng phí token: Chỉ những phần quan trọng nhất mới đi vào prompt cuối cùng → giảm chi phí suy luận.
• Phản hồi tự tin và ổn định hơn: Người dùng không phải hỏi đi hỏi lại vì câu trả lời thiếu dữ liệu.

Chính nhờ 3 yếu tố này, các kỹ thuật tối ưu context window (retrieval + re-ranking + caching + chunking hợp lý) là bước chuyển từ “demo phòng lab” sang “sản phẩm có thể triển khai thật trong doanh nghiệp”.

Kết luận

Tối ưu context window cho hội thoại dài không chỉ là xử lý một giới hạn kỹ thuật của LLM. Đây là cách để đảm bảo rằng mô hình có thể đọc hiểu thông tin phức tạp, truy xuất đúng phần liên quan, và trả lời có trách nhiệm trong các tình huống nghiệp vụ thực tế. Cách tiếp cận đúng không phải là “đưa hết mọi thứ vào mô hình”, mà là:

1. Thu thập dữ liệu phù hợp.
2. Chia nhỏ và biểu diễn dữ liệu đúng cách.
3. Tìm kiếm thông minh.
4. Xếp hạng lại theo mức độ liên quan.
5. Ghép prompt cuối cùng một cách có chủ đích.

Khi quy trình này được áp dụng chuẩn, chúng ta có thể khai thác LLM như một công cụ hỗ trợ phân tích, chăm sóc khách hàng, tra cứu nội bộ hay đọc tài liệu dài với độ chính xác cao hơn, chi phí hợp lý hơn và trải nghiệm người dùng mượt mà hơn.

Nguồn tham khảo: https://bizfly.vn/techblog/toi-uu-context-windown-cho-hoi-thoai-dai.html