Active filters:
All
Loading video player...
Tổng quan Repository MT-RAG Benchmark Repository MT-RAG Benchmark được thiết kế nhằm đánh giá hiệu quả của hệ thống Retrieval-Augmented Generation (RAG) trong bối cảnh hội thoại đa lượt (multi-turn), nơi mô hình cần truy xuất và sinh ngôn ngữ dựa trên nhiều vòng tương tác. I. Cấu trúc Repository - corpora/: Chứa dữ liệu nền cho truy xuất, gồm hai dạng: document_level (toàn văn) và passage_level (chia đoạn, chi tiết hơn – khuyến nghị cho RAG). Các miền dữ liệu gồm clapnq, cloud, fiqa, govt. Cần giải nén trước khi tạo index. - human/: Lưu các dữ liệu hội thoại thật, gồm 110 cuộc hội thoại, 842 tác vụ sinh ngôn ngữ và các file truy vấn dùng cho đánh giá retriever. Có sẵn kết quả mẫu trong evaluations/. - synthetic/: Gồm dữ liệu hội thoại sinh tự động (~200 hội thoại), dùng mở rộng tập huấn luyện hoặc kiểm thử tính tổng quát. - scripts/: Chứa mã thực thi chính, gồm run_retrieval_eval.py (đánh giá retriever), run_generation_eval.py (đánh giá mô hình sinh ngôn ngữ) cùng các module hỗ trợ judge_wrapper.py và judge_utils.py. II. Đánh giá Hiệu suất Truy xuất File run_retrieval_eval.py dùng để kiểm tra độ chính xác của mô hình truy xuất — liệu mô hình có tìm đúng tài liệu chứa thông tin cần thiết hay không. Các chỉ số đánh giá: - nDCG@k: Đánh giá chất lượng xếp hạng trong top-k kết quả. - Recall@k: Tỷ lệ tài liệu liên quan được tìm thấy. Kết quả cuối cùng là trung bình có trọng số theo số lượng truy vấn của từng tập dữ liệu con. Quy trình xử lý: - Nhận file dự đoán và nhãn đúng (qrels.tsv). - Đọc dữ liệu truy xuất từ JSONL (task_id, contexts, score). - Đọc nhãn đúng và điểm liên quan. - Dùng pytrec_eval để tính các chỉ số. - Tổng hợp kết quả theo từng bộ dữ liệu con. - Tính trung bình có trọng số. Xuất kết quả ra file CSV và cập nhật vào JSON output. III. Các Thành phần Kỹ thuật Cốt lõi 1. Tokenization và Embedding - Tokenization: Chuyển văn bản thành các đơn vị nhỏ (token) để mô hình hiểu. Thường dùng các phương pháp như BPE, WordPiece, SentencePiece hoặc Tiktoken. Việc giới hạn số token giúp kiểm soát “cửa sổ ngữ cảnh” (context window). - Embedding: Biểu diễn token hoặc câu dưới dạng vector số học, sao cho các từ tương đồng nằm gần nhau trong không gian đa chiều. Chiều dài vector là siêu tham số quan trọng, ảnh hưởng đến khả năng biểu diễn ngữ nghĩa và chi phí tính toán. 2. Vector Database Là cơ sở dữ liệu chuyên dụng để lưu trữ và tìm kiếm các vector embedding. Nó giúp truy vấn tài liệu tương đồng nhanh chóng và chính xác — một thành phần cốt lõi trong mọi hệ thống RAG hiện đại. 3. Prompting và Xử lý Ngữ cảnh Đa lượt Cấu trúc Prompt: Gồm ba vai trò — System (đặt ngữ cảnh), User (câu hỏi), Assistant (câu trả lời). Các đoạn thông tin được truy xuất (contexts) sẽ được chèn vào phần User để LLM sinh phản hồi chính xác hơn. Multi-Turn Handling: - Query Rewriting: Viết lại câu hỏi dựa trên lịch sử hội thoại nhằm tránh mất ngữ cảnh và vượt giới hạn token. - Semantic Router: Dùng embedding để xác định loại truy vấn và định tuyến phù hợp (ví dụ: hỏi thông tin hay trò chuyện). - Hybrid Search: Kết hợp tìm kiếm ngữ nghĩa (vector) và tìm kiếm từ khóa (BM25) để tăng độ chính xác. IV. Quy trình Thực thi và Báo cáo A. Pipeline Tổng thể - Chuẩn bị dữ liệu: Giải nén passage_level corpus. - Tạo index: Sử dụng BM25 hoặc FAISS. - Chạy truy xuất: Thực hiện các tác vụ retrieval tasks. - Sinh ngôn ngữ: Chạy run_generation_eval.py với cấu hình khác nhau (full_rag, reference...). - Đánh giá tự động: Tính các chỉ số như ROUGE-L, BLEU, BERTScore, Semantic Consistency, Factuality. - So sánh: Đối chiếu với đánh giá của con người để kiểm chứng độ tin cậy. Phân tích: Dùng công cụ trực quan như InspectorRAGet để xem chi tiết hiệu suất và lỗi. B. Yêu cầu Bài Báo Kỹ thuật (SemEval) Bài báo tối đa 5 trang, tuân theo mẫu ACL (LaTeX). Nội dung cần mô tả rõ ràng pipeline, mô hình, và kết quả để người khác có thể tái lập. Không bắt buộc đạt kết quả cao nhất, nhưng cần có ý tưởng hợp lý, quy trình chặt chẽ và phân tích sâu. Những bài tốt sẽ được công bố trong kỷ yếu hội nghị.