Cách Xây Dựng Reliable RAG: Một Phân Tích Sâu Về 7 Điểm Lỗi và Khung Đánh Giá

Retrieval-Augmented Generation (RAG) là một thành phần quan trọng trong kiến trúc AI hiện đại, đóng vai trò là một khuôn khổ thiết yếu để xây dựng các tác nhân nhận thức về ngữ cảnh.

Nhưng việc chuyển từ một nguyên mẫu cơ bản sang một hệ thống sẵn sàng sản xuất liên quan đến việc vượt qua các chướng ngại vật đáng kể trong việc thu thập dữ liệu, hợp nhất ngữ cảnh và tổng hợp phản hồi.

Bài viết này cung cấp một phân tích sâu về bảy điểm lỗi phổ biến của RAG và các chỉ số đánh giá với các ví dụ mã hóa thực tế.

Cấu Trúc Của Sự Sụp Đổ Của RAG – 7 Điểm Lỗi (FPs)

Theo các nhà nghiên cứu Barnett et al., Hệ Thống Tăng Cường Tái Tạo (RAG) gặp phải bảy điểm lỗi cụ thể trong toàn bộ quá trình.

Dưới đây là sơ đồ minh họa các giai đoạn này:

Hình A. Các Quá Trình Chỉ Mục và Truy Vấn Cần Thiết Để Tạo Hệ Thống RAG. Quá Trình Chỉ Mục Được Thực Hiện Tại Thời Điểm Phát Triển và Truy Vấn Tại Thời Điểm Chạy. Các Điểm Lỗi Được Xác Định Trong Nghiên Cứu Này Được Hiển Thị Trong Các Hộp Đỏ (Nguồn)

Hãy cùng khám phá từng điểm lỗi theo thứ tự trong quá trình, theo tiến trình từ trái sang phải như được hiển thị trong Hình A.

FP1. Nội Dung Thiếu

Nội dung thiếu xảy ra khi hệ thống được hỏi một câu hỏi mà không thể trả lời vì thông tin liên quan không có trong cửa hàng vector có sẵn từ đầu.

Sự cố xảy ra khi mô hình ngôn ngữ lớn (LLM) cung cấp một phản hồi nghe có vẻ hợp lý nhưng không chính xác thay vì nói rằng nó không biết.

FP2. Bỏ Qua Các Tài Liệu Được Xếp Hạng Cao

Đây là tình huống mà một tài liệu chính xác tồn tại trong cửa hàng vector, nhưng bộ thu thập không thể xếp hạng nó đủ cao để bao gồm trong số các tài liệu hàng đầu được cung cấp cho LLM làm ngữ cảnh.

Kết quả là thông tin chính xác không bao giờ đến được LLM.

FP3. Không Trong Ngữ Cảnh (Giới Hạn Chiến Lược Hợp Nhất)

Đây là tình huống mà một tài liệu chính xác tồn tại và được thu thập từ cửa hàng vector, nhưng bị loại bỏ trong quá trình hợp nhất.

Điều này xảy ra khi quá nhiều tài liệu được trả về và hệ thống phải lọc chúng xuống để phù hợp trong cửa sổ ngữ cảnh của LLM, giới hạn token hoặc giới hạn tỷ lệ.

FP4. Không Trích Xuất

Đây là tình huống mà LLM không thể xác định thông tin chính xác trong ngữ cảnh, ngay cả khi thông tin chính xác có trong cửa hàng vector và được thu thập / hợp nhất thành công.

Điều này xảy ra khi ngữ cảnh quá ồn ào hoặc chứa thông tin mâu thuẫn khiến LLM bị nhầm lẫn.

FP5. Định Dạng Sai

Đây là tình huống mà việc lưu trữ, thu thập, hợp nhất và giải thích của LLM đều được xử lý thành công, nhưng LLM không thể tuân theo các hướng dẫn định dạng cụ thể được cung cấp trong lời nhắc, chẳng hạn như một bảng, danh sách có dấu đầu dòng hoặc lược đồ JSON.

FP6. Độ Chính Xác Không Chính Xác

Đầu ra của LLM có mặt về mặt kỹ thuật, nhưng hoặc quá chung chung hoặc quá phức tạp so với nhu cầu của người dùng.

Ví dụ, LLM tạo ra câu trả lời đơn giản cho một truy vấn của người dùng có mục tiêu chuyên nghiệp phức tạp.

