Vấn đề của việc đánh giá dựa trên “cảm tính”
Tất cả chúng ta đều đã từng trải qua điều này. Bạn xây dựng một hệ thống Retrieval-Augmented Generation (RAG), đặt cho nó 5 câu hỏi, và vì câu trả lời trông có vẻ hợp lý, bạn mặc định rằng nó đã sẵn sàng để triển khai (production-ready). Trong ngành, chúng tôi gọi đây là đánh giá dựa trên “vibe” (cảm tính). Nó có thể ổn với một dự án cá nhân cuối tuần, nhưng lại là công thức dẫn đến thảm họa trong môi trường chuyên nghiệp.
Tôi đã học được bài học này một cách cay đắng khi một hệ thống trông có vẻ hoàn hảo trong lúc thử nghiệm lại bắt đầu “ảo tưởng” (hallucinating) về các mức giảm giá 40% không hề tồn tại khi đến tay người dùng thật. Bạn không thể cải thiện những gì bạn không thể đo lường. Nếu bạn thay đổi embedding model hoặc điều chỉnh kích thước chunk từ 500 lên 1.000 token, bạn cần biết — bằng dữ liệu — liệu hệ thống có thực sự tốt hơn không. RAGAS (RAG Assessment) giải quyết vấn đề này bằng cách sử dụng phương pháp “LLM-as-a-judge” (LLM làm giám khảo) để đưa ra các điểm số khách quan.
Bộ ba RAG: Những chỉ số quan trọng
RAGAS không chỉ nhìn vào văn bản cuối cùng. Nó phân tích mối quan hệ giữa câu hỏi của người dùng, các tài liệu được truy xuất (retrieved documents) and câu trả lời được tạo ra. Điều này tạo ra một bức tranh rõ ràng về nơi mà quy trình (pipeline) của bạn đang gặp lỗi.
- Faithfulness (Sự trung thực): Chỉ số này đo lường mức độ trung thành của câu trả lời so với ngữ cảnh được truy xuất. Nếu tài liệu của bạn ghi “Hạn mức là 500$” nhưng LLM lại nói “Hạn mức là 5.000$”, điểm faithfulness của bạn sẽ giảm xuống gần bằng 0. Đây là công cụ tốt nhất để phát hiện các lỗi ảo tưởng (hallucinations).
- Answer Relevancy (Sự liên quan của câu trả lời): Chỉ số này kiểm tra xem phản hồi có thực sự giải quyết được vấn đề của người dùng hay không. Nó bỏ qua các thông tin rườm rà và trừ điểm những câu trả lời đúng về mặt kỹ thuật nhưng lại đi chệch khỏi trọng tâm của truy vấn.
- Context Recall (Khả năng truy xuất ngữ cảnh): Chỉ số này đánh giá retriever (bộ truy xuất) của bạn. Nó kiểm tra xem công cụ tìm kiếm có thực sự tìm thấy thông tin cụ thể cần thiết để trả lời câu hỏi hay không, bằng cách so sánh kết quả với một “Ground Truth” (Sự thật hiển nhiên) đã được con người xác minh.
Thiết lập môi trường
Bạn sẽ cần một môi trường Python và API key từ một nhà cung cấp LLM. Vì RAGAS sử dụng một LLM để chấm điểm hệ thống của bạn, việc chạy đánh giá trên 100 truy vấn thường tốn khoảng 0,50$ đến 2,00$ tùy thuộc vào model bạn chọn. Đây là một cái giá nhỏ để đổi lấy quy trình QA tự động.
Cài đặt các gói cần thiết để bắt đầu:
pip install ragas datasets openai langchainCấu hình các biến môi trường. Sử dụng file .env là cách tốt nhất, nhưng để kiểm tra nhanh, bạn có thể thiết lập chúng ngay trong script:
import os
os.environ["OPENAI_API_KEY"] = "nhập-api-key-của-bạn-tại-đây"Xây dựng bộ dữ liệu đánh giá
RAGAS không nằm trong code ứng dụng thực tế của bạn. Thay vào đó, bạn cung cấp cho nó một bộ dữ liệu gồm các đầu ra gần đây của hệ thống. Để có được báo cáo đầy đủ, bạn cần sắp xếp dữ liệu của mình thành bốn cột cụ thể.
- Question: Câu hỏi gốc của người dùng.
- Answer: Văn bản được tạo ra bởi quy trình RAG của bạn.
- Contexts: Các đoạn văn bản cụ thể mà retriever đã lấy ra từ cơ sở dữ liệu.
- Ground Truth: Câu trả lời lý tưởng do con người viết, được sử dụng làm chuẩn đối sánh.
Dưới đây là cách cấu trúc dữ liệu bằng thư viện datasets:
from datasets import Dataset
data_samples = {
'question': ['Chính sách đổi trả cho đồ điện tử là gì?'],
'answer': ['Bạn có thể đổi trả đồ điện tử trong vòng 30 ngày.'],
'contexts': [['Chính sách của chúng tôi cho phép đổi trả đồ điện tử trong vòng 30 ngày nếu có hóa đơn.']],
'ground_truth': ['Đồ điện tử phải được đổi trả trong vòng 30 ngày và cần có hóa đơn.']
}
dataset = Dataset.from_dict(data_samples)Chạy đánh giá
Khi dữ liệu đã sẵn sàng, bạn có thể kích hoạt quá trình đánh giá. Tôi thường chạy các bài kiểm tra này theo đợt mỗi khi thay đổi một tham số truy xuất, chẳng hạn như chuyển từ tìm kiếm vector cơ bản sang Hybrid Search với BM25.
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
# Chạy quy trình chấm điểm
results = evaluate(
dataset,
metrics=[faithfulness, answer_relevancy, context_recall],
)
df = results.to_pandas()
print(df)Kết quả đầu ra cung cấp một điểm số từ 0 đến 1 cho mỗi danh mục. Điểm Faithfulness là 0,95 là mức xuất sắc. Nếu bạn thấy điểm 0,40, có khả năng LLM đang phớt lờ các tài liệu được cung cấp và thay vào đó dựa vào dữ liệu đào tạo nội bộ của chính nó.
Biến điểm số thành hành động
Giá trị thực sự của RAGAS nằm ở khả năng chẩn đoán. Nếu Context Recall thấp nhưng Faithfulness cao, nghĩa là LLM của bạn đang trung thực, nhưng công cụ tìm kiếm của bạn đang thất bại. Bạn có thể cần cải thiện chiến lược chia nhỏ văn bản (chunking) hoặc nâng cấp embedding model từ text-embedding-3-small lên 3-large.
Ngược lại, nếu Answer Relevancy thấp, retriever đã tìm đúng dữ liệu nhưng LLM lại bị lạc đề. Trong trường hợp này, tôi thường đơn giản hóa system prompt hoặc sử dụng một model mạnh mẽ hơn như GPT-4o cho bước tạo câu trả lời cuối cùng.
Mở rộng với các model chạy local
Nếu bạn lo lắng về chi phí khi đánh giá hàng ngàn dòng dữ liệu, bạn có thể chuyển trình đánh giá sang một model chạy local bằng Ollama. Điều này cho phép bạn chạy các bài kiểm tra hiệu năng (benchmark) khổng lồ tại máy cục bộ mà không cần gửi dữ liệu đến API bên ngoài.
from langchain_openai import ChatOpenAI
from ragas.metrics import faithfulness
# Sử dụng một model hiệu suất cao cụ thể để chấm điểm
faithfulness.llm = ChatOpenAI(model="gpt-4o")Việc tiêu chuẩn hóa các chỉ số này đã thay đổi cách tôi phát triển AI. Thay vì phỏng đoán, giờ đây tôi có thể chứng minh rằng một thay đổi nhỏ trong prompt đã giúp tăng độ chính xác thêm 12%. Hãy bắt đầu bằng cách tạo một “Golden Dataset” gồm 20 câu hỏi chất lượng cao. Chạy RAGAS mỗi khi bạn chạm vào code, và bạn sẽ phát hiện ra các lỗi suy giảm hiệu năng (regressions) trước khi người dùng của bạn nhận thấy.
