Thực hànhTrung cấp

Đánh giá retrieval trước khi sửa prompt

Lập bộ câu hỏi có căn cứ, đo chất lượng danh sách truy xuất và phân loại lỗi để biết nên sửa dữ liệu, bộ lọc hay xếp hạng.

Trong bài viết này

Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.

Trợ lý trả lời sai giờ nhận hàng tại kho, dù tài liệu đúng đã tồn tại. Trước khi sửa lời nhắc, hãy mở danh sách đoạn mà hệ thống vừa tìm được. Nếu danh sách chỉ có giờ giao hàng tận nhà, mô hình chưa nhận đủ căn cứ để trả lời câu hỏi ban đầu.

Xác định thế nào là một kết quả liên quan

Đánh giá retrieval bắt đầu bằng câu hỏi và nhãn liên quan. Với câu “Kho A nhận hàng trả lại vào thứ Bảy không?”, một tài liệu giới thiệu địa chỉ kho chưa đủ. Đoạn về lịch tiếp nhận thứ Bảy mới trực tiếp hỗ trợ đáp án.

Bạn có thể dùng nhãn nhị phân: liên quan hoặc không liên quan. Với kho phức tạp hơn, dùng ba mức: không giúp trả lời, giúp một phần, đủ căn cứ cho một ý. Viết ví dụ của từng mức để người gán nhãn không tự dùng các tiêu chuẩn khác nhau.

Lưu mã tài liệu và phiên bản kèm nhãn. Nếu quy định thay đổi mà bộ đáp án vẫn chỉ về bản cũ, điểm đánh giá sẽ gây hiểu nhầm. Cần biết đang đo khả năng tìm đúng lịch sử hay tìm đúng quy định hiện hành.

Chọn thước đo theo cách dùng danh sách

Giáo trình Stanford về đánh giá kết quả truy xuất có thứ hạng giải thích việc xét tập kết quả ở các vị trí đầu và vai trò của thứ tự. Trong RAG, giới hạn ngữ cảnh khiến những vị trí đầu đặc biệt đáng quan tâm.

Giả sử có hai đoạn liên quan là A và C. Bộ tìm kiếm trả về [B, A, D]. Precision@3 bằng 1/3, vì một trong ba đoạn liên quan. Recall@3 bằng 1/2, vì lấy được một trong hai đoạn cần xét. Các số này là ví dụ tự dựng để tính tay, không phải benchmark.

Nếu tác vụ chỉ cần tìm một đáp án trực tiếp, vị trí kết quả đúng đầu tiên có ích. Nếu câu hỏi cần ghép quy định và ngoại lệ, tìm thấy một đoạn chưa đủ. Hãy thêm tiêu chí “đủ toàn bộ căn cứ” theo từng câu, không ép mọi bài toán vào cùng một số.

Nhìn để hiểuMột điểm số chưa đủ để chọn mô hình

Chạy các mô hình trên cùng bộ thử, đọc cả điểm tổng lẫn kiểu lỗi, rồi cân nhắc tốc độ và chi phí. Một chênh lệch nhỏ chưa chứng minh mô hình nào luôn tốt hơn.

Đọc điểm số cùng loại lỗi và chi phíVí dụ hoàn toàn giả định trên cùng 20 tình huống: A đúng 18, B đúng 17. Ô có dấu chéo biểu thị ca sai. Cần xem loại lỗi, như sai tên hay quá dài, và đo độ trễ, chi phí, số lần thử lại. Những con số này không phải benchmark thật và không chứng minh A luôn tốt hơn B.Cùng 20 tình huốngA18/20B17/20Lỗi: sai tên ngườiLỗi: vượt độ dàiĐo thêm: độ trễ · chi phí · số lần thử lại

↔ Vuốt ngang để xem toàn bộ sơ đồ.

  1. 01 / Cùng bộ thử

    Dùng cùng các trường hợp và quy tắc chấm đã xác định trước cho cả hai mô hình.

  2. 02 / Đọc điểm số

    Trong ví dụ giả định, A đúng 18/20, B đúng 17/20. Chênh lệch một trường hợp chưa đủ kết luận chung.

  3. 03 / Xem kiểu lỗi

    Mở các trường hợp thất bại: sai tên người và vượt độ dài có mức ảnh hưởng khác nhau.

  4. 04 / Đánh giá nhiều chiều

    Đo thêm tốc độ, chi phí và độ ổn định trên dữ liệu phù hợp với công việc thực tế.

A đúng 18/20 và B đúng 17/20 là số liệu giả định để giải thích cách đọc kết quả, không phải benchmark của mô hình có thật.

Hình minh họa vòng đánh giá chung. Khi áp dụng cho retrieval, đầu ra được chấm là danh sách đoạn và thứ tự của chúng, chưa phải câu trả lời do mô hình sinh.

Đọc lỗi theo đường đi của dữ liệu

Với mỗi câu trượt, kiểm tra lần lượt: tài liệu có trong kho không, văn bản có được trích xuất đúng không, người hỏi có quyền đọc không, bộ lọc có loại nhầm không, rồi mới xem cách tìm và xếp hạng.

Nếu đoạn căn cứ tồn tại ở vị trí thứ hai mươi nhưng bạn chỉ lấy năm đoạn, đó là vấn đề khác với việc OCR làm mất chữ “không”. Cách sửa đầu tiên có thể là cải thiện thứ hạng; cách sửa thứ hai nằm ở khâu nhập dữ liệu.

Nhớ thêm câu không có đáp án. Khi kho không có lịch ngày lễ, tìm được một đoạn rất gần nghĩa không có nghĩa là có căn cứ. Bộ đánh giá nên ghi nhận trường hợp hệ thống trả về ứng viên nhưng chưa đủ dữ liệu, thay vì tự gán tài liệu gần nhất là đáp án đúng.

Bài tập: một bảng lỗi có thể hành động

Tạo mười câu hỏi từ một sổ tay giả định: bốn câu trực tiếp, ba câu dùng cách diễn đạt khác, hai câu cần nhiều đoạn và một câu ngoài phạm vi. Đánh dấu nguồn đúng trước khi chạy tìm kiếm.

Chạy hai cấu hình chỉ khác một yếu tố, chẳng hạn kích thước chunk. Giữ cùng kho, phiên bản embedding, số kết quả và quyền đọc. Lưu danh sách kết quả thô để có thể tính lại khi thay thước đo.

Tiêu chí đạt là mỗi lỗi được gắn một nguyên nhân có bằng chứng, câu ngoài phạm vi không bị coi là thành công chỉ vì có kết quả, và báo cáo tách rõ nhóm câu hỏi. Một điểm trung bình tăng vẫn cần xem có nhóm quan trọng nào giảm; bảng này sẽ chỉ ra bước sửa tiếp theo cụ thể hơn một lần đổi prompt hàng loạt.

Bạn muốn hiểu điều gì?

Khám phá tất cả bài viết esc để đóng