AI Solution Architect

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.

Xây một bộ đánh giá (eval set) đại diện cho câu hỏi thật, chạy tự động như test hồi quy mỗi khi đổi prompt, mô hình hay cách truy xuất.

• Dữ liệu: câu hỏi thật đã ẩn danh, trường hợp khó, câu hỏi ngoài phạm vi, câu cố tình phá.
• Đánh giá truy xuất: tài liệu đúng có nằm trong top-k không (recall@k).
• Đánh giá câu trả lời: đúng sự thật, bám nguồn, đầy đủ, đúng định dạng; dùng kiểm tra bằng code khi được, LLM-as-judge có rubric rõ, và người chấm mẫu để hiệu chỉnh.
• Sau ra mắt: thu phản hồi người dùng, log và soi các ca thất bại để bổ sung bộ eval.

Hay sai: chỉ thử vài câu bằng tay rồi kết luận "ổn".

Đo trước: chi phí và độ trễ đến từ số token vào/ra, kích thước mô hình, số lần gọi trong một yêu cầu.

• Chọn mô hình: định tuyến, việc dễ cho mô hình nhỏ, việc khó mới gọi mô hình lớn.
• Giảm token: prompt gọn, truy xuất ít đoạn nhưng chính xác hơn (rerank), giới hạn độ dài đầu ra.
• Prompt caching cho phần prompt cố định lặp lại; cache câu trả lời cho câu hỏi trùng.
• Streaming để người dùng thấy chữ sớm, cải thiện độ trễ cảm nhận.
• Gộp việc không gấp thành batch.
• Tự host: quantization, batching động, engine suy luận tối ưu.

Người phỏng vấn muốn nghe: mọi tối ưu đều kiểm tra lại bằng bộ eval để chắc chất lượng không giảm.

Cả ba đều giảm rủi ro khi deploy nhưng khác ở chi phí và tốc độ phát hiện lỗi.

• Rolling: thay dần từng Pod, rẻ, mặc định của Deployment; hai phiên bản chạy song song một lúc.
• Blue-green: dựng nguyên bộ mới, chuyển traffic một lần, rollback tức thì; tốn gấp đôi tài nguyên.
• Canary: đưa một phần nhỏ traffic sang bản mới, theo dõi metric rồi tăng dần; cần công cụ (service mesh, Argo Rollouts) và metric tốt.

Với thanh toán, canary kèm tự động rollback theo tỷ lệ lỗi và độ trễ là lựa chọn hợp lý.

Hay sai: quên migration DB. Schema phải tương thích cả bản cũ lẫn mới (expand rồi mới contract).

Ưu tiên khôi phục dịch vụ trước, tìm nguyên nhân gốc sau.

1. Xác nhận phạm vi qua dashboard: endpoint nào, từ lúc nào, có trùng thời điểm deploy không.
2. Nếu nghi deploy: rollback ngay (kubectl rollout undo, hoặc revert trong GitOps) thay vì sửa nóng.
3. Thông báo kênh sự cố, chỉ định người điều phối, ghi lại mốc thời gian.
4. Sau khi ổn định: so sánh log, trace, diff cấu hình giữa hai phiên bản.
5. Viết postmortem không đổ lỗi, có hành động phòng ngừa (thêm test, canary, alert).

Người phỏng vấn muốn nghe: bình tĩnh, có thứ tự, biết giảm thiệt hại trước, và rút kinh nghiệm thành thay đổi quy trình.

RPO là lượng dữ liệu tối đa chấp nhận mất (tính theo thời gian); RTO là thời gian tối đa để khôi phục dịch vụ. Hai con số này do nghiệp vụ quyết định và định giá chiến lược.

Từ rẻ đến đắt:

• Backup & restore: sao lưu sang region khác, dựng lại khi cần; RTO hàng giờ.
• Pilot light: dữ liệu được replicate liên tục, chỉ phần lõi chạy sẵn.
• Warm standby: bản thu nhỏ chạy sẵn ở region khác, scale lên khi failover.
• Active-active: nhiều region cùng phục vụ; RTO/RPO gần 0, phức tạp nhất.

Hay sai: có backup nhưng chưa bao giờ thử khôi phục. Kế hoạch DR phải được diễn tập định kỳ.

Tách lỗi theo từng khâu của pipeline, kiểm tra từ dưới lên.

1. Dữ liệu: tài liệu đã được nạp chưa, trích xuất từ PDF/bảng có bị vỡ không, có phiên bản cũ mâu thuẫn không.
2. Chunking: thông tin cần thiết có bị cắt đôi giữa hai chunk không.
3. Truy xuất: log các chunk lấy về cho câu hỏi đó; đúng chunk có nằm trong top-k không. Thử hybrid search, rerank, viết lại câu hỏi.
4. Sinh: chunk đúng đã có trong prompt mà vẫn sai thì xem prompt, thứ tự đặt ngữ cảnh, quá nhiều ngữ cảnh nhiễu.
5. Thêm ca này vào bộ eval để tránh tái diễn.

Người phỏng vấn muốn nghe: có tracing để xem từng bước, không đoán mò.

Agent cho LLM tự quyết định gọi tool theo nhiều bước, nên lỗi và rủi ro tăng theo số bước; cần giới hạn quyền và kiểm soát chặt.

• Tool rõ ràng: mô tả và schema tham số chặt, kiểm tra đầu vào bằng code trước khi thực thi.
• Quyền tối thiểu: tool chỉ đọc khi có thể; thao tác ghi, xoá, chuyển tiền cần người xác nhận.
• Prompt injection: nội dung lấy từ web, email, tài liệu là dữ liệu không tin cậy; không để nó điều khiển tool nhạy cảm.
• Giới hạn số bước, timeout, ngân sách token; xử lý lỗi tool và cho phép thử lại có kiểm soát.
• Log và tracing toàn bộ chuỗi hành động để audit.
• Đánh giá theo tỷ lệ hoàn thành tác vụ trên bộ kịch bản.

Người phỏng vấn muốn nghe: workflow cố định thường đủ; chỉ dùng agent tự do khi thật cần.

"My current contract requires a 30-day notice period, so I could start about a month after accepting an offer. I'd like to make sure I hand over my work properly to my team. If you need someone sooner, I can discuss with my manager whether an earlier date is possible, but I can't promise that yet."

Mẹo: nói đúng thời gian báo trước theo hợp đồng của bạn, đừng hứa đi làm ngay để lấy điểm. Dùng "notice period", "hand over", "start date". Tránh nói "I can go to work immediately" khi bạn vẫn còn hợp đồng.

Dùng STAR: Situation (bối cảnh), Task (nhiệm vụ), Action (bạn làm gì), Result (kết quả). Phần Action nên chiếm nhiều nhất.

Câu mẫu:

• S: "Lead muốn dùng một thư viện mới cho module báo cáo, em thấy thư viện đó còn ít người dùng và lo về bảo trì."
• T: "Em cần nêu rủi ro mà không làm chậm tiến độ."
• A: "Em gặp riêng anh, đưa so sánh hai phương án và đề xuất làm thử một bản nhỏ trong hai ngày để đánh giá."
• R: "Kết quả thử cho thấy thư viện cũ đáp ứng đủ, anh đồng ý giữ lại. Từ đó team có thói quen làm bản thử trước khi đổi công nghệ."

Người phỏng vấn muốn nghe: bạn tranh luận bằng dữ liệu, tôn trọng người khác, và chấp nhận quyết định cuối cùng kể cả khi không theo ý mình.