Top-K càng cao, AI trả lời càng chính xác?

Không. Trong RAG, tăng Top-K không tự động làm AI trả lời chính xác hơn. K lớn hơn giúp bộ tìm kiếm lấy nhiều ứng viên hơn nên có thể giảm nguy cơ bỏ sót tài liệu liên quan. Nhưng nếu các kết quả bổ sung có chất lượng thấp, chúng lại làm context dài hơn, tăng nhiễu, tốn token và có thể khiến mô hình dựa vào thông tin kém liên quan.

Vì vậy câu hỏi đúng không phải là "K bao nhiêu là tốt nhất?" mà là "K nào tạo ra tập tài liệu đủ đầy nhưng vẫn tập trung cho loại câu hỏi và dữ liệu của mình?" Trong hệ thống production, nên tách K dùng để lấy candidate khỏi số chunk cuối cùng đưa vào LLM, sau đó tune bằng evaluation thay vì chọn một con số cố định theo cảm tính.

Trong vector search, truy vấn được biểu diễn dưới dạng vector và hệ thống tìm các vector tài liệu gần nhất. Top-K thường chỉ số lượng kết quả gần nhất cần trả về. Với hybrid search, kết quả keyword và vector có thể còn được hợp nhất, xếp hạng và xếp hạng lại trước khi ứng dụng chọn context cho LLM.

Do đó cần phân biệt ít nhất hai lớp. Retrieval K quyết định độ rộng của tập ứng viên. Final context K là số chunk thật sự đi vào prompt sau filter hoặc reranking. Nếu đặt cả hai bằng một giá trị duy nhất, tăng K có thể vô tình biến mục tiêu "tìm rộng hơn" thành "nhét nhiều dữ liệu hơn vào model". Đây là hai bài toán khác nhau.

K quá thấp có thể bỏ sót chunk chứa điều kiện, ngoại lệ hoặc phần trả lời nằm ở một tài liệu khác. Khi đó LLM không có đủ bằng chứng để tạo câu trả lời đầy đủ. Tăng K có thể cải thiện recall vì nhiều tài liệu liên quan có cơ hội xuất hiện trong tập kết quả.

Nhưng sau một điểm nhất định, những chunk mới thường kém liên quan hơn các chunk đầu. Nếu vẫn gửi tất cả vào prompt, tín hiệu tốt bị pha loãng bởi nội dung gần nghĩa nhưng sai ngữ cảnh, phiên bản cũ hoặc thông tin không trực tiếp trả lời câu hỏi. Microsoft cũng khuyến nghị tune Top-K theo metric: quá nhiều chunk làm lãng phí token và đưa nhiễu vào prompt; quá ít chunk có thể làm thiếu thông tin. Nghiên cứu Lost in the Middle cho thấy model có context dài không đồng nghĩa model luôn sử dụng ổn định mọi thông tin bên trong context.

Cách thực tế hơn là retrieve rộng → rerank/filter → gửi context hẹp hơn. Bước đầu lấy đủ candidate để hạn chế bỏ sót. Bước sau dùng semantic reranker, relevance threshold, metadata filter hoặc logic nghiệp vụ để loại kết quả yếu trước khi gọi LLM.

Azure AI Search minh họa rõ sự khác biệt này. Khi dùng vector search cùng Semantic Ranker, tài liệu Microsoft hiện khuyến nghị đặt retrieval k=50 để semantic ranker có đủ đầu vào; semantic ranker xếp hạng lại tối đa 50 kết quả. Con số 50 ở đây là candidate set cho tầng reranking, không phải khuyến nghị gửi 50 chunk vào prompt của LLM. Sau reranking, ứng dụng vẫn cần chọn phần grounding phù hợp với token budget và chất lượng thực tế.

Tư duy này đặc biệt hữu ích với knowledge base doanh nghiệp có tài liệu dài, nhiều phiên bản hoặc nhiều tenant: recall có thể được bảo vệ ở tầng tìm kiếm trong khi context cuối vẫn tập trung.

