Từ blueprint của NVIDIA đến trợ lý mua sắm thực tế: Phân tích một dự án mẫu “Retail Shopping Assistant”

by Alex Le

Trong lĩnh vực thương mại điện tử (E-commerce), đặc biệt là ngành thời trang và phụ kiện, trải nghiệm mua sắm cá nhân hóa đòi hỏi một giải pháp thông minh hơn những chatbot thông thường. Khách hàng không chỉ muốn tìm kiếm sản phẩm bằng văn bản mà còn muốn upload một tấm ảnh mẫu và ra lệnh: “Tìm cho tôi chiếc váy giống thế này nhưng giá dưới $100”.

Giải pháp AI Retail Shopping Assistant dựa trên tiêu chuẩn thiết kế NVIDIA Blueprint dưới đây cung cấp một kiến trúc tham khảo mẫu mực (Reference Architecture). Giải pháp này giải quyết triệt để bài toán tích hợp giữa Tìm kiếm đa phương thức (Multimodal Retrieval), Quản lý giỏ hàng có ràng buộc (Cart Grounding) và Kiểm soát an toàn (Guardrails).

Định vị giải pháp: Đây thuần túy là giải pháp trợ lý mua sắm dạng văn bản (Text-based Retail Assistant) chạy trên kiến trúc đa tác tử. Hệ thống tập trung tối ưu hóa trải nghiệm runtime (tra cứu, giỏ hàng, an toàn) và không tích hợp sẵn tính năng tương tác giọng nói (Voice Agent), RAG doanh nghiệp tổng quát, hay hệ thống thu thập Feedback/Like-Dislike tự động ở backend.

1. Kiến Trúc Hệ Thống và Luồng Điều Phối LangGraph

Giải pháp được module hóa thành các microservices độc lập thông qua Docker Compose, giao tiếp mượt mà để chia sẻ trách nhiệm xử lý:

Đoạn mã

Phần chú thích ngắn gọn cho kiến trúc này:

  • React UI: Giao diện người dùng tương tác, gửi câu hỏi và nhận phản hồi dạng streaming.
  • Nginx: Cổng trung gian nhận request từ UI và chuyển vào backend.
  • Chain Server + LangGraph: Bộ não điều phối chính, quyết định nên tìm sản phẩm, tư vấn, xử lý giỏ hàng hay trả lời trực tiếp.
  • Memory Retriever: Lưu và lấy lại ngữ cảnh hội thoại, thông tin giỏ hàng và lịch sử tương tác.
  • Guardrails: Lớp kiểm duyệt an toàn, kiểm tra cả câu hỏi đầu vào lẫn câu trả lời đầu ra.
  • Catalog Retriever: Thành phần tìm kiếm sản phẩm trong catalog, hỗ trợ cả truy vấn văn bản và hình ảnh.
  • Milvus + CSV: Nơi lưu dữ liệu sản phẩm và vector tìm kiếm phục vụ truy xuất nhanh.
  • Embedding Models: Giúp hệ thống hiểu ý nghĩa của text và hình ảnh sản phẩm để tìm kiếm chính xác hơn.
  • LLM NIM/API: Mô hình ngôn ngữ dùng để lập kế hoạch, tư vấn, tạo câu trả lời và tóm tắt hội thoại.

2. Giải Pháp Multimodal Product Retrieval (Tìm Kiếm Bằng Ảnh + Text)

Thay vì chỉ tìm kiếm theo từ khóa truyền thống, cấu trúc catalog_retriever tích hợp giải pháp RAG đa phương thức trên nền tảng Milvus Vector DB:

  • Tách biệt Collection: Cơ sở dữ liệu được chia làm 2 không gian lưu trữ rõ rệt: shopping_advisor_text_db (chứa dữ liệu văn bản sản phẩm) và shopping_advisor_image_db (chứa vector hình ảnh).

  • Đồng bộ hóa Model: Hệ thống sử dụng cặp mô hình tối ưu cao từ NVIDIA: nvidia/nv-embedqa-e5-v5 để xử lý văn bản và mô hình thị giác nvidia/nvclip để chuyển đổi hình ảnh thành vector.

  • Độ trễ và Ngữ cảnh: Khi người dùng upload ảnh kèm câu hỏi, prompt có logic giải quyết đại từ chỉ định (Deictic References). Các từ khóa mang tính chỉ định như “chiếc này”, “nó”, “sản phẩm này” sẽ được ánh xạ thẳng vào tấm ảnh vừa gửi lên chứ không bị nhầm lẫn với các sản phẩm được nhắc tới trong lịch sử chat cũ.

3. Cart Grounding: Quản Lý Giỏ Hàng Tuyệt Đối Chính Xác

