Context evaluation là gì? Cách đo chất lượng ngữ cảnh cho AI

Context evaluation (đánh giá ngữ cảnh) là quá trình định lượng độ chính xác, độ liên quan và tính đầy đủ của các mẩu thông tin (context) được truy xuất để cung cấp cho mô hình ngôn ngữ lớn (Large Language Model - LLM).

Thay vì chỉ soi câu trả lời cuối cùng, bạn quay ngược lên đo chất lượng "nguyên liệu đầu vào", để LLM có đủ dữ kiện để xử lý, thay vì rơi vào cảnh đoán mò.

Về bản chất, đây là kỹ thuật cô lập và kiểm soát nhiễu trong hệ thống RAG (Retrieval-Augmented Generation). Nếu ngữ cảnh không đạt chuẩn, LLM sẽ tự lấp đầy khoảng trống bằng các ảo giác (hallucination) hoặc bằng kiến thức nội tại đã lỗi thời. Làm context evaluation cho nghiêm, bạn mới chỉ ra được đúng chỗ pipeline gãy: gãy ở khâu tìm kiếm dữ liệu, hay gãy ở khâu suy luận của mô hình.

Đánh giá ngữ cảnh không phải một bài kiểm tra "có/không" đơn thuần, mà là phép đo xem mỗi token bạn đưa vào prompt có thực sự đáng chỗ nó chiếm hay không.

Sơ đồ minh hoạ việc đo chất lượng ngữ cảnh trước khi khối thông tin đó được nạp vào mô hình ngôn ngữ lớn

Context evaluation là gì?

Context engineering rốt cuộc là bài toán tối ưu attention budget (ngân sách chú ý). Nhồi hàng triệu token vào prompt là cách tiêu tiền, không phải cách giải bài toán; thứ bạn cần là tập token nhỏ nhất nhưng có tín hiệu cao nhất (high-signal), sao cho tỷ lệ tín hiệu trên nhiễu đủ tốt để mô hình bám vào đúng dữ kiện cần thiết.

Các benchmark truyền thống như Needle In A Haystack (NIAH, tức giấu một câu thông tin giữa đống văn bản dài rồi bắt mô hình tìm lại) đến giờ đã lộ rõ giới hạn của chúng. NIAH thực chất chỉ đo khả năng khớp từ vựng (lexical matching) ở mức sơ khai, trong khi hệ thống AI ngoài đời phải hiểu được ngữ nghĩa (semantic understanding) mới nối nổi các thông tin nằm rải rác. Một mô hình có thể tìm thấy "cây kim" khi từ khóa trùng khớp hoàn toàn, nhưng nó thua ngay nếu câu hỏi đòi hỏi suy luận dựa trên những khái niệm tương đương.

Một tiêu chuẩn khắt khe hơn là Gold Context. Đây không phải một tập tài liệu mẫu gom đại, mà là tập hợp các artifact (mẩu tin, đoạn code) tối thiểu nhưng đủ để giải quyết một yêu cầu cụ thể. Vì vậy quy trình xây Gold Context tốn công thấy rõ: chuyên gia phải dán nhãn thủ công, rồi còn thêm một bước kiểm chứng là mô hình phải giải được bài toán khi chỉ được cung cấp đúng tập ngữ cảnh đó. Tốn công thật, nhưng tôi chưa thấy con đường nào vừa rẻ hơn vừa cho ra một thước đo đáng tin.

Bạn cũng cần phân biệt rõ giữa việc AI "có thấy" dữ liệu (retrieval) và AI "dùng được" dữ liệu (utilization). Nhiều hệ thống đạt recall cao nhưng vẫn hỏng, vì ngữ cảnh nhiễu tới mức LLM không trích nổi thông tin quan trọng ra khỏi đống đó. Đo lường chất lượng ngữ cảnh chính là để thu hẹp khoảng cách giữa hai chuyện ấy.

Vì sao một pipeline ngữ cảnh hoàn chỉnh vẫn nuôi mô hình bằng tài liệu tồi?

Lỗi hệ thống RAG thường bắt nguồn từ tầng hạ tầng dữ liệu. Ngay cả khi các metric tìm kiếm như precision và recall đạt điểm gần tuyệt đối, kết quả vẫn sai nếu dữ liệu gốc đã lỗi thời hoặc không đồng nhất. Không một metric nào ở tầng truy xuất cứu nổi một kho tài liệu đã hỏng từ gốc.

