Bin E-Commerce

Tối ưu ảnh sản phẩm có kiểm duyệt

Mục lục trang

Vì sao cần chức năng này?

Biến ảnh sản phẩm thành hình ảnh bán hàng chuyên nghiệp bằng AI

Tạo ảnh nền trắng hoặc lifestyle đẹp, rõ và phù hợp hơn; seller chọn bản tốt nhất để khách dễ hình dung sản phẩm.

AI làm gì?

3 bước
Ảnh sản phẩmAI tối ưuSeller duyệt
Nổi bật hơn
Dễ hình dung
Seller duyệt

Luồng tổng quát

Từ ảnh nguồn đến ảnh sẵn sàng dùng

5 chặng
  1. 01

    Chọn ảnh nguồn

    Seller chọn sản phẩm, ảnh gốc, kiểu nền trắng hoặc lifestyle và gửi yêu cầu.

  2. 02

    Xác minh trước khi tạo

    Backend kiểm tra seller, quyền thao tác, ảnh nguồn và phiên bản hiện tại.

  3. 03

    Tạo ảnh ở nền

    Job được lưu để worker xử lý; màn hình seller không phải chờ provider AI.

  4. 04

    Seller xem và chọn

    Output được trả về để xem trước, so sánh và quyết định có sử dụng hay không.

  5. 05

    Xác nhận hoặc quay lại

    Ảnh chỉ được sử dụng sau khi kiểm tra lần cuối; seller vẫn có thể từ chối hoặc khôi phục.

Điểm kiểm soát: AI chỉ tạo đề xuất; seller là người quyết định ảnh nào được sử dụng.

Tài liệu chi tiết

1Kiến trúc hệ thốngSeller UI gửi yêu cầu nhanh; worker xử lý nền; Product Service là nơi duy nhất áp dụng thay đổi vào catalog.
1.1Luồng hoạt động của hệ thốngTheo dõi từ lúc seller chọn ảnh, backend xác minh và tạo job, worker sinh preview, đến lúc seller duyệt để cập nhật catalog hoặc quay lại phiên bản an toàn.
1.1.1Luồng tạo preview · đi từ trên xuống dướiMỗi bước trả lời ba câu hỏi: hệ thống làm gì, vì sao phải làm và đánh đổi nào được chấp nhận để seller có preview nhanh nhưng an toàn.

Request → kiểm tra → worker → review

Đọc theo mũi tên từ bước 01 đến bước 06

