Cách Xây Dựng RAG Tin Cậy: Khám Phá Sâu Về 7 Điểm Lỗi và Khung Đánh Giá

Retrieval-Augmented Generation (RAG) là yếu tố quan trọng cho kiến trúc AI hiện đại, đóng vai trò là khuôn khổ thiết yếu để xây dựng các tác nhân nhận thức 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 cuộc khám phá sâu về bảy điểm lỗi điển hình 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 Phân Tích RAG – 7 Điểm Lỗi (FPs)

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

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

Figure A. 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 Hộp Đỏ (nguồn)

Hãy cùng khám phá từng điểm lỗi, sắp xếp theo trình tự trong đường ống, theo tiến trình từ trên cùng bên trái đến dưới cùng bên phải như được hiển thị trong Figure 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.

Điểm lỗi xảy ra khi một 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 nó không biết.

FP2. Bỏ Qua Tài Liệu 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 xếp hạng nó đủ cao để bao gồm nó trong số 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ốc độ.

FP4. Không Trích Xuất

Đây là tình huống mà LLM không xác định được 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à lưu trữ, thu thập, hợp nhất và giải thích LLM được xử lý thành công, nhưng LLM không 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 về mặt kỹ thuật có mặ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 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.

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

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

Tính Toàn Vẹn Dữ Liệu và Sự Tin Cậy

Khi thông tin thiếu hoặc không chính xác có mặt, 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.

Thu Thập và Hiệu Suất

Đường ống RAG có thể không hiệu quả khi nó bỏ qua 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 Tài Liệu 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 tài liệu để phù hợp với giới hạn của LLM loại bỏ các phần quan trọng nhất.

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

Mặc dù chính xác, đầu ra với khả năng đọc kém hoặc định dạng sai có thể làm tổn hại 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 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 cho một câu hỏi có / không đơn giản, hoặc ngược lại (đầu ra quá ngắn cho một câu hỏi phức tạp).

Ngăn Đánh Giá: Khung Để 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 thẩm phán (ví dụ: GPT-4o) đánh giá từng tiêu chí đối với đầu ra của LLM:

DeepEval tận dụng G-eval, một khuôn khổ sự 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ự nhất quán”, “sự lưu loát” hoặc “sự liên quan”).
2. Thiết lập 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 một tổng trọng số dự kiến 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 nếu bot có thể trả lời truy vấn 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ụ suy giảm CI / CD vào 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 trong việc xây dựng CI, ngăn chặn sự suy giảm im lặng đến sản xuất.

Ưu Điểm

• Đa dạng các chỉ số (50+) bao gồm các kiểm tra thiên vị và độc tính chuyên dụng có sẵn.
• Tích hợp liền mạch với các đường ống CI / CD hiện có.
• Không cần tham chiếu. Đánh giá đầu ra dựa chỉ trên lời nhắc và ngữ cảnh được cung cấp.

Nhược Điểm

• Chất lượng đánh giá phụ thuộc nặng vào khả năng của LLM thẩm phán.
• Tốn kém về mặt tính toán khi LLM thẩm phán là một mô hình cao cấp.

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 xác định 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 người dùng quan trọng và đầu ra được gắn nhãn với ngữ cảnh được thu thập.

Những thứ này có thể được thu thập từ một tệp JSON hoặc CSV.

RAGAS – Người Tối Ưu Hóa Kim

Đánh Giá Tạo RAG (Ragas) nhằm đánh giá RAG mà không cần tập dữ liệu được chú thích bởi con người bằng cách tạo các tập thử nghiệm tổng hợp.

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

Figure B. Sơ Đồ Đánh Giá 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ệ, Tính Trung Thực và 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 đen, đường thẳng, Figure B): Độ chính xác ngữ cảnh, tỷ lệ thu hồi ngữ cảnh.
• Đường ống tạo (đường đen, đường chấm, Figure B): Tính trung thực, liên quan câu trả lời.
• Đất (hộp đỏ, Figure B): Tương tự ngữ nghĩa câu trả lời, độ chính xác 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 hợp đồng pháp lý thiếu các điều khoản chính. Bạn không chắc liệu vấn đề nằm ở Tìm Kiếm (Truy Vấn) hay Đọc (Tạo).
• Vấn Đề: Không biết về số lượng tối ưu hàng đầu (số lượng mảnh được thu thập).
• Giải Pháp: Sử dụng RAGAS để tạo một tập thử nghiệm 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 thử nghiệm để tính toán tỷ lệ 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ả của chỉ số, kế hoạch hành động có thể là:

Bảng 1. Kế Hoạch Hành Động Chẩn Đoán RAGAS – Mapping Điểm Số sang Điều Chỉnh Hệ Thống.

Ưu Điểm

• Hoàn hảo cho một dự án giai đoạn đầu không có tập dữ liệu thực (Như chúng ta đã thấy trong đoạn mã, RAGAS có thể tạo một tập thử nghiệm tổng hợp).

Nhược Điểm

• Tập thử nghiệm tổng hợp có thể bỏ qua các lỗi thực tế tinh vi.
• Yêu cầu một mô hình trích xuất mạnh mẽ để phá vỡ câu trả lời thành các tuyên bố cá nhân (Tôi đã sử dụng gpt-4o trong ví dụ).

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ố LLM dựa trên mức độ phản hồi thỏa mãn ý đị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 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 tra.
• 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ề tính 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 mảnh được thu thập, TruLens đánh dấu bản ghi trong bảng điều khiển của bạn.

Ưu Điểm

• Visualizes chuỗi lý luận để xác định chính xác nơi tác nhân đi sai đường.
• Cung cấp hỗ trợ tích hợp để căn cứ để bắt các ảo tưởng trong thời gian thực.

Nhược Điểm

• Độ dốc học tập để định nghĩa các hàm phản hồi tùy chỉnh.
• Bảng điều khiển có thể cảm thấy nặng nề cho các kịch bản đơn giản.

Arize Phoenix – Bản Đồ Lỗi 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 LLM, bao gồm 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 bối cảnh đánh giá RAG, Phoenix vượt trội trong phân tích nhúng, sử dụng Phân Tích và Dự Báo Đồng Nhất (UMAP) để giảm các vector nhúng chiều cao xuống không gian 2D / 3D.

Phân tích nhúng này tiết lộ toán học nếu các truy vấn thất bại được nhóm lại theo ngữ nghĩa, cho thấy một khoảng trống trong cơ sở 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ỗ dữ liệu trong cơ sở vector (Không tìm thấy trong nhật ký).
• Giải Pháp: Sử dụng Arize Phoenix để tạo một hình ảnh trực quan Umap Embedding (UEV), một bản đồ 3D cho cơ sở vector – để chồng các truy vấn người dùng lên các mảnh tài liệu.
• Kết Quả Dự Kiến: Nhìn thấy trực quan một cụm truy vấn người dùng hạ cánh trong vùng tối nơi không có tài liệu nào tồn tại, cho thấy rằng một số tài liệu đã bị quên không tải lên cửa hàng vector.

Ưu Điểm

• Đigenous; tích hợp với các ngăn xếp giám sát doanh nghiệp hiện có.
• Công cụ tốt nhất để trực quan hóa điểm mù của cửa hàng vector.

Nhược Điểm

• Ít tập trung vào việc ghi điểm, hơn là quan sát.
• Có thể là quá mức cho các ứng dụng quy mô nhỏ hoặc công cụ đơn.

Braintrust – Lưới An Toàn Định Dạng Lời Nhắc

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

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

• Tình Huống: Một nhóm 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 phá vỡ 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 các ví dụ hoàn hảo (ví dụ: N = 50). Hãy để Braintrust chạy so sánh song song (SxS) mỗi khi nhóm 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 / tồi tệ hơn cho từng tập dữ liệu vàng (N = 50).

Ưu Điểm

• Rất nhanh để kiểm tra trước khi triển khai.
• Giao diện người dùng tuyệt vời cho các bên liên quan không kỹ thuật để xem xét và đánh giá đầu ra.

Nhược Điểm

• Độc quyền / Tập Trung Dịch Vụ (mặc dù họ có các thành phần mã nguồn mở).
• Ít các chỉ số công nghệ sâu hơn so với DeepEval hoặc Ragas.

Kết Thúc

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 cho LLM ngữ cảnh liên quan nhất đến truy vấn người dùng.

Chiến Lược Triển Khai: Mapping Chỉ Số sang Đ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 tôi đã đề 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ố trung thực của chúng để đo lường các lỗi toàn vẹn dữ liệu (FP1, FP4, FP7).

TruLens tận dụng độ chính xác ngữ cảnh / tỷ lệ 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.

Đối với các lỗi UX, DeepEval tạo ra các chỉ số tùy chỉnh để đánh giá lỗi UX, trong khi Braintrust vượt trội trong việc so sánh tập dữ liệu thực.