§ blog · Data Analytics16/10/2026
← Tất cả bài viết

Điểm benchmark không phải điểm của bạn: tự dựng bộ đánh giá để chọn mô hình AI — và cần bao nhiêu câu hỏi

Mỗi tuần lại có một mô hình AI mới tuyên bố đứng đầu một bảng điểm nào đó. Nhưng bảng điểm đo việc của người khác, và hai bảng lớn nhất hiện nay còn không đồng ý với nhau. Cách duy nhất để biết mô hình nào tốt cho việc của bạn là tự đo. Bài này chỉ cách dựng một bộ đánh giá từ dữ liệu thật, và trả lời bằng mô phỏng một câu hỏi ít ai tính: với hai mô hình chênh nhau 6 điểm phần trăm, 30 câu hỏi chỉ chọn đúng mô hình tốt hơn khoảng 72% số lần — cần khoảng 200 câu để gần như chắc chắn.

Đánh giá mô hình AIBenchmarkĐo lườngThống kêAI11 phút đọc
By KonexForge Engineering Team
HAI MÔ HÌNH CHÊNH 6 ĐIỂM (80% vs 86%) · BAO NHIÊU CÂU THÌ CHỌN ĐÚNG30 câu72% đúng · 15% nhầm50 câu81% đúng · 11% nhầm100 câu91% đúng · 5% nhầm200 câu98% đúng · 2% nhầm300 câu99% đúng · 0% nhầmmô hình tốt hơn thắnghoàchọn nhầm mô hình kém hơnSAI SỐ ĐIỂM ĐO (95%) KHI ĐÚNG ~80%30 câu± 14 điểm100 câu± 8 điểm300 câu± 4,5 điểmCÙNG MÔ HÌNH · CÙNG 30 CÂU · CHẠY LẠI60%80%100%điểm dao động 73% – 87% (95% số lần)→ chạy mỗi câu 3 lầnKHI DÙNG AI CHẤM AI · BA THIÊN LỆCH VÀ CÁCH GIẢMTHIÊN LỆCH VỊ TRÍđảo thứ tự, chấm hai lầnTHIÊN LỆCH ĐỘ DÀItiêu chí cụ thể, viết trướcTỰ ƯU ÁIgiấu tên · chấm bằng họ khác30 CÂUloại mô hình kém rõ · so chi phí~100 CÂUphân biệt chênh vài điểm3 LẦN MỖI CÂUbiết câu nào không ổn địnhcâu hỏi lấy từ nhật ký thật · viết đáp án trước khi nhìn câu trả lờinguồn: mô phỏng KonexForge (20.000 lần) · Zheng et al., NeurIPS 2023konexforge.com

Một tuần giữa tháng 10/2026: Google nói Gemini 4 Argon đứng đầu bảng Vals. Anthropic công bố Claude Haiku 5.5 vượt GPT-6 Luna ở mọi bài đo có số liệu. Alibaba nói Qwen3.8-27B ngang mô hình lớn hơn nhiều lần ở các bài lập trình. Tất cả có thể đều đúng — trên những bài đo mà họ chọn.

Còn bạn thì cần biết một điều đơn giản hơn: mô hình nào trả lời đúng nhiều nhất các câu hỏi mà khách hàng và nhân viên của bạn thật sự hỏi? Không bảng điểm công khai nào trả lời được câu đó. Bài này chỉ cách tự trả lời — và tính xem cần bao nhiêu câu hỏi thì câu trả lời mới đáng tin.

Vì sao bảng điểm công khai không đủ

Một — chúng đo việc của người khác. Một bảng điểm tổng hợp các bài thi toán, lập trình, kiến thức chuyên sâu. Việc của bạn có thể là trả lời khách bằng tiếng Việt về chính sách đổi trả, hay trích số tiền từ hoá đơn chụp bằng điện thoại. Mô hình giỏi toán olympic không chắc giỏi việc đó hơn.

Hai — các bảng không đồng ý với nhau. Trong bài so sánh ba mô hình cùng giá $2/$10, Gemini 4 Argon đứng đầu bảng Vals nhưng kém Claude Opus 5.5 năm điểm trên bảng Artificial Analysis. Không bảng nào sai — chúng đo những thứ khác nhau.

