AI Operations Manager (from 5yoe, Excellent English)

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.

N+1 là khi lấy danh sách bằng 1 query, rồi mỗi phần tử truy cập quan hệ lại sinh thêm 1 query. Ví dụ duyệt 50 bài viết và in post.author.name sẽ thành 51 query.

• select_related: dùng SQL JOIN, cho quan hệ trỏ tới một object (ForeignKey, OneToOne).
• prefetch_related: chạy query riêng rồi ghép trong Python, cho quan hệ nhiều (ManyToMany, reverse ForeignKey).

posts = (Post.objects
         .select_related("author")
         .prefetch_related("tags"))

Phát hiện bằng Django Debug Toolbar, hoặc assertNumQueries trong test.

Hay sai: gọi .filter() trên quan hệ đã prefetch bên trong vòng lặp. Lệnh đó tạo query mới và bỏ qua dữ liệu prefetch; dùng Prefetch(..., queryset=...) để lọc ngay từ đầu.

Context manager đảm bảo việc "mở" và "dọn dẹp" luôn đi cùng nhau, kể cả khi có exception: đóng file, trả connection, nhả lock, rollback transaction.

Cách nhanh nhất là dùng contextlib.contextmanager:

from contextlib import contextmanager

@contextmanager
def db_transaction(conn):
    try:
        yield conn
        conn.commit()
    except Exception:
        conn.rollback()
        raise

• Cách đầy đủ: viết class có __enter__ và __exit__(self, exc_type, exc, tb). Nếu __exit__ trả về True thì exception bị nuốt.
• Bản async: async with, __aenter__/__aexit__ hoặc asynccontextmanager.

Hay sai: quên raise lại exception trong khối except, khiến lỗi bị che mất và code phía sau tưởng mọi thứ đã thành công.

Nguyên tắc: secret không nằm trong Git, không in ra log, được cấp theo quyền tối thiểu và xoay vòng được.

• Dùng secret manager (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) làm nguồn gốc.
• Đồng bộ vào cluster bằng External Secrets Operator hoặc CSI driver; nếu phải để trong Git thì mã hoá (Sealed Secrets, SOPS).
• Kubernetes Secret mặc định chỉ base64: bật mã hoá etcd và giới hạn RBAC đọc Secret.
• CI dùng biến được che (masked), ưu tiên OIDC để lấy credential ngắn hạn thay vì key dài hạn.
• Bật quét secret khi push code.

Người phỏng vấn muốn nghe: biết base64 không phải mã hoá, và có kế hoạch xoay key khi bị lộ.

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.

"I'd focus on the impact and what we're doing about it, not the technical details. For example: 'Some customers saw the wrong total in their cart when they applied two discount codes at once. No payments were affected. We've found the cause, the fix is being tested now, and it should be live tomorrow morning. Until then, we've limited orders to one code each.'"

Mẹo: cấu trúc ảnh hưởng – nguyên nhân (một câu đơn giản) – đã làm gì – khi nào xong. Tránh thuật ngữ như "null pointer", "race condition". Cụm hữu ích: "The good news is…", "To be safe, we have…".

Người phỏng vấn muốn biết bạn tự quản lý được và giao tiếp chủ động khi không ngồi cạnh team.

• Cập nhật tiến độ thường xuyên trên công cụ chung (ticket, kênh chat của team), không để người khác phải hỏi.
• Viết rõ ràng: câu hỏi có ngữ cảnh, ghi lại kết quả thảo luận.
• Có khung giờ làm việc ổn định, phản hồi trong giờ làm, báo trước khi vắng.
• Dùng ngày lên văn phòng (nếu hybrid) cho thảo luận, brainstorm, gặp gỡ team.

Câu mẫu: "Team cũ của em làm hybrid hai ngày ở văn phòng. Những ngày remote em cập nhật trạng thái task mỗi sáng và cuối ngày, vướng gì thì gọi nhanh 10 phút thay vì nhắn qua lại."