Khi AI Đánh Giá Chính Nó: Lợi Bất Cập Hại

Hãy tưởng tượng bạn đang phát triển một hệ thống AI dựa trên Mô hình Ngôn ngữ Lớn (LLM). Bạn hào hứng với những gì nó có thể làm, từ trả lời câu hỏi đến sáng tạo nội dung. Nhưng có một vấn đề: làm sao để biết kết quả trả về là “đúng”? Đừng vội trả lời. Hầu hết các team phát triển hiện nay chỉ dựa vào… cảm giác. Đúng vậy, họ đọc qua kết quả, cảm nhận xem “có vẻ đúng”, và tiếp tục. Nhưng bạn có biết, cách làm này không hề bền vững khi bạn muốn scale hệ thống?

Vấn đề lớn nhất không phải là các mô hình LLM "bịa chuyện" (hallucination), mà là chúng bịa với sự tự tin cao. Một câu trả lời nghe có vẻ hợp lý, nhưng thực ra lại sai hoàn toàn, có thể đánh lừa cả người kiểm tra. Và đây chính là lý do tôi bắt đầu xây dựng một hệ thống đánh giá hoàn toàn mới.

Tại Sao Một Số Kết Quả "Sai Nhưng Nghe Đúng" Vẫn Qua Mặt Được?

Hãy cùng xem xét một ví dụ thực tế. Bạn thêm một dòng prompt vào hệ thống của mình: "Hãy chi tiết và cụ thể." Và kết quả? Một câu trả lời như sau:

"Kỹ thuật 'context engineering' được phát minh tại MIT vào năm 1987, chuyên dùng để tối ưu bộ nhớ cache trong CPU. Nó không liên quan gì đến mô hình ngôn ngữ."

Thoạt nhìn, câu trả lời thật chi tiết, đầy đủ và có vẻ rất đáng tin. Nhưng thực tế? Mọi thông tin trong đó đều sai, từ năm 1987 cho đến ứng dụng của 'context engineering'. Điểm đánh giá của hệ thống? 0.525 — cao hơn ngưỡng chấp nhận 0.5. Điều này nghĩa là gì? Nghĩa là hệ thống đã "bật đèn xanh" cho một câu trả lời hoàn toàn bịa đặt, chỉ vì nó "cụ thể" hơn bình thường.

Vấn đề nằm ở đâu? Trong cách đánh giá. Một số hệ thống hiện tại dùng duy nhất một điểm số để đánh giá cả hai khía cạnh: tính đúng đắn (faithfulness) và độ chi tiết (specificity). Nhưng khi bạn gộp hai yếu tố này làm một, bạn sẽ bỏ qua những lỗi tinh vi. Và đây là lúc tôi nhận ra, chúng ta cần một lớp đánh giá khác biệt.

Xây Dựng Lớp Đánh Giá: Từ Ý Tưởng Đến Thực Tế

Tách Bạch Faithfulness và Specificity

Đầu tiên, tôi quyết định chia nhỏ vấn đề. Thay vì đánh giá toàn bộ câu trả lời bằng một điểm số chung, tôi tạo ra hai tín hiệu riêng biệt:

- Faithfulness (Độ trung thực): Mức độ mà câu trả lời bám sát vào nguồn dữ liệu hoặc ngữ cảnh ban đầu.
- Specificity (Độ chi tiết): Mức độ mà câu trả lời đi sâu vào chi tiết cụ thể.

Điều này giúp tôi phát hiện ra các trường hợp "cụ thể nhưng sai" — dấu hiệu điển hình của hiện tượng hallucination. Khi điểm specificity cao nhưng điểm faithfulness thấp, đó là lúc bạn biết mình đang gặp vấn đề.

Triển Khai Trong Python

Để hiện thực hóa ý tưởng, tôi đã xây dựng một hệ thống đánh giá nhẹ nhàng bằng Python. Dưới đây là một đoạn mã ví dụ minh họa cách tôi tính hai điểm số này:

```python
from sklearn.metrics import accuracy_score

Giả sử chúng ta có output và context

output = "Context engineering was invented at MIT in 1987."
context = "No data supports the claim about context engineering in 1987."

Hàm tính điểm faithfulness

def calculate_faithfulness(output, context):
# Đơn giản hóa: so sánh sự khớp giữa output và context
return 1.0 if output in context else 0.0

Hàm tính điểm specificity

def calculate_specificity(output):
# Đánh giá mức độ chi tiết bằng độ dài câu trả lời
return len(output.split()) / 20 # Giả định 20 từ là ngưỡng tối ưu

faithfulness_score = calculate_faithfulness(output, context)
specificity_score = calculate_specificity(output)

print(f"Faithfulness: {faithfulness_score}, Specificity: {specificity_score}")
```

Đây là một cách tiếp cận đơn giản, nhưng nó đã giúp tôi xác định rõ ràng hơn các vấn đề mà trước đây thường bị bỏ qua.

Từ Đánh Giá Đến Quyết Định

Sau khi có hai tín hiệu, bước tiếp theo là tạo ra một engine ra quyết định. Bạn không thể chỉ dựa vào điểm số để làm "đẹp lòng" người dùng. Một số quy tắc logic cần được áp dụng, chẳng hạn:

- Nếu faithfulness < 0.5, từ chối luôn câu trả lời.
- Nếu specificity > 0.8 và faithfulness < 0.5, gắn cờ "nguy hiểm" vì khả năng cao là hallucination.
- Nếu cả hai điểm số đều cao, bật đèn xanh.

Điều này biến lớp đánh giá từ một công cụ "chấm điểm" thành một engine thực sự, giúp bạn quyết định câu trả lời nào nên được gửi đến người dùng và câu nào cần bị loại bỏ.

So Sánh Với Các Phương Pháp Khác

Hệ thống của tôi không phải là cách duy nhất. Một số team chọn cách sử dụng một LLM thứ hai để đánh giá LLM đầu tiên. Nghe có vẻ hợp lý, nhưng nếu bạn không kiểm soát được LLM đánh giá, bạn chỉ đang "đẩy vấn đề lên một tầng khác". Những cách khác, như kiểm tra thủ công hoặc dựa vào feedback từ người dùng, cũng có hạn chế lớn về quy mô và tính nhất quán.

Điểm mạnh của hệ thống tôi xây dựng là tính nhẹ nhàng, dễ dàng tích hợp và không phụ thuộc vào các mô hình AI khác để hoạt động.

Góc Nhìn Cá Nhân: Chúng Ta Đang Đi Đúng Hướng?

LLM là một công nghệ đầy tiềm năng, nhưng việc sử dụng nó một cách bừa bãi có thể dẫn đến những hậu quả khó lường. Việc các team phát triển quá phụ thuộc vào "cảm giác" khi đánh giá chất lượng đầu ra không chỉ là một sai lầm kỹ thuật, mà còn là một rủi ro kinh doanh. Chúng ta không thể mãi dựa vào sự may mắn để phát hiện lỗi.

Hệ thống đánh giá mà tôi xây dựng không phải là giải pháp hoàn hảo, nhưng nó là một bước tiến trong việc biến quá trình kiểm tra chất lượng LLM trở nên minh bạch, nhất quán và có thể mở rộng. Nếu bạn cũng đang đối mặt với những vấn đề tương tự, tại sao không thử xây dựng lớp đánh giá của riêng mình? Tin tôi đi, bạn sẽ không muốn làm việc với một hệ thống mà mọi quyết định đều dựa trên "vibes" đâu.