Virtual try-on — bốn lớp kiến trúc không ai nói trước

Thử đồ ảo" tưởng chỉ cần gọi API sinh ảnh — nhưng production thật cần bốn lớp xếp chồng mà team nào cũng hay thiếu một.

Mình hỏi thật: feature "thử đồ ảo bằng AI" — bạn nghĩ cần mấy API call?

Nếu bạn trả lời "một" — gọi model sinh ảnh, đưa ảnh người + ảnh sản phẩm, nhận kết quả — thì bạn đang ở đúng chỗ mà hầu hết team mình gặp đều dừng lại. Demo thì đẹp. Lên production thì... khách thử áo đỏ mà model trả về áo xanh, recommend toàn đồ không liên quan, và search thì gõ "váy dự tiệc" ra dép tông.

Bài này mình bóc ra bốn lớp kiến trúc phía sau một hệ thống virtual try-on thực tế — lấy cảm hứng từ một reference architecture trên AWS. Nhưng mình sẽ nói luôn: lớp nào tự build được, lớp nào nên dùng managed service, và lớp nào có open-source thay thế ngon lành.

Lớp 1 — Sinh ảnh "mặc thử": pipeline dài hơn bạn tưởng

Phần core của virtual try-on là image generation: đưa ảnh khách hàng + ảnh sản phẩm, model sinh ra ảnh khách đang mặc sản phẩm đó.

AWS dùng combo Amazon Nova Canvas (sinh ảnh) + Amazon Rekognition (detect khuôn mặt, tư thế) cho bước này. Rekognition lo phần "hiểu" ảnh đầu vào — xác định vùng cơ thể, góc chụp — rồi Nova Canvas sinh ảnh output.

Nói thẳng ra thì phần sinh ảnh chỉ là bước cuối của một pipeline dài. Trước khi model chạy, bạn cần:

Ví dụ cụ thể: Giả sử team bạn xây feature thử kính mắt cho một e-commerce Việt Nam. Khách upload selfie, chọn gọng kính. Nếu bạn chỉ gọi API sinh ảnh "đặt kính lên mặt" — kết quả sẽ ổn khi khách chụp thẳng, nhưng nghiêng 15 độ là kính lệch. Bạn cần face landmark detection trước, rồi mới gọi sinh ảnh.

Open-source thay thế: Cộng đồng có IDM-VTON (model virtual try-on mở trên Hugging Face), kết hợp MediaPipe cho pose/face detection. Trade-off? Bạn tự host, tự scale, tự chịu latency.

Lớp 2 — Recommendation: "mặc cái này thì hợp cái kia"

Đây là lớp mà nhiều team đẩy sang "phase 2" rồi quên luôn. Nhưng nếu khách thử một chiếc áo và bạn không gợi ý được quần/giày phù hợp ngay lúc đó, bạn đang bỏ tiền trên bàn.

AWS dùng Amazon Titan Multimodal Embeddings — biến cả ảnh lẫn text thành vector, rồi tìm sản phẩm "gần" nhau trong không gian vector. Khác với collaborative filtering truyền thống ("người mua A cũng mua B"), cách này hiểu được visual style — áo linen trắng sẽ được recommend cùng quần khaki, không phải cùng áo linen đen.

Kịch bản team Việt Nam: Bạn đang xây cho một brand thời trang nội địa, catalog khoảng 2.000 SKU. Embed toàn bộ ảnh sản phẩm thành vector, lưu vào vector store. Mỗi khi khách thử một món, query top-5 sản phẩm gần nhất theo visual similarity. Đơn giản, nhưng hiệu quả rõ rệt so với recommend theo category cứng.

Open-source: CLIP hoặc SigLIP cho phần embedding, Qdrant hoặc Milvus cho vector store. Pipeline tự build hết được — chi phí chủ yếu là GPU cho embedding lần đầu.

Lớp 3 — Search theo ý, không theo từ khóa

Lớp này biến search bar từ keyword matching thành intent understanding. AWS dùng OpenSearch Serverless với vector search — khách gõ "áo đi biển nhưng che được bắp tay" và hệ thống hiểu context, không chỉ match từ khóa.

Pha search layer vào hệ thống virtual try-on giống quán cà phê có menu theo mood: khách không cần biết tên chính xác, chỉ mô tả cảm giác muốn, barista tự hiểu phải pha gì.

Bẫy hay gặp: Team thường index sản phẩm bằng title + description. Nhưng thời trang phụ thuộc nhiều vào visual — hai cái áo cùng mô tả "áo thun trắng basic" có thể nhìn hoàn toàn khác. Bạn cần hybrid search: vừa text embedding vừa image embedding, rồi combine score. Bỏ qua image embedding là mất một nửa tín hiệu.

Lớp 4 — Analytics: không sexy nhưng quyết định sống chết

AWS dùng DynamoDB cho phần này — ghi log mọi interaction: khách thử món gì, recommend có click không, search query nào trả kết quả trống.

Plot twist: lớp này mới là lớp giúp bạn justify budget cho cả hệ thống. Không có data, bạn không chứng minh được virtual try-on giảm return rate hay tăng conversion. Mà không chứng minh được thì sếp cắt budget sprint sau — chuyện cũ như trái đất.

Thử ngay trong một buổi chiều

Bạn không cần build cả bốn lớp để bắt đầu:

  1. Muốn nhanh: Clone repo mẫu từ AWS (link trong nguồn tham khảo) — có CDK stack deploy được luôn trên account của bạn
  2. Muốn tự chủ: Lấy IDM-VTON từ Hugging Face, chạy trên Colab hoặc một GPU instance. Upload 5–10 ảnh sản phẩm, 2–3 ảnh người, chạy pipeline thử
  3. Thêm recommendation: Dùng CLIP encode 50 ảnh sản phẩm, lưu vào Qdrant chạy local bằng Docker, query nearest neighbor
  4. Đo kết quả: Screenshot before/after, gửi sếp — đây là cách nhanh nhất để có buy-in cho sprint tiếp theo

Cái bẫy team nào cũng giẫm ít nhất một lần

Pattern mình thấy lặp đi lặp lại: team demo virtual try-on trên 10 sản phẩm, sếp gật gù, rồi scale lên 10.000 SKU thì mọi thứ vỡ.

Lý do? Latency. Sinh một ảnh virtual try-on mất vài giây — chấp nhận được cho demo. Nhưng khi khách browse 20 sản phẩm, mỗi cái đều muốn thử, bạn cần caching strategy, pre-generation cho sản phẩm hot, và fallback khi model quá tải. Kiến trúc serverless (Lambda + API Gateway) giúp scale tự động, nhưng cold start với model nặng là bài toán thật.

Giả sử team bạn 3 dev, chạy sprint 2 tuần: đừng cố ôm cả bốn lớp cùng lúc. Ship lớp 1 (sinh ảnh) + lớp 4 (analytics) làm MVP. Recommendation và smart search là lớp tăng trưởng — thêm sau khi đã có user data thật.

Rót đúng thứ tự, ly mới ra hình

Xây virtual try-on giống pha cà phê nhiều lớp: espresso (sinh ảnh) phải chuẩn trước, sữa (recommendation) rót sau, latte art (search) là để gây ấn tượng — và cái ly (analytics) thì phải có từ đầu, không thì rót đi đâu?

Bốn lớp, không lớp nào thừa. Nhưng thứ tự triển khai mới quyết định bạn ship được hay cháy sprint.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo