Haystack hữu ích vì có thể thay từng component mà không viết lại toàn bộ hệ thống: đổi sparse/dense retriever, đổi reader, hoặc thay cách lưu document.
Trong end-to-end QA, retriever đặt upper bound cho cả hệ thống: nếu passage chứa đáp án không vào top-k, reader không có bằng chứng để trả lời đúng.
Tăng top_k_retriever thường tăng recall, nhưng reader phải xử lý nhiều passage hơn nên latency tăng.
BM25 là retriever lexical: nó xếp hạng document theo overlap từ khóa, độ hiếm của term và normalize theo độ dài document.
BM25 là baseline tốt vì nhanh, dễ debug và cho biết pipeline có thể tìm passage chứa đáp án bằng keyword matching hay không.
Sparse Retriever dùng vector thưa dựa trên term/keyword; nó mạnh khi query và document có cùng từ quan trọng.
Dense Passage Retrieval dùng encoder để biến question và passage thành embeddings; nó mạnh hơn khi query và passage cùng nghĩa nhưng dùng từ khác nhau.
DPR dùng bi-encoder: một encoder cho question và một encoder cho passage. Passage embeddings được index trước; khi có query, hệ thống encode query rồi tìm passage gần nhất.
Trong kết quả của chương, DPR không nhất thiết luôn hơn BM25; với SubjQA, BM25 có thể đã đạt recall rất cao ở k đủ lớn.
Pipeline QA cần trả về cả answer, score và supporting context để debug xem câu trả lời đến từ passage nào.
Khi pipeline trả lời sai, cần tách lỗi theo tầng: dữ liệu/chunking, index, retriever top-k, reader span, và bước rank answer.
Chỉ nhìn F1 có thể misleading: prediction overlap token với label nhưng vẫn sai nghĩa. Vì vậy nên theo dõi cả EM và F1.
Reader fine-tuned trên SQuAD có thể kém trên SubjQA vì review ngắn, informal, subjective và khác Wikipedia. Đây là lý do cần Domain Adaptation.
Viết lại bằng lời của tôi
Haystack giống cái khung lắp ráp cho QA system. Retriever quyết định “đọc đoạn nào”, reader quyết định “trích câu nào”, còn pipeline giúp nối các bước đó lại để test và debug.
BM25 là bước tìm kiếm kiểu “khớp chữ thông minh”: term hiếm quan trọng hơn, từ lặp lại có lợi nhưng bão hòa, và document dài không tự động thắng.
Sparse retriever giống tìm đúng bằng chữ; dense passage retrieval giống tìm đúng bằng nghĩa.
Đánh giá QA phải chia thành hai câu hỏi: retriever có đem đúng đoạn về không, và reader có gạch chân đúng câu trả lời trong đoạn đó không.
top_k_retriever là núm chỉnh recall/latency: kéo lên thì ít bỏ sót passage đúng hơn, nhưng phải đọc nhiều passage hơn.
Gợi ý trả lời câu hỏi dẫn đường
Retriever và reader chia việc như thế nào? Retriever chọn top-k passage/document có khả năng chứa đáp án; reader đọc các passage đó và trích answer span. Retriever quyết định “đọc ở đâu”, reader quyết định “trả lời đoạn nào”.
Đánh giá retriever khác đánh giá reader ra sao? Retriever dùng Recall@k hoặc Mean Average Precision để đo passage đúng có vào ranking không. Reader dùng Exact Match và F1 Score để đo answer span có khớp label không.
Khi nào QA system thất bại dù reader tốt? Khi retriever không đưa passage chứa đáp án vào top-k, khi chunking/index sai, hoặc khi domain review khác dữ liệu reader được fine-tune khiến span scoring lệch.
Gợi ý trả lời điều chưa rõ
API cụ thể của Haystack thay đổi theo version nào? Đây là chi tiết nên kiểm theo version cài đặt khi code. Phần cần nhớ lâu dài là kiến trúc: DocumentStore chứa/index tài liệu, retriever lấy top-k passage, reader trích answer, pipeline nối các component và evaluation tách lỗi retrieval/extraction.
Điều chưa rõ
API cụ thể của Haystack thay đổi theo version nào? Xem phần trả lời bên trên; khi code thật cần kiểm tài liệu/API đúng version.