Software Engineer (Fullstack, AI-Native)

Precision là trong các ca mô hình báo dương, bao nhiêu ca đúng; recall là trong các ca dương thật, mô hình bắt được bao nhiêu; F1 là trung bình điều hoà của hai chỉ số.

Ví dụ phát hiện gian lận với 1% giao dịch gian lận: mô hình đoán "không gian lận" cho mọi giao dịch đạt accuracy 99% nhưng recall bằng 0.

• Ưu tiên recall khi bỏ sót đắt (bệnh, gian lận); ưu tiên precision khi báo nhầm đắt (chặn nhầm giao dịch).
• Dùng PR-AUC thay vì chỉ ROC-AUC khi lớp dương rất hiếm.
• Chọn ngưỡng quyết định theo chi phí nghiệp vụ, không mặc định 0.5.

Người phỏng vấn muốn nghe: gắn metric với hậu quả kinh doanh.

Attention cho mỗi token "nhìn" tất cả token khác và tính trọng số mức liên quan, nhờ đó nắm được phụ thuộc xa trong câu. Mỗi token tạo ra query, key, value; trọng số là softmax của tích query với key (chia cho căn bậc hai số chiều), rồi lấy tổng có trọng số của value.

Transformer thắng RNN vì:

• Xử lý song song cả chuỗi khi train, tận dụng GPU tốt; RNN phải đi tuần tự.
• Ít gặp vấn đề mất thông tin ở chuỗi dài.
• Mở rộng quy mô tốt, là nền của các LLM hiện nay.

Đánh đổi: chi phí attention tăng theo bình phương độ dài chuỗi, nên ngữ cảnh dài tốn bộ nhớ và tính toán.

RAG (Retrieval-Augmented Generation) tìm các đoạn tài liệu liên quan rồi đưa vào prompt để LLM trả lời dựa trên đó, giúp dùng dữ liệu riêng, cập nhật mà không cần train lại.

Các bước:

1. Nạp và làm sạch tài liệu (PDF, wiki), giữ metadata và quyền truy cập.
2. Chunking theo cấu trúc (tiêu đề, đoạn), có chồng lấp hợp lý.
3. Embedding và lưu vào vector DB.
4. Truy xuất: kết hợp tìm vector và từ khoá (hybrid), rồi rerank.
5. Sinh câu trả lời với prompt yêu cầu bám nguồn và trích dẫn, trả lời "không biết" khi thiếu thông tin.

Hay sai: bỏ qua phân quyền, để người dùng nhận được nội dung từ tài liệu họ không được xem.

Generator sinh giá trị lười (lazy): mỗi lần được hỏi mới tính phần tử tiếp theo, rồi tạm dừng tại yield. Nhờ vậy nó không phải giữ toàn bộ dữ liệu trong bộ nhớ.

def read_lines(path):
    with open(path) as f:
        for line in f:
            yield line.rstrip()

total = sum(len(l) for l in read_lines("big.log"))

• List comprehension [x * 2 for x in data] tạo cả list ngay. Generator expression (x * 2 for x in data) thì không.
• Hợp với file lớn, dữ liệu stream, phân trang API, pipeline xử lý nhiều bước.

Hay sai: duyệt một generator hai lần. Lần thứ hai không có gì vì nó đã cạn; cần duyệt lại thì tạo generator mới hoặc chuyển thành list.

Decorator là hàm nhận một hàm và trả về hàm mới bọc quanh nó. @timer chỉ là cú pháp ngắn của func = timer(func).

import functools, time

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        try:
            return func(*args, **kwargs)
        finally:
            print(func.__name__, time.perf_counter() - start)
    return wrapper

• functools.wraps giữ lại __name__, docstring của hàm gốc, quan trọng cho log và debug.
• Decorator có tham số (ví dụ @retry(times=3)) cần thêm một lớp hàm bên ngoài.
• Ví dụ thực tế: @app.get của FastAPI, @login_required của Django, @functools.lru_cache.

Hay sai: decorator viết kiểu đồng bộ bọc hàm async def. Kết quả là đo thời gian tạo coroutine chứ không phải thời gian chạy.

JavaScript chạy trên một thread. Code đồng bộ chạy hết trên call stack trước, sau đó event loop lấy việc từ hàng đợi. Microtask (Promise .then, await, queueMicrotask) luôn được chạy hết trước khi sang macrotask tiếp theo (setTimeout, sự kiện I/O, sự kiện người dùng).