Bốn chiều chất lượng của kho tài liệu trước khi vào vector database: freshness, ownership, lineage và canonical alignment

Quản trị tầng dữ liệu thô trước khi đưa vào vector database cần dựa trên bốn chiều chất lượng. Freshness (độ tươi) hỏi dữ liệu có phản ánh đúng trạng thái mới nhất hay không. Ownership (quyền sở hữu) xác định ai chịu trách nhiệm xác thực tính đúng đắn của tài liệu. Lineage (nguồn gốc) theo dõi dòng chảy dữ liệu từ nguồn thô đến vector database xem có bị biến đổi sai lệch không. Còn canonical alignment (đồng bộ chuẩn mực) kiểm tra tài liệu có tuân thủ quy chuẩn chung của tổ chức hay không, bởi nếu mỗi phòng ban dùng một bộ thuật ngữ khác nhau, embedding model (mô hình chuyển văn bản thành vector) sẽ không xếp chúng vào cùng một vùng không gian vector.

Tài liệu rác và các phiên bản trùng lặp, chẳng hạn file PDF hướng dẫn năm 2022 nằm cạnh bản 2024 trong cùng một chỉ mục (index), tạo ra nhiễu tín hiệu rất lớn. Khi retriever lấy ra cả hai, LLM nhận về hai dữ kiện mâu thuẫn mà không có cơ sở nào để chọn. Quản trị dữ liệu kém, nói gọn lại, là bạn đang tự động hóa việc tạo ra sai số ở quy mô lớn.

Lỗi truy xuất và lỗi sinh câu trả lời: đo tách ra ở đâu?

Để sửa một hệ thống RAG hỏng, trước hết bạn phải biết nó hỏng ở khâu "tìm" hay khâu "viết". Vì vậy hãy tách bạch hai thành phần: retriever (bộ truy xuất) và generator (bộ sinh), mỗi bên có bộ metric và bộ tham số riêng.

Pipeline RAG tách làm hai nửa retriever và generator, mỗi nửa có nhóm metric đo riêng

Nhóm metric của retriever trỏ thẳng vào tham số hệ thống, và đó là điểm dễ chịu nhất của nhóm này. Contextual recall đo xem ngữ cảnh lấy về có chứa đủ dữ kiện cần thiết không; khi nó thấp, thủ phạm thường là embedding model. Contextual precision đo xem các chunk (mẩu văn bản cắt nhỏ từ tài liệu) liên quan có được xếp lên trên các chunk không liên quan hay không; khi nó thấp, reranker (bộ xếp hạng lại) là chỗ cần chỉnh. Contextual relevancy phản ánh mức độ ngữ cảnh bám sát truy vấn, và nó gắn với kích thước chunk cùng giá trị top-K.

Nhóm metric của generator đánh giá phần mô hình làm với ngữ cảnh đã nhận. Faithfulness đo câu trả lời có trung thành với ngữ cảnh không; điểm thấp nghĩa là mô hình đang bịa thêm ngoài dữ liệu được cấp. Answer relevancy đo câu trả lời có đúng ý người dùng không, và nó phản ánh chất lượng prompt template.

Quy tắc cô lập lỗi vì thế rất gọn: ngữ cảnh sai thì sửa retriever (chunk size, top-K, embedding model, reranker); ngữ cảnh đúng mà output vẫn sai thì sửa generator (prompt template, mô hình). Và chất lượng của cả pipeline là một phép nhân chứ không phải phép cộng, nên chỉ cần một trong hai khâu hỏng hẳn, chất lượng đầu ra rơi thẳng về không.

Context precision và context recall: xếp hạng đúng hay lấy đủ?

Đây là hai metric nền tảng, và chúng đo hai thứ khác nhau. Context precision đo khả năng xếp các chunk liên quan lên đầu danh sách: nó là trung bình của precision@k tại từng vị trí, nên nếu thông tin quan trọng nhất nằm ở chunk thứ mười, điểm sẽ bị kéo xuống rất thấp dù thông tin đó vẫn có mặt đầy đủ. Context recall đo mức độ đầy đủ: hệ thống chia nhỏ câu trả lời tham chiếu thành các claim (mệnh đề khẳng định) rồi kiểm tra từng claim có được ngữ cảnh đã truy xuất hỗ trợ hay không.

So sánh context precision đo việc xếp hạng đúng với context recall đo mức độ lấy đủ thông tin

