Câu hỏi phỏng vấn AI Engineer (2026)
Vai trò AI engineer mới hơn và ít được chuẩn hóa hơn so với software hay data science, vì vậy các buổi phỏng vấn rất khác nhau — nhưng quy trình năm 2026 thường tìm hiểu về nền tảng LLM, retrieval-augmented generation (RAG), prompt và context engineering, đánh giá, và công việc kỹ thuật để triển khai các tính năng AI một cách đáng tin cậy. Nhiều quy trình cũng vẫn giữ một vòng coding cổ điển, vì vậy đừng bỏ qua cấu trúc dữ liệu.
Người phỏng vấn tìm kiếm người hiểu cả mô hình và kỹ thuật xung quanh nó: transformer và attention hoạt động như thế nào ở mức khái niệm, cách neo (ground) một mô hình với retrieval, cách đánh giá các hệ thống không xác định (non-deterministic), và cách kiểm soát độ trễ và chi phí trong production. Nói mơ hồ rằng 'chỉ cần gọi API' là cách nhanh nhất để bị loại.
Vì lĩnh vực này thay đổi nhanh, việc thể hiện rằng bạn suy luận từ các nguyên lý cơ bản — và rằng bạn triển khai và đo lường, không chỉ làm prototype — quan trọng hơn việc đọc lại các số liệu benchmark của ngày hôm qua.
Câu hỏi phỏng vấn AI Engineer và Cách Trả lời
1. Giải thích cách attention hoạt động trong một transformer, ở mức tổng quan.
Cách tiếp cận: Mô tả query/key/value, scaled dot-product attention, và tại sao self-attention cho phép mỗi token chú ý đến mọi token khác — nắm bắt các phụ thuộc tầm xa mà RNN khó xử lý. Nhắc đến vai trò của multi-head attention và chi phí bậc hai.
2. Bạn sẽ thiết kế một hệ thống RAG cho cơ sở kiến thức của một công ty như thế nào?
Cách tiếp cận: Trình bày pipeline: chiến lược chunking, lựa chọn mô hình embedding, một vector store, retrieval (top-k, kết hợp với keyword), reranking, và lắp ghép prompt. Thảo luận về độ chồng lấp (overlap) của chunk, làm mới dữ liệu cũ, và việc trích dẫn nguồn.
3. Bạn giảm hallucination trong một ứng dụng LLM như thế nào?
Cách tiếp cận: Neo bằng retrieval, ràng buộc bằng đầu ra có cấu trúc, giảm temperature cho các tác vụ thực tế, thêm yêu cầu trích dẫn, và xác minh bằng một lượt kiểm tra thứ hai hoặc các quy tắc. Nhấn mạnh việc đánh giá: bạn không thể giảm cái bạn không đo lường.
4. Bạn sẽ đánh giá một tính năng LLM không xác định (non-deterministic) như thế nào?
Cách tiếp cận: Xây dựng một tập đánh giá có nhãn, dùng chấm điểm theo rubric hoặc LLM-as-judge, theo dõi sự thoái hóa (regression) khi thay đổi prompt/mô hình, và kết hợp đánh giá offline với các chỉ số online. Nhắc đến chi phí và thiên lệch của LLM-as-judge.
5. Khi nào bạn sẽ fine-tune so với dùng RAG so với prompt engineering?
Cách tiếp cận: Prompt engineering trước (rẻ nhất, nhanh nhất). RAG cho kiến thức/độ mới. Fine-tuning cho hành vi, định dạng, hoặc phong cách theo lĩnh vực mà prompting không thể đạt được một cách đáng tin cậy. Thường là kết hợp cả ba; biện minh bằng chi phí, độ trễ, và khả năng duy trì.
6. Bạn kiểm soát độ trễ và chi phí trong một sản phẩm LLM như thế nào?
Cách tiếp cận: Chọn mô hình theo từng tác vụ (mô hình nhỏ cho các lượt dễ), cắt gọn prompt/context, caching, streaming để giảm độ trễ cảm nhận, batching, và routing. Định lượng: context nhỏ hơn và mô hình rẻ hơn có thể giảm chi phí xuống một bậc độ lớn.
7. Sự đánh đổi giữa chạy một mô hình cục bộ so với qua một API trên cloud là gì?
Cách tiếp cận: Cục bộ: bảo mật, không tốn chi phí theo token, hoạt động offline, nhưng bị giới hạn bởi phần cứng và kích thước mô hình. Cloud: mô hình hàng đầu và khả năng mở rộng, nhưng có chi phí, độ trễ, và dữ liệu rời khỏi thiết bị của bạn. Gắn với use case — chính xác là sự đánh đổi mà Natively được xây dựng xung quanh.
8. Bạn sẽ chọn một mô hình embedding cho retrieval như thế nào?
Cách tiếp cận: Khớp với lĩnh vực và ngôn ngữ, kiểm tra các benchmark kiểu MTEB, cân nhắc kích thước chiều so với lưu trữ/độ trễ, và xác thực trên dữ liệu CỦA BẠN bằng một đánh giá retrieval. Đừng tin một bảng xếp hạng hơn một bài kiểm tra chuyên biệt theo lĩnh vực.
9. Triển khai một tìm kiếm ngữ nghĩa đơn giản trên một tập hợp văn bản.
Cách tiếp cận: Embed các văn bản và câu truy vấn, lưu trữ các vector, tính độ tương tự cosine (hoặc dùng một chỉ mục vector như sqlite-vec/FAISS), trả về top-k. Thảo luận về việc chuẩn hóa và sự đánh đổi tốc độ/độ chính xác của tìm kiếm láng giềng gần nhất xấp xỉ.
10. Kể cho tôi về một tính năng AI bạn đã triển khai và cách bạn đo lường thành công của nó.
Cách tiếp cận: Dùng STAR. Nhấn mạnh phương pháp đánh giá và chỉ số trong production, không chỉ bản demo. Các AI engineer biết triển khai và đo lường — thay vì làm prototype vô tận — mới là những gì được tìm kiếm.
Nhận trợ giúp theo thời gian thực trong buổi phỏng vấn AI engineer của bạn
Natively chính nó là một ứng dụng AI local-first — LLM chạy trên thiết bị, RAG cục bộ với sqlite-vec, và kiến trúc bring-your-own-key. Trong một buổi phỏng vấn AI engineering trực tiếp, nó có thể chuyển lời nói thành văn bản và hiển thị một định nghĩa chính xác hoặc một trade-off theo thời gian thực, trên thiết bị của bạn.
