1. Đề bài phỏng vấn: 'Thiết kế test strategy đánh giá một tính năng LLM'
Đây là một câu hỏi phỏng vấn ngày càng phổ biến cho vị trí QA cấp cao và test engineer làm sản phẩm AI: 'Hãy thiết kế chiến lược kiểm thử để đánh giá một tính năng LLM.' Câu hỏi mở này không có đáp án duy nhất, và đó chính là dụng ý. Người phỏng vấn muốn xem bạn dẫn dắt từ mơ hồ đến rõ ràng như thế nào: bạn có làm rõ yêu cầu trước không, bạn có nhận ra bài toán oracle đặc thù của LLM không, bạn có biết xây golden set và dùng LLM-as-judge một cách có kỷ luật không, và bạn có gắn tất cả vào một cổng regression trong CI không. Bài viết này mô phỏng buổi phỏng vấn đó theo từng bước, kèm câu trả lời mẫu và điều người phỏng vấn thực sự tìm kiếm.
Trước khi đi vào từng bước, hãy nắm cấu trúc chiến lược tổng thể. Một chiến lược đánh giá LLM tốt gồm sáu mảnh: một, làm rõ yêu cầu và định nghĩa 'tốt'; hai, xây golden set các cặp input–tham chiếu đã được người duyệt; ba, chọn cách chấm — metric xác định cộng LLM-as-judge cho phần chủ quan; bốn, chọn tập metric cân bằng gồm độ chính xác, grounding, an toàn, độ trễ và chi phí; năm, đặt guardrail cho các hành vi cấm; sáu, gắn tất cả vào CI như một cổng regression theo dõi điểm qua thời gian. Sáu mảnh này là dàn ý mà bạn có thể trình bày mạch lạc trong mọi buổi phỏng vấn.
❓ Người phỏng vấn hỏi: 'Bạn bắt đầu từ đâu khi được giao đánh giá một tính năng LLM?'
Trả lời mẫu: Tôi bắt đầu bằng làm rõ yêu cầu, không bằng công cụ. Tôi hỏi: tính năng này giải bài toán gì, đầu vào–đầu ra là gì, 'tốt' nghĩa là gì cho người dùng, rủi ro cao nhất là gì (sai sự thật? rò rỉ dữ liệu? độc hại?). Chỉ khi có định nghĩa 'tốt' rõ, tôi mới xây golden set và chọn cách chấm. Bắt đầu từ công cụ mà chưa có oracle là sai lầm phổ biến nhất.
2. Làm rõ yêu cầu: hỏi đúng trước khi thiết kế
Bước đầu tiên và cũng là bước ghi điểm nhất là làm rõ yêu cầu. Một tính năng LLM có thể là tóm tắt tài liệu, trả lời câu hỏi dựa trên tri thức nội bộ, sinh code, hay phân loại. Mỗi loại có 'tốt' khác nhau và rủi ro khác nhau. Bạn cần hỏi: tính năng nhắm người dùng nào, ngữ cảnh nào, ngôn ngữ nào; đầu vào có kèm ngữ cảnh grounding như tài liệu nguồn không; đầu ra tự do hay có cấu trúc; và quan trọng nhất, hậu quả của một câu trả lời sai là gì. Một câu trả lời tóm tắt sai gây khó chịu; một câu trả lời tư vấn y tế sai gây nguy hiểm. Mức rủi ro quyết định độ ngặt của oracle.
# eval/spec.yaml — spec đánh giá, viết TRƯỚC khi build test
feature: internal-knowledge-qa
users: [nhân viên hỗ trợ]
languages: [vi, en]
input:
question: string
context_docs: [string] # grounding: câu trả lời phải dựa vào đây
output:
type: free_text
must_cite: true # bắt buộc trích nguồn
risk: high # sai → tư vấn khách hàng sai
definition_of_good:
- grounded: chỉ dùng thông tin trong context_docs
- accurate: khớp fact với nguồn
- safe: không rò rỉ dữ liệu nhạy cảm, không độc hại
- concise: trả lời gọn, đúng trọng tâm
forbidden:
- bịa fact ngoài context (hallucination)
- trả lời khi context không đủ (phải nói "không đủ thông tin")Viết spec đánh giá ra thành văn bản như trên là một hành động mạnh trong phỏng vấn. Nó cho thấy bạn biến câu hỏi mơ hồ thành hợp đồng kiểm chứng được. Đặc biệt trường 'forbidden' rất quan trọng: nó định nghĩa các hành vi mà dù câu trả lời nghe hay đến đâu cũng phải bị đánh trượt — như bịa fact ngoài ngữ cảnh, hay trả lời tự tin khi lẽ ra phải nói 'không đủ thông tin'. Chính những hành vi cấm này, chứ không phải điểm trung bình đẹp, mới là thứ bảo vệ người dùng khỏi rủi ro thật.
3. Bài toán oracle: khi không có một đáp án đúng duy nhất
Đây là phần cốt lõi mà người phỏng vấn muốn nghe. Với test phần mềm truyền thống, oracle thường rõ: hàm cộng 2 và 3 phải ra 5. Với LLM, cùng một câu hỏi có thể có nhiều câu trả lời đều đúng, khác nhau về từ ngữ, độ dài, thứ tự. So khớp chuỗi chính xác là vô nghĩa vì một câu trả lời đúng viết cách khác sẽ bị đánh trượt. Đây là 'bài toán oracle' của LLM: bạn phải đo tính đúng mà không có một đáp án chuẩn để so bằng nhau. Nhận ra điều này ngay là dấu hiệu ứng viên hiểu bản chất, không áp máy móc tư duy test tất định lên một hệ thống sinh.
Cách giải bài toán oracle không phải tìm một thước đo hoàn hảo, mà là kết hợp nhiều tín hiệu bổ sung nhau. Với phần có thể xác định — như đầu ra phải là JSON hợp lệ, phải chứa một con số cụ thể, phải trích đúng nguồn — dùng metric tất định. Với phần chủ quan — như câu trả lời có mạch lạc, có bám ngữ cảnh, có hữu ích — dùng LLM-as-judge kèm rubric. Với rủi ro an toàn — như rò rỉ dữ liệu, độc hại — dùng guardrail chặn cứng. Không tín hiệu nào đủ một mình, nhưng gộp lại chúng cho một bức tranh đáng tin. Nguyên tắc vàng: đừng tin một con số, hãy tin sự đồng thuận của nhiều tín hiệu.
❓ Người phỏng vấn hỏi: 'Vì sao không so khớp chuỗi chính xác với đáp án mẫu?'
Trả lời mẫu: Vì LLM sinh ngôn ngữ tự nhiên — cùng một ý đúng có vô số cách diễn đạt. So chuỗi chính xác sẽ đánh trượt câu trả lời đúng chỉ vì khác từ ngữ, và cho điểm giả cao khi câu sai tình cờ trùng chuỗi. Đây là bài toán oracle của LLM. Tôi giải bằng nhiều tín hiệu: metric tất định cho phần xác định (JSON, con số, trích nguồn), LLM-as-judge cho phần chủ quan, guardrail cho an toàn — rồi lấy đồng thuận.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!