Hãy tạo một evaluation set gồm các câu hỏi thật hoặc đại diện cho production, kèm tài liệu hoặc đáp án kỳ vọng. Sau đó chạy cùng tập câu hỏi với nhiều cấu hình K. Ví dụ có thể thử K=3, 5, 10 và 20 như các điểm thí nghiệm; đây không phải các giá trị chuẩn cho mọi hệ thống.

Ở tầng retrieval, theo dõi Recall@K để biết tài liệu liên quan có xuất hiện trong Top-K hay không và NDCG@K hoặc metric xếp hạng tương đương để xem kết quả tốt có nằm đủ cao hay không. Ở tầng answer, đo groundedness/faithfulness, completeness, relevancy và correctness theo nhu cầu hệ thống. Đồng thời ghi nhận token context, latency và chi phí.

Nếu tăng K làm Recall@K tốt hơn nhưng answer correctness đứng yên hoặc giảm, vấn đề nhiều khả năng đã chuyển từ "thiếu candidate" sang "context có quá nhiều nhiễu hoặc reranking chưa tốt". Đây là lúc cần tối ưu pipeline thay vì tiếp tục tăng K.

Một cấu hình production nên xem Top-K trong cả chuỗi retrieval. Hybrid search giúp kết hợp tín hiệu keyword với semantic similarity khi dữ liệu có mã sản phẩm, thuật ngữ nội bộ hoặc câu hỏi diễn đạt không giống tài liệu. Reranking ưu tiên lại candidate theo mức liên quan sâu hơn với truy vấn. Relevance threshold loại các chunk dưới ngưỡng chất lượng trước khi chúng đi vào prompt. Metadata filter giới hạn đúng tenant, sản phẩm, phiên bản, ngôn ngữ hoặc thời gian hiệu lực.

Cũng nên kiểm tra chunking trước khi tăng K. Nếu một ý hoàn chỉnh bị cắt thành quá nhiều đoạn hoặc mỗi chunk chứa nhiều chủ đề, K cao chỉ làm vấn đề retrieval lan rộng. Với câu hỏi không có bằng chứng đủ mạnh, hệ thống nên có chính sách abstain hoặc yêu cầu làm rõ thay vì cố trả lời bằng các kết quả gần nhất nhưng không thực sự đúng.

Top-K bao nhiêu là tốt nhất cho RAG?

Không có một giá trị tốt nhất cho mọi hệ thống. K phụ thuộc dữ liệu, chunking, search strategy, reranker, loại câu hỏi, token budget và yêu cầu latency. Hãy chọn bằng evaluation set đại diện cho production.

Tăng K có luôn làm Recall@K tăng không?

Về định nghĩa, mở rộng K tạo cơ hội chứa nhiều tài liệu liên quan hơn, nhưng mức cải thiện thực tế phụ thuộc chất lượng retrieval. Quan trọng hơn, recall tốt hơn chưa đảm bảo câu trả lời cuối tốt hơn.

Retrieval K và final context K có nên bằng nhau?

Không bắt buộc. Pipeline có reranker thường có lợi khi lấy candidate rộng hơn ở retrieval rồi chỉ chọn một tập nhỏ, liên quan hơn cho LLM.

Có nên dùng relevance threshold cùng Top-K không?

Có thể. Threshold giúp chặn kết quả yếu dù chúng vẫn nằm trong Top-K. Tuy nhiên ngưỡng phải được hiệu chỉnh theo scoring của search engine và dữ liệu của bạn, không nên sao chép một con số từ hệ thống khác.

Khi dùng Azure AI Search Semantic Ranker, tại sao thường thấy k=50?

Microsoft khuyến nghị k=50 cho vector query khi dùng Semantic Ranker để cung cấp đủ candidate cho tầng reranking. Đây là đầu vào của reranker, không phải quy tắc buộc phải gửi 50 chunk vào LLM.