6 bước
  1. Bước 01

    Input

    Chọn ảnh nguồn và kiểu hiển thị

    Làm gì?

    Seller chọn sản phẩm cần làm ảnh, ảnh nguồn đang dùng và kiểu nền trắng hoặc lifestyle.

    Tại sao?

    Nếu chọn nhầm sản phẩm hoặc ảnh nguồn, AI có thể tạo một ảnh đẹp nhưng không đúng hàng thật.

    Đánh đổiRequest cần thêm product, source asset và mode; đổi lại AI có đủ ngữ cảnh để tạo đúng mục tiêu.

    Công nghệ phía sau bước này

    Chọn 1 pipeline

    Nền trắng

    Local

    rembg/u2net tách chủ thể, Pillow ghép nền trắng và xuất WebP. Không gọi OpenAI nên không phát sinh token/phí theo request.

    Chọn khi: cần nhanh, ổn định, tiết kiệm cho ảnh catalog.

    Lifestyle

    OpenAI

    OpenAILifestyleImageProvider gọi gpt-image-2 để đổi bối cảnh, ánh sáng và mặt phẳng xung quanh sản phẩm.

    Đánh đổi: đẹp và linh hoạt hơn nhưng tốn phí, lâu hơn, cần seller review.

    Hồ sơ chất lượng

    Lifestyle / OpenAI

    Preview

    Nhanh để duyệt

    Quality low, kích thước provider 1024×1024, nén JPEG 65%, giới hạn cạnh 768px.

    Mục tiêu là phản hồi nhanh và đủ rõ để seller kiểm tra bố cục, không phải bản dùng cuối.

    Final

    Dùng sau khi duyệt

    Quality medium, kích thước provider 1024×1024, nén JPEG 85%, giới hạn cạnh 1024px.

    Được tạo trong trạng thái FINALIZING sau khi seller xác nhận và trước khi Product Service apply.

    Nền trắng là pipeline local rembg/Pillow nên dùng giới hạn xử lý local riêng; bảng trên mô tả profile provider lifestyle.

  2. Bước 02

    Identity

    Xác thực seller và quyền thao tác

    Làm gì?

    Gateway đọc JWT, xác định seller rồi kiểm tra người đó có quyền xem và tạo ảnh cho sản phẩm hay không.

    Tại sao?

    Không để request giả, sai shop hoặc người khác dùng nhầm quota AI của seller.

    Đánh đổiRequest không hợp lệ bị từ chối ngay; đổi lại hệ thống tiết kiệm chi phí gọi AI.
    Bước 03

    Guard

    Kiểm tra sản phẩm trước khi tạo

    Làm gì?

    AI Service đối chiếu owner, ảnh nguồn và version hiện tại trước khi cho phép tạo job.

    Tại sao?

    Đảm bảo preview được tạo từ dữ liệu seller đang sở hữu, không dùng ảnh đã bị thay thế hoặc xóa.

    Đánh đổiThêm một lượt kiểm tra giữa service, nhưng tránh tốn AI cho dữ liệu cũ và sai phạm vi.
  3. Bước 04

    Queue

    Lưu job để xử lý nền

    Xem logic

    Làm gì?

    Backend lưu request ở trạng thái PENDING rồi gửi event cho worker; seller nhận phản hồi ngay.

    Tại sao?

    Việc tạo ảnh có thể mất thời gian, nên màn hình seller không bị khóa trong lúc provider AI xử lý.

    Đánh đổiCần queue, lease và trạng thái job; đổi lại hệ thống retry được và không làm request HTTP bị timeout.
    Bước 05

    Worker

    Tạo ảnh và lưu dấu vết output

    Xem logic

    Làm gì?

    Worker nhận job, gọi provider AI, upload preview lên S3 và lưu output liên kết với ảnh nguồn.

    Tại sao?

    Seller cần biết ảnh được tạo từ nguồn nào, provider nào và có thể xem lại đúng preview đó.

    Đánh đổiPreview phải có retention và cleanup; đổi lại storage không phình vô hạn và output vẫn truy vết được.
  4. Bước 06

    Review

    Trả preview để seller quyết định

    Làm gì?

    Job chuyển sang REVIEW_REQUIRED; seller xem ảnh, chọn bản phù hợp hoặc từ chối trước khi áp dụng.

    Tại sao?

    AI chỉ đưa ra phương án hình ảnh; seller mới hiểu rõ sản phẩm, thương hiệu và mục tiêu bán hàng.

    Đánh đổiThêm một bước review, nhưng ngăn ảnh sai được dùng ngay và giữ quyền quyết định ở seller.
1.1.2Luồng duyệt và cập nhật · preview đến sản phẩmPreview chỉ là đề xuất. Seller chọn trước, backend kiểm tra lại sau; sản phẩm chỉ thay đổi khi đúng người, đúng phiên bản và đúng transaction.

Review → kiểm tra → quyết định → kết quả

Chỉ seller chọn ảnh; backend mới được phép ghi thay đổi