Sự khác biệt đó quyết định cách bạn đọc điểm số, và đây là chỗ tôi thấy người ta đọc nhầm nhiều nhất. Recall thấp nghĩa là thông tin cần thiết chưa bao giờ được lấy về, và không một reranker nào cứu được điều đó. Precision thấp lại là chuyện khác: thông tin có mặt nhưng bị chôn dưới nhiễu, và đây là lỗi xếp hạng chứ không phải lỗi tìm kiếm. Hai chẩn đoán đó dẫn tới hai việc sửa hoàn toàn khác nhau, nên đọc nhầm một cái là bạn mất cả tuần chỉnh nhầm chỗ.

Cả hai metric đều có biến thể không cần LLM: một bản so khớp chuỗi dựa trên reference_contexts, và một bản so khớp theo ID dựa trên retrieved_context_ids. Biến thể ID rẻ và tất định, nên nó hợp cho hệ thống lớn cần chạy đánh giá liên tục mà không muốn trả tiền cho một lượt gọi LLM trên mỗi mẫu.

python

from ragas.metrics.collections import ContextRecall
 
scorer_recall = ContextRecall(llm=evaluator_llm)
 
result = await scorer_recall.ascore(
    user_input="Hợp đồng bảo hiểm X bao gồm những gì?",
    retrieved_contexts=["Hợp đồng X bao gồm điều khoản nội trú."],
    reference="Hợp đồng X bao gồm điều khoản nội trú và ngoại trú.",
)

Thực tế luôn tồn tại một đánh đổi không mẹo nào né được: lấy dư để khỏi bỏ sót ý sẽ nâng recall, nhưng nếu precision tụt quá thấp thì tín hiệu bị loãng và mô hình dễ lạc lối giữa những thông tin không liên quan.

Chấm điểm tự động bằng LLM-as-judge và chỗ không nên tin nó

Mô hình RAG Triad là bộ khung triển khai nhanh nhất cho việc chấm điểm tự động, gồm ba phép kiểm tách rời nhau. Context relevance hỏi ngữ cảnh lấy về có liên quan đến truy vấn không. Groundedness tách câu trả lời thành từng claim rồi truy ngược xem mỗi claim có bằng chứng trong ngữ cảnh hay không. Answer relevance hỏi câu trả lời cuối cùng có thực sự phục vụ ý định người dùng hay không. Ba phép kiểm này chạy bằng feedback function, tức một LLM được prompt cẩn thận đóng vai trọng tài, nên bạn chấm được ở quy mô lớn ngay cả khi chưa có bộ đáp án chuẩn (ground truth) đầy đủ.

Ba phép kiểm tách rời của RAG Triad: context relevance, groundedness và answer relevance

Khổ nỗi, chính cơ chế đó cũng là chỗ yếu nhất của nó. Trọng tài ở đây là một mô hình ngôn ngữ, nên nó dính đúng những thiên lệch mà nó đang đo: một câu trả lời trôi chảy, tự tin và đúng văn phong dễ được chấm cao hơn một câu trả lời đúng nhưng cụt lủn. Điểm số vì thế là tín hiệu, không phải sự thật.

Cách dùng lành mạnh là coi trọng tài như một bộ lọc chứ không phải quan tòa. Hãy định kỳ đối chiếu điểm máy chấm với nhãn do người thật gán trên một mẫu nhỏ, và chạy lại việc đối chiếu đó mỗi khi bạn đổi mô hình trọng tài hoặc sửa prompt chấm điểm, vì đó là hai thay đổi âm thầm làm trôi cả thang điểm của bạn mà không báo lỗi ở đâu cả.

Nhiễu, tài liệu lỗi thời và context rot: khi thêm ngữ cảnh lại làm hại

Thử nghiệm context rot (hiện tượng chất lượng suy giảm khi ngữ cảnh dài ra) chạy trên 18 mô hình hàng đầu, trong đó có GPT-4.1, Claude 4, Gemini 2.5 và Qwen3, cho thấy một nghịch lý: hiệu suất giảm không đồng đều khi độ dài đầu vào tăng, ngay cả với những tác vụ đơn giản như truy xuất hay chép lại văn bản. Mô hình không xử lý token thứ 10.000 đáng tin như token thứ 100.

Độ tin cậy của mô hình giảm dần khi ngữ cảnh dài thêm và các đoạn gây nhiễu chen vào giữa

