Retrieval hỏng theo bốn kiểu, mỗi kiểu sửa một cách

Retrieval hỏng theo bốn kiểu, mỗi kiểu sửa một cách A data-flow diagram generated by Archify. 01 / Câu hỏi 02 / Candidate set 03 / Ranked list 04 / Top-k 05 / Context Câu hỏi user · evidence đúng có tồn tại · 01 / Câu hỏi Câu hỏi user evidence đúng có tồn tại Candidate retrieval · quét rộng, lấy top 50 · 02 / Candidate set Candidate retrieval quét rộng, lấy top 50 Xếp hạng · fusion và rerank · 03 / Ranked list Xếp hạng fusion và rerank Cắt top-k · giữ lại vài đoạn · 04 / Top-k Cắt top-k giữ lại vài đoạn Context · evidence vào prompt · 05 / Context Context evidence vào prompt Không lọt top 50 · recall của candidate · 02 / Candidate set Không lọt top 50 recall của candidate Đứng hạng 17 · có mặt nhưng quá thấp · 03 / Ranked list Đứng hạng 17 có mặt nhưng quá thấp Sai version · đúng chủ đề, sai ràng buộc · 04 / Top-k Sai version đúng chủ đề, sai ràng buộc Quá nhiều nhiễu · recall đủ, precision kém · 05 / Context Quá nhiều nhiễu recall đủ, precision kém đi tìm evidence 50 ứng viên danh sách có thứ tự evidence cuối hỏng kiểu 1 hỏng kiểu 2 hỏng kiểu 3 hỏng kiểu 4 Legend primary data data flow

Bốn kiểu hỏng không sửa bằng một cách

  • • Không lọt candidate set thì reranker phía sau không thể cứu
  • • Rank quá thấp là bài toán xếp hạng, không phải bài toán tìm kiếm
  • • Nhiễu nhiều là bài toán precision và ngân sách context

Similarity không tự giải quyết ràng buộc

  • • Chính sách 2024 và 2026 đều gần nghĩa với câu hỏi như nhau
  • • department, version, tenant và ACL là điều kiện cứng chứ không phải ngữ nghĩa
  • • Đây là việc của metadata filter, không phải của embedding

Trước khi sửa, hãy hỏi hai câu

  • • Evidence cần thiết có nằm trong retrieved set không
  • • Nếu có rồi thì LLM có dùng nó đúng không
  • • Câu thứ nhất là retrieval, câu thứ hai đã là generation