Ba — số do nhà sản xuất công bố được chọn lọc. Mỗi hãng công bố các bài đo mà mô hình của mình làm tốt, thường ở mức suy luận cao nhất — mức đắt nhất mà không phải ai cũng dùng khi chạy thật.

Bốn — câu hỏi có thể đã lọt vào dữ liệu huấn luyện. Các bài đo công khai nằm trên internet nhiều năm. Một mô hình có thể đã "thấy" câu hỏi trong lúc huấn luyện, và điểm cao phản ánh trí nhớ nhiều hơn năng lực. Câu hỏi lấy từ nhật ký nội bộ của bạn thì chắc chắn chưa mô hình nào thấy.

Dựng bộ đánh giá từ dữ liệu thật

Lấy câu hỏi từ nhật ký, không tự nghĩ ra. Câu tự nghĩ thường sạch sẽ và rõ ràng hơn câu thật. Câu thật có lỗi chính tả, viết tắt, hai ý trong một tin, ảnh chụp nghiêng. Trích từ một hai tháng gần nhất: tin nhắn khách, email, tài liệu cần tóm tắt, câu hỏi nhân viên gửi bộ phận hỗ trợ.

Chia theo loại việc và lấy đủ mỗi loại. Ví dụ với một cửa hàng: hỏi giá và tồn kho, đổi trả, khiếu nại, đặt hàng, câu hỏi ngoài phạm vi. Nếu 80% tin nhắn là hỏi giá, bộ đánh giá vẫn cần đủ câu khiếu nại — vì đó là nơi trả lời sai đắt nhất.

Đưa vào ba loại câu khó. Những ca hệ thống hiện tại từng xử lý sai. Những ca mơ hồ mà nhân viên giỏi cũng phải hỏi lại. Và vài câu mà câu trả lời đúng là "không có thông tin" — để biết mô hình nào chịu nói không biết thay vì bịa.

Viết đáp án trước khi chạy. Với câu có đáp án rõ (nhóm tin nhắn, mã đơn hàng, số tiền), ghi đáp án để máy tự so được. Với câu mở (soạn câu trả lời), viết ba bốn tiêu chí cụ thể: có nêu đúng mã đơn không, có xin lỗi khi khách khiếu nại không, có hứa điều công ty không làm không. Viết trước khi xem câu trả lời của bất kỳ mô hình nào — nếu không, tiêu chí sẽ vô tình nghiêng về câu trả lời bạn đọc đầu tiên.

Cần bao nhiêu câu hỏi

Đây là phần ít người tính, và là lý do nhiều cuộc so sánh nội bộ kết luận sai. Chúng tôi mô phỏng tình huống sau: hai mô hình, một mô hình đúng 80% và một đúng 86% trên toàn bộ các câu hỏi có thể gặp — chênh 6 điểm phần trăm, cỡ khoảng cách giữa hạng 2 và hạng 9 trên bảng Vals hiện tại. Hai mô hình có xu hướng cùng sai ở câu khó và cùng đúng ở câu dễ, như ngoài thực tế. Lấy ngẫu nhiên n câu, chấm cả hai, xem mô hình nào điểm cao hơn. Lặp lại hai mươi nghìn lần:

  • 30 câu: mô hình tốt hơn thắng 72% số lần, hoà 13%, và mô hình kém hơn thắng 15%.
  • 50 câu: thắng 81%, kém hơn thắng 11%.
  • 100 câu: thắng 91%, kém hơn thắng 5%.
  • 200 câu: thắng 98%.
  • 300 câu: thắng hơn 99%.

Nói cách khác, với bộ 30 câu, cứ khoảng bảy lần so sánh thì có một lần bạn chọn nhầm mô hình kém hơn mà không biết.

Tin tốt: khi khoảng cách lớn, ít câu là đủ. Với hai mô hình đúng 60% và 85%, 30 câu chọn đúng mô hình tốt hơn hơn 99% số lần. Vì vậy:

  • Khoảng 30 câu: đủ để loại mô hình kém rõ rệt, phát hiện lỗi hệ thống (sai định dạng, không hiểu tiếng Việt địa phương), và so chi phí.
  • Khoảng 100 câu: đủ để phân biệt các mô hình chênh khoảng 6 điểm, đúng chín trên mười lần.
  • Khoảng 200 câu trở lên: khi hai mô hình gần nhau và quyết định quan trọng — ví dụ chọn mô hình cho việc xử lý hợp đồng hằng ngày trong một năm.