4 bước
  1. Bước 01

    Review

    Seller xác nhận preview muốn dùng

    Làm gì?

    Seller mở job REVIEW_REQUIRED, xem preview và xác nhận bản phù hợp với sản phẩm trước khi yêu cầu tạo ảnh final.

    Tại sao?

    AI có thể tạo ảnh đẹp nhưng không hiểu đầy đủ chiến lược thương hiệu; quyết định cuối phải thuộc về seller.

    Đánh đổiThêm một lần xác nhận, nhưng tránh việc output chưa phù hợp tự động thay đổi sản phẩm.
  2. Bước 02

    Guard

    Kiểm tra lại quyền và phiên bản

    Làm gì?

    Backend kiểm tra seller, job, ownership, trạng thái output và version sản phẩm ngay trước action.

    Tại sao?

    Trong lúc seller review, sản phẩm có thể đã bị người khác sửa; không được ghi đè thay đổi mới.

    Đánh đổiApply có thể bị từ chối dù preview vẫn hợp lệ; đổi lại dữ liệu sản phẩm luôn an toàn.
  3. Bước 03A

    Apply

    Tạo final rồi ghi ảnh bằng transaction

    Làm gì?

    Lần xác nhận đầu chuyển job sang FINALIZING để worker tạo ảnh final; sau đó Product Service lock sản phẩm, lưu snapshot, cập nhật gallery row rồi chuyển job thành APPLIED.

    Tại sao?

    Ảnh preview chỉ để duyệt; ảnh final và gallery phải thành công cùng nhau, không để sản phẩm cập nhật nửa chừng.

    Đánh đổiCần lock và transaction lâu hơn một lần update thường, nhưng có thể phục hồi nếu có lỗi.
    Bước 03B

    Reject / Rollback

    Từ chối hoặc quay về bản trước

    Làm gì?

    Reject cleanup preview; rollback khôi phục snapshot đã lưu và chuyển job sang trạng thái tương ứng.

    Tại sao?

    Seller luôn cần đường lui nếu ảnh không đạt, provider lỗi hoặc thay đổi mới gây vấn đề.

    Đánh đổiCần lưu snapshot và dọn asset; đổi lại ảnh gốc không bị mất và có thể khôi phục rõ ràng.

Kết quả sau quyết định

Mỗi trạng thái cho biết sản phẩm đang ở đâu

review → mutation → recovery

  • REVIEW_REQUIRED

    Seller chưa chọn output để áp dụng.

  • Version check

    Đảm bảo không ghi đè thay đổi mới.

  • Transaction

    Snapshot và gallery được cập nhật cùng nhau.

  • APPLIED / ROLLED_BACK

    Có kết quả cuối và đường phục hồi.

1.2Công nghệ sử dụngCác thành phần phục vụ seller UI, API gateway, xử lý AI bất đồng bộ, lưu asset và cập nhật catalog có kiểm soát.
  • Next.jsSeller UI
  • NestJSAPI Gateway
  • PostgreSQLJob state
  • RedisRate limit
  • FastAPIAI worker API
  • PythonAI processing
  • OpenAI Images APIgpt-image-2 · Lifestyle
  • Apache KafkaJob queue và DLQ
  • Media ServiceS3/CDN asset owner
1.3Các service tham giaAI Service điều phối job và output; Product Service giữ ownership và mutation catalog; Media Service giữ asset; Recommendation Service cung cấp dữ liệu impact.
1.3.1Luồng tạo và xử lý previewTừ seller UI đến generated asset REVIEW_REQUIRED; request không chờ provider AI.
  1. 01 · Seller

    Seller Center

    Gửi input, đọc overview/job và hiển thị review actions.

  2. 02 · Gateway

    AI proxy controller

    Bảo vệ view/generate và forward identity/context.

  3. 03 · Orchestrator

    AI Service

    Resolve owner, persist batch/job, quota và publish event.

  4. 04 · Worker

    Provider + Media

    Generate output, gửi Media Service lưu asset và trả job về review.

