Vì sao PM phải hiểu kiến trúc
Bạn không cần code, nhưng bạn phải đọc được bản đồ. Vì đội của bạn là kỹ thuật, họ sẽ tôn trọng PM hiểu ranh giới hệ thống, biết chỗ nào là điểm nghẽn, chỗ nào là rủi ro chung. Không hiểu kiến trúc, bạn sẽ ưu tiên sai và hứa những thứ không khả thi.
Các tầng của một nền tảng AI nội bộ
- Tầng dữ liệu (data layer) — feature store, dữ liệu huấn luyện, dữ liệu đánh giá. Ai kiểm soát dữ liệu, kiểm soát chất lượng model.
- Tầng model — model được huấn luyện/fine-tune, và model registry (nơi đăng ký, gắn version, metadata). Đây là 'kho tài sản' của nền tảng.
- Tầng phục vụ (serving/inference) — API/gateway để đội khác gọi. Đây là bề mặt hợp đồng quan trọng nhất, nơi phát sinh độ trễ, chi phí, giới hạn tải.
- Tầng đánh giá (eval) — bộ test tự động đo chất lượng model trước và sau khi lên. Nền tảng không có eval dùng chung thì mỗi đội tự phán, không so sánh được.
- Tầng quan sát (observability) — logging, tracing, đo drift, đo chi phí theo đội. Không thấy được thì không quản được.
Khung tư duy: "đường đi của một request"
Hãy tập vẽ hành trình một yêu cầu suy luận: đội Search gọi → gateway xác thực và định tuyến → chọn version model → chạy inference → ghi log + metric → trả kết quả. Với mỗi mũi tên, hỏi: ai chịu trách nhiệm, đo bằng gì, hỏng thì sao? Bài tập này giúp bạn phát hiện điểm nghẽn và trách nhiệm mập mờ.
Model registry — trái tim của versioning
Model registry là nơi mọi model được đăng ký với: tên, version, chỉ số eval, dữ liệu huấn luyện, người sở hữu, trạng thái (staging/production/deprecated). Đây là công cụ trung tâm để chống phân mảnh: nếu mọi model dùng chung đều phải qua registry, bạn có một 'nguồn sự thật' duy nhất. Nếu đội nào cũng có model 'ngoài luồng', bạn mất kiểm soát ngay.
Ví dụ cụ thể
Công ty có embedding-v3 phục vụ 4 đội. Trong registry, nó ghi rõ: eval recall@10 = 0.82, chi phí 0.4ms/query, deprecate v2 sau 90 ngày. Khi đội Fraud phàn nàn kết quả kém, bạn mở registry, thấy họ vẫn gọi v2 chưa migrate — vấn đề được định vị trong 5 phút thay vì 5 ngày.
Sai lầm thường gặp
- Coi gateway chỉ là 'proxy kỹ thuật' thay vì bề mặt sản phẩm nơi mọi SLA và chính sách được thực thi.
- Không có eval dùng chung → mỗi đội tự tuyên bố chất lượng, không ai so sánh được, không nâng cấp an toàn được.
- Cho phép model ngoài registry vì 'gấp' → sinh ra shadow model, mầm mống phân mảnh.
Checklist đọc bản đồ nền tảng
- [ ] Tôi vẽ được đường đi của một request qua đủ 5 tầng.
- [ ] Tôi biết mọi model production đều nằm trong registry (nếu không, đó là rủi ro cần đưa vào roadmap).
- [ ] Tôi biết ai sở hữu từng tầng và đo bằng metric gì.
- [ ] Tôi xác định được ít nhất một điểm nghẽn hiện tại (thường là gateway hoặc eval).
Bài tập vẽ nhanh trong 10 phút
Lấy một năng lực nền tảng bạn đang phụ trách và vẽ đủ 5 tầng cho nó: dữ liệu nào nuôi model, model nào trong registry, gateway phục vụ ra sao, eval đo bằng bộ test nào, observability thấy được những gì. Với mỗi tầng, ghi tên người sở hữu và một metric. Nếu có ô trống, đó chính là điểm mù cần đưa vào roadmap. Bài tập đơn giản này thường phát lộ ngay những trách nhiệm không ai nhận và những chỗ không đo được — nguồn gốc của phần lớn sự cố nền tảng.
Hiểu bản đồ này, bạn nói cùng ngôn ngữ với kỹ sư và ưu tiên roadmap dựa trên hiện thực hệ thống, không phải cảm tính.