Một cách tính nhanh khác: với bộ n câu và tỉ lệ đúng khoảng 80%, sai số của điểm đo được (khoảng tin cậy 95%) là khoảng ± 1,96 × căn(0,8 × 0,2 ÷ n). Với 30 câu là ±14 điểm phần trăm; 100 câu là ±8; 300 câu là ±4,5. Khi hai mô hình chênh nhau ít hơn sai số này, đừng kết luận mô hình nào hơn.

Cùng một mô hình, hai lần chạy, hai điểm khác nhau

Mô hình ngôn ngữ không trả lời giống hệt nhau mỗi lần. Với phần lớn câu hỏi, nó đúng hoặc sai ổn định; nhưng có những câu "lưng chừng" mà lần này đúng, lần sau sai.

Mô phỏng thêm một tình huống: bộ 30 câu, mô hình luôn đúng 21 câu, luôn sai 3 câu, và 6 câu còn lại đúng hay sai như tung đồng xu. Điểm trung bình là 80%. Nhưng chạy lại cùng bộ câu trên cùng mô hình, điểm dao động từ 73% tới 87% trong 95% số lần chạy, và cứ khoảng bảy cặp lần chạy thì có một cặp lệch nhau từ 10 điểm trở lên.

Hệ quả: nếu chạy mỗi mô hình một lần rồi so, một phần chênh lệch có thể chỉ là may rủi. Cách xử lý đơn giản: chạy mỗi câu ba lần, ghi tỉ lệ đạt từng câu. Một câu mà mô hình chỉ đạt 2 trên 3 lần là thông tin quý — trong sản phẩm thật, đó là câu mà một phần ba khách hàng sẽ nhận câu trả lời sai.

Khi dùng AI để chấm AI

Chấm tay 200 câu trả lời mở cho mỗi mô hình rất tốn công. Cách phổ biến là dùng một mô hình mạnh làm người chấm. Cách này dùng được, nhưng có những thiên lệch đã được ghi nhận. Nghiên cứu của Zheng và cộng sự trình bày tại hội nghị NeurIPS 2023, khi xây dựng bộ đánh giá MT-Bench, mô tả ba loại:

  • Thiên lệch vị trí: khi so hai câu trả lời, người chấm AI có xu hướng chọn câu đặt ở vị trí đầu (hoặc sau, tuỳ mô hình) bất kể nội dung.
  • Thiên lệch độ dài: câu trả lời dài hơn thường được chấm cao hơn, kể cả khi không đúng hơn.
  • Tự ưu ái: mô hình chấm có xu hướng chấm cao câu trả lời của chính nó hoặc của mô hình cùng họ.

Cùng nghiên cứu cho thấy khi được dùng cẩn thận, mức đồng ý giữa người chấm AI mạnh và người chấm là người tương đương mức đồng ý giữa hai người với nhau. Ba cách giảm thiên lệch:

  • Đảo thứ tự: chấm mỗi cặp hai lần, đổi vị trí. Chỉ tính là thắng khi thắng cả hai lần; nếu kết quả đổi theo vị trí, tính là hoà.
  • Giấu tên và dùng mô hình chấm khác họ: không để mô hình của hãng A chấm câu trả lời của chính hãng A.
  • Đối chiếu với người: lấy ngẫu nhiên khoảng 30 câu, nhờ người chấm độc lập, so với máy chấm. Nếu hai bên lệch nhiều, sửa tiêu chí chấm trước khi tin kết quả của 200 câu còn lại.

Với câu có đáp án rõ, đừng dùng AI chấm — so trực tiếp bằng mã: trùng khớp chính xác, biểu thức chính quy, hay kiểm tra định dạng JSON. Rẻ hơn, nhanh hơn và không có thiên lệch.

Ghi gì cho mỗi lần chạy

Mỗi câu, mỗi mô hình, mỗi lần chạy, ghi một dòng: mã câu hỏi, tên và phiên bản mô hình, mức suy luận, câu lệnh đã dùng (hoặc mã phiên bản câu lệnh), câu trả lời, đạt hay không đạt, số token đầu vào và đầu ra, thời gian phản hồi. Một bảng tính là đủ để bắt đầu.

