Đánh giá hệ LLM/RAG: test thuộc tính, groundedness, hallucination, LLM-as-judge (2026)

1. Bối cảnh: vì sao không thể test LLM như test hàm thuần

Khi kiểm thử một hàm thuần, bạn cho input và so sánh output với một giá trị mong đợi chính xác. Với một hệ LLM hay RAG (検索拡張生成 / retrieval-augmented generation), cách đó sụp đổ ngay lập tức. Cùng một câu hỏi, mô hình có thể trả lời bằng nhiều cách diễn đạt khác nhau, thay đổi theo phiên bản, thậm chí theo nhiệt độ lấy mẫu. Nếu bạn viết assertion 'output phải bằng đúng chuỗi này', test sẽ đỏ liên tục dù câu trả lời hoàn toàn đúng về nội dung. Đây là bản chất phi tất định (non-deterministic) mà mọi người kiểm thử LLM phải chấp nhận từ đầu.

Lối thoát là chuyển từ kiểm chuỗi chính xác sang kiểm thuộc tính (property). Thay vì hỏi 'câu trả lời có đúng bằng chuỗi X không', ta hỏi những câu như: câu trả lời có neo vào tài liệu được truy xuất không (groundedness), có trả lời đúng câu hỏi không (relevance), có bịa thông tin không (hallucination), có chứa dữ liệu nhạy cảm hay lời lẽ độc hại không (safety). Mỗi thuộc tính là một chiều đánh giá riêng, và một hệ đáng tin phải đạt ngưỡng trên nhiều chiều đồng thời chứ không chỉ 'nghe có vẻ hợp lý'.

2. Test thuộc tính thay vì chuỗi chính xác

Kiểm thuộc tính nghĩa là định nghĩa những bất biến mà câu trả lời đúng phải thỏa, bất kể diễn đạt cụ thể. Ví dụ với một trợ lý hỏi đáp tài liệu nội bộ, một số bất biến có thể là: câu trả lời phải chứa con số chính sách đúng (ví dụ '15 ngày nghỉ phép'), không được nêu con số không có trong tài liệu, phải trích dẫn đúng nguồn, và phải từ chối lịch sự khi câu hỏi nằm ngoài phạm vi tài liệu. Những bất biến này ổn định qua các cách diễn đạt, nên chúng là nền vững chắc cho assertion trong khi chuỗi chính xác thì không.

Cần phân biệt hai loại kiểm tra. Kiểm tra xác định (deterministic checks) là những assertion cứng có thể chạy bằng code thường: câu trả lời có chứa con số bắt buộc không, có trích dẫn nguồn nào không, độ dài có nằm trong giới hạn không, có rò rỉ chuỗi cấm không. Kiểm tra ngữ nghĩa (semantic checks) cần đến một bộ chấm điểm, thường là một mô hình khác đóng vai giám khảo, để đánh giá những chiều mờ như 'câu trả lời có thực sự đúng trọng tâm không'. Một bộ eval tốt kết hợp cả hai: chạy kiểm tra cứng trước để bắt lỗi rõ ràng và rẻ, rồi mới dùng giám khảo tốn kém cho phần ngữ nghĩa.

// Test thuộc tính: assertion cứng + kiểm ngữ nghĩa, KHÔNG so chuỗi chính xác
import { test, expect } from '@playwright/test';
import { ask } from '../src/ragClient';
import { judge } from './llmJudge';

test('trả lời chính sách nghỉ phép: đúng số, có nguồn, không bịa', async () => {
  const { answer, citations } = await ask('Tôi được nghỉ phép bao nhiêu ngày?');

  // 1) Kiểm tra XÁC ĐỊNH (rẻ, chạy trước)
  expect(answer).toMatch(/15\s*ngày/);                 // con số bắt buộc từ tài liệu
  expect(citations).toContainEqual(expect.objectContaining({ docId: 'HR-LEAVE-2026' }));
  expect(answer).not.toMatch(/\b(20|25)\s*ngày/);     // không nêu số sai

  // 2) Kiểm tra NGỮ NGHĨA (giám khảo, tốn hơn — chạy sau)
  const g = await judge({ question: 'số ngày nghỉ phép', answer, contexts: citations });
  expect(g.groundedness).toBeGreaterThanOrEqual(0.8);  // neo vào tài liệu
  expect(g.relevance).toBeGreaterThanOrEqual(0.8);     // đúng trọng tâm
});

3. Groundedness và faithfulness: câu trả lời có neo vào ngữ cảnh không

Groundedness, hay tính trung thực với ngữ cảnh (faithfulness), là câu hỏi trung tâm của một hệ RAG: mọi khẳng định trong câu trả lời có được hỗ trợ bởi các đoạn tài liệu đã truy xuất không, hay mô hình tự thêm thắt thông tin không có nguồn. Một hệ RAG có thể truy xuất đúng tài liệu nhưng vẫn sinh câu trả lời chứa chi tiết bịa đặt, và đó chính là loại lỗi nguy hiểm nhất vì nó trông rất đáng tin. Đo groundedness nghĩa là tách câu trả lời thành từng khẳng định nhỏ rồi kiểm mỗi khẳng định có tìm được chỗ dựa trong ngữ cảnh hay không.

Trong thực hành, groundedness thường được chấm bằng một mô hình giám khảo nhận vào ba thứ: câu hỏi, câu trả lời, và các đoạn ngữ cảnh, rồi trả về tỉ lệ khẳng định được hỗ trợ. Điểm cần cẩn trọng là phân biệt groundedness với tính đúng đắn tuyệt đối. Một câu trả lời có thể grounded hoàn hảo vào tài liệu nhưng tài liệu đó lại lỗi thời hoặc sai. Vì thế groundedness kiểm 'mô hình có trung thành với nguồn không', còn tính đúng đắn của chính nguồn là một lớp kiểm khác thuộc về chất lượng dữ liệu.

// Chấm groundedness bằng cách tách khẳng định và kiểm từng cái
export async function scoreGroundedness(answer: string, contexts: string[]) {
  const claims = await extractClaims(answer);   // tách thành các khẳng định nhỏ
  let supported = 0;
  for (const c of claims) {
    const ok = await isSupported(c, contexts);   // giám khảo: có chỗ dựa trong ngữ cảnh?
    if (ok) supported++;
  }
  return {
    groundedness: claims.length ? supported / claims.length : 1,
    unsupportedClaims: claims.length - supported,   // > 0 ⇒ có khả năng hallucination
  };
}
// Bất biến eval: groundedness >= 0.8 VÀ unsupportedClaims === 0 cho câu hỏi trong phạm vi

4. Answer relevance và context precision/recall

Answer relevance đo mức câu trả lời thực sự bám vào câu hỏi, không lan man hay né tránh. Một mô hình có thể trả lời trung thực với ngữ cảnh nhưng lại trả lời lệch câu hỏi, kiểu người dùng hỏi thời hạn nộp thuế mà nó lại giải thích cách tính thuế. Relevance thấp báo hiệu hoặc mô hình hiểu sai ý định, hoặc ngữ cảnh truy xuất về không chứa thứ cần thiết nên mô hình nói vòng vo. Đo relevance giúp tách nhóm lỗi 'đúng nhưng lạc đề' vốn dễ bị bỏ qua khi chỉ nhìn groundedness.