Thực tập sinh AI

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.

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ỗi yêu cầu "nhỏ" cộng lại thành trễ hạn. Cần quy trình tiếp nhận thay đổi rõ ràng từ đầu dự án.

• Chốt phạm vi bằng tài liệu hoặc backlog đã thống nhất, kèm định nghĩa hoàn thành.
• Mọi yêu cầu mới đi qua một kênh: ghi nhận, đánh giá effort và ảnh hưởng tới mốc bàn giao.
• Đưa lựa chọn cho khách: đổi lấy hạng mục khác, dời mốc, tính thêm chi phí, hoặc để giai đoạn sau.
• Dự án fixed-price: dùng change request có ký duyệt. Dự án time & material: minh bạch ảnh hưởng tới ngân sách.
• Dặn team không nhận yêu cầu trực tiếp từ khách mà không qua PM/PO.

Người phỏng vấn muốn nghe: bạn vẫn giữ được quan hệ tốt với khách. Nói "có, và đây là cái giá" thay vì chỉ nói "không".

Nói chuyện riêng, sớm và dựa trên sự việc trước khi kết luận.

• Chuẩn bị ví dụ cụ thể (task nào, trễ bao lâu, ảnh hưởng gì), tránh nhận xét chung chung kiểu "em làm chậm".
• Hỏi để hiểu nguyên nhân: việc quá sức, thiếu kiến thức, yêu cầu không rõ, vấn đề cá nhân, hay mất động lực.
• Cùng thống nhất kế hoạch: chia task nhỏ hơn, ghép cặp với người kinh nghiệm, check-in thường xuyên hơn, hỗ trợ đào tạo.
• Theo dõi và phản hồi định kỳ. Nếu không cải thiện, phối hợp với line manager/HR theo quy trình của công ty.

Hay sai: góp ý trước cả team, hoặc lẳng lặng giao việc cho người khác làm thay. Cách đó làm người giỏi kiệt sức và vấn đề không được giải quyết.

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.

Overfitting là mô hình học thuộc cả nhiễu của tập train nên kém trên dữ liệu mới; underfitting là mô hình quá đơn giản, kém ngay cả trên tập train.

Phát hiện: so sánh lỗi train và validation. Train tốt mà validation kém là overfit; cả hai đều kém là underfit.

Khắc phục overfitting:

• Thêm dữ liệu, data augmentation.
• Regularization (L1/L2, dropout, weight decay), early stopping.
• Giảm độ phức tạp mô hình, bớt đặc trưng nhiễu.

Khắc phục underfitting: mô hình mạnh hơn, đặc trưng tốt hơn, train lâu hơn, giảm regularization.

Người phỏng vấn muốn nghe: liên hệ với bias-variance trade-off và dùng cross-validation khi dữ liệu ít.

Train để học tham số, validation để chọn mô hình và siêu tham số, test để ước lượng hiệu năng thật lúc cuối và chỉ dùng một lần.

Data leakage là khi thông tin không có ở thời điểm dự đoán lọt vào lúc train, khiến kết quả offline đẹp nhưng chạy thật thì kém.

Ví dụ hay gặp:

• Chuẩn hoá hoặc chọn đặc trưng trên toàn bộ dữ liệu trước khi chia tập.
• Dữ liệu chuỗi thời gian chia ngẫu nhiên thay vì theo thời gian.
• Đặc trưng chứa thông tin từ tương lai hoặc từ chính nhãn (như "ngày huỷ hợp đồng" khi dự đoán khách rời bỏ).
• Cùng một người dùng xuất hiện ở cả train và test.

Hay sai: tinh chỉnh nhiều lần dựa trên tập test, biến nó thành validation.

PO ưu tiên theo giá trị mang lại so với chi phí và rủi ro, gắn với mục tiêu sản phẩm.

• Mục tiêu sản phẩm/công ty trong giai đoạn này: tăng người dùng mới, giữ chân, doanh thu, hay giảm chi phí vận hành.
• Dữ liệu: số liệu sử dụng, phản hồi người dùng, ticket hỗ trợ, kết quả phỏng vấn người dùng.
• Effort và rủi ro do team ước lượng; phụ thuộc kỹ thuật; nợ kỹ thuật cần trả.
• Ràng buộc bắt buộc: quy định pháp lý, cam kết hợp đồng, hạn chót của đối tác.
• Framework hỗ trợ: RICE, MoSCoW, Kano, value/effort.

Người phỏng vấn muốn nghe: ví dụ một lần bạn từ chối hoặc hoãn một yêu cầu từ sếp/khách lớn nhờ dữ liệu, và cách bạn giải thích để họ đồng ý.

Đây là câu mở đầu gần như chắc chắn có. Dùng công thức Hiện tại – Quá khứ – Tương lai, gói trong khoảng 1–2 phút.

• Hiện tại: vị trí, số năm kinh nghiệm, mảng/công nghệ chính.
• Quá khứ: một hai dự án hoặc thành tích liên quan nhất tới vị trí đang tuyển.
• Tương lai: vì sao bạn quan tâm tới vị trí này.

Câu mẫu: "Em là backend developer, khoảng 3 năm kinh nghiệm, chủ yếu làm Java Spring cho hệ thống thanh toán. Ở dự án gần nhất em phụ trách module đối soát và tối ưu các truy vấn báo cáo chạy chậm. Em đang tìm môi trường làm sản phẩm lâu dài để đi sâu hơn về thiết kế hệ thống, nên rất quan tâm tới vị trí này."

Hay sai: kể từ quê quán, trường cấp ba, hoặc đọc lại nguyên CV.