Context Engineering trong RAG: Lọc, nén và sắp xếp

Trong một hệ thống Retrieval-Augmented Generation (RAG), lấy được tài liệu liên quan mới chỉ là một nửa công việc. Nếu đưa nguyên toàn bộ kết quả retrieval vào prompt, mô hình vẫn có thể bị phân tán bởi đoạn dư thừa, thông tin lặp hoặc bằng chứng quan trọng nằm ở vị trí khó chú ý.

Context Engineering trong RAG là bước biến tập tài liệu truy xuất thành ngữ cảnh phù hợp nhất trước khi gửi cho Large Language Model (LLM). Thay vì hỏi “retriever tìm được gì?”, bước này tập trung vào câu hỏi thực tế hơn: “LLM nên nhìn thấy chính xác những gì và theo thứ tự nào?”.

Context Engineering nằm ở đâu trong pipeline RAG?

Một pipeline RAG đơn giản thường có dạng:

Query → Retrieval → Context Processing → Prompt → LLM → Answer

Retrieval chịu trách nhiệm tìm các chunk có khả năng chứa câu trả lời. Context processing tiếp tục xử lý tập chunk đó bằng cách loại nhiễu, rút gọn nội dung, điều chỉnh thứ tự và chọn lượng thông tin vừa với giới hạn context window của mô hình.

Ví dụ, với câu hỏi “RAG khác fine-tuning ở điểm nào?”, retriever có thể trả về tám chunk nói về RAG, fine-tuning, embedding và huấn luyện LLM. Một hệ thống tốt không nhất thiết đưa cả tám chunk vào prompt. Nó có thể giữ lại bốn chunk trực tiếp so sánh hai kỹ thuật, loại phần không liên quan và đặt bằng chứng quan trọng lên trước.

Vì vậy, retrieval tối ưu khả năng tìm thấy bằng chứng, còn Context Engineering tối ưu cách bằng chứng được trình bày cho generator. Hai bước liên quan chặt chẽ nhưng giải quyết hai vấn đề khác nhau.

Filtering: loại chunk không đủ liên quan

Retriever thường ưu tiên recall: lấy đủ rộng để tránh bỏ sót tài liệu đúng. Hệ quả là danh sách kết quả có thể chứa nhiều chunk chỉ liên quan một phần. Filtering thêm một ngưỡng quyết định sau retrieval để chỉ giữ những đoạn đủ hữu ích.

Cách đơn giản nhất là lọc theo similarity score hoặc reranking score. Giả sử retriever trả về các điểm số sau:

Chunk	Score	Xử lý
Giải thích kiến trúc RAG	0.91	Giữ
So sánh RAG và fine-tuning	0.87	Giữ
Cách tạo embedding	0.54	Loại

Không nên xem một ngưỡng score cụ thể là giá trị chuẩn cho mọi hệ thống. Ý nghĩa của score phụ thuộc embedding model, phương pháp tìm kiếm, cách chuẩn hóa và reranker. Ngưỡng nên được chọn dựa trên dữ liệu đánh giá của chính ứng dụng.

Filtering cũng có thể dùng mô hình riêng để phân loại từng chunk thành relevant hoặc irrelevant. Cách này tốn thêm chi phí nhưng hữu ích khi similarity score không phản ánh tốt mức độ tài liệu thực sự trả lời câu hỏi.

Contextual Compression: giữ bằng chứng, bỏ phần thừa

Một chunk có thể liên quan nhưng chỉ vài câu bên trong thực sự cần thiết. Contextual Compression là quá trình rút gọn tài liệu dựa trên query, giữ lại phần chứa thông tin có ích thay vì gửi nguyên chunk cho LLM.

Ví dụ, một chunk dài 500 từ mô tả nhiều chiến lược xây dựng RAG nhưng query chỉ hỏi về hybrid search. Compressor có thể trích ra vài câu giải thích việc kết hợp lexical search và dense retrieval. Context cuối cùng ngắn hơn nhưng vẫn giữ bằng chứng cần để tạo câu trả lời.

Điểm quan trọng: compression không đơn giản là summarization. Một bản tóm tắt cố gắng mô tả nội dung chung của tài liệu, còn contextual compression chỉ quan tâm đến phần có ích đối với query hiện tại.

Có hai hướng phổ biến. Extractive compression chọn nguyên câu hoặc span từ tài liệu nên dễ bảo toàn nội dung gốc. Abstractive compression dùng mô hình viết lại nội dung ngắn hơn, linh hoạt hơn nhưng có nguy cơ tạo thông tin không có trong nguồn.

Trong RAG yêu cầu độ chính xác cao, extractive compression thường dễ kiểm soát hơn. Nếu dùng LLM để nén theo kiểu abstractive, cần coi kết quả nén là một bước sinh nội dung trung gian và đánh giá nguy cơ mất hoặc biến đổi bằng chứng.

Reordering: thứ tự tài liệu cũng ảnh hưởng đến context

Sau filtering và compression, hệ thống vẫn cần quyết định thứ tự các chunk trong prompt. Cách đơn giản là sắp xếp giảm dần theo relevance score, nhưng đây không phải lựa chọn duy nhất.