Từ bảng đó tính được những con số thực sự dùng để quyết định: tỉ lệ đạt theo từng loại việc (không chỉ tổng), số câu không ổn định giữa các lần chạy, chi phí cho mỗi câu đạt, và thời gian phản hồi ở phân vị 90 — vì khách hàng nhớ lần chờ lâu nhất, không phải lần trung bình.

Giữ bộ đánh giá sống

Bộ đánh giá có giá trị nhất không phải bộ được dựng một lần cho cuộc chọn mô hình, mà là bộ được giữ và chạy lại:

  • Lưu như mã nguồn: câu hỏi, đáp án, tiêu chí và kết quả mỗi lần chạy đều có ghi phiên bản.
  • Thêm mọi lỗi mới: mỗi khi hệ thống trả lời sai một ca thật, thêm ca đó vào bộ. Sau vài tháng, bộ đánh giá chứa đúng những tình huống khó nhất của doanh nghiệp bạn.
  • Chạy lại khi có thay đổi: đổi mô hình, sửa câu lệnh, hãng cập nhật phiên bản mới cùng tên. Một thay đổi nhỏ trong câu lệnh để sửa một lỗi có thể làm hỏng ba ca khác — bộ đánh giá là cách duy nhất để thấy trước khi khách hàng thấy.

Kết

Bảng điểm công khai hữu ích để chọn ra ba bốn ứng viên đáng thử. Nhưng quyết định cuối cùng nên dựa trên câu hỏi của chính bạn, với đủ số câu để kết quả không phải là may rủi.

Ba con số để nhớ: 30 câu để loại mô hình kém rõ rệt và so chi phí; khoảng 100 câu để phân biệt các mô hình chênh vài điểm; chạy mỗi câu ba lần vì cùng một mô hình không trả lời giống nhau mọi lần. Và một nguyên tắc: viết đáp án trước khi nhìn câu trả lời.

Nếu bạn muốn dựng bộ đánh giá từ dữ liệu thật của doanh nghiệp — từ chọn câu hỏi, viết tiêu chí chấm tới tự động hoá việc chạy lại mỗi khi có mô hình mới — liên hệ với chúng tôi hoặc xem năng lực Data Analytics của KonexForge.

Bài viết liên quan

Data Analytics

Đặt hàng theo số bán trung bình thì cứ hai lần nhập lại hết hàng một lần — tính tồn kho an toàn bằng Excel

Cách đặt hàng phổ biến nhất ở cửa hàng và nhà phân phối nhỏ là lấy số bán trung bình mỗi ngày nhân số ngày chờ hàng về. Chúng tôi mô phỏng 200.000 chu kỳ nhập hàng: cách đó hết hàng trong 50% số lần. Bài này đưa công thức tồn kho an toàn làm được bằng sáu ô Excel, chỉ ra vì sao nhà cung cấp giao lệch hai ngày có thể làm lượng dự phòng cần thiết tăng gấp đôi, và những trường hợp công thức không dùng được.

Data Analytics

Dashboard đã bàn giao nhưng không ai mở: vấn đề không nằm ở công cụ

Doanh nghiệp bỏ tiền làm một màn hình báo cáo, bàn giao suôn sẻ, ba tháng sau không còn ai mở. Phản xạ đầu tiên là đổ cho phần mềm hoặc đổ cho nhân viên chưa quen dùng số liệu. Có một con số cho thấy cả hai cách giải thích đều trượt: trong cùng một công ty, ban giám đốc dùng khoảng 80% còn nhân viên khoảng 26% — cùng phần mềm, cùng dữ liệu, cùng màn hình.

Data Analytics

Luật Bảo vệ dữ liệu cá nhân: phần pháp lý đọc trong một buổi, phần kỹ thuật mất nhiều tháng

Luật số 91/2025/QH15 có hiệu lực từ 1/1/2026 cùng Nghị định 356/2025/NĐ-CP. Đọc hết cả hai mất một buổi chiều, nhưng nghĩa vụ thật quy về ba câu hỏi kiến trúc — và phần lớn doanh nghiệp đang vận hành không trả lời được câu đầu tiên: bạn đang giữ dữ liệu cá nhân nào, ở những đâu?

Có một bài toán tương tự đang cần giải?

Liên hệ team