Distractor (yếu tố gây nhiễu) là nguyên nhân chính. Đây là những đoạn văn bản liên quan về mặt chủ đề với câu hỏi nhưng lại không trả lời được câu hỏi đó. Chỉ một distractor đã đủ làm giảm độ chính xác, và càng nhiều distractor thì mức giảm càng cộng dồn. Độ tương đồng ngữ nghĩa giữa câu hỏi và "cây kim" cũng quan trọng không kém: tương đồng càng thấp thì hiệu suất càng tụt nhanh khi ngữ cảnh dài ra.

Có một phát hiện phản trực giác tôi phải đọc lại hai lần mới tin: haystack (đống văn bản nền) bị xáo trộn ngẫu nhiên đôi khi cho kết quả tốt hơn haystack có cấu trúc logic mạch lạc. Lý do là một mạch văn liền lạc tạo ra "cạnh tranh ngữ nghĩa", nghĩa là các ý xung quanh đủ giống nhau để che khuất chính thông tin bạn cần. Kết luận rút ra cho kỹ sư vì thế rất thẳng: hãy ưu tiên lọc nhiễu thay vì mở rộng cửa sổ ngữ cảnh, bởi nới cửa sổ ngữ cảnh không xóa được bài toán chọn bằng chứng.

Vì sao vẫn phải tự đọc output: error analysis và bảng phân loại lỗi

Metric tự động chỉ là lớp vỏ. Bạn không thể tối ưu một hệ thống nếu chưa trực tiếp đọc các trace, tức nhật ký đầy đủ của một lượt chạy, gồm cả những gì mô hình đã lấy về lẫn những gì nó đã viết ra. Đây là hoạt động quan trọng nhất của việc đánh giá, vì chính nó quyết định bạn nên viết eval nào ngay từ đầu, thay vì đi chép một bộ metric chung chung của người khác về dùng lại.

Quy trình đọc lỗi thủ công: đọc trace, open coding, axial coding rồi dựng bảng phân loại lỗi

Quy trình gồm ba bước. Trước hết là đọc trace và open coding: ghi chú tự do bằng ngôn ngữ của chính bạn về mọi vấn đề quan sát được, tập trung vào lỗi đầu tiên trong mỗi trace vì các lỗi phía sau thường chỉ là hệ quả dây chuyền của nó. Sau đó là axial coding: gom các ghi chú giống nhau thành từng nhóm để dựng nên một bảng phân loại lỗi (error taxonomy) của riêng dự án, rồi đếm số lần xuất hiện của mỗi nhóm. Bước gom nhóm này là bước quan trọng nhất trong cả quy trình, và cũng là bước hay bị làm cho có nhất.

Bạn dừng lại khi đạt bão hòa, tức khi các trace mới không còn sinh ra nhóm lỗi mới nào nữa. Con số kinh nghiệm là đọc ít nhất 100 trace để bắt đầu, và nếu khoảng 20 trace liên tiếp không sinh thêm nhóm lỗi nào thì bạn có thể dừng. Một bảng error taxonomy thực chiến thường gồm những nhãn như Missing_Information (dữ liệu không tồn tại trong database), Outdated_Source (lấy nhầm phiên bản tài liệu cũ), Reasoning_Failure (ngữ cảnh đúng nhưng mô hình suy luận sai) và Extraction_Failure (thông tin có trong ngữ cảnh nhưng mô hình không tìm thấy vì nhiễu). Điểm mấu chốt là những nhãn này phải sinh ra từ chính dữ liệu của bạn, chứ không phải chép từ một danh sách có sẵn.

Nên bắt đầu đo từ đâu?

Đừng sa đà tối ưu engine tìm kiếm hay đổi mô hình liên tục khi bạn còn chưa có lấy một thước đo cho chất lượng ngữ cảnh đầu vào. Hãy chọn khoảng 50 câu hỏi neo quan trọng nhất với sản phẩm của bạn, tự tay soạn Gold Context cho chúng, và coi bộ đó như unit test cho dữ liệu.

Giá trị của bộ này nằm ở chỗ nó biến một thay đổi mơ hồ thành một tín hiệu đọc được: nếu bạn đổi thuật toán chunking hoặc thay embedding model mà recall trên bộ câu hỏi neo tụt xuống, hệ thống đang đi lùi — và bạn biết điều đó trước khi người dùng biết.