Với context dài, thông tin quan trọng có thể khó được mô hình tận dụng nếu nằm giữa nhiều đoạn khác. Một chiến lược thực dụng là ưu tiên các chunk có độ liên quan cao ở những vị trí nổi bật, đồng thời nhóm các đoạn cùng chủ đề hoặc cùng tài liệu để duy trì mạch thông tin.

Reordering đặc biệt hữu ích khi câu trả lời cần tổng hợp từ nhiều nguồn. Chẳng hạn, một query hỏi cả ưu điểm và hạn chế của Graph RAG có thể cần hai nhóm tài liệu khác nhau. Gom các chunk theo khía cạnh trước khi xây prompt thường tạo context dễ đọc hơn việc xen kẽ chúng chỉ dựa trên score.

Nếu ứng dụng cần trích dẫn nguồn, metadata như document ID, section hoặc URL nội bộ cũng nên đi cùng chunk trong quá trình sắp xếp. Điều này giúp giữ liên kết giữa phát biểu và bằng chứng thay vì cố khôi phục nguồn sau khi mô hình đã tạo câu trả lời.

Context Packing: chọn dữ liệu trong giới hạn token

LLM có context window hữu hạn và mỗi token đưa vào prompt đều làm tăng chi phí xử lý. Context Packing là quá trình chọn tập chunk tốt nhất sao cho không vượt quá ngân sách token dành cho phần tài liệu.

Một chiến lược cơ bản là duyệt các chunk theo relevance score và thêm chúng cho đến khi hết ngân sách. Đoạn code dưới đây minh họa nguyên tắc này bằng số token đã được tính trước:

def pack_context(chunks, max_tokens):
    selected = []
    used_tokens = 0

    for chunk in sorted(
        chunks,
        key=lambda x: x["score"],
        reverse=True
    ):
        size = chunk["tokens"]

        if used_tokens + size > max_tokens:
            continue

        selected.append(chunk)
        used_tokens += size

    return selected

Hàm trên không phải thuật toán packing tối ưu trong mọi trường hợp, nhưng thể hiện rõ mục tiêu: ưu tiên tài liệu có score cao trong một ngân sách cố định. Trong hệ thống thực tế, số token nên được tính bằng tokenizer tương ứng với model thay vì ước lượng từ số ký tự.

Ngoài relevance, packing có thể cân nhắc thêm tính đa dạng. Nếu năm chunk điểm cao nhất đều lặp lại cùng một thông tin, lấy cả năm thường kém hiệu quả hơn việc giữ hai chunk tốt nhất và dành chỗ cho bằng chứng bổ sung từ nguồn khác.

Đừng nhầm Context Engineering với Prompt Engineering

Prompt Engineering chủ yếu thiết kế instruction: yêu cầu model làm gì, trả lời theo định dạng nào và tuân theo quy tắc nào. Context Engineering rộng hơn ở phần dữ liệu: thông tin nào được đưa vào model, lấy từ đâu, được lọc ra sao và được tổ chức theo thứ tự nào.

Khía cạnh	Prompt Engineering	Context Engineering
Trọng tâm	Instruction cho model	Thông tin model được nhìn thấy
Ví dụ	“Chỉ trả lời dựa trên tài liệu”	Lọc và nén tài liệu trước khi đưa vào prompt
Vấn đề chính	Cách giao nhiệm vụ	Chất lượng và cấu trúc ngữ cảnh

Trong RAG thực tế, hai kỹ thuật thường được dùng cùng nhau. Một instruction tốt không thể bù hoàn toàn cho context chứa tài liệu sai; ngược lại, retrieval chính xác vẫn có thể cho kết quả kém nếu prompt không nói rõ model phải sử dụng bằng chứng như thế nào.

Khi nào cần đầu tư vào bước xử lý context?

Context Engineering trở nên quan trọng khi hệ thống lấy nhiều chunk, tài liệu dài, có nhiều nguồn trùng lặp hoặc chi phí token bắt đầu tăng đáng kể. Nó cũng hữu ích khi quan sát thấy retriever đã tìm đúng tài liệu nhưng câu trả lời của LLM vẫn bỏ sót bằng chứng hoặc tập trung vào đoạn ít quan trọng.

• Dùng filtering khi top-k chứa nhiều kết quả chỉ liên quan yếu.
• Dùng contextual compression khi chunk dài nhưng thông tin cần thiết chỉ chiếm một phần nhỏ.
• Dùng reordering khi câu trả lời phải tổng hợp nhiều bằng chứng hoặc context khá dài.
• Dùng context packing khi cần kiểm soát context window, latency hoặc chi phí token.

Không nên thêm tất cả kỹ thuật ngay từ đầu. Mỗi tầng processing làm pipeline phức tạp hơn và có thể tăng latency. Cách phù hợp là đo retrieval trước, kiểm tra những chunk thực sự được gửi tới LLM, rồi bổ sung bước xử lý giải quyết đúng lỗi đang quan sát được.

Một hệ thống RAG tốt không cố nhồi nhiều tài liệu nhất có thể vào prompt. Mục tiêu là cung cấp ít context nhưng đủ bằng chứng, đúng với câu hỏi và được tổ chức để model sử dụng dễ dàng. Sau chunking, retrieval và query transformation, Context Engineering là lớp nối quan trọng giữa “tìm thấy thông tin” và “tạo ra câu trả lời dựa trên thông tin đó”.