FP7. Câu Trả Lời Không Hoàn Chỉnh

Đây là tình huống mà LLM tạo ra đầu ra không nhất thiết sai, nhưng thiếu các mảnh thông tin chính mà có sẵn trong ngữ cảnh.

Ví dụ, khi người dùng hỏi một câu hỏi phức tạp như “Những điểm chính trong tài liệu A, B và C là gì?”, LLM chỉ giải quyết một hoặc hai nguồn.

FPs Ảnh Hưởng Như Thế Nào đến Hiệu Suất của Dòng RAG

Mỗi điểm lỗi này ảnh hưởng đến hiệu suất của các đường ống RAG:

Sự Thiếu Tín và Hỏng Hóc Dữ Liệu

Khi thông tin thiếu hoặc không chính xác, hệ thống không còn là nguồn thông tin đáng tin cậy. Các điểm lỗi chính bao gồm:

• FP1 (Nội Dung Thiếu): Câu trả lời không có trong tài liệu từ đầu.
• FP4 (Không Trích Xuất): LLM quyết định bỏ qua câu trả lời chính xác trong tài liệu.
• FP7 (Không Hoàn Chỉnh): LLM cung cấp nửa sự thật, thiếu các mảnh thông tin quan trọng.

Các Nút thắt về Thu Thập và Hiệu Suất

Đường ống RAG có thể không hiệu quả khi nó bỏ lỡ thông tin chính trong các giai đoạn thu thập và hợp nhất. Các điểm lỗi chính bao gồm:

• FP2 (Bỏ Qua Các Tài Liệu Được Xếp Hạng Cao): Mô hình nhúng không chọn được các nhúng hàng đầu.
• FP3 (Chiến Lược Hợp Nhất): Kịch bản để cắt các tài liệu xuống để phù hợp trong giới hạn của LLM loại bỏ các phần quan trọng nhất.

Lỗi Trải Nghiệm Người Dùng và Định Dạng

Mặc dù đúng, đầu ra có khả năng đọc kém hoặc định dạng sai có thể làm suy giảm trải nghiệm người dùng. Các điểm lỗi chính bao gồm:

• FP5 (Định Dạng Sai): LLM không thể tuân theo định dạng đầu ra cụ thể như JSON.
• FP6 (Độ Chính Xác Không Chính Xác): LLM tạo ra đầu ra dài dòng cho một câu hỏi đơn giản hoặc ngược lại (quá ngắn cho một câu hỏi phức tạp).

Ngăn Đánh Giá: Khung Đánh Giá Để Giảm Thiểu FPs

Các chỉ số đánh giá được thiết kế để giảm thiểu một cách có hệ thống các điểm lỗi này.

Phần này khám phá các chỉ số đánh giá chính với các trường hợp sử dụng thực tế.

Các Chỉ Số Đánh Giá RAG Chính:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Bài Kiểm Tra Trước Khi Triển Khai

DeepEval tính toán một điểm số có trọng số dựa trên các tiêu chí.

Một LLM làm trọng tài (ví dụ, GPT-4o) đánh giá từng tiêu chí chống lại đầu ra của LLM:

DeepEval tận dụng G-eval, một khuôn khổ suy nghĩ theo chuỗi (CoT) thực hiện một cách tiếp cận đa bước để đánh giá đầu ra:

1. Định nghĩa một tiêu chí để đo lường (ví dụ, “sự mạch lạc”, “sự trôi chảy” hoặc “sự liên quan”).
2. Thực hiện các bước đánh giá (sử dụng một LLM đánh giá).
3. Theo dõi bước đánh giá và phân tích đầu vào và đầu ra của LLM.
4. Tính toán tổng điểm có trọng số của điểm số của từng tiêu chí.

Tình Huống Thông Thường Trong Thực Tiễn

• Tình Huống: Một trợ lý tài liệu kỹ thuật (bot) cho một sản phẩm phần mềm phức tạp dường như hoạt động mọi lúc khi nhóm kỹ sư cập nhật cơ sở mã.
• Vấn Đề: Không có bằng chứng định lượng về việc bot có thể trả lời truy vấn của người dùng (Bạn chỉ “nghĩ” nó hoạt động…).
• Giải Pháp: Tích hợp một hàm PyTest vào bộ dụng cụ hồi quy CI / CD trong Github Action nơi DeepEval chạy G-Eval và các chỉ số khác trên một trường hợp thử nghiệm:

• Kết Quả Dự Kiến: Nếu bất kỳ điểm số nào của các chỉ số giảm xuống dưới ngưỡng (0,85), PyTest sẽ nâng AssertionError – ngay lập tức thất bại việc xây dựng CI, ngăn chặn sự suy giảm im lặng đến sản xuất.

Lưu Ý Của Nhà Phát Triển – Trường Hợp Thử Nghiệm Cho DeepEval
Một tập hợp các đối tượng LLMTestCase định nghĩa trường hợp thử nghiệm mà DeepEval chạy.

Trong thực tế, trường hợp thử nghiệm này nên chứa hầu hết các truy vấn của người dùng và đầu ra được gắn nhãn với ngữ cảnh được thu thập.

Những điều này có thể được truy xuất từ một tệp JSON hoặc CSV.

RAGAS – Chuyên Gia Tối Ưu Hóa Kim

RAGAS nhằm đánh giá RAG mà không cần tập dữ liệu được chú thích bằng người bằng cách tạo các tập kiểm tra tổng hợp.

Sau đó, nó tính toán các chỉ số cờ:

Hình B. Sơ Đồ Tam Phân Của RAGAS Kết Nối Câu Hỏi, Ngữ Cảnh và Câu Trả Lời Thông Qua Các Chỉ Số Độ Chính Xác, Tỷ Lệ Thu Hồi, Tính Tin Cậy và Sự Liên Quan (Tạo Bởi Kuriko IWAI)

Các chỉ số cờ được chia thành ba nhóm:

• Đường ống thu thập (đường liền, màu đen, Hình B): Độ chính xác ngữ cảnh, tỷ lệ thu hồi ngữ cảnh.
• Đường ống tạo (đường đứt, màu đen, Hình B): Tính tin cậy, sự liên quan của câu trả lời.
• Điểm chuẩn (hộp màu đỏ, Hình B): Tương tự ngữ nghĩa của câu trả lời, độ chính xác của câu trả lời.

Tình Huống Thông Thường Trong Thực Tiễn

• Tình Huống: Hệ thống RAG cho các hợp đồng pháp lý thiếu các điều khoản quan trọng. Bạn không chắc chắn liệu vấn đề có nằm trong Tìm kiếm (Truy xuất) hay Đọc (Tạo).
• Vấn Đề: Không có ý tưởng về số lượng tối ưu các phần được thu thập (top-k).
• Giải Pháp: Sử dụng RAGAS để tạo một tập kiểm tra tổng hợp với 100 cặp câu hỏi và bằng chứng. Sau đó, chạy đường ống RAG chống lại tập kiểm tra để tính độ thu hồi ngữ cảnh và độ chính xác ngữ cảnh:
• Kết Quả Dự Kiến: Tùy thuộc vào kết quả chỉ số, kế hoạch hành động có thể là như sau:

Bảng 1. Ma Trận Chẩn Đoán và Hành Động Của RAGAS – Mapping Điểm Số sang Điều Chỉnh Hệ Thống.

TruLens – Chuyên Gia Vòng Lặp Phản Hồi

TruLens tập trung vào các cơ chế nội bộ của quá trình RAG thay vì chỉ đầu ra cuối cùng bằng cách sử dụng hàm phản hồi.

Nó cũng sử dụng một điểm số dựa trên LLM phản ánh mức độ đáp ứng của phản hồi với ý định của truy vấn, sử dụng thang điểm Likert 4 điểm (0-3), khiến nó vượt trội trong xếp hạng chất lượng của các kết quả tìm kiếm khác nhau.

Tình Huống Thông Thường Trong Thực Tiễn

• Tình Huống: Một bot tư vấn y tế trả lời câu hỏi của người dùng một cách chính xác nhưng thêm một mẹo không có trong cơ sở PDF được kiểm chứng.
• Vấn Đề: Mẹo thêm vào có thể hữu ích nhưng không có căn cứ.
• Giải Pháp: Sử dụng TruLens để thực hiện một hàm phản hồi về căn cứ với một ngưỡng như điểm số > 0,8.

• Kết Quả Dự Kiến: Khi LLM tạo ra một phản hồi chứa thông tin không có trong các phần được thu thập, TruLens đánh dấu bản ghi trong bảng điều khiển của bạn.

Arize Phoenix – Bản Đồ Sự Cố Im Lặng

