Gần như mọi vị trí ML/AI Engineer hiện nay đều chạm tới LLM ở mức độ nào đó — nhà tuyển dụng cần biết bạn hiểu khi nào dùng prompt engineering đơn giản, khi nào cần fine-tuning, và khi nào các phương pháp này không phù hợp bài toán.
"RAG giải quyết vấn đề gì của LLM thuần?" — LLM có kiến thức "đóng băng" tại thời điểm training, không biết thông tin mới hoặc dữ liệu riêng của tổ chức. RAG bổ sung bước truy xuất (retrieval) dữ liệu liên quan từ nguồn ngoài (vector database) trước khi đưa vào prompt cho LLM sinh câu trả lời — giảm hallucination (bịa thông tin) và cho phép trả lời dựa trên dữ liệu cập nhật/riêng tư.
"Chất lượng retrieval kém ảnh hưởng gì tới kết quả RAG?" — Nếu bước truy xuất lấy sai/thiếu tài liệu liên quan, LLM dù mạnh cũng không thể sinh câu trả lời đúng ("garbage in, garbage out") — vì vậy chất lượng embedding model và chiến lược chunk hoá tài liệu quan trọng không kém việc chọn LLM nào.
Fine-tuning đáng cân nhắc khi: cần model phản hồi theo format/phong cách rất đặc thù mà prompt engineering không đủ ổn định, cần giảm độ trễ/chi phí (prompt dài với nhiều ví dụ tốn token hơn model đã học sẵn hành vi), hoặc cần model học kiến thức chuyên ngành sâu mà few-shot không đủ. Đánh đổi: fine-tuning tốn chi phí, thời gian, và dữ liệu training chất lượng.
"Làm sao đánh giá chất lượng output của LLM 1 cách hệ thống?" — Không thể chỉ "nhìn qua thấy ổn" — cần bộ test case rõ ràng, có thể dùng LLM khác làm giám khảo (LLM-as-judge) kết hợp đánh giá của con người cho mẫu quan trọng, và theo dõi các chỉ số như tỷ lệ hallucination, độ liên quan câu trả lời.
Nếu từng xây dựng ứng dụng LLM thật, kể rõ: bài toán giải quyết, tại sao chọn prompt engineering/RAG/fine-tuning (không phải cái khác), và cách đánh giá/giám sát chất lượng output sau khi triển khai — điều này thể hiện tư duy kỹ thuật có hệ thống, không chỉ "dùng ChatGPT API là xong".