Hallucination (AI tự bịa thông tin) là thảm họa đối với các tính năng liên quan đến tiền bạc và kho vận. Giải pháp này xử lý triệt để bằng cơ chế Cart Grounding chặt chẽ thông qua dịch vụ memory_retriever chạy SQLite:

  • Xác thực trạng thái gốc (Source of Truth): Toàn bộ thông tin về số lượng, mặt hàng, và đặc biệt là cột giá tiền (price) được lưu trữ, tính toán một cách tường minh (Deterministic) bằng mã nguồn hệ thống thông qua bảng cart_items. LLM không được tự tính nhẩm hay tự đoán tổng tiền.

  • Ràng buộc Prompt (chatter_prompt): Tác tử tạo câu thoại (ChatterAgent) bị ràng buộc nghiêm ngặt: Không được phép tự nhận là đã thêm/bớt hàng thành công vào giỏ trừ khi tác tử giỏ hàng (CartAgent) xử lý trước đó xác nhận tác vụ thành công. Hệ thống luôn đối chiếu trực tiếp với biến CURRENT CART trong DB để phản hồi khách.

4. Lớp Phòng Thủ Guardrails Bảo Vệ Thương Hiệu

Giải pháp tích hợp NeMo Guardrails như một màng lọc hai đầu (Input/Output Safety Gates):

  • Nếu khách hàng cố tình đưa vào các nội dung độc hại hoặc hỏi các câu hỏi lạc đề ngoài phạm vi mua sắm thời trang (Out of Domain), hệ thống lập tức chặn lại và đưa ra câu thoại an toàn đã định nghĩa sẵn: “Sorry, I am a shopping assistant that specializes in apparel…”.

  • Chính sách an toàn (Risk Policy): Mã nguồn mặc định được cấu hình theo dạng Fail-open (Default to safe on failure – tức là nếu service kiểm tra an toàn gặp sự cố kết nối, hệ thống vẫn cho phép phản hồi tiếp tục đi tiếp để tránh gián đoạn trải nghiệm).

5. Hướng Dẫn Cấu Hình Vận Hành

Giải pháp hỗ trợ linh hoạt giữa hai chế độ vận hành tùy thuộc vào tài nguyên phần cứng của doanh nghiệp:

Chế độ Cloud/API Mode (Khuyên dùng để test nhanh)

Chế độ này gọi API trực tiếp thông qua Cloud Endpoint của NVIDIA, giúp giảm tải toàn bộ gánh nặng tính toán mô hình cho máy host:

Bash

cd Shop-Retail-Provider-mion-
cp .env.example .env

# Export API Key dùng chung cho cả 3 tác vụ chính
export NGC_API_KEY=<your-nvidia-api-key>
export LLM_API_KEY=$NGC_API_KEY
export EMBED_API_KEY=$NGC_API_KEY
export RAIL_API_KEY=$NGC_API_KEY
export CONFIG_OVERRIDE=config-build.yaml

docker login nvcr.io
docker compose -f docker-compose.yaml up -d --build

Ở chế độ này, giải pháp sẽ gọi mô hình nền tảng meta/llama-3.1-70b-instruct cho các tác vụ suy luận. Giao diện UI sẽ sẵn sàng tại http://localhost:3000.

Chế độ Local NIM Mode (Bảo mật dữ liệu nội bộ)

Dành cho hạ tầng On-premise có phần cứng lớn (khuyến nghị cụm 4x H100) để tự host hoàn toàn các container mô hình biệt lập:

Bash

export LOCAL_NIM_CACHE=~/.cache/nim
mkdir -p "$LOCAL_NIM_CACHE" && chmod a+w "$LOCAL_NIM_CACHE"
export NGC_API_KEY=<your-nvidia-api-key>

docker compose -f docker-compose-nim-local.yaml up -d
docker compose -f docker-compose.yaml up -d --build

Hệ thống sẽ kéo các container NIM chuyên dụng về vận hành nội bộ: Mô hình LLM khổng lồ nemotron-3-super-120b-a12b (được gán cố định cho GPU 0 và 1), cùng hai bản mô hình an toàn nội bộ llama-3.1-nemoguard-8b-content-safety và llama-3.1-nemoguard-8b-topic-control.

6. Khuyến Nghị Hardening Khi Triển Khai Thực Tế (Production-Ready)

Để chuyển đổi bản thiết kế tham khảo này thành giải pháp thương mại chịu tải thực tế cho doanh nghiệp, các kỹ sư hệ thống cần lưu ý nâng cấp các hạng mục sau:

  1. Xây dựng module Feedback loop biệt lập: Kiến trúc gốc hoàn toàn không thiết kế sẵn API backend hay giao diện Like/Dislike thu thập phản hồi. Doanh nghiệp phải tự thiết kế schema lưu trữ, chính sách bảo mật dữ liệu khách hàng (Consent/PII controls) và xây dựng tập dữ liệu đánh giá ngoại tuyến (Offline Eval Pipeline).

  2. Nâng cấp hạ tầng lưu trữ trạng thái: Cơ sở dữ liệu SQLite (context.db) cần được thay thế ngay bằng cụm DB phân tán, bền vững hơn, có tích hợp cơ chế xác thực (AuthN/AuthZ) và cô lập dữ liệu giữa các khách hàng (Tenant Isolation).

  3. Cấu hình lại rủi ro bảo mật (Risk Policy): Cần cân nhắc chuyển đổi cấu hình mặc định của Guardrails từ Fail-open sang Fail-closed để đảm bảo an toàn tuyệt đối cho thương hiệu, chấp nhận từ chối trả lời nếu hệ thống an toàn gặp sự cố.

____
Bài viết liên quan
TAG: , , ,