Arize Phoenix là một công cụ đánh giá và quan sát mã nguồn mở để đánh giá đầu ra của LLM, bao gồm cả các hệ thống RAG phức tạp.

Xây dựng trên OpenTelemetry bởi Arize AI, nó tập trung vào khả năng quan sát bằng cách coi đánh giá LLM là một tập con của MLOps.

Trong ngữ cảnh của đánh giá RAG, Phoenix vượt trội trong phân tích nhúng, sử dụng Uniform Manifold Approximation and Projection (UMAP) để giảm các nhúng vector chiều cao xuống không gian 2D / 3D.

Phân tích nhúng này tiết lộ một cách toán học nếu các truy vấn thất bại được nhóm lại về mặt ngữ nghĩa, chỉ ra một khoảng trống trong cơ sở dữ liệu vector.

Tình Huống Thông Thường Trong Thực Tiễn

• Tình Huống: Một bot hỗ trợ khách hàng hoạt động tốt cho việc hoàn trả nhưng đưa ra câu trả lời vô nghĩa cho các yêu cầu bảo hành.
• Vấn Đề: Lỗ hổng dữ liệu trong cơ sở dữ liệu vector (Không tìm thấy trong nhật ký).
• Giải Pháp: Sử dụng Arize Phoenix để tạo một Tấm Bản Đồ Nhúng UMAP (UEV), một bản đồ 3D cho cơ sở dữ liệu vector – để chồng các truy vấn của người dùng lên các phần tài liệu.
• Kết Quả Dự Kiến: Nhìn thấy trực quan một cụm truy vấn của người dùng rơi vào vùng tối nơi không có tài liệu, cho thấy một số tài liệu bị quên tải lên cửa hàng vector.

Braintrust – Lưới An Toàn Suy Nghĩ Lại

Braintrust được thiết kế cho các chu kỳ lặp lại với tần suất cao bằng cách sử dụng so sánh giữa các mô hình.

Tình Huống Thông Thường Trong Thực Tiễn

• Tình Huống: Một đội kỹ sư nâng cấp lời nhắc từ “Trả Lời Câu Hỏi” (Trường Hợp A) lên một hướng dẫn hệ thống phức tạp 500 từ (Trường Hợp B).
• Vấn Đề: Cải thiện lời nhắc cho Trường Hợp B có thể vô tình làm hỏng Trường Hợp A.
• Giải Pháp: Sử dụng Braintrust để tạo một tập dữ liệu vàng với một tập hợp N ví dụ hoàn hảo (ví dụ, N = 50). Hãy để Braintrust chạy so sánh song song (SxS) mỗi khi đội cập nhật một từ trong lời nhắc:

• Kết Quả Dự Kiến: Một báo cáo khác biệt hiển thị chính xác những trường hợp nào được cải thiện / xấu đi cho mỗi tập dữ liệu vàng (N = 50).

Kết Luận

Khi được xử lý với các khuôn khổ đánh giá phù hợp, RAG có thể là một công cụ cạnh tranh để cung cấp ngữ cảnh LLM liên quan nhất đến truy vấn của người dùng.

Chiến Lược Triển Khai: Mapping Chỉ Số Đến Điểm Lỗi

Mặc dù không có giải pháp phù hợp với tất cả, Bảng 2 hiển thị các chỉ số đánh giá nào để áp dụng cho từng điểm lỗi mà chúng ta đã đề cập trong bài viết này:

Bảng 2. Ma Trận Giảm Thiểu Điểm Lỗi – Công Cụ Nào Giải Quyết Điểm Lỗi Nào?

DeepEval và RAGAS có thể tận dụng các chỉ số tính tin cậy của chúng để đo lường các lỗi về tính toàn vẹn dữ liệu (FP1, FP4, FP7).

TruLens tận dụng độ chính xác ngữ cảnh / độ thu hồi của nó để đo lường sự liên quan của ngữ cảnh đến đầu ra – hiệu quả đánh giá FP2.

Arize Phoenix cung cấp một bản đồ truy vết của quá trình thu hồi, giúp dễ dàng xem liệu tài liệu thu hồi có bị mất trong quá trình hợp nhất (FP3) hay không.

Đối với các lỗi về trải nghiệm người dùng, DeepEval tạo ra các chỉ số tùy chỉnh để đánh giá lỗi về trải nghiệm người dùng, trong khi Braintrust vượt trội trong việc so sánh tập dữ liệu chuẩn.