console.log(1);
setTimeout(() => console.log(2));
Promise.resolve().then(() => console.log(3));
console.log(4);
// 1, 4, 3, 2

• Trên trình duyệt, việc render thường diễn ra giữa các macrotask.
• Một vòng lặp đồng bộ dài, hoặc chuỗi microtask không dứt, sẽ làm treo giao diện.

Người phỏng vấn muốn nghe: setTimeout(fn, 0) không chạy ngay mà chỉ được xếp hàng, và vì sao microtask được ưu tiên.

Bắt đầu từ cách rẻ và nhanh nhất, chỉ nâng cấp khi đo được là chưa đủ.

• Prompting: thử đầu tiên; chỉ dẫn rõ, ví dụ mẫu (few-shot), định dạng đầu ra có cấu trúc.
• RAG: khi mô hình thiếu kiến thức (tài liệu nội bộ, dữ liệu thay đổi thường xuyên), cần trích dẫn nguồn.
• Fine-tuning: khi cần đổi hành vi ổn định (văn phong, định dạng, tác vụ hẹp lặp lại), hoặc muốn dùng mô hình nhỏ rẻ hơn thay mô hình lớn. Kỹ thuật như LoRA giảm chi phí.

Fine-tuning không phải cách tốt để nhồi kiến thức mới hay thay đổi liên tục; RAG hợp hơn.

Người phỏng vấn muốn nghe: có bộ đánh giá trước để so sánh các phương án bằng số liệu.

Hallucination là khi mô hình sinh ra nội dung nghe hợp lý nhưng sai hoặc không có căn cứ. Không loại bỏ hoàn toàn được, chỉ giảm và kiểm soát.

• Cung cấp ngữ cảnh đúng qua RAG, yêu cầu chỉ trả lời dựa trên nguồn và trích dẫn.
• Cho phép và khuyến khích trả lời "không đủ thông tin".
• Dùng đầu ra có cấu trúc (JSON schema) và kiểm tra hợp lệ bằng code.
• Với số liệu, tra cứu hoặc tính toán qua tool/API thay vì để mô hình tự nhớ.
• Kiểm tra sau sinh: đối chiếu câu trả lời với nguồn.
• Thiết kế UX hiển thị nguồn; tác vụ rủi ro cao có người duyệt.

Người phỏng vấn muốn nghe: đo tỷ lệ hallucination bằng bộ đánh giá, không chỉ dựa vào cảm giác.

Mô hình lên production là một phần mềm cần đóng gói, phiên bản hoá, giám sát và cập nhật như mọi dịch vụ khác.

• Đóng gói: lưu mô hình kèm phiên bản dữ liệu, code, siêu tham số (model registry).
• Phục vụ: API online hoặc chạy batch tuỳ yêu cầu độ trễ; dùng chung code tính đặc trưng giữa train và serve để tránh lệch.
• Triển khai an toàn: shadow hoặc canary, so sánh với mô hình cũ.
• Giám sát: độ trễ, lỗi; data drift (phân phối đầu vào thay đổi); chất lượng dự đoán khi có nhãn thật.
• Cập nhật: train lại định kỳ hoặc khi drift vượt ngưỡng, có rollback.

Hay sai: training-serving skew, xử lý đặc trưng ở hai nơi bằng hai đoạn code khác nhau.

Luôn có câu hỏi. Đây là cơ hội thể hiện sự quan tâm và cũng là lúc bạn đánh giá công ty.

Câu hỏi nên chuẩn bị (chọn 2–3 câu hợp với người đang phỏng vấn):

• "Một ngày làm việc của vị trí này thường như thế nào? Team có bao nhiêu người, gồm những vai trò gì?"
• "Ba tháng đầu, anh/chị kỳ vọng người vào vị trí này làm được gì?"
• "Team đang gặp thách thức kỹ thuật hoặc quy trình nào lớn nhất?"
• "Quy trình release và code review của team ra sao?"
• "Công ty đánh giá hiệu suất và review lương theo chu kỳ nào?"
• "Vì sao vị trí này đang tuyển: mở rộng team hay thay người?"

Hay sai: "Dạ không ạ", hoặc chỉ hỏi về nghỉ phép, lương thưởng ngay ở vòng kỹ thuật. Chuyện chế độ nên hỏi kỹ với HR.