1.3.2Luồng duyệt và cập nhật catalogApply/rollback luôn quay về service sở hữu product để giữ transaction và snapshot.
  1. 01 · Decision

    Seller review

    Xác nhận preview hoặc reject; không gửi URL tùy ý làm nguồn sự thật.

  2. 02 · Guard

    Gateway + access

    Kiểm tra action apply/rollback trước proxy và tại domain.

  3. 03 · Mutation

    Product Service

    Lock, version check, snapshot và cập nhật đúng gallery row.

  4. 04 · Recovery

    AI job state

    APPLIED, REJECTED hoặc ROLLED_BACK phản ánh kết quả cuối.

1.3.3Luồng đo impact sau applyAI Service giữ mốc lifecycle; Recommendation Service trả dữ liệu view/sales để dashboard so sánh trước và sau.
  1. 01 · Lifecycle

    AI Service

    Xác định product đã apply cover và tạo impact session boundary.

  2. 02 · Analytics

    Recommendation Service

    Tổng hợp baseline, daily views và sales theo product.

  3. 03 · Presentation

    Seller Center

    Hiển thị trạng thái collecting/ready và delta theo sản phẩm.

Ranh giới service: AI Service không sở hữu product gallery hoặc binary S3; Product Service không gọi provider AI; Recommendation Service chỉ là nguồn dữ liệu analytics view/sales.

2Logic xử lý ảnhState machine, permission theo hành động, ownership và version check phối hợp để preview không trở thành thay đổi ngoài ý muốn.
2.1Vòng đời batch/jobBatch giữ danh tính của một request; job theo dõi quá trình tạo ảnh. Đọc từ trái sang phải trên desktop hoặc từ trên xuống dưới trên mobile để biết output đang ở đâu.

Batch là gì?

Một lần seller gửi yêu cầu

Batch gom sản phẩm, ảnh nguồn, mode hiển thị và idempotency key. Nhờ vậy retry cùng một request không tạo thêm job trùng.

Job là gì?

Một đơn vị worker phải xử lý

Job có state, lease và output riêng. Worker chỉ chuyển job qua những trạng thái đã được backend cho phép.

  1. Bước01

    Request

    Tạo batch

    Backend làm gì?
    Backend kiểm tra request, tạo batch và ghi fingerprint để nhận diện lần gửi này.
    Seller hiểu gì?
    Yêu cầu đã được nhận; chưa gọi provider AI và chưa đụng vào sản phẩm.
    Đi tiếp đến
    PENDING
  3. Bước02

    Waiting

    Chờ worker claim

    Backend làm gì?
    Job ở PENDING trong queue. Một worker nhận lease có thời hạn trước khi bắt đầu xử lý.
    Seller hiểu gì?
    Seller có thể rời màn hình; hệ thống vẫn giữ request và sẽ tiếp tục xử lý nền.
    Đi tiếp đến
    PROCESSING
  5. Bước03

    Processing

    Tạo preview

    Backend làm gì?
    Worker fetch source, prepare prompt, gọi provider AI, upload output và lưu lineage.
    Seller hiểu gì?
    Ảnh đang được tạo; mọi output vẫn là preview riêng, chưa phải ảnh đang dùng.
    Đi tiếp đến
    REVIEW_REQUIRED hoặc FAILED
  7. Bước04

    Review

    Chờ seller chọn

    Backend làm gì?
    Job chuyển REVIEW_REQUIRED và giữ preview để seller xem, chọn hoặc từ chối.
    Seller hiểu gì?
    Seller nhìn thấy kết quả thật trước khi cho phép bất kỳ thay đổi nào.
    Đi tiếp đến
    FINALIZING hoặc REJECTED
  9. Bước05

    Result

    Kết thúc có kiểm soát

    Backend làm gì?
    Apply ghi transaction và snapshot; lỗi được FAILED; bản đã apply có thể ROLLED_BACK.
    Seller hiểu gì?
    Sản phẩm chỉ đổi khi action hợp lệ thành công; nếu không, ảnh gốc vẫn an toàn.
    Đi tiếp đến
    APPLIED, FAILED hoặc ROLLED_BACK
