top_k thực ra là ba tham số ở ba chặng khác nhau

top_k thực ra là ba tham số ở ba chặng khác nhau A data-flow diagram generated by Archify. 01 / Chặng một 02 / Hợp nhất 03 / Chặng hai 04 / Evidence 05 / Context retrieval_k = 50 · mỗi retriever lấy 50 · 01 / Chặng một retrieval_k = 50 mỗi retriever lấy 50 Sau RRF và khử trùng · khoảng 60 ứng viên · 02 / Hợp nhất Sau RRF và khử trùng khoảng 60 ứng viên rerank_input_k = 50 · số cặp đem đi chấm lại · 03 / Chặng hai rerank_input_k = 50 số cặp đem đi chấm lại rerank_output_k = 8 · số evidence giữ lại · 04 / Evidence rerank_output_k = 8 số evidence giữ lại context_k = 5 · số đoạn thật sự vào prompt · 05 / Context context_k = 5 số đoạn thật sự vào prompt Quá nhỏ thì mất evidence · reranker không được thấy · 01 / Chặng một Quá nhỏ thì mất evidence reranker không được thấy Trùng lặp lộ ra ở đây · nhiều chunk cùng một file · 02 / Hợp nhất Trùng lặp lộ ra ở đây nhiều chunk cùng một file Chi phí theo số cặp · chặng đắt nhất của retrieval · 03 / Chặng hai Chi phí theo số cặp chặng đắt nhất của retrieval Ngân sách token · chỗ nhiễu bắt đầu có giá · 05 / Context Ngân sách token chỗ nhiễu bắt đầu có giá gộp hai list đưa đi chấm cắt lần một cắt lần hai rủi ro rủi ro cái giá cái giá Legend primary data data store data flow

Ba chữ k không nên bị gộp thành một

  • • candidate_k quyết định evidence có sống sót qua chặng một hay không
  • • rerank_k quyết định reranker nhìn bao nhiêu, giữ bao nhiêu
  • • context_k quyết định cuối cùng LLM đọc mấy đoạn

Nếu chỉ rerank top 10 của retriever

  • • Tài liệu đúng đang đứng hạng 20 sẽ không bao giờ được cứu
  • • Reranker khi đó chỉ sắp xếp lại một tập vốn đã sai
  • • Đây là chỗ nên đo candidate Recall@K trước khi đổi reranker

Lấy nhiều hơn không phải lúc nào cũng tốt hơn

  • • K lớn thêm recall nhưng cũng thêm trùng lặp và mâu thuẫn
  • • Lost in the Middle: model dùng long context không đều
  • • Mục tiêu là mật độ evidence hữu ích, không phải số chunk