2.2Permission và sở hữu sản phẩmMột nút trên UI không tự tạo ra quyền. Mỗi action đi qua Gateway rồi được Product Service kiểm tra lại trên dữ liệu thật trước khi được chấp nhận.

  1. 01 · Seller action

    Seller gửi yêu cầu

    Seller muốn xem job, tạo preview, áp dụng ảnh hoặc khôi phục ảnh cũ. Backend nhận action cụ thể, không nhận một quyền “dùng AI” chung chung.

  2. 02 · Gateway

    Kiểm tra route permission

    Gateway xác thực JWT, đọc permission profile và chặn request trước khi nó đi vào service xử lý ảnh.

  3. 03 · Product Service

    Kiểm tra ownership và version

    Service đối chiếu seller có thật sự sở hữu sản phẩm, ảnh nguồn còn hợp lệ và version chưa bị thay đổi hay không.

  4. 04 · Decision

    Cho phép hoặc từ chối

    Chỉ khi tất cả điều kiện hợp lệ, action mới được chạy; nếu không, backend trả lỗi rõ ràng và không ghi dữ liệu.

View

Đọc overview và job

Cho xem trạng thái, preview và lịch sử xử lý. Không được tạo ảnh, apply hoặc rollback.

Generate

Tạo preview mới

Cho tạo job và gọi AI trên source asset thuộc shop. Output chỉ là preview, chưa được đổi sản phẩm.

Apply

Ghi ảnh mới vào sản phẩm

Bắt buộc có seller review, đúng owner, đúng version và transaction thành công.

Rollback

Khôi phục snapshot

Chỉ chạy sau APPLIED. Backend khôi phục snapshot đã lưu, không tin vào trạng thái hiển thị ở UI.

2.3Queue và điều phối jobKhi seller bấm tạo ảnh, hệ thống không đứng chờ AI hoàn thành. Request được ghi nhận, xếp hàng và giao cho worker theo cách có thể retry mà không tạo thêm job trùng.
Cách đọc: API chỉ xác nhận “đã nhận yêu cầu”. Outbox Relay đọc event bền vững từ PostgreSQL và publish sang Kafka; image worker lấy event ra xử lý. Vì vậy seller không phải chờ AI chạy xong trong cùng một request.

01 · Command

Nhận request và tạo job

API kiểm tra quyền, fingerprint và idempotency. Nếu hợp lệ, backend lưu job ở PENDING rồi trả jobId ngay cho seller.

Kết quả: yêu cầu đã được ghi nhận, nhưng ảnh chưa được tạo.

02 · Outbox → Kafka

Đưa event vào hàng đợi

Backend lưu outbox cùng job, relay publish event gồm jobId và fingerprint vào Kafka. Event lỗi hoặc hết lượt retry được đưa vào DLQ.

Kết quả: công việc được tách khỏi vòng đời của màn hình seller.

03 · Kafka Worker

Nhận và claim job

Image worker consume event, lấy lease, kiểm tra job còn hợp lệ và chuyển sang PROCESSING; lease ngăn hai consumer xử lý cùng một job.

Kết quả: chỉ một worker chịu trách nhiệm cho lần xử lý này.

2.4Worker, Media Service và lineage outputWorker không chỉ gọi AI rồi trả về một file ảnh. Nó phải chứng minh preview này được tạo từ ảnh nguồn nào, bằng provider nào, lưu ở đâu và còn được phép review trong bao lâu.
Cách đọc: Worker giống một dây chuyền: lấy đúng ảnh nguồn, nhờ provider tạo bản mới, rồi lưu bản preview cùng thông tin để seller kiểm tra được nó sinh ra từ đâu.

01 · Prepare

Đọc đúng source

Worker lấy đúng ảnh seller đã chọn, kiểm tra mode nền trắng/lifestyle, prompt version và product version trước khi gọi provider.

Mục đích: không tạo ảnh từ source đã bị xóa hoặc đã cũ.

02 · Generate

Gọi provider có kiểm soát

Worker gửi request tới provider AI và chờ output. Nó lưu provider/model, prompt version và failure code để biết kết quả hoặc lỗi đến từ đâu.

Mục đích: retry đúng lỗi tạm thời, không gọi lại vô hạn với lỗi input.

03 · Persist

Upload và ghi lineage

Output được gửi đến Media Service để lưu vào S3/CDN. Database lưu sourceId, outputId, provider, prompt version, retention và jobId rồi chuyển job sang REVIEW_REQUIRED.

Kết quả: seller có preview để xem, còn gallery sản phẩm vẫn chưa thay đổi.

2.5Kiểm soát token và chi phí AIChi phí được giảm bằng cách không gọi provider thêm khi không cần và chỉ tạo đúng phần seller đã chọn.

Nền trắng

Local, không tính phí theo request

Worker dùng rembg/u2net để tách nền và Pillow ghép canvas trắng. Pipeline này có thể retry có backoff vì không gọi provider AI trả phí.

Lifestyle

OpenAI, chỉ gọi khi seller có nhu cầu

Worker gọi gpt-image-2 qua OpenAILifestyleImageProvider. Lease và max_retries=0 ngăn redelivery/timeout tự động nhân đôi request có thể đã bị tính phí.

Quota production: mỗi seller được tối đa 2 lượt trong cửa sổ 24 giờ. Development/test dùng cửa sổ cấu hình riêng.
Giới hạn cần nói rõ: AI Service lưu provider, model và prompt version để audit, nhưng chưa có token meter trên frontend. Số tiết kiệm được là provider call tránh được, không phải token giả định.
2.6Retry, reject và rollbackWorker claim lease trước external call để redelivery không nhân đôi lời gọi trả phí. Hệ thống phân loại lỗi trước khi retry; reject xử lý preview không đạt, còn rollback phục hồi sản phẩm đã từng apply.

01 · Retry

Làm lại có điều kiện

Dùng khi lỗi có thể tự hết

Khi nào?
Worker mất kết nối, timeout hạ tầng hoặc provider tạm unavailable.
Làm gì?
Worker claim lease, tăng attempt và chạy lại trong giới hạn. Pipeline local được retry có backoff; OpenAI không auto-retry vì request ảnh có thể đã bị tính phí.
Kết quả
Thành công thì đi tiếp; vượt giới hạn thì job thành FAILED để seller biết và xử lý lại chủ động.

02 · Reject

Bỏ preview

Dùng khi seller không chọn ảnh

Khi nào?
Preview không đúng sản phẩm, không hợp thương hiệu hoặc seller không muốn sử dụng.
Làm gì?
Đổi job thành REJECTED và cleanup generated output trên storage tạm.
Kết quả
Ảnh gốc và catalog đang dùng không bị xóa; reject chỉ kết thúc bản preview bị từ chối.

03 · Rollback

Khôi phục

Dùng sau khi ảnh đã được apply

Khi nào?
Ảnh mới đã vào catalog nhưng sau đó phát hiện không phù hợp hoặc cần quay lại bản cũ.
Làm gì?
Product Service dùng snapshot đã lưu để phục hồi trong transaction.
Kết quả
Chỉ job đã APPLIED mới được rollback; trạng thái cuối là ROLLED_BACK, không tạo lại ảnh bằng AI.
2.7Đo tác động sau tối ưuSau khi ảnh cover được apply, hệ thống theo dõi lượt xem và lượt bán theo từng sản phẩm để seller so sánh trước và sau một cách minh bạch.
Ranh giới dữ liệu: Seller UI đọc impact theo product từ AI Service; AI Service giữ lifecycle job, còn Recommendation Service là nguồn dữ liệu analytics view/sales.