Mục lục trang
Tổng quan hệ thống

Trước khi sản phẩm được gợi ý

Một gợi ý tốt bắt đầu từ ngữ cảnh.

Không chỉ hỏi “sản phẩm nào bán chạy?” — hệ thống còn kết nối người mua quan tâm gì, đang xem gì và sản phẩm nào liên quan. Từ đó, danh sách được xếp theo từng ngữ cảnh; mỗi tương tác lại góp dữ liệu cho lần gợi ý tiếp theo.

Chưa có lịch sử? Hệ thống vẫn thử nguồn candidate dự phòng và xếp hạng bằng Standard.

Ngữ cảnh

Sở thích, phiên truy cập và sản phẩm đang xem

Ứng viên

Tìm từ hồ sơ, xu hướng, nội dung tương đồng và hành vi.

Xếp hạng

Standard chấm theo trọng số; AI-Enhanced kết hợp dự đoán ML.

Kết quả

Sản phẩm phù hợp, thứ hạng và lý do gợi ý

Kết quả mở đầu cho lần gợi ý tiếp theo. Impression và click đi qua Kafka để cập nhật hồ sơ, không chặn request hiện tại.

Đọc tiếp: mở Kiến trúc hệ thống bên dưới để xem service nào đứng sau từng bước.

Tài liệu chi tiết

1Kiến trúc hệ thốngLần theo request và event để biết thành phần nào xử lý, dữ liệu được lưu ở đâu và Kafka cập nhật gì ở nền; qua đó thấy ranh giới giữa các service.
1.1Khám phá hai luồng tạo nên gợi ýLuồng đọc tạo danh sách trong request; luồng ghi xử lý hành vi ở nền để cập nhật dữ liệu cho lần gợi ý sau.
1.1.1Luồng đọc · Xử lý đồng bộRecommendation xử lý yêu cầu trong cùng lượt gọi. Redis có thể trả kết quả đã xếp hạng; nếu cache miss, hệ thống mới dựng ngữ cảnh, tìm ứng viên và chạy bước xếp hạng.
  1. Bước 01

    Web Storefront

    Chọn vị trí hiển thị, trang và số sản phẩm cần lấy. Trang chi tiết gửi thêm productId làm sản phẩm mốc.

  2. Bước 02

    API Gateway

    Chuyển tiếp GET /api/v1/recommendation/recommendations cùng user đã xác thực hoặc session khách; Web không tự truy vấn catalog hay xếp hạng sản phẩm.

  3. Bước 03

    Recommendation API

    Kiểm tra surface, định dạng ID và phân trang. Mỗi trang tối đa 24 sản phẩm; khách chỉ xem trang đầu, trang chi tiết tối đa 6.

Bước 04

Redis · kiểm tra cache

Mục đích

Giảm thời gian chờ và xử lý lặp

Nếu kết quả còn dùng được, service bỏ qua việc đọc hồ sơ/phiên, gom sản phẩm tiềm năng và chạy xếp hạng/ML. Nhờ đó giảm thời gian chờ và tải lặp lên các nguồn dữ liệu, nhất là ở trang có nhiều request cùng ngữ cảnh.

Dữ liệu được lưu

Response đã chọn sản phẩm và xếp hạng

Redis lưu response của đúng trang: sản phẩm, thứ hạng, điểm, nguồn/lý do và metadata. Khi cache miss, kết quả được dựng từ hồ sơ/catalog trong PostgreSQL, hành vi gần đây trong session và candidate từ xu hướng, quan hệ hoặc Qdrant khi có dữ liệu phù hợp. Redis chỉ giữ bản kết quả tạm, không thay dữ liệu gốc.

Điều kiện cache hit

Đúng người dùng, đúng lượt xem

Key phải khớp người dùng/phiên khách, vị trí, sản phẩm mốc, trang, phiên bản luật xếp hạng/thử nghiệm và version cache; kết quả cũng phải còn hạn. TTL mặc định 5 phút, cấu hình từ 30 giây đến 1 giờ. Mỗi lượt hit vẫn có requestId và item token mới.

Đánh đổi & kiểm soát

Nhanh hơn, nhưng kết quả là snapshot tạm thời

Hành vi mới có thể cần chờ Kafka cập nhật hồ sơ. Khi cập nhật xong, phiên bản cache của người đó tăng để request kế tiếp bỏ qua snapshot cũ; catalog đổi cũng tăng phiên bản cache chung. Nếu Redis lỗi, hệ thống chạy lại pipeline từ PostgreSQL nhưng thiếu ngữ cảnh phiên, nên phản hồi có thể chậm và kém cá nhân hóa hơn. TTL giới hạn thời gian lưu snapshot.

HIT · response đã xếp hạng + requestId/token mới

MISS · dựng ngữ cảnh → tìm ứng viên → xếp hạng → lưu cache

Bước 05

Từ tín hiệu người mua đến danh sách ứng viên

03 chặng ·09 nguồn

  1. Bước 5.1
    Dựng ngữ cảnh

    Kết hợp sở thích đã lưu với hành vi mới để chọn hướng tìm.

    Hồ sơ dài hạn

    PostgreSQL · tối đa 30 sản phẩm, 12 danh mục và 12 thương hiệu.

    Phiên hiện tại

    Redis · các mặt hàng và nhóm hàng vừa được tương tác.

    Chiến lược tìm

    Có sở thích → cá nhân hóa; thiếu dữ liệu → theo phiên hoặc cold-start.

  2. Bước 5.2
    Thu ứng viên

    Các nguồn chạy độc lập; nguồn thiếu dữ liệu được bỏ qua, không chặn nguồn khác.

    Sở thích người mua
    03 nguồn

    01 · PRODUCT_AFFINITY · HỒ SƠ

    Sản phẩm đã quan tâm
    Chi tiết

    Đưa lại mặt hàng từng tạo tín hiệu sở thích tích cực.

    02 · CATEGORY_AFFINITY · HỒ SƠ + PHIÊN

    Sản phẩm cùng danh mục
    Chi tiết

    Mở rộng sang nhóm hàng người mua đang quan tâm.

    03 · BRAND_AFFINITY · HỒ SƠ + PHIÊN

    Sản phẩm cùng thương hiệu
    Chi tiết

    Giữ lại thương hiệu người mua thường chọn.

    Xu hướng và cold-start
    04 nguồn

    04 · TRENDING · NGUỒN NỀN

    Đang được quan tâm
    Chi tiết

    Bổ sung sản phẩm có xu hướng tăng.

    05 · BEST_SELLING · COLD-START

    Bán chạy
    Chi tiết

    Tạo điểm bắt đầu khi chưa rõ sở thích.

    06 · NEWEST · COLD-START

    Mới nhất
    Chi tiết

    Dành chỗ cho sản phẩm mới chưa có lịch sử.

    07 · EXPLORE · COLD-START

    Khám phá ổn định
    Chi tiết

    Thêm lựa chọn mà không ngẫu nhiên mỗi request.

    Tương đồng nội dung và hành vi
    02 nguồn

    08 · SEMANTIC_SIMILARITY · QDRANT

    Gần nhau về nội dung
    Chi tiết

    Tìm sản phẩm gần nghĩa dù chưa có lịch sử mua chung.

    09 · CO_BEHAVIOR · QUAN HỆ SẢN PHẨM

    Thường được xem hoặc mua cùng
    Chi tiết

    Tìm liên hệ hành vi mà thuộc tính catalog không thể hiện.

  3. Bước 5.3
    Hợp nhất pool

    Loại trùng và giới hạn tập đầu vào trước khi xếp hạng.

    1. 01

      Thu nguồn

      Một nguồn lỗi không dừng phần còn lại.

    2. 02

      Loại món vừa xem

      Bỏ sản phẩm mốc và tối đa 3 món mới tương tác.

    3. 03

      Gộp sản phẩm trùng

      Giữ một productId cùng nguồn và lý do tìm thấy.

    4. 04

      Giới hạn pool

      Tối đa 300 món, chia lượt giữa các nguồn nếu cần.

    Pool ≤300 · ứng viên chuyển sang Standard hoặc AI-Enhanced Ranking; chưa phải thứ tự hiển thị.

    Chi tiết hợp nhất

AI có cải thiện thứ tự gợi ý không?

Hai phương pháp dùng chung quy trình tìm sản phẩm, chỉ khác cách chấm điểm. Trong thử nghiệm, mỗi tài khoản hoặc phiên khách luôn ở cùng một nhánh; lượt hiển thị, nhấp và đơn hoàn tất được gắn về đúng gợi ý để so sánh. AI không mặc định được xem là tốt hơn.

Bước 06
Standard Ranking

Công thức điểm

clamp(Σ(weight × feature) − negativePenalty, 0, 1)

8 feature được chuẩn hóa; trọng số policy có tổng 100%, penalty từ sở thích âm được trừ riêng.

Vai trò
Tạo baseline xác định, dễ lần ngược từng tín hiệu để biết vì sao sản phẩm đứng ở vị trí đó.
Điều chỉnh
Admin tinh chỉnh hybridWeights trong policy; HYBRID là baseline để đối chiếu ranking mode.

Đánh đổi · Dễ kiểm soát, không cần gọi model; nhưng phụ thuộc trọng số con người đặt và khó nắm hết tương tác phức tạp giữa tín hiệu.

Bước 06
AI-Enhanced Ranking

Công thức điểm

clamp(Standard × (1 − mlBlend) + ML × mlBlend, 0, 1)

Model dự đoán điểm cho từng ứng viên từ cùng feature vector; không tạo thêm nguồn sản phẩm.

Điều chỉnh & đo lường
mlBlend mặc định 0,3, giới hạn tối đa 0,5. Analytics nhóm theo ranking mode thực tế để đo hiệu quả có attribution.
Fallback an toàn
Nếu response model thiếu phiên bản hợp lệ, cả lượt dùng Standard; ứng viên thiếu prediction vẫn giữ điểm baseline.

Đánh đổi · Có thể khai thác quan hệ giữa nhiều tín hiệu, nhưng cần model ổn định, thêm độ trễ inference và attribution đủ tin cậy để chứng minh hiệu quả.

Quyết định bằng outcome, không chỉ bằng score

So impression → click → đơn hoàn tất có attribution; dùng kết quả để tinh chỉnh trọng số Standard hoặc tỷ lệ blend.

Xem logic xếp hạng

Sau xếp hạng, cả hai nhánh cùng qua bước cân bằng độ đa dạng; danh sách chuẩn tối đa 180 sản phẩm.

Bước 07

Response danh sách gợi ý

Trên từng sản phẩm

Nội dung để hiển thị
product
Tên, ảnh, slug, giá và thông tin cần để dựng thẻ sản phẩm.
rank · score
Vị trí và điểm dùng để xếp hạng — không phải xác suất mua.
source · reasons
source cho biết nguồn ứng viên được ưu tiên; reasons là câu viết sẵn ánh xạ từ nguồn đó (ví dụ PRODUCT_AFFINITY → “Dựa trên sản phẩm bạn từng quan tâm”). Nếu nhiều nguồn cùng tìm thấy sản phẩm, API chọn nguồn đứng trước theo thứ tự ưu tiên — đây không phải lời giải thích do AI tạo.

Trên toàn bộ response

Ngữ cảnh và phân trang
requestId
Mã riêng cho response, giúp nối log và sự kiện phát sinh từ lượt gợi ý.
strategy · profileState
Cho biết gợi ý theo hồ sơ, phiên hay cold-start; đồng thời phân biệt khách với tài khoản đã có hoặc chưa có sở thích tích cực.
page · pageSize · total · totalPages
Cho biết đang ở trang nào và còn bao nhiêu sản phẩm.
generatedAt
Thời điểm response được tạo.

Dấu vết xếp hạng

Policy, model và ranking mode
ruleVersion · rankingPolicyVersion
Phiên bản luật và policy đã dùng để xếp hạng.
rankingModelVersion
Phiên bản model nếu lượt này có dự đoán ML hợp lệ; nếu không sẽ là null.
rankingMode
ID và nhánh đang được so sánh; nếu request dùng mode nào thì ghi nhận đúng mode đó; khi fallback là null.

Giới hạn danh sách

Tối đa 24 sản phẩm mỗi trang · trang chi tiết tối đa 6 · khách chỉ xem trang đầu.

Ghi nhận đúng lượt tương tác

recommendationItemId được ký theo người dùng/phiên, request, sản phẩm, thứ hạng và policy để xác thực impression/click đúng lượt gợi ý. Ngay cả khi Redis trả danh sách đã cache, mỗi response vẫn có requestId và token mới, tránh gộp nhầm nhiều lần hiển thị.

1.1.2Luồng ghi · Xử lý bất đồng bộWeb/Order → Kafka → hai consumer cập nhật hồ sơ người mua và quan hệ sản phẩm; request gợi ý không phải chờ các bước này.

Nguồn 01 · tín hiệu quan tâm

Tương tác trên Web

Ghi lại điều người mua quan tâm trước khi phát sinh giao dịch.

  1. Bước 01

    Web Storefront

    Ghi impression, view, click, tìm kiếm và thêm giỏ.

  2. Bước 02

    API Gateway

    Nhận event đơn/lô và identity user/guest.

    POST /api/v1/recommendation/events · /events/batch
  3. Bước 03

    InteractionIngestionService

    Kiểm tra event, attribution; gắn eventId và giờ server trước khi gửi Kafka.

Vì sao cần
Impression và click ghi nhận ý định sớm; item token gắn hành vi với đúng sản phẩm, vị trí và lượt gợi ý.
Đánh đổi
Click không đảm bảo chuyển đổi. Attribution cần token hợp lệ; batch 1–50 event phải hợp lệ toàn bộ mới được gửi.

Nguồn 02 · giao dịch đã xác nhận

Mua hàng và hoàn hàng

Chỉ ghi nhận giao dịch do Order Service xác nhận, không suy đoán từ click.

  1. Bước 01

    Order Service

    Phát event khi đơn hoàn tất hoặc hàng hoàn được xác nhận.

  2. Bước 02

    PostgreSQL Outbox

    Ghi event cùng transaction cập nhật đơn hoặc hoàn hàng.

  3. Bước 03

    Outbox dispatcher

    Gửi event lên Kafka; retry nếu broker chưa xác nhận.

Vì sao cần
Đơn hoàn tất là tín hiệu mua mạnh; hàng hoàn giúp điều chỉnh lại tín hiệu đó.
Đánh đổi
Chỉ có dữ liệu sau khi đơn được xác nhận. Outbox tăng độ tin cậy nhưng projection vẫn cập nhật bất đồng bộ.

Event bus · buffer và phân phối

Apache Kafka

Web chỉ trả HTTP 202 sau khi broker nhận event, không chờ consumer xử lý xong. Với đơn hàng, Order Service ghi event vào PostgreSQL Outbox trước khi dispatcher gửi lên Kafka.

Luồng event (Kafka topic)

Hành vi Web
recommendation.interactions.v1
Đơn hoàn tất
order.purchase.completed
Hàng hoàn
order.purchase.returned

Kafka giải quyết gì?

Kafka đệm event rồi phân phối cùng luồng cho hai consumer group: một cập nhật hồ sơ, một dựng quan hệ sản phẩm. Hai nhánh scale và retry độc lập; key user/session giữ thứ tự tương đối của tương tác cùng một người.

Đánh đổi & xử lý lỗi

HTTP 202 chỉ xác nhận broker đã nhận, không có nghĩa dữ liệu đã cập nhật. Consumer chỉ đánh dấu offset sau xử lý; ledger chống ghi trùng nếu event được gửi lại. Lỗi được retry giới hạn rồi chuyển vào dead-letter queue (DLQ) để xử lý riêng. Nếu publish Web lỗi, API trả 503; event đơn hàng còn trong outbox để dispatcher gửi lại.

Hai loại dữ liệu · hai điểm sử dụng

Một nhánh hiểu người mua, một nhánh nối sản phẩm.

Consumer 01 lưu người mua quan tâm gì; Consumer 02 tìm các sản phẩm thường xuất hiện cùng nhau. Luồng đọc lấy hai loại dữ liệu này khi Redis cache miss; cache hit trả kết quả đã lưu.

Consumer group 01 · hồ sơ người mua

KafkaConsumerService

Dữ liệu tạo ra
Hồ sơ gắn với user/session: người này quan tâm sản phẩm, danh mục hay thương hiệu nào. Đây là tín hiệu riêng theo người mua.
Cách xử lý
Ledger chống trùng; PostgreSQL lưu projection, Redis cập nhật session khách và xóa cache liên quan. Mua/hoàn điều chỉnh preference theo số lượng.
Luồng đọc dùng ở đâu?
Cache miss → “Hồ sơ lâu dài + ý định trong phiên”. Sở thích giúp tìm ứng viên theo món, danh mục, thương hiệu và trở thành tín hiệu chấm điểm; sản phẩm vừa xem làm mốc tìm món tương tự hoặc thường mua cùng.
Đánh đổi
Profile đổi sau khi consumer xử lý xong; request gợi ý không chờ nhánh ghi này.

Consumer group 02 · quan hệ sản phẩm

RelationConsumerService

Dữ liệu tạo ra
Quan hệ giữa các cặp sản phẩm (A → B), tổng hợp từ lượt xem, thêm giỏ và đơn mua; không phải hồ sơ sở thích của một người cụ thể.
Cách tạo
Ghép view/click trong 30 phút, add-to-cart trong 7 ngày và sản phẩm cùng đơn; hoàn hàng tạo điều chỉnh âm.
Luồng đọc dùng ở đâu?
Cache miss → “Tạo ứng viên”, nguồn CO_BEHAVIOR. RelationCandidateService tìm món thường đi cùng sản phẩm đang xem hoặc vừa quan tâm; CandidateUnionService nhập chúng vào pool. Sau đó Standard/AI-Enhanced mới chấm điểm và quyết định thứ tự.
Đánh đổi
Cần đủ event và sản phẩm mốc; hàng mới có thể chưa có quan hệ. Cửa sổ giới hạn liên hệ quá xa.

Nhận event không đồng nghĩa hồ sơ đã cập nhật.

HTTP 202 xác nhận event Web đã vào hàng đợi; Order Service dùng outbox để không mất event khi cập nhật đơn. Hai consumer xử lý nền, nên hồ sơ và quan hệ chỉ ảnh hưởng request gợi ý sau khi projection hoàn tất.

1.2Công nghệ sử dụngCác thành phần phục vụ giao diện, API gợi ý, lưu trữ, tìm kiếm vector và xử lý sự kiện/AI.
  • Next.jsWeb storefront
  • NestJSRecommendation API
  • PostgreSQLCatalog & profile
  • RedisCache & session
  • Apache KafkaEvent stream
  • QdrantVector search
  • FastAPIAI prediction API
  • PythonAI & embedding worker
1.3Các service tham giaRequest gợi ý chạy riêng với cập nhật event nền: service phục vụ người mua không phải chờ consumer xử lý xong.
1.3.1Luồng trả gợi ý · đồng bộĐi theo thứ tự từ giao diện đến bộ xếp hạng.
  1. 01 · Web
    Web Storefront

    Gọi API gợi ý, hiển thị kết quả và gửi impression/click gắn với đúng request.

  2. 02 · Cổng API
    API Gateway

    Chuyển tiếp request/event cùng identity user hoặc session; không tự tạo hay xếp hạng gợi ý.

  3. 03 · Điều phối
    Recommendation Service

    Đọc cache/ngữ cảnh, gom ứng viên, xếp hạng và trả sản phẩm kèm nguồn, lý do, attribution.

  4. 04 · Khi dùng AI
    AI Service

    Dự đoán điểm cho AI-Enhanced; nếu prediction không dùng được, Recommendation quay về Standard.

1.3.2Nguồn dữ liệu & cập nhật nền · bất đồng bộCác nguồn phát event; Kafka phân phối tới worker nội bộ.
  • Tín hiệu sử dụng
    Web + Gateway

    Gửi lượt xem, click, tìm kiếm và thêm giỏ vào luồng ghi nhận hành vi.

  • Dữ liệu catalog
    Product Service

    Phát thay đổi sản phẩm; Recommendation đồng bộ vào catalog read model riêng.

  • Giao dịch thật
    Order Service

    Phát đơn hoàn tất/hoàn trả qua outbox để tín hiệu mua dựa trên giao dịch đã xác nhận.

  • Phân phối & projection
    Kafka + workers

    Consumer trong Recommendation cập nhật catalog, profile/session và quan hệ sản phẩm cho request sau.

Ranh giới service: Catalog read model và Kafka consumer là module/worker bên trong Recommendation Service, không phải microservice độc lập. Request gợi ý đọc dữ liệu đã đồng bộ, không truy cập trực tiếp database của Product hoặc Order.

2Logic tạo gợi ýĐi từ hồ sơ và phiên truy cập, qua tạo ứng viên, chấm Standard/AI, đến fallback và attribution; từng quyết định, giới hạn và trade-off được trình bày bên dưới.

Tìm nhóm sản phẩm phù hợp, chấm điểm, rồi kiểm soát danh sách trước khi trả về.

Mỗi lần trang yêu cầu gợi ý, hệ thống xử lý để trả danh sách ngay. Lượt xem, nhấp và đơn hàng được xử lý nền qua Kafka; dữ liệu mới chỉ tác động đến những request tiếp theo.

01Hiểu ngữ cảnh

Hồ sơ + phiên hiện tại

Đọc sở thích đã tích lũy, hoạt động gần đây, màn hình và sản phẩm đang xem để chọn gợi ý cá nhân hóa, theo phiên hoặc dành cho khách mới.

Giải quyết: không dùng chung một danh sách cho mọi người.

02Tạo tập ứng viên

Nhiều nguồn, một danh sách ứng viên

Catalog tìm theo sản phẩm, danh mục, thương hiệu và xu hướng; hệ thống còn có thể tìm mặt hàng gần nội dung hoặc thường được xem/mua cùng nhau khi đủ dữ liệu.

Giải quyết: mở rộng lựa chọn mà không để một nguồn quyết định tất cả.

03Chấm và cân bằng

Standard hoặc AI-Enhanced

Standard chấm 8 tiêu chí trên cùng thang điểm. AI-Enhanced dự đoán lại điểm trên chính danh sách đó; bước cân bằng sau cùng tránh để một nhóm chiếm quá nhiều vị trí.

Giải quyết: vừa có baseline giải thích được, vừa có đường thử ML an toàn.

04Trả kết quả, học sau

Response có thể đo lường

Web nhận danh sách kèm thứ hạng, nguồn, lý do và mã truy vết đã ký để nối lượt thấy/nhấp với đúng sản phẩm. Consumer cập nhật dữ liệu nền cho request sau.

Giải quyết: giữ request nhanh và biết được item nào đã được hiển thị.

Các phần dưới giải thích dữ liệu đến từ đâu, từng điểm số ảnh hưởng thế nào và hệ thống cân bằng độ mới, đa dạng với tốc độ ra sao.

2.1Hệ thống lấy tín hiệu và tìm sản phẩm từ đâu?Theo luồng từ hồ sơ/phiên đến danh sách ứng viên rồi xếp hạng; xem từng nguồn dùng để làm gì, cách tìm sản phẩm và đánh đổi của các giới hạn.
  1. 01Đọc tín hiệuHồ sơ dài hạn + phiên hiện tại
  2. 02Tìm nhiều nguồnCatalog · Qdrant · quan hệ hành vi
  3. 03Gộp và giới hạnBỏ trùng · giữ nguồn · tối đa 300
  4. 04Chuyển sang rankingNguồn không tự quyết định vị trí
2.1.1Đọc hai lớp tín hiệu, không trộn lịch sử với ý định mớiHồ sơ cho biết người mua thường quan tâm gì; session phản ánh điều họ đang xem hoặc làm trong phiên này.

Dữ liệu bền vững · PostgreSQL

Hồ sơ sở thích dài hạn

Vì sao dùng
Giữ sở thích đã tích lũy theo user; khách chưa đăng nhập vẫn có profile theo session, nhưng không thành hồ sơ xuyên phiên.
Cách hình thành
Consumer xử lý event rồi cộng/trừ preference theo sản phẩm, danh mục và thương hiệu; cập nhật bất đồng bộ sau request.
Áp dụng vào đâu
Bước tạo ứng viên lấy tối đa 30 sản phẩm, 12 danh mục, 12 thương hiệu có điểm dương. Điểm âm được giữ riêng để ranking áp penalty; giới hạn này giữ phần đọc/tính điểm gọn.
Trade-off
Top 30/12/12 bỏ bớt sở thích yếu để giới hạn query/feature; tăng thì tốn đọc/chấm điểm, giảm thì mất độ phủ. Half-life mặc định 7 ngày làm điểm giảm một nửa mỗi tuần: đổi dần, không tức thì.

Ý định ngắn hạn · Redis

Ngữ cảnh phiên hiện tại

Vì sao dùng
Bắt kịp nhu cầu vừa đổi, kể cả khi người mua chưa đăng nhập hoặc hồ sơ dài hạn nói về nhóm hàng khác.
Cách lưu
Giữ sản phẩm, danh mục, thương hiệu, từ khóa và giỏ hàng gần đây; tối đa 30 sản phẩm, TTL mặc định 24 giờ.
Áp dụng vào đâu
Danh mục/thương hiệu phiên mở rộng nguồn catalog; sản phẩm đang xem và gần đây làm anchor semantic/co-behavior; ranking nhận feature sessionContext.
Trade-off
30 sản phẩm/24 giờ là mặc định để giữ mạch mua sắm mà không giữ session vô hạn; ngắn hơn dễ quên ý định, dài hơn dễ bám ngữ cảnh cũ. Impression không thành anchor; raw query được lưu nhưng chưa trực tiếp lọc candidate/chấm điểm.

Chọn cách tìm ứng viên

Có dữ liệu nào, dùng chiến lược đó

Hồ sơ là sở thích đã tích lũy; phiên là sản phẩm hoặc danh mục người mua đang xem lúc này.

01Có sở thích tích lũy

PERSONALIZED

Ưu tiên sở thích đã tích lũy; hoạt động trong phiên và nguồn catalog vẫn có thể bổ sung sản phẩm.

Hồ sơPhiên hiện tạiCatalog
02Chưa có sở thích · có hoạt động phiên

SESSION_BASED

Chưa có sở thích ghi nhận nhưng đang xem sản phẩm hoặc danh mục? Dùng hoạt động trong phiên làm tín hiệu, kể cả với khách chưa đăng nhập.

Sản phẩm vừa xemDanh mục / thương hiệu
03Chưa có sở thích · chưa có hoạt động phiên

COLD_START

Tạo danh sách mở đầu từ hàng bán chạy, hàng mới và khám phá; xu hướng vẫn được bổ sung riêng.

Bán chạyHàng mớiKhám phá
2.1.2Vì sao lượt xem là +1, còn đơn hoàn tất là +8?Đây là thang heuristic để so sánh mức độ tín hiệu trong hồ sơ sở thích — không phải xác suất mua hay điểm xếp hạng cuối.
01
Lấy lượt xem làm mốc

Một lần mở trang sản phẩm được tính +1. Các hành vi khác quy đổi theo mốc này để dễ so sánh và điều chỉnh.

+1=một lượt xem sản phẩm

02
Ý định càng rõ, điểm càng cao

Impression được tính rất nhẹ; click và thêm giỏ thể hiện quan tâm rõ hơn. Đơn hoàn tất là tín hiệu mạnh nhất.

0,05248

Hiển thị → click → giỏ → mua

03
Bỏ giỏ và trả hàng sẽ trừ điểm

Bỏ giỏ chỉ trừ một phần điểm; trả hàng đảo điểm mua theo đúng số lượng được trả.

Bỏ giỏ −2·Trả hàng −8 / sản phẩm

Mặc định trong RecommendationRuleService; có thể ghi đè bằng RECOMMENDATION_WEIGHT_*.

+1Mốc chuẩnMột lượt xem

Impression

+0,05 · 1/20 lượt xem

Tìm kiếm

+1,5 · giữa +1 / +2

Click

+2 · 2 lượt xem

Thêm giỏ

+4 · 2 click

Mua hàng

+8 · mỗi SP

Điểm âm: bỏ giỏ −2 giảm một nửa điểm thêm giỏ; trả hàng −8 đảo điểm mua theo số lượng được trả.

Impression

0,05

Chỉ xác nhận sản phẩm đã xuất hiện. 20 impression cùng một sản phẩm cộng bằng +1 trước suy giảm thời gian, tránh exposure lấn át ý định thật.

Xem sản phẩm

1

Một lần mở trang sản phẩm cộng một đơn vị. Chọn mốc 1 để các hành vi khác có thể đọc thành bội số dễ so sánh.

Tìm kiếm

1,5

Tìm kiếm chủ động hơn lướt xem nhưng chưa gắn chắc với một sản phẩm. Hiện điểm được lưu ở QUERY, request chưa dùng chiều này để gợi ý.

Click

2

Mở sản phẩm được tính gấp đôi lượt xem vì có hành động chủ động; vẫn thấp hơn giỏ hàng vì chưa thể hiện ý định mua.

Thêm vào giỏ

4

Tín hiệu mua mạnh hơn mở trang nhưng chưa phải giao dịch đã xác nhận, nên giữ dưới mức +8 của đơn hoàn tất.

Xóa khỏi giỏ

−2

Nếu thêm giỏ +4 rồi xóa −2, hồ sơ còn +2: giảm ý định mua nhưng không xóa lịch sử xem. Đây là điều chỉnh nhẹ hơn một lần trả hàng.

Đơn hoàn tất

+8

Đơn đã xác nhận là tín hiệu mạnh nhất. Điểm nhân với số lượng: mua 2 sản phẩm cùng mã cộng +16 vào preference sản phẩm và danh mục nếu có mã.

Đơn trả hàng

−8

Cùng độ lớn ngược dấu với mua hàng: trả 1 sản phẩm trừ −8, trả một phần chỉ hiệu chỉnh đúng số lượng đã trả.

2.1.3Hệ thống tìm sản phẩm để gợi ý như thế nào?Đầu vào là hồ sơ, phiên truy cập hoặc sản phẩm làm mốc. Bốn hướng tìm tạo các danh sách candidate có nguồn gốc rõ ràng; hệ thống gộp chúng trước, rồi ranking mới quyết định thứ tự hiển thị.
2.1.3.1Tìm từ sản phẩm, danh mục và thương hiệu đã quan tâmDùng khi đã có tín hiệu sở thích: bắt đầu từ thứ người mua từng chọn, rồi mở rộng vừa đủ để không chỉ trả lại đúng những món cũ.
Bước01

Ngữ cảnh đầu vào

Hồ sơ dài hạn + phiên hiện tại
Profile · PostgreSQLSession · Redis

Hồ sơ

Tối đa 30 sản phẩm, 12 danh mục và 12 thương hiệu có preference dương.

Phiên

Bổ sung danh mục và thương hiệu vừa xem để phản ánh ý định mới.

Loại trừ

Sản phẩm đang mở và tối đa 3 sản phẩm tương tác gần nhất.

Bước02

Chuẩn hóa trước khi truy vấn

Gộp ngữ cảnh, giữ đúng ý định
  1. Đọc đúng hồ sơ: theo user đã xác thực hoặc session khách.
  2. Tạo ứng viên: chỉ dùng preference có điểm dương.
  3. Gộp phiên: hợp nhất ID danh mục/thương hiệu từ Redis rồi khử trùng.
  4. Giữ điểm âm: không tạo ứng viên; ranking áp penalty sau.
Bước03

Ba nhánh truy vấn chạy song song

Mỗi nhánh tìm candidate theo một loại tín hiệu; các giới hạn dưới đây được áp dụng riêng cho từng nhánh.

PRODUCT_AFFINITY

Tối đa 30
Khớp đúng sản phẩm

Tra product ID có preference dương, giữ thứ tự sở thích; chỉ trả món đang hoạt động và còn hàng.

Đổi lại: sát sở thích đã biết, nhưng không tự tìm món mới nếu profile thiếu ID phù hợp.

CATEGORY_AFFINITY

Tối đa 100
Mở rộng trong cùng danh mục

Ghép danh mục hồ sơ với danh mục vừa xem; ưu tiên món còn hàng có tổng đã bán cao.

Đổi lại: tăng độ phủ, nhưng cùng danh mục chưa chắc cùng ý định cụ thể.

BRAND_AFFINITY

Tối đa 80
Giữ thương hiệu quen thuộc

Ghép thương hiệu hồ sơ với thương hiệu vừa xem; ưu tiên món còn hàng có tổng đã bán cao.

Đổi lại: hợp với người trung thành thương hiệu, nhưng có thể làm lựa chọn kém đa dạng.

Bước04

Hợp nhất kết quả

Candidate Union

Ba danh sách candidate có thể trùng nhau. Hợp nhất khử trùng theo productId, đồng thời giữ lại nguồn đã tìm thấy từng món.

Bước05

Ranking quyết định thứ tự

Feature hồ sơ được tính từ preference đã suy giảm theo thời gian và chuẩn hóa về 0–1:

profileAffinity = clamp(P + 0,6C + 0,4B)

P/C/B lần lượt là điểm sản phẩm/danh mục/thương hiệu. Trọng số Standard mặc định là 25%, có thể thay theo policy.

2.1.3.2Vẫn tạo được danh sách khi chưa biết khách thích gìDùng nguồn thị trường làm nền cho khách mới; khi đã có hồ sơ hoặc tín hiệu trong phiên, chỉ giữ trending để không thay thế cá nhân hóa bằng danh sách đại trà.
Bước 01

Chọn theo dữ liệu thực sự có

Strategy quyết định có cần mở rộng bằng nguồn cold-start hay không

Không có điểm đủ lớn thì hệ thống không tự bịa ra sở thích.

Trending luôn chạy

PERSONALIZED

Có preference dương trong hồ sơ

Dùng affinity cá nhân và các nguồn mở rộng; trending vẫn bổ sung góc nhìn thị trường.

SESSION_BASED

Chưa có hồ sơ dương, nhưng có context phiên

Dựa vào danh mục/thương hiệu vừa xem; không thêm cả bộ best-selling, newest và explore.

COLD_START

Chưa có hồ sơ hay context phiên

Bổ sung ba nguồn catalog ổn định để request đầu tiên vẫn có lựa chọn.

Bước 02

Truy vấn catalog song song

Một nguồn xu hướng chung, ba nguồn chỉ mở khi cold-start

Tất cả chỉ lấy sản phẩm đang hoạt động, còn hàng và không nằm trong danh sách loại trừ.

TRENDING

mọi strategy
Bắt nhịp nhu cầu gần đây

Tối đa 80 món, xếp theo tổng hợp hành vi: 0,1×view hôm nay + 0,5×click hôm nay + 2×add-to-cart 7 ngày + 3×purchase 30 ngày.

Nếu thiếu aggregate gần đây, code dùng legacy popularity; hòa điểm thì ưu tiên total_sold rồi productId. Vẫn là xu hướng chung, không phải sở thích riêng.

BEST_SELLING · COLD_START

Lấy món có tổng đã bán cao

Tối đa 80 món, sắp theo total_sold giảm dần; tạo mốc khởi đầu đáng tin khi chưa có hành vi cá nhân.

Có thể nghiêng về món lâu năm, chưa chắc đang tăng nhu cầu.

NEWEST · COLD_START

Dành chỗ cho mặt hàng mới

Tối đa 80 món, sắp theo created_at mới nhất; không đợi sản phẩm tích lũy view hay đơn bán.

Đổi lại, hàng mới chưa có đủ dữ liệu để xác nhận chất lượng.

EXPLORE · COLD_START

Giữ một lối khám phá ổn định

Tối đa 60 món theo productId tăng dần; cùng request sẽ không đổi ngẫu nhiên vì thứ tự nguồn.

Ổn định và đa dạng, nhưng thứ tự này không biểu thị độ phù hợp.

Bước 03

Hợp nhất và bàn giao

Candidate Union xử lý kết quả trước ranking

Đầu ra & xử lý lỗi

Mỗi nguồn trả về một list riêng, không trả vị trí cuối. Nguồn chạy song song; nếu một truy vấn lỗi, nguồn khác vẫn được giữ. Candidate Union gộp trùng và giới hạn toàn pool ở 300 trước ranking.

Đánh đổi & cách cải thiện

Nguồn thị trường giúp tránh danh sách rỗng nhưng có thể quá đại trà; bestseller nhìn về tổng bán, newest ưu tiên độ mới, explore ưu tiên tính ổn định. Các mức 80/80/60/80 là giới hạn hiện tại, cần đánh giá coverage, latency và hiệu quả ranking trên toàn bộ traffic trước khi tinh chỉnh.

2.1.3.3Tìm sản phẩm gần nghĩa bằng nội dung, không chỉ bằng danh mụcDùng khi tên, mô tả hoặc thuộc tính sản phẩm diễn đạt khác nhau nhưng vẫn nói về nhu cầu tương tự. Luồng này tạo thêm ứng viên; nó không kết luận khách chắc chắn muốn mua.
QdrantTop 60
Bước 01

Chuẩn bị trước · bất đồng bộ

Vector catalog được tạo trước request gợi ý

Recommendation request không gọi model để tạo embedding mới.

  1. 01 · NỘI DUNG

    Catalog snapshot

    Tên, thương hiệu, đường dẫn danh mục, mô tả và thuộc tính.

  2. 02 · CHUẨN HÓA

    Tạo nội dung chuẩn + hash

    Loại HTML, chuẩn Unicode/khoảng trắng, giới hạn độ dài; hash chỉ đổi khi nội dung ngữ nghĩa đổi.

  3. 03 · EMBEDDING JOB

    Tạo vector ngoài request

    Job phát yêu cầu; worker embedding xử lý theo model/số chiều cấu hình rồi cập nhật Qdrant. Giá, tồn kho không buộc tạo lại vector.

  4. 04 · LƯU VECTOR

    Qdrant · trạng thái READY

    Lưu vector cùng productId, contentHash và modelVersion để request tra đúng phiên bản.

Bước 02

Khi có request · retrieval online

Từ ngữ cảnh người mua đến tối đa 60 candidate

Mỗi bước chỉ đọc hoặc biến đổi dữ liệu đã có.

  1. 01
    Chọn anchor (món làm mốc)

    Món đang xem có trọng số 1; lấy tối đa 5 món gần đây theo event weight dương (thiếu thì dùng 1, bằng 0/âm thì bỏ); lấy tối đa 5 món sở thích hồ sơ, mỗi món × 0,5.

  2. 02
    Nạp vector hợp lệ

    Khử trùng anchor và cộng trọng số nếu trùng ID. Đọc vector theo productId + contentHash; chỉ nhận vector READY, đúng model, đúng số chiều và toàn giá trị hữu hạn.

  3. 03
    Tạo vector truy vấn

    Tính trung bình có trọng số của vector các anchor. Món đang xem hoặc event mạnh tác động nhiều hơn; hồ sơ dài hạn vẫn bổ sung ngữ cảnh.

  4. 04
    Tìm láng giềng

    Qdrant tìm gần nhất theo metric cấu hình (Cosine mặc định), tối đa 60. Chỉ xét hàng ACTIVE, còn tồn, embedding READY, đúng model và không thuộc danh sách loại trừ.

  5. 05
    Kiểm tra rồi hydrate

    Lấy thông tin sản phẩm từ Catalog. Chỉ nhận kết quả nếu contentHash trong Qdrant vẫn bằng snapshot hiện tại; raw similarity được giữ làm bằng chứng cho ranking.

Bước 03

Đầu ra · chuẩn hóa

Tạo feature semantic để bàn giao sang ranking

Công thức · gộp nhiều ý định thành một query

q = Σ(wᵢ × vᵢ) / Σwᵢ

vᵢ là vector nội dung của sản phẩm anchor; wᵢ là mức ưu tiên từ ngữ cảnh. Ví dụ: món đang xem = 1, món vừa thêm giỏ = event weight, món hồ sơ = 0,5. Nếu cùng một ID xuất hiện ở nhiều nhóm, trọng số được cộng trước khi tính.

Đây là weighted mean của vector đã có, không phải cộng điểm sản phẩm và không phải AI sinh danh sách bằng prompt.

Đầu ra, cách dùng và giới hạn

Đầu ra
Tối đa 60 sản phẩm kèm similarity/rawScore, modelVersion và anchor có trọng số cao nhất trong ngữ cảnh. contentHash của Qdrant được dùng để xác thực trước; anchor là metadata chung, không phải lý do riêng cho từng món.
Fallback
Tắt CANDIDATE_PIPELINE_V3_ENABLED/SEMANTIC_CANDIDATES_ENABLED, thiếu vector tương thích, Qdrant lỗi hoặc nội dung đã đổi thì source trả rỗng; các nguồn khác vẫn chạy.
Đánh đổi
Nội dung gần nghĩa không đồng nghĩa có ý định mua. Anchor chính chỉ mô tả tâm vector chung, không phải lời giải thích riêng cho từng kết quả.
2.1.3.4Tìm món có quan hệ từ hành vi xem, thêm giỏ và mua cùngDùng khi nội dung catalog chưa đủ để nhận ra hai món thường được quan tâm cùng nhau. Quan hệ được tính trước từ event/order; request chỉ đọc read model đã tổng hợp.
PostgreSQL read modelTop 100
Bước 01

Giai đoạn A · chiếu dữ liệu bất đồng bộ

Event được ghép thành cặp sản phẩm trước request gợi ý

Mỗi quan hệ được lưu hai chiều: A → B và B → A.

CO_VIEWcùng session · 30 phút

Xem, click hoặc impression gần nhau

Ghép tối đa 20 tín hiệu PRODUCT_VIEWED, PRODUCT_CLICKED, PRODUCT_IMPRESSED trong cùng session. Trọng số mặc định lần lượt là 1, 2 và 0,05.

CO_CARTcùng user/session · 7 ngày

Cùng được thêm vào giỏ

Ghép tối đa 50 event PRODUCT_ADDED_TO_CART trong cửa sổ thời gian; trọng số mặc định là 3. Có thể nối qua user hoặc session nếu định danh tương ứng tồn tại.

CO_PURCHASEcùng một đơn hàng

Các món xuất hiện trong cùng đơn

Tạo cặp từ các productId khác nhau trong đơn (tối đa 50 mã). Đơn hoàn tất mặc định +6; đơn trả hàng tạo hiệu chỉnh −6 để giảm quan hệ đã ghi.

Các trọng số là default có thể cấu hình. Event ledger và pair ledger giúp retry không cộng cùng một cặp hai lần; quan hệ được giới hạn top 100 đích cho mỗi anchor/loại.

Event → pair → relation score
Bước 02

Giai đoạn B · request recommendation

Từ tối đa 10 anchor đến tối đa 100 sản phẩm liên quan

Không quét lại toàn bộ lịch sử event trong mỗi request.

  1. 01
    Chọn anchor (món làm mốc)

    Gộp món đang xem, tối đa 30 product preference dương và product trong session; khử trùng rồi giữ 10 ID đầu theo thứ tự: món đang xem → hồ sơ → session.

  2. 02
    Đọc và làm mới điểm

    Tra quan hệ đi ra từ từng anchor theo CO_VIEW/CART/PURCHASE. Điểm giảm theo tuổi quan hệ; chỉ lấy effective score > 0, top 100 mỗi cặp anchor/loại rồi giới hạn toàn truy vấn ở 100.

  3. 03
    Loại trùng, giữ bằng chứng

    Bỏ món trong danh sách exclude của request. Nếu một target nối từ nhiều anchor/loại quan hệ, gom thành một sản phẩm và giữ từng contribution; điểm mạnh nhất được xếp trước.

  4. 04
    Lấy dữ liệu Catalog

    Lấy (hydrate) dữ liệu Catalog cho tối đa 100 target; gắn source, anchor, relationType, rawScore và vị trí nguồn để bước ranking sử dụng.

Bước 03

Chuẩn hóa và bàn giao

Điều chỉnh quan hệ theo độ mới rồi tạo feature ranking

Công thức · giảm ảnh hưởng của quan hệ cũ

effective = relationScore × 0,5(age / halfLife)

Mặc định halfLife = 30 ngày: quan hệ 30 ngày tuổi còn một nửa điểm; 60 ngày còn khoảng một phần tư. Giá trị được cấu hình bằng RELATION_SCORE_HALF_LIFE_DAYS.

Ví dụ: relationScore 8, tuổi 30 ngày → effective score 4. Đây là ví dụ tính decay, không phải điểm cố định cho mọi cặp.

Ý nghĩa đầu ra và trade-off

Điểm mạnh
Tìm được quan hệ bổ trợ mà text/danh mục không diễn đạt; request đọc bảng tổng hợp thay vì quét lịch sử hành vi.
Giới hạn dữ liệu
Sản phẩm mới dễ thiếu relation; co-view/popular item có thể phản ánh cùng phiên hoặc mức độ được hiển thị, không chứng minh khách sẽ mua hay hai món thực sự bổ trợ nhau.
Khi thiếu dữ liệu/lỗi
Tắt CO_BEHAVIOR_CANDIDATES_ENABLED, không có anchor/quan hệ hoặc query lỗi thì nguồn trả rỗng; candidate từ nguồn khác vẫn được dùng.
Chuẩn hóa trước khi xếp hạng
Mỗi quan hệ có n = score / (score + scale[loại]); coBehavior = max(n) qua các anchor/quan hệ của món đó. Scale mặc định: CO_VIEW 1, CO_CART 3, CO_PURCHASE 6 — không cộng mọi đường nối thành điểm phình lớn.

Bàn giao sang ranking: mỗi quan hệ được chuẩn hóa thành feature theo loại (CO_VIEW/CART/PURCHASE); Standard Hybrid mặc định dành trọng số 0,10 cho coBehavior (policy có thể thay đổi).

Candidate ≠ thứ hạng
2.1.4Từ nhiều danh sách thành một pool không trùngCác nguồn tìm sản phẩm riêng; bước này lọc, gộp và giới hạn kết quả trước khi Standard hoặc AI Ranking tính thứ tự.
Bước 01

Thu thập và chuẩn hóa pool

Bốn thao tác trước khi candidate được xếp hạng

Các nguồn được thu độc lập; pool sau cùng chỉ giữ một entry cho mỗi productId và tối đa 300 sản phẩm.

productId duy nhất · tối đa 300
  1. 01 · THU KẾT QUẢ

    Nguồn nào chạy được thì dùng nguồn đó

    Các nguồn chạy song song bằng Promise.allSettled: nguồn lỗi hoặc không có kết quả được bỏ qua, kết quả từ nguồn khác vẫn được giữ.

    Đánh đổi: nguồn lỗi làm pool ít lựa chọn hơn, nhưng không làm hỏng cả request.

  2. 02 · LỌC ID

    Không lặp món vừa xem

    Tạo danh sách loại trừ gồm sản phẩm đang mở và tối đa 3 sản phẩm tương tác gần nhất. Các nguồn lọc danh sách này; union kiểm tra lại trước khi nhận món.

    Đánh đổi: giảm gợi ý lặp, nhưng món đang mở sẽ không được đề xuất lại trong request đó.

  3. 03 · GỘP TRÙNG

    Một mã sản phẩm, một candidate

    Dùng productId làm khóa Map. Nếu nhiều nguồn cùng trả một món, chỉ giữ một sản phẩm; nguồn, lý do, rawScore và món làm mốc vẫn được lưu riêng.

    Ý nghĩa: không cộng điểm nguồn thành điểm cuối; ranking nhận đủ dấu vết để tự chấm và giải thích.

  4. 04 · GIỚI HẠN POOL

    Giữ tối đa 300 món để xếp hạng

    Nếu vượt 300, mỗi vòng lấy một món từ từng nguồn. Trong nguồn đó, ưu tiên rawScore cao; món đã được chọn ở nguồn khác thì bỏ qua.

    Đánh đổi: request nhẹ và có giới hạn, nhưng món ít ưu tiên có thể bị cắt. 300 là guardrail hiện tại, chưa phải ngưỡng tối ưu đã được kiểm chứng.

Bước 02

Ví dụ minh họa

Nhiều nguồn có thể cùng tìm thấy một sản phẩm

Hợp nhất theo productId; thông tin từng nguồn vẫn được giữ để ranking sử dụng.

Ví dụ · đầu vào từ ba nguồn

PRODUCT_AFFINITYSP-01, SP-02

SEMANTIC_SIMILARITYSP-01, SP-03

CO_BEHAVIORSP-01, SP-04

Sau khi hợp nhất

SP-01 · 3 nguồnSP-02SP-03SP-04

SP-01 chỉ còn một entry; ba nguồn và lý do xuất hiện vẫn được lưu riêng.

Bước 03

Đầu ra · ranking

Pool candidate được bàn giao để tính điểm

Ứng viên chưa phải thứ hạng hiển thị; bước ranking tiếp theo mới quyết định thứ tự.

Pool đầu vào

Tối đa 300 productId duy nhất

Sản phẩm đang xem và tối đa 3 sản phẩm tương tác gần nhất đã bị loại khỏi pool.

Dấu vết nguồn

Giữ thông tin đóng góp của nguồn

Candidate lưu nguồn tìm thấy; reasonCode và rawScore được giữ theo đóng góp, anchor được lưu khi nguồn cung cấp.

Bước kế tiếp

Standard hoặc AI Ranking

Ranking dùng pool candidate để tính điểm và quyết định thứ tự hiển thị; Candidate Union không cộng điểm nguồn thành điểm cuối.

2.2Vì sao sản phẩm này đứng trước sản phẩm kia?Từ dữ liệu đầu vào, hệ thống tính 8 điểm thế nào, nhân trọng số ra sao và AI pha vào Standard theo công thức nào?

Luồng xếp hạng candidate

Hệ thống tính điểm theo chế độ Standard hoặc AI-Enhanced, sắp candidate theo điểm rồi áp dụng trộn nguồn cold-start (nếu có) và diversity trước khi trả danh sách.

01 · ĐẦU VÀO

Candidate từ pool đã hợp nhất

Mỗi sản phẩm đi kèm dữ liệu sản phẩm, ngữ cảnh hồ sơ/phiên và thông tin nguồn đã tìm thấy.

02 · TẠO FEATURE

Tạo 8 feature cho candidate

Feature đo mức phù hợp trong khoảng 0–1; tín hiệu không có dữ liệu hỗ trợ được tính bằng 0.

03 · TÍNH ĐIỂM

Standard hoặc AI-Enhanced

Standard cộng feature theo trọng số rồi trừ penalty (tối đa 0,15). AI-Enhanced pha điểm Standard với dự đoán AI; thiếu điểm AI hợp lệ thì giữ Standard.

04 · SẮP XẾP

Sắp thứ tự và làm đa dạng

Sắp điểm giảm dần; nếu là COLD_START thì trộn theo quota nguồn, sau đó diversity giới hạn lặp danh mục, thương hiệu và shop. Các bước này có thể đổi thứ tự trả về.

2.2.1Công thức Standard — áp dụng riêng cho từng sản phẩmTính một điểm cho từng candidate; sau đó sắp xếp điểm từ cao xuống thấp.

Cách đọc công thức

Mỗi ứng viên đi qua bốn bước tính điểm
  1. Bước01
    Tính 8 tín hiệu

    Mỗi tín hiệu của sản phẩm được chuẩn hóa về khoảng 0–1.

  2. Bước02
    Nhân trọng số

    Mặc định tổng trọng số là 100%; policy có thể đổi tỷ lệ và hệ thống chuẩn hóa lại.

  3. Bước03
    Trừ điểm không thích

    Preference âm ở sản phẩm, danh mục hoặc thương hiệu giảm theo thời gian (mặc định còn nửa sau 7 ngày); penalty tối đa 0,15.

  4. Bước04
    Giới hạn và xếp thứ tự

    Clamp về 0–1 rồi sắp điểm giảm dần; hòa điểm xét số đóng góp rồi productId. Cold-start và diversity có thể đổi thứ tự trả về.

Trọng số mặc định:Hồ sơ 25%Phiên 18%Ngữ nghĩa 15%Hành vi 10%Phổ biến 12%Độ mới 8%Chất lượng 8%Khám phá 4%

Bước 1 · Tính điểm Standard

S_standard = clamp(Σ(featureᵢ × weightᵢ) − negativePenalty, 0, 1)
Σ weightᵢ = 1  ·  0 ≤ negativePenalty ≤ 0,15

Feature: độ phù hợp theo một tín hiệu; mỗi tín hiệu nằm trong khoảng 0–1.

Weight: mức ảnh hưởng của tín hiệu. Tám trọng số được chuẩn hóa để tổng bằng 100%.

Điểm phạt: trừ phần sở thích tiêu cực đã ghi nhận; giới hạn tối đa 0,15.

Clamp: chặn điểm cuối trong khoảng 0–1, không âm hoặc vượt trần.

Bước 2 · Nhân từng tín hiệu với trọng số

Bảng này giải thích đúng vai trò của Standard: mỗi tín hiệu có ý nghĩa và nguồn điểm riêng, sau đó mới nhân với weight để tạo phần đóng góp. Đây là phép tính xác định, không phải prediction từ model AI.

8 tín hiệu · tổng trọng số 100%
Ý nghĩa, điểm đầu vào, trọng số và phần đóng góp của từng tín hiệu Standard
Tín hiệuÝ nghĩa / nguồn điểmĐiểm · weightĐóng góp
Sở thích hồ sơMức hợp với sở thích dài hạn theo sản phẩm, danh mục và thương hiệu.0,80·25%0,80 × 25% = 0,200
Phiên hiện tạiMức khớp với danh mục, thương hiệu và sản phẩm người dùng vừa xem.0,60·18%0,60 × 18% = 0,108
Tương tự nội dungĐộ gần nội dung hoặc embedding giữa candidate và ngữ cảnh hiện tại.0,90·15%0,90 × 15% = 0,135
Hành vi đi cùngMức candidate thường được xem, thêm giỏ hoặc mua cùng sản phẩm khác.0,50·10%0,50 × 10% = 0,050
Phổ biếnTín hiệu nhu cầu chung từ tổng đã bán và thứ hạng trending/best-selling.0,70·12%0,70 × 12% = 0,084
Độ mớiMức ưu tiên dành cho sản phẩm mới dựa trên tuổi trong catalog.0,55·8%0,55 × 8% = 0,044
Chất lượngKết hợp rating, số review và khả năng còn hàng để phục vụ.0,90·8%0,90 × 8% = 0,072
Khám pháCơ hội thử sản phẩm mới từ EXPLORE/NEWEST khi sở thích chưa rõ.0,00·4%0,00 × 4% = 0,000

Cách đọc: ví dụ “Sở thích hồ sơ” có điểm 0,80 và trọng số 25%, nên đóng góp 0,80 × 0,25 = 0,200. Cộng tám đóng góp được 0,693 trước khi trừ penalty.

Bước 3 · Cộng đóng góp

Tổng có trọng số 0,693

Bước 4 · Trừ phạt, rồi giới hạn

0,693 − 0,040 phạt giả định = 0,653 Standard

Cách đọc kết quả: 0,653 là điểm dùng để so thứ tự các ứng viên trong lần gợi ý này, không phải xác suất mua 65,3%. Ví dụ là số giả định để minh họa.

2.2.2Tám tiêu chí xếp hạngXem cách tính, lý do chọn và đánh đổi của từng tiêu chí bên dưới.

Hướng dẫn

Cách đọc một tiêu chí

Mỗi tiêu chí tạo một phần đóng góp vào điểm Standard; điểm feature và trọng số là hai giá trị khác nhau.

Cách tính đóng gópđiểm feature × trọng số

1. Điểm feature · 0–1

Đo mức phù hợp của sản phẩm theo riêng tiêu chí này: 0 là không có tín hiệu phù hợp, 1 là mức tối đa của công thức.

2. Trọng số · %

Cho biết tiêu chí ảnh hưởng nhiều hay ít đến tổng điểm. Đây là cấu hình của policy, không phải mức phù hợp của sản phẩm.

3. Phần đóng góp

Ví dụ: 0,8 × 25% = 0,20 điểm. Hệ thống cộng đóng góp của tám tiêu chí rồi trừ penalty riêng.

Các trọng số hiển thị bên dưới là mặc định trong code, chưa phải cấu hình tối ưu theo dữ liệu thực tế. Mỗi tiêu chí được tách thành một hàng để dễ xem công thức, ví dụ và đánh đổi.

2.2.2.1Sở thích trong hồ sơƯu tiên sản phẩm, danh mục hoặc thương hiệu người mua từng quan tâm.25% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 25% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Điểm từng sở thích = giới hạn 0–1 [max(0, điểm tích lũy × 0.5^(số ngày ÷ số ngày giảm một nửa)) ÷ 8]

Độ phù hợp hồ sơ = giới hạn 0–1 [điểm sản phẩm + 0.6 × điểm danh mục + 0.4 × điểm thương hiệu]

Nói đơn giản

Hệ thống nhìn vào lịch sử để xem người dùng từng quan tâm đến chính sản phẩm này, nhóm hàng của nó, hay thương hiệu của nó chưa. Khớp đúng sản phẩm được tính mạnh nhất; khớp nhóm hàng hoặc thương hiệu vẫn có ích nhưng được cộng ít hơn.

Hệ thống lấy dữ liệu nào?

Mỗi hành động sẽ cộng hoặc trừ điểm vào lịch sử sở thích của người dùng. Mặc định các điểm là:

  • Thấy sản phẩm được hiển thị: +0.05 điểm.
  • Xem sản phẩm: +1 điểm.
  • Bấm vào sản phẩm: +2 điểm.
  • Thêm vào giỏ: +4 điểm.
  • Bỏ khỏi giỏ: −2 điểm.
  • Tìm kiếm: +1.5 điểm.
  • Mua hàng: +8 điểm cho mỗi sản phẩm.
  • Hoàn trả: −8 điểm cho mỗi sản phẩm.

Ví dụ mua 2 sản phẩm sẽ cộng 16 điểm cho sản phẩm đó. Điểm tìm kiếm chỉ cộng vào sản phẩm, danh mục hoặc thương hiệu nếu hành động tìm kiếm có thông tin tương ứng; riêng nội dung từ khóa được lưu nhưng không được dùng trong phép tính này. Các điểm mặc định có thể thay đổi bằng cấu hình. Danh mục và thương hiệu lấy từ thông tin sản phẩm trong hệ thống.

Mỗi phần trong công thức nghĩa là gì?

  • điểm_lưuTổng điểm đã tích lũy cho một sản phẩm, một danh mục hoặc một thương hiệu. Ví dụ hai lần xem và một lần bấm có điểm mặc định là 1 + 1 + 2 = 4.
  • số_ngàySố ngày từ lần tương tác gần nhất với đúng mục đó đến hiện tại. Mục mới tương tác thì số này gần 0.
  • halfLifeDaysSố ngày để điểm sở thích giảm còn một nửa. Mặc định là 7 ngày; có thể đổi bằng cấu hình.
  • 0.5^(số_ngày / halfLifeDays)Hệ số làm điểm cũ yếu dần. Ví dụ một sở thích có 8 điểm: ngay sau tương tác vẫn là 8; sau 7 ngày còn 8 × 0.5 = 4; sau 14 ngày còn 8 × 0.25 = 2. Như vậy hệ thống ưu tiên điều người dùng quan tâm gần đây hơn.
  • chia cho 8Đổi điểm hành vi sang thang 0–1. Điểm 8 trở lên được xem là mức tối đa 1; 4 điểm thành 0.5; 0 điểm thành 0.
  • max(0, điểm đã giảm)Chỉ lấy sở thích dương cho phần phù hợp. Nếu điểm đang âm, phần phù hợp này nhận 0. Nói cách khác, không thích không thể biến thành “thích”; nó chỉ làm giảm tổng điểm ở khoản trừ riêng.
  • 0.6 × điểm danh mục; 0.4 × điểm thương hiệuĐiểm khớp danh mục được nhân 0.6; điểm khớp thương hiệu được nhân 0.4. Ví dụ danh mục đạt 0.5 thì đóng góp 0.5 × 0.6 = 0.3; thương hiệu đạt 0.5 thì đóng góp 0.5 × 0.4 = 0.2. Khớp đúng sản phẩm không bị nhân giảm.
  • giới hạn trong 0–1Tổng cao hơn 1 vẫn chỉ nhận 1, để một tiêu chí không vượt thang điểm chung.

Nói gọn: điểm sở thích sau khi giảm theo thời gian → đổi về 0–1 → cộng điểm sản phẩm, danh mục và thương hiệu.

Ví dụ tính từng bước

Giả sử sau khi tính độ cũ/mới, hồ sơ đang có: sản phẩm này 4 điểm, danh mục 4 điểm và thương hiệu 2 điểm.

  1. Sản phẩm: 4 ÷ 8 = 0.5 điểm phù hợp.
  2. Danh mục: 4 ÷ 8 = 0.5; nhân 0.6 = 0.3.
  3. Thương hiệu: 2 ÷ 8 = 0.25; nhân 0.4 = 0.1.

Cộng lại: 0.5 + 0.3 + 0.1 = 0.9. Nghĩa là sản phẩm khớp khá mạnh với hồ sơ ở tiêu chí này; không có nghĩa người dùng có 90% khả năng mua.

Lưu ý về thời gian và điểm âm

Hệ thống giảm tổng điểm đang lưu cho từng sản phẩm, danh mục hoặc thương hiệu dựa theo lần tương tác gần nhất với mục đó; không tính tuổi riêng cho từng lượt xem hay lượt mua cũ. Điểm âm như bỏ giỏ hoặc hoàn trả không làm tăng độ phù hợp, mà có thể làm giảm điểm cuối qua khoản trừ riêng. Nếu chưa có lịch sử thì tiêu chí này bằng 0, các tiêu chí khác vẫn có thể xếp hạng sản phẩm.

Khoản trừ vì người dùng không thích được tính ra sao?

  • điểm âmĐiểm âm trong hồ sơ của đúng sản phẩm, danh mục hoặc thương hiệu đang được chấm, thường đến từ hành động như bỏ giỏ hoặc hoàn trả.
  • chia độ lớn điểm âm cho 8Đổi mức không thích sang thang chung. Ví dụ −4 điểm thành 4 ÷ 8 = 0.5; dấu trừ chỉ dùng để nhận ra đây là sở thích âm.
  • cộng các điểm âm rồi nhân 0.15Nhiều dấu hiệu không thích có thể cộng lại. Kết quả bị giới hạn tối đa 0.15, tức tối đa 15 điểm trên thang 100.

Ví dụ một sở thích âm −4 điểm, chưa tính giảm theo thời gian, tạo khoản trừ (4 ÷ 8) × 0.15 = 0.075, tương đương 7.5 điểm trên thang 100. Nếu tổng khoản trừ lớn hơn 0.15 thì chỉ trừ 0.15.

2.2.2.2Nhu cầu trong phiên hiện tạiBắt kịp điều người mua đang xem trong phiên, kể cả khi khác sở thích lâu dài.18% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 18% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Điểm ngữ cảnh = giới hạn 0–1 [(khớp danh mục ? 0.60 : 0) + (khớp thương hiệu ? 0.25 : 0) + (được gợi ý từ sản phẩm hiện tại ? 0.15 : 0)]

Mỗi điều kiện trong ngoặc nhận 1 nếu đúng, 0 nếu sai.

Nói đơn giản

Đây là phần ghi nhận điều người dùng đang quan tâm trong lần ghé thăm hiện tại. Khác với hồ sơ dài hạn, nó giúp gợi ý thay đổi nhanh khi người dùng vừa xem một nhóm hàng hoặc thương hiệu nào đó.

Hệ thống nhớ những gì trong lần ghé thăm?

Trong lúc người dùng ghé website, hệ thống nhớ tạm các danh mục/thương hiệu người dùng vừa tương tác và sản phẩm gần nhất họ thật sự xem hoặc bấm. Dữ liệu này chỉ được nhớ tạm trong lần ghé thăm, không phải toàn bộ lịch sử dài hạn. Chỉ nhìn thấy sản phẩm trên màn hình mà chưa xem/bấm thì không đổi sản phẩm hiện tại.

Các con số trong cách tính

  • 0.60 điểmCộng khi sản phẩm đang chấm thuộc danh mục người dùng vừa xem/tương tác. Nếu không trùng, phần này cộng 0.
  • 0.25 điểmCộng khi thương hiệu của sản phẩm nằm trong các thương hiệu vừa tương tác; không trùng thì cộng 0.
  • 0.15 điểmCộng khi sản phẩm đang chấm được tìm thấy nhờ sản phẩm người dùng đang xem/bấm. Nếu không có mốc này thì cộng 0.
  • tổng điểmCộng các phần khớp lại. Ba phần cộng tối đa 0.60 + 0.25 + 0.15 = 1.00. Các số này là điểm của tiêu chí, không phải xác suất mua.

Ví dụ

Người dùng vừa xem một chiếc nồi. Một sản phẩm khác cùng danh mục nhận 0.60; nếu cùng thương hiệu thì cộng thêm 0.25; nếu còn được gợi ý từ chính chiếc nồi đang xem thì cộng thêm 0.15. Khớp cả ba được 0.60 + 0.25 + 0.15 = 1.00; chỉ cùng danh mục thì được 0.60.

Khi nào điểm bằng 0?

Không có dữ liệu phiên, sản phẩm không trùng danh mục/thương hiệu gần đây và cũng không được tìm từ sản phẩm hiện tại. Khi đó tiêu chí này không cộng điểm; các tiêu chí còn lại vẫn hoạt động.
2.2.2.3Sản phẩm tương tự về nội dungTìm thêm lựa chọn gần với sản phẩm người mua đang quan tâm, dù khác danh mục.15% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 15% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Dãy số nội dung chung = tổng(dãy số của từng mốc × trọng số mốc) ÷ tổng trọng số mốc

Điểm tương đồng = giới hạn 0–1 (điểm bộ tìm kiếm trả về khi so sản phẩm với dãy số chung)

Nói đơn giản

Hệ thống mã hóa nội dung sản phẩm thành một dãy số ngắn, có thể hình dung như “dấu vân tay nội dung”. Sản phẩm có tên/mô tả/đặc điểm gần nhau thường có dấu vân tay gần nhau, dù khác danh mục hoặc chưa từng được mua cùng. Điểm này đo độ giống nội dung, không đo khả năng người dùng sẽ mua.

Sản phẩm nào được dùng làm mốc?

  • Sản phẩm hiện tại — trọng số 1Sản phẩm người dùng đang xem hoặc sản phẩm được truyền vào làm điểm bắt đầu.
  • Tối đa 5 sản phẩm vừa tương tácMỗi sản phẩm được đặt trọng số theo hành động gần nhất: mặc định xem = 1, bấm = 2, thêm giỏ = 4. Nếu không có trọng số thì dùng 1. Hành động có điểm 0 hoặc âm, như bỏ giỏ, không được dùng làm mốc nội dung.
  • Tối đa 5 sản phẩm hồ sơ — trọng số 0.5Chỉ lấy sản phẩm người dùng đã thể hiện sở thích dương; mỗi sản phẩm này có ảnh hưởng bằng một nửa mốc trọng số 1.

Từng phần trong cách tính

  • dấu vân tay × trọng sốLấy dãy số của từng sản phẩm mốc nhân với trọng số tương ứng. Mốc có trọng số lớn sẽ ảnh hưởng nhiều hơn đến “dấu vân tay chung” mà hệ thống dùng để tìm sản phẩm.
  • chia cho tổng trọng sốCộng trọng số của các mốc rồi chia để lấy mức trung bình có cân nhắc độ quan trọng. Nhờ vậy, thêm nhiều sản phẩm mốc không tự làm điểm cao hơn.
  • điểm giống nhau từ 0 đến 1Bộ tìm kiếm so sánh dấu vân tay chung với từng sản phẩm. 0 nghĩa là rất ít giống; 1 là mức giống cao nhất. Ví dụ 0.82 nghĩa là bộ tìm kiếm cho điểm tương đồng 0.82 trên thang 0–1. Đây không phải phép đếm 82% từ ngữ trùng nhau hay xác suất mua 82%.

Dãy số được tạo trước bằng mô hình mã hóa nội dung — mô hình biến tên, thương hiệu, danh mục, mô tả và thuộc tính sản phẩm thành số — rồi lưu lại. Khi có yêu cầu, hệ thống dùng các số này để tìm sản phẩm gần giống; đây không phải AI-Enhanced Ranking và cũng không phải AI trò chuyện viết câu trả lời mới cho từng lượt.

Ví dụ dễ hình dung

Giả sử hai sản phẩm mốc là sản phẩm đang xem (trọng số 1) và sản phẩm vừa bấm (trọng số 2). Tổng trọng số là 1 + 2 = 3: sản phẩm đang xem ảnh hưởng 1/3, sản phẩm vừa bấm ảnh hưởng 2/3 đến dấu vân tay chung. Nếu sản phẩm được tìm thấy có điểm giống 0.82 thì điểm tiêu chí là 0.82.

Khi nào không có điểm?

Mốc nào chưa có dãy số nội dung thì được bỏ qua. Nếu không còn mốc nào dùng được, nội dung đã đổi nhưng chưa cập nhật, hoặc bộ tìm kiếm không trả sản phẩm phù hợp, tiêu chí này không đóng góp; các cách gợi ý khác vẫn tiếp tục chạy.
2.2.2.4Sản phẩm thường đi cùng nhauDùng hành vi của nhiều người để nhận ra các món thường được xem, thêm giỏ hoặc mua cùng nhau.10% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 10% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Điểm quan hệ sau giảm = điểm quan hệ ban đầu × 0.5^(số ngày ÷ số ngày giảm một nửa)

Điểm một mối liên hệ = max(0, điểm sau giảm) ÷ [max(0, điểm sau giảm) + mốc so sánh]

Điểm Hành vi liên quan = điểm cao nhất trong các mối liên hệ tìm được

Nói đơn giản

Nếu nhiều phiên mua sắm cho thấy hai sản phẩm hay xuất hiện cùng nhau, hệ thống ghi nhận chúng có liên quan. Khi người dùng quan tâm sản phẩm A, sản phẩm B có thể được gợi ý theo mối liên hệ đó. Đây là “người mua/xem cùng nhau”, không phải “nội dung giống nhau”.

Hệ thống ghi nhận hai sản phẩm liên quan khi nào?

  • Cùng được xemTrong cùng phiên ghé website, nếu hai sản phẩm được xem, bấm hoặc hiển thị trong khoảng 30 phút thì ghi nhận một mối liên hệ.
  • Cùng được thêm giỏNếu cùng người dùng hoặc cùng phiên thêm hai sản phẩm vào giỏ trong vòng 7 ngày, hệ thống ghi nhận chúng liên quan.
  • Cùng đơn hàngCác sản phẩm trong một đơn mua hoàn tất được nối với nhau. Nếu đơn hàng bị hoàn trả, điểm của mối liên hệ mua sẽ bị trừ.

Mỗi hành động đóng góp một số điểm mặc định: xem = 1, bấm = 2, chỉ được hiển thị = 0.05, thêm vào giỏ = 3, mua chung = 6 và hoàn trả = −6. Đây là điểm quy ước để so sánh, không phải số người. Nhiều lần liên quan sẽ cộng dồn; điểm cũ giảm còn một nửa sau mỗi 30 ngày. Các mức này có thể được đổi bằng cấu hình.

Từng con số trong công thức

  • điểm quan hệĐiểm tích lũy giữa hai sản phẩm sau khi đã tính các lần cùng xem/thêm giỏ/mua và làm giảm ảnh hưởng của điểm cũ. Điểm càng cao nghĩa là mối liên hệ càng mạnh.
  • 0 nếu điểm quan hệ âmMột lần hoàn trả có thể kéo điểm quan hệ mua xuống. Điểm âm không tạo gợi ý liên quan dương.
  • mốc so sánh (scale)Đây là số dùng để đổi điểm quan hệ sang thang 0–1: mặc định 1 cho cùng xem, 3 cho cùng thêm giỏ và 6 cho cùng mua. Chọn mốc lớn hơn khiến cùng một điểm tích lũy được đổi thành điểm thấp hơn. Có thể thay các mốc này bằng cấu hình.
  • điểm quan hệ ÷ (điểm quan hệ + mốc so sánh)Đổi điểm tích lũy sang thang 0–1. Khi điểm quan hệ bằng mốc so sánh thì kết quả là 0.5. Điểm càng tăng thì kết quả tiến gần 1, nhưng không vượt 1.
  • lấy điểm mạnh nhấtNếu một sản phẩm liên quan qua nhiều sản phẩm mốc hoặc nhiều loại hành vi, hệ thống dùng mối liên hệ có điểm cao nhất, không cộng tất cả lại.

Ví dụ tính điểm

Giả sử mối liên hệ “cùng thêm giỏ” có 3 điểm sau khi đã tính thời gian. Loại quan hệ này có mốc so sánh 3, nên kết quả là 3 ÷ (3 + 3) = 0.5. 0.5 ở đây là điểm liên quan đã quy đổi, không có nghĩa 50% người dùng chắc chắn mua sản phẩm.

Khi nào tiêu chí này bằng 0?

Chưa có đủ tương tác để nối sản phẩm với sản phẩm mốc, hoặc điểm quan hệ bị các lần hoàn trả kéo về 0. Khi đó các nguồn và tiêu chí gợi ý khác vẫn tiếp tục hoạt động.
2.2.2.5Mức độ phổ biếnTạo điểm tựa khi người mua chưa có nhiều dữ liệu cá nhân.12% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 12% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Điểm thứ hạng = giới hạn 0–1 [1 − (hạng − 1) ÷ max(số sản phẩm trong danh sách − 1, 1)]

Điểm phổ biến = giới hạn 0–1 [max(ln(1 + max(số đã bán, 0)) ÷ 12, điểm thứ hạng cao nhất từ danh sách thịnh hành/bán chạy)]

Nói đơn giản

Tiêu chí này giúp sản phẩm bán được nhiều hoặc đang đứng cao trong danh sách thịnh hành có cơ hội được gợi ý. Nó đặc biệt hữu ích khi người dùng chưa có nhiều lịch sử riêng.

Hai nguồn điểm

  • Số lượng đã bánTổng số lượng đã bán được đồng bộ trong thông tin sản phẩm. Bán nhiều giúp tăng điểm, nhưng mức tăng chậm dần để một sản phẩm bán cực nhiều không lấn át tất cả sản phẩm khác.
  • Thứ hạng trong danh sáchVị trí sản phẩm trong danh sách thịnh hành hoặc bán chạy: hạng 1 là đầu danh sách. Danh sách bán chạy được dùng khi hệ thống đang gợi ý cho người chưa có hồ sơ sở thích.
  • lấy điểm cao hơnSo sánh điểm từ số bán với điểm từ thứ hạng rồi chọn điểm lớn hơn. Cuối cùng giới hạn kết quả tối đa là 1.

Các biến trong công thức thứ hạng

  • rankVị trí của sản phẩm trong một danh sách: hạng 1 là đầu danh sách, hạng 10 là vị trí thứ 10.
  • sizeTổng số sản phẩm trong chính danh sách đó. Nếu danh sách có 10 sản phẩm thìsize = 10.
  • 1 − (rank − 1) ÷ (size − 1)Công thức đổi vị trí thành điểm. Ví dụ danh sách có 10 sản phẩm: hạng 1 được 1; hạng 4 được 1 − (4−1) ÷ (10−1) = 0.67; hạng 10 được 0. Danh sách chỉ có một sản phẩm thì sản phẩm đó được 1.
  • ln(1 + totalSold) ÷ 12totalSold là tổng số lượng đã bán; ln là phép đổi khiến số bán tăng điểm chậm dần; số 1 giúp trường hợp chưa bán món nào cho kết quả 0. Số 12 là mức điều chỉnh độ lớn, không đảm bảo riêng phép tính này luôn nằm dưới 1: nếu vượt 1, bước cuối sẽ chặn điểm ở 1. Ví dụ bán 100 món: ln(101) ÷ 12 ≈ 0.38.

Ví dụ tính đầy đủ

Giả sử sản phẩm đã bán 100 món và đứng hạng 4 trong danh sách có 10 món. Điểm từ số bán xấp xỉ 0.38. Điểm từ thứ hạng là 1 − (4 − 1) ÷ (10 − 1) = 0.67. Hệ thống chọn điểm cao hơn, nên Độ phổ biến của sản phẩm là khoảng 0.67.

Lưu ý

Số bán và danh sách thịnh hành/bán chạy lấy từ dữ liệu sản phẩm đã đồng bộ; tiêu chí này không đếm lượt bấm mới theo thời gian thực. 0.67 là điểm để xếp thứ tự, không có nghĩa sản phẩm có 67% cơ hội được mua.
2.2.2.6Độ mới của sản phẩmDành một phần cơ hội hiển thị cho sản phẩm mới.8% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 8% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Điểm độ mới theo số ngày từ lúc tạo sản phẩm:

1.00 nếu không quá 1 ngày

0.80 nếu trên 1 ngày và không quá 7 ngày

0.55 nếu trên 7 ngày và không quá 30 ngày

0.30 nếu trên 30 ngày và không quá 90 ngày

0.10 nếu trên 90 ngày

Nói đơn giản

Sản phẩm mới được cộng điểm “còn mới” cao hơn. Càng lâu không còn là sản phẩm mới thì điểm này càng thấp, nhưng sản phẩm cũ vẫn còn 0.10 điểm chứ không bị về 0 hoàn toàn.

Các giá trị nghĩa là gì?

  • ngày tuổi sản phẩmSố ngày từ ngày sản phẩm được tạo đến lúc chấm điểm. Nếu ngày tạo bị ghi trong tương lai do lệch đồng hồ, hệ thống tính tuổi là 0 ngày.
  • 1.00Sản phẩm được tạo trong vòng 1 ngày; đây là điểm mới cao nhất.
  • 0.80Sản phẩm đã hơn 1 ngày nhưng chưa quá 7 ngày.
  • 0.55Sản phẩm đã hơn 7 ngày nhưng chưa quá 30 ngày.
  • 0.30Sản phẩm đã hơn 30 ngày nhưng chưa quá 90 ngày.
  • 0.10Sản phẩm đã hơn 90 ngày.

Ví dụ

Sản phẩm được tạo 5 ngày trước nhận 0.80 điểm mới. Sản phẩm được tạo 20 ngày trước nhận 0.55. Khi bước qua mốc 30 ngày, điểm chuyển xuống 0.30; điểm không giảm từng chút mỗi ngày mà đổi theo các mốc cố định này.

Vì sao không dùng tuổi chính xác từng giờ?

Chia thành các mốc giúp điểm ổn định và dễ dự đoán; sản phẩm mới có lợi thế vừa phải thay vì mỗi phút đều làm thứ hạng thay đổi. Tỷ trọng của tiêu chí này hiện là 8%, nên độ mới không tự quyết định toàn bộ thứ hạng.
2.2.2.7Chất lượng và tồn khoKhuyến khích sản phẩm được đánh giá tốt, có đánh giá đủ tin cậy và còn hàng.8% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 8% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Điểm Chất lượng = giới hạn 0–1 [(giới hạn ratingAvg ÷ 5 trong 0–1 × 0.55) + (giới hạn ln(1 + max(reviewCount, 0)) ÷ ln(101) trong 0–1 × 0.25) + (còn hàng ? 0.20 : 0)]

Nói đơn giản

Điểm này gộp ba điều dễ hiểu: khách chấm sản phẩm bao nhiêu sao, có bao nhiêu lượt đánh giá và sản phẩm còn hàng hay không. Mục đích là tránh để số bán hoặc độ mới quyết định hết thứ hạng.

Từng giá trị và tỷ lệ đóng góp

  • ratingAvg ÷ 5 × 0.55ratingAvg là điểm sao trung bình, từ 0 đến 5. Chia 5 để đổi thành thang 0–1; nhân 0.55 nghĩa là số sao có thể đóng góp tối đa 55% điểm Chất lượng. Ví dụ 4.5 sao: 4.5 ÷ 5 × 0.55 = 0.495.
  • ln(1 + reviewCount) ÷ ln(101) × 0.25reviewCount là số lượt đánh giá. Phép ln làm số lượt tăng điểm chậm dần. Số 101 là 100 lượt đánh giá cộng 1; vì vậy chia cho ln(101)để 100 lượt tương ứng mức 1. Nhân 0.25 nên phần đánh giá đóng góp tối đa 25%. Không có lượt đánh giá thì phần này bằng 0; trên 100 lượt cũng không vượt mức 25%.
  • còn hàng × 0.20Trạng thái còn hàng chỉ có hai trường hợp: còn hàng thì cộng 0.20, hết hàng thì cộng 0. Phần này đóng góp tối đa 20% điểm Chất lượng.
  • 0.55 + 0.25 + 0.20Ba phần trên chia toàn bộ điểm Chất lượng: sao chiếm 55%, số lượt đánh giá 25%, tình trạng còn hàng 20%. Tổng cuối được giới hạn trong khoảng 0–1.

Ví dụ tính điểm

Giả sử sản phẩm có 4.5 sao, 25 lượt đánh giá và còn hàng. Phần sao là 0.495; 25 lượt đánh giá được đổi thành khoảng 0.71 rồi nhân 0.25, được khoảng 0.177; còn hàng cộng 0.20. Tổng là khoảng 0.87/1. Nếu không có sao hoặc đánh giá, phần tương ứng bằng 0; nếu hết hàng thì không được cộng 0.20.

Dữ liệu này đến từ đâu?

Số sao trung bình, số lượt đánh giá và tình trạng còn hàng được đọc từ thông tin sản phẩm đã đồng bộ. Đây là công thức quy tắc cố định, không phải AI đọc nội dung từng bài đánh giá. Bộ lọc sản phẩm không hợp lệ vẫn chạy riêng trước bước chấm điểm.
2.2.2.8Khám phá sản phẩm mớiCho người ít dữ liệu cơ hội thấy sản phẩm mới hoặc được chọn từ nguồn khám phá.4% · mặc địnhMở “Cách tính” để xem công thức, dữ liệu và ví dụ chi tiết

Tỷ trọng 4% là mức quan trọng bạn dành cho tiêu chí này, không phải điểm sản phẩm đạt được. Điểm riêng của tiêu chí nằm trong khoảng 0–1: 0 là không có dấu hiệu phù hợp, 1 là mức tối đa công thức cho phép. Ví dụ 0.8 tương đương 80/100 điểm riêng; nó không có nghĩa người dùng có 80% khả năng mua.

Khi chấm điểm, hệ thống cộng tất cả tỷ trọng rồi chia tỷ trọng của tiêu chí này cho tổng đó. Ví dụ 25% trên tổng 100% trở thành 0.25; điểm riêng 0.8 × 0.25 = 0.20, tức đóng góp 20/100 điểm tổng. Nếu tổng các ô là 80%, một ô 20% được quy đổi thành 20 ÷ 80 = 25% trước khi tính. Nếu tất cả tỷ trọng đều bằng 0, hệ thống quay về bộ mặc định thay vì chia cho 0.

Lưu ý về các con số: tỷ trọng trong các ô là thứ bạn đang chỉnh. Còn các số nằm bên trong công thức như 0.6, 7 ngày hay 12 là quy tắc mặc định do dự án đặt để bắt đầu — không phải kết quả hệ thống đã học từ khách hàng thật. Một số có thể đổi trong cấu hình dịch vụ; những số khác hiện cố định trong code. Đây là Standard Ranking, không phải mô hình AI-Enhanced Ranking.

Công thức đầy đủ

Điểm khám phá = 1 nếu độ phù hợp hồ sơ ≤ 0.4 VÀ nguồn sản phẩm là NEWEST hoặc EXPLORE

Trong mọi trường hợp khác, điểm khám phá = 0.

Nói đơn giản

Khi hệ thống chưa hiểu rõ sở thích người dùng, tiêu chí này cho sản phẩm mới hoặc sản phẩm được chọn để khám phá thêm cơ hội xuất hiện. Khi hồ sơ đã đủ rõ, hệ thống ưu tiên những tiêu chí phù hợp trực tiếp hơn.

Từng phần trong điều kiện

  • Độ phù hợp hồ sơ ≤ 0.4Dùng kết quả của tiêu chí Độ phù hợp hồ sơ đã giải thích ở trên. 0.4 tương đương 40/100; nghĩa là hệ thống chưa có bằng chứng sở thích mạnh. Mốc này là điều kiện bật khám phá, không phải tỷ trọng.
  • NEWESTSản phẩm được lấy từ danh sách sản phẩm mới trong dữ liệu sản phẩm.
  • EXPLORESản phẩm được lấy từ danh sách sản phẩm dành cho khám phá.
  • điểm 1 hoặc 0Nếu đồng thời hồ sơ không quá 0.4 và sản phẩm đến từ NEWEST hoặc EXPLORE, tiêu chí này cho 1 điểm. Thiếu một trong hai điều kiện thì cho 0 điểm.

Ví dụ

Hồ sơ đạt 0.35/1 và sản phẩm thuộc danh sách mới: cả hai điều kiện đúng, nên điểm khám phá = 1. Nếu đặt tỷ trọng 4%, phần đóng góp sẽ là 1 × 0.04 = 0.04 điểm. Nếu hồ sơ đạt 0.41/1 thì điểm khám phá bằng 0, kể cả sản phẩm mới.

Khi nào không được cộng điểm?

Khi hồ sơ đã trên 0.4, hoặc sản phẩm không có nguồn từ danh sách mới/khám phá. Hai tên này chỉ cho biết sản phẩm được đưa vào danh sách gợi ý từ đâu; chúng không phải điểm hay dữ liệu sở thích.
2.2.3Công thức AI-Enhanced Ranking hoạt động như thế nào?Đọc từ trên xuống: xem cách hệ thống chọn sản phẩm, chấm điểm ban đầu, nhờ AI sắp xếp tốt hơn và vẫn giữ kết quả an toàn khi AI gặp lỗi.

01 · ĐỌC TRƯỚC FLOW TỔNG QUAN

Từ một candidate đến thứ hạng cuối cùng

AI không tự tạo danh sách sản phẩm. Hệ thống chọn ra các sản phẩm phù hợp trước, chấm điểm theo cách thông thường, rồi chỉ nhờ AI sắp xếp lại khi đủ điều kiện. Nếu AI gặp lỗi, hệ thống vẫn trả kết quả bằng cách chấm điểm ban đầu.

Bước 01

Đầu vào · candidate pool

Hợp nhất sản phẩm phù hợp

Gộp candidate từ catalog, profile/session và các nguồn liên quan.

Bước 02

Baseline · Standard Ranking

Tính Standard score

Tính từ 8 feature, weight và negative penalty.

Bước 03

Điều kiện · runtime policy

Kiểm tra điều kiện chạy AI

Kiểm tra policy, khả năng gọi model và trạng thái model.

Bước 04

Inference · LightGBM

Dự đoán AI score

Gửi 9 feature theo batch đến AI Service.

Bước 05

Blend · hybrid score

Pha AI với Standard

λ quyết định mức ảnh hưởng AI.

Bước 06

Đầu ra · final ranking

Sort và trả kết quả

Sort, diversity/quota và trả metadata.

Cách đọc flow: Nếu một bước AI thất bại, flow không dừng. Nó quay về Standard ở đúng boundary phù hợp và vẫn trả được recommendation.

02 · CÔNG THỨC CỐT LÕI

Standard tạo nền, AI điều chỉnh có giới hạn

Mục tiêu của công thức là xếp sản phẩm phù hợp lên trước nhưng vẫn giữ kết quả ổn định, giải thích được và có thể quay về Standard bất cứ lúc nào.

Standard score

S_standard = clamp(Σ(featureᵢ × weightᵢ) − negativePenalty, 0, 1)

Đây là điểm nền do code tính trực tiếp từ 8 tín hiệu nghiệp vụ. Mỗi tín hiệu nằm trong khoảng 0–1, được nhân với trọng số, cộng lại rồi trừ riêng tín hiệu không phù hợp.

Mục tiêu: luôn có một thứ tự sản phẩm an toàn để phục vụ người dùng và làm mốc so sánh khi thử AI.

AI-Enhanced final score

S_final = clamp((1 − λ) × S_standard + λ × S_AI, 0, 1)

AI không thay thế điểm nền. Model chỉ dự đoán thêm S_AI, sau đó hệ thống pha hai điểm bằng λ = mlBlend.

Mục tiêu: tận dụng quan hệ phức tạp mà model học được nhưng giới hạn rủi ro; λ chỉ từ 0 đến 0,5 nên Standard luôn giữ ít nhất 50% ảnh hưởng.

Feature: tín hiệu đã đưa về 0–1.

Weight: mức ảnh hưởng của feature trong Standard.

λ: mức ảnh hưởng của AI ở điểm cuối.

Clamp: giữ score cuối trong khoảng 0–1.

Đọc các ký hiệu trong công thức

featureᵢ: một tín hiệu của candidate, ví dụ sản phẩm có hợp sở thích hay đang được xem cùng sản phẩm hiện tại không. Tất cả đều được chuẩn hóa về 0–1.

weightᵢ: mức ưu tiên của tín hiệu trong Standard. Weight không phải điểm của sản phẩm; nó là “quyền biểu quyết” của từng feature.

negativePenalty: mức trừ cho preference âm như sản phẩm, category hoặc brand người dùng từng trả lại hay thể hiện không phù hợp. Penalty bị giới hạn tối đa 0,15.

S_AI: điểm LightGBM dự đoán từ đúng 9 giá trị đầu vào. Đây là ranking score 0–1, không phải xác suất mua hàng.

λ = mlBlend: tỷ lệ ảnh hưởng của AI. λ = 0 nghĩa là chỉ Standard; λ = 0,3 nghĩa là 70% Standard và 30% AI.

clamp(x, 0, 1): nếu x nhỏ hơn 0 thì đưa về 0, lớn hơn 1 thì đưa về 1. Việc này giữ mọi score cùng một thang đo.

Công thức tạo ra từng feature

Đây là lớp chuẩn hóa trước khi cộng weight. Mục đích là đưa các nguồn dữ liệu khác nhau — preference, phiên truy cập, Qdrant, quan hệ hành vi và catalog — về cùng thang 0–1 để so sánh công bằng.

profileAffinity = clamp(P + 0,6C + 0,4B)

P/C/B lần lượt là preference của product/category/brand. Mỗi preference được decay theo score × 0,5^(tuổi / halfLife), chia 8 rồi clamp. Mặc định half-life là 7 ngày.

sessionContext = clamp(0,6C + 0,25B + 0,15A)

C = trùng category gần đây, B = trùng brand gần đây, A = candidate có cùng sản phẩm neo hiện tại. Mỗi điều kiện là 0 hoặc 1; trọng số giúp nhu cầu trong phiên phản ứng nhanh.

semanticSimilarity = clamp(rawSimilarity)

Lấy similarity từ embedding/Qdrant. Source chỉ đóng góp khi vector còn khớp snapshot catalog; clamp bảo vệ ranker nếu provider trả giá trị ngoài 0–1.

coBehavior = max(raw / (raw + scale))

Chuẩn hóa từng quan hệ rồi lấy giá trị lớn nhất của candidate. Scale mặc định: CO_VIEW = 1, CO_CART = 3, CO_PURCHASE = 6; hành vi mua vì thế có ngưỡng mạnh hơn xem.

popularity = clamp(max(log1p(totalSold) / 12, sourceRankScore))

Kết hợp tổng đã bán với vị trí trong TRENDING/BEST_SELLING. Dùng log1p để vài sản phẩm bán quá nhiều không lấn át toàn bộ danh sách.

freshness = bucket theo tuổi sản phẩm

≤ 1 ngày: 1, ≤ 7 ngày: 0,8, ≤ 30 ngày: 0,55, ≤ 90 ngày: 0,3, cũ hơn: 0,1. Bucket ổn định hơn một hàm liên tục và vẫn tạo cơ hội cho item mới.

quality = clamp(0,55R + 0,25V + 0,2I)

R = rating/5, V = log1p(reviewCount) / log1p(100), I = 1 nếu còn tồn kho. Rating là tín hiệu chính, review tạo độ tin cậy, stock ngăn đẩy item không thể phục vụ.

exploration = profileAffinity > 0,4 ? 0 : sourceMatch

Nếu đã có affinity mạnh thì không cộng thêm exploration. Nếu chưa, candidate từ EXPLORE/NEWEST nhận 1 để khám phá có kiểm soát thay vì ngẫu nhiên.

Penalty riêng: các preference âm được decay giống preference dương, cộng theo product/category/brand, chuẩn hóa theo 8 rồi giới hạn negativePenalty ≤ 0,15. Tách penalty khỏi feature dương giúp “không phù hợp” luôn làm giảm điểm và không bị triệt tiêu bởi một tín hiệu tích cực khác.

Trọng số Standard mặc định và mục tiêu của từng tín hiệu
Tín hiệuWeight mặc địnhNguồn dữ liệuMục tiêu
profileAffinity0,25 · 25%Preference dài hạn theo sản phẩm, category, brandCá nhân hóa theo sở thích đã tích lũy
sessionContext0,18 · 18%Category, brand và sản phẩm gần đây trong phiênBắt kịp nhu cầu hiện tại nhanh hơn profile dài hạn
semanticSimilarity0,15 · 15%Similarity từ embedding/QdrantTìm sản phẩm gần nhau về nội dung
coBehavior0,10 · 10%Quan hệ xem, thêm giỏ và mua cùng nhauKhai thác hành vi “người xem món này cũng xem món kia”
popularity0,12 · 12%Total sold và thứ hạng trending/best-sellingGiữ sản phẩm có nhu cầu chung không bị bỏ quên
freshness0,08 · 8%Tuổi sản phẩm trong catalogTạo cơ hội cho sản phẩm mới
quality0,08 · 8%Rating, số review và tình trạng tồn khoƯu tiên item có chất lượng và còn khả năng phục vụ
exploration0,04 · 4%Nguồn EXPLORE/NEWEST khi affinity chưa caoMở rộng khám phá nhưng không lấn át cá nhân hóa
Tổng1,00 · 100%Backend tự normalize tổng weight về 1. Admin có thể thay đổi tỷ lệ, nhưng không được gửi key lạ hoặc tổng bằng 0.

Các con số này lấy từ đâu?

Weight mặc định là policy khởi đầu được khai báo trong RecommendationRuleService. Chúng là quyết định sản phẩm có thể điều chỉnh qua Admin, không phải con số tự sinh bởi LightGBM.

AI học từ đâu?

LightGBM được train offline từ dataset gồm 9 feature và label 0–1. Runtime chỉ load artifact đã train; model không tự thay đổi trọng số trong lúc người dùng gửi request.

Vì sao không để AI quyết định hết?

Standard dễ audit và luôn có sẵn. Giới hạn mlBlend ≤ 0,5, kiểm tra prediction và fallback giúp rollout AI có kiểm soát.

03 · ĐI CHI TIẾT THEO FLOW

Mỗi bước giải quyết một vấn đề khác nhau

Đọc lần lượt từ Bước 01 đến Bước 06. Phần này giải thích tại sao bước đó tồn tại, nó dùng thành phần nào và đánh đổi là gì.

Bước 01

Điều kiện · runtime policy

Kiểm tra policy và khả năng chạy AI

Khi policy bật, mọi request đều được thử bằng AI; model lỗi sẽ fallback Standard.

Tại sao cần: Cần biết AI đang được bật hay tắt trước khi chọn mode phục vụ request.

Dùng để làm gì: Đọc mlEnabled. Khi bật, AI áp dụng cho 100% request đủ điều kiện; không hash actor/session để chia nhóm.

Đánh đổi: AI có thể tốn thêm độ trễ; vì vậy model lỗi hoặc không hợp lệ vẫn phải fallback về Standard để không làm hỏng response.

Bước 02

Baseline · Standard Ranking

Tính Standard score trước

Baseline phải sẵn sàng ngay cả khi AI chưa tồn tại hoặc không phản hồi.

Tại sao cần: Người dùng luôn cần kết quả; Standard cũng là mốc để so sánh AI.

Dùng để làm gì: Tính 8 feature theo hybrid weights, trừ negativePenalty và clamp thành S_standard.

Đánh đổi: Dễ giải thích và ổn định, nhưng không học được tương tác phức tạp giữa nhiều tín hiệu.

Bước 03

Đầu vào · model contract

Tạo feature vector đúng thứ tự

Một candidate được biến thành 9 cột số mà artifact đã được train để hiểu.

Tại sao cần: JSON đúng format chưa đủ; sai thứ tự cột sẽ khiến model hiểu sai ý nghĩa dữ liệu.

Dùng để làm gì: Gửi profileAffinity, sessionContext, semanticSimilarity, coBehavior, popularity, freshness, quality, exploration, negativePenalty.

Đánh đổi: Kết quả nhất quán và dễ validate, nhưng đổi feature bắt buộc kiểm tra hoặc train lại artifact.

Bước 04

Inference · AI Service

Gọi LightGBM qua internal contract

Recommendation Service gọi batch prediction; browser không được gọi trực tiếp AI Service.

Tại sao cần: Tách model thành AI Service giúp thay model, scale inference và theo dõi readiness độc lập.

Dùng để làm gì: Gửi tối đa 300 item bằng internal token; AI Service validate payload và trả S_AI trong 0–1.

Đánh đổi: Có network hop và timeout. Batch hiệu quả hơn nhưng lỗi có thể khiến cả batch fallback.

Bước 05

Safety check · validation

Kiểm tra prediction trước khi blend

Response nội bộ vẫn được xem là untrusted input cho đến khi đủ điều kiện.

Tại sao cần: Prediction sai có thể làm sai thứ hạng và cả số liệu phân tích hiệu quả.

Dùng để làm gì: Kiểm tra item ID, duplicate, số lượng, 9 feature, số hữu hạn, score 0–1 và model version. ranking-fallback-v1 không được tính là ML.

Đánh đổi: Validation chặt làm fallback nhiều hơn, nhưng bảo vệ chất lượng và độ tin cậy của metrics.

Bước 06

Đầu ra · final ranking

Blend, sort và áp dụng luật hiển thị

AI điều chỉnh score; nó không được bypass diversity, quota hoặc fallback của hệ thống.

Tại sao cần: Điểm AI chỉ là tín hiệu bổ sung, không phải quyết định kinh doanh cuối cùng.

Dùng để làm gì: Tính S_final, sort giảm dần, áp cold-start mix/diversity và trả rankingModevà model version.

Đánh đổi: Diversity có thể đẩy item điểm cao xuống để tránh lặp shop/category, nhưng danh sách cân bằng và hữu ích hơn.

04 · MODEL ĐƯỢC TRAIN NHƯ THẾ NÀO?

LightGBM học từ feature và label, không tự học trực tiếp trong request

Training là quy trình offline. Request online chỉ load artifact đã train và gọi prediction; không train lại, không gọi provider AI để tạo dữ liệu trong lúc người dùng chờ.

LightGBM là thuật toán gì?

LightGBM là thuật toán học có giám sát thuộc nhóm Gradient Boosting Decision Tree. Model tạo ra nhiều cây quyết định nhỏ. Cây sau quan sát lỗi của các cây trước rồi học thêm phần còn thiếu; tổng của các cây tạo thành dự đoán cuối.

Mỗi nhánh cây có thể học một điều kiện như “sessionContext cao nhưng quality thấp” hoặc “semanticSimilarity cao và candidate đến từ nhóm liên quan”. Vì vậy model nhìn được mối quan hệ kết hợp giữa nhiều feature mà phép cộng tuyến tính của Standard không biểu diễn được.

Trong hệ thống này: LightGBM chỉ re-rank tối đa 300 candidate đã được Recommendation Service chọn. Nó không tìm sản phẩm, không đọc trực tiếp catalog và không thay thế bước filter, quota hay diversity.

Model cải thiện điểm nào?

  • Standard: dễ hiểu nhưng cộng các tín hiệu theo weight cố định.
  • LightGBM: học được ngưỡng và tương tác phi tuyến từ dữ liệu lịch sử.
  • Kết quả: các candidate có cùng Standard score vẫn có thể được phân biệt tốt hơn theo pattern từng xuất hiện trong hành vi người dùng.
  • Giới hạn: model chỉ cải thiện thứ tự trong candidate pool; candidate bị thiếu từ bước tạo nguồn sẽ không thể được AI “tìm lại”.

Model chỉ tốt khi nào?

  • Dữ liệu đủ: có đủ lượt hiển thị và tương tác đại diện cho nhiều nhóm người dùng, không chỉ một vài sản phẩm phổ biến.
  • Label đúng: click, thêm giỏ hoặc purchase phải phản ánh đúng mục tiêu muốn tối ưu; label nhiễu sẽ khiến model học sai.
  • Feature nhất quán: 9 feature lúc train phải có cùng ý nghĩa, thứ tự và cách chuẩn hóa khi inference.
  • Được đo lường: cần validation offline, theo dõi CTR, conversion, latency và data drift sau khi rollout.
  • Không bị lệch dữ liệu: nếu chỉ train từ sản phẩm đã được ưu tiên trước đó, model có thể lặp lại bias cũ.

Vì sao chọn LightGBM thay vì các hướng khác?

Đây là lựa chọn phù hợp nhất với bài toán re-ranking hiện tại

LightGBM không được chọn vì nó luôn tốt hơn mọi thuật toán. Nó được chọn vì khớp với các ràng buộc đang có: mỗi candidate chỉ có 9 feature dạng số, label được chuẩn hóa về 0–1, request cần inference nhanh, model phải dễ kiểm tra và có thể fallback về Standard bất cứ lúc nào.

Dữ liệu: Gradient boosting rất hợp với dữ liệu bảng nhỏ và feature số; không cần dựng thêm embedding hoặc chuỗi xử lý phức tạp.
Độ trễ: Model dạng cây dự đoán nhanh trên batch candidate, phù hợp với giới hạn thời gian của request recommendation.
Khả năng audit: Có thể kiểm tra thứ tự 9 feature, version artifact, validation metric và kết quả prediction.
Rollout: AI chỉ bổ sung score; Standard vẫn là baseline, nên có thể bật cho toàn bộ request và tắt ngay khi model không ổn định.
Nó cải thiện gì? Standard cộng các tín hiệu theo weight cố định. LightGBM học thêm các ngưỡng và tương tác phi tuyến, ví dụ cùng một mức profileAffinity nhưng candidate có quality, freshness hoặc semanticSimilarity khác nhau sẽ được phân biệt tốt hơn. Vì vậy AI chủ yếu cải thiện thứ tự trong candidate pool và khả năng tie-break; nó không tự tạo candidate mới, không thay filter/quota/diversity và không đảm bảo score là xác suất mua hàng.

Cách ra quyết định: So sánh mức phù hợp với input hiện tại, chi phí inference, độ phức tạp vận hành và khả năng rollback. XGBoost là đối thủ gần nhất và vẫn cần benchmark thực tế nếu dữ liệu hoặc tải thay đổi; các lựa chọn còn lại chỉ nên thay thế khi contract dữ liệu và mục tiêu sản phẩm thay đổi.

So sánh LightGBM với các thuật toán ranking khác
Thuật toánPhù hợp ở đâu?Hạn chế với hệ thống hiện tạiQuyết định
LightGBMDữ liệu bảng, feature số, quan hệ phi tuyến và inference theo batch.Chất lượng phụ thuộc label, dữ liệu lịch sử và việc giữ đúng thứ tự 9 feature.Chọn làm model hiện tại vì cân bằng tốt giữa chất lượng, tốc độ và khả năng rollback.
Logistic RegressionNhanh, dễ giải thích, phù hợp làm baseline.Chủ yếu học quan hệ tuyến tính; khó biểu diễn tương tác phức tạp giữa 9 feature.Giữ làm mốc so sánh, không chọn làm AI re-ranker.
Random ForestỔn định, ít nhạy với scale và dễ triển khai.Các cây độc lập có thể nặng hơn cho batch inference; không tận dụng boosting để sửa lỗi tuần tự.Chưa ưu tiên vì cần footprint lớn hơn cho cùng pipeline.
XGBoostRất mạnh trên dữ liệu bảng và là đối thủ gần nhất.Thêm một lựa chọn runtime cần benchmark, đóng gói và vận hành song song; chưa có bằng chứng đủ để đổi model hiện tại.Ứng viên benchmark khi tải, dữ liệu hoặc metric thay đổi.
CatBoostXử lý categorical feature tốt, giảm công sức encode.Input hiện tại đã là 9 số đã chuẩn hóa; chưa cần lợi thế categorical trực tiếp.Chưa dùng để tránh thêm độ phức tạp không cần thiết.
Neural NetworkHọc pattern rất phức tạp khi dữ liệu lớn và feature phong phú.Cần nhiều dữ liệu, tuning và giám sát hơn; khó audit và thường tăng chi phí/độ trễ với tabular nhỏ.Chỉ cân nhắc khi dữ liệu đủ lớn và có nhu cầu biểu diễn sâu hơn.
LambdaMART / LTRTối ưu trực tiếp thứ tự trong từng query/session group.Dataset hiện tại mới là từng dòng feature + label, chưa có group/query label contract.Có thể chuyển sang khi log đủ session và mục tiêu ranking rõ hơn.

Kết luận: LightGBM là quyết định phù hợp với giai đoạn hiện tại, không phải cam kết vĩnh viễn. Khi có dataset lớn hơn, label theo session rõ hơn hoặc metric thực tế cho thấy model khác tốt hơn, hệ thống có thể benchmark model mới rồi thay artifact theo version; contract 9 feature, validation và fallback vẫn là các điều kiện bắt buộc.

TRAINING INPUT

  1. 1. Dataset JSONL: mỗi dòng có features[9] label 0–1.
  2. 2. Validate dữ liệu: tối thiểu 20 dòng, có cả label thấp/cao, không có NaN/Infinity và mọi dòng đủ 9 giá trị.
  3. 3. Tách khoảng 80% train và 20% validation theo thứ tự dataset; dữ liệu nên được sắp theo thời gian để validation gần với dữ liệu tương lai.

LIGHTGBM CONFIGURATION

  • Algorithm: gradient-boosted decision trees, phù hợp với dữ liệu dạng bảng và các quan hệ feature không tuyến tính.
  • Objective: binary; metric validation là binary_logloss.
  • Guardrail: learning rate 0,05, tối đa 200 rounds, early stopping sau 20 rounds không cải thiện, seed cố định 42 để tái lập.

Từ dữ liệu đến model artifact

  1. 01 · Ghi nhận: lấy các feature tại thời điểm candidate được hiển thị cùng kết quả tương tác thực tế.
  2. 02 · Gán label: chuyển tín hiệu kết quả thành nhãn 0–1; label phải phản ánh mục tiêu đã chọn, ví dụ click hoặc purchase, không được trộn tùy ý.
  3. 03 · Chia dữ liệu: 80% đầu để học, 20% sau để kiểm tra. Chia theo thời gian giúp tránh dùng “tương lai” để dự đoán quá khứ.
  4. 04 · Học: LightGBM thêm từng cây để sửa sai số của ensemble hiện tại, đến khi đạt giới hạn hoặc validation không còn tốt hơn.
  5. 05 · Đóng gói: lưu artifact, model version và metadata; AI Service chỉ load khi số cột đúng 9, nếu không thì fallback.
Tham số huấn luyện LightGBM và tác dụng
Tham sốGiá trị hiện tạiTác dụng
objectivebinaryHọc điểm dự đoán cho label nhị phân/0–1 theo contract hiện tại.
metricbinary_loglossĐo mức lệch giữa dự đoán và label trên validation; thấp hơn là tốt hơn.
learning_rate0,05Mỗi cây sửa một phần nhỏ, học chậm hơn nhưng giảm nguy cơ nhảy quá mạnh.
num_leaves31Giới hạn độ phức tạp mỗi cây; cao hơn học được pattern sâu hơn nhưng dễ overfit.
feature/bagging_fraction0,9 / 0,9Mỗi vòng chỉ dùng khoảng 90% feature/data để giảm phụ thuộc vào một mẫu duy nhất.
rounds / early stopping200 / 20Tối đa 200 vòng; dừng nếu 20 vòng liên tiếp không cải thiện validation.
seed42Giúp lần train lặp lại được trong cùng dữ liệu và cấu hình.

Train xong: lưu LightGBM artifact và metadata như model version, feature count, train rows, validation rows, best iteration.

Khi boot: AI Service chỉ load artifact nếu model có đúng 9 feature; thiếu file hoặc sai count thì dùng fallback.

Đánh đổi: LightGBM nhanh và nhẹ khi inference, nhưng chất lượng phụ thuộc label, dữ liệu lịch sử và việc train lại khi hành vi thay đổi.

05 · MODEL NHẬN 9 GIÁ TRỊ

Feature vector được tạo ở Recommendation Service
Chín feature đầu vào của model AI, nguồn dữ liệu và mục tiêu
FeatureĐang đo gì?Lấy từ đâu / cách tínhMục tiêu và đánh đổi
profileAffinityMức hợp với sở thích dài hạn.Preference theo product/category/brand, có decay theo thời gian.Cá nhân hóa tốt; có thể lặp sở thích cũ.
sessionContextÝ định trong phiên hiện tại.Match category, brand và sản phẩm neo gần đây.Bắt kịp nhu cầu nhanh; có thể nhiễu nếu phiên ngắn.
semanticSimilarityĐộ gần về nội dung.Raw similarity từ embedding/Qdrant, clamp về 0–1.Tìm item tương tự; phụ thuộc catalog và vector mới.
coBehaviorMức thường đi cùng item khác.Quan hệ xem/giỏ/mua, chuẩn hóa bằng raw/(raw + scale).Tận dụng hành vi cộng đồng; yếu ở cold-start.
popularityNhu cầu chung của sản phẩm.Max giữa log1p(totalSold)/12 và rank trending/best-selling.Có điểm tựa khi thiếu profile; tránh để item hot lấn át cá nhân hóa.
freshnessSản phẩm mới đến mức nào.Bucket theo tuổi: 1, 7, 30 và 90 ngày.Tạo cơ hội cho item mới; item mới chưa chắc phù hợp.
qualityChất lượng và khả năng phục vụ.Rating 55%, review 25%, còn hàng 20%.Ưu tiên item đáng tin; shop mới ít review có thể bất lợi.
explorationCơ hội khám phá sản phẩm mới.Chỉ bật khi affinity ≤ 0,4 và source là EXPLORE/NEWEST.Tăng discovery; có thể giảm precision tức thời.
negativePenaltyMức không phù hợp cần trừ.Preference âm đã decay, cộng theo product/category/brand, tối đa 0,15.Giảm lặp item không thích; cần decay để không phạt nhầm tín hiệu cũ.
Ví dụ λ = 0,3

Giả sử S_standard = 0,653 S_AI = 0,800:

S_final = (1 − 0,3) × 0,653 + 0,3 × 0,800
= 0,4571 + 0,2400 = 0,6971

Standard đóng góp 70%, AI đóng góp 30%. 0,6971 là ranking score, không phải xác suất mua 69,71%.

0,653: điểm Standard đã tính từ 8 feature và penalty.

0,800: điểm model dự đoán từ 9 feature của cùng candidate.

0,6971: điểm cuối dùng để sort trước diversity/quota.

Ảnh hưởng lên thứ tự: nếu AI đánh giá candidate cao hơn Standard, điểm cuối có thể tăng; nếu AI thấp hơn, điểm có thể giảm. Mức thay đổi bị giới hạn bởi λ, nên AI không thể tự thay thế hoàn toàn baseline.

Fallback và response contract

Fallback không phải là xóa kết quả. Hệ thống bỏ phần điểm AI không đáng tin, giữ điểm Standard đã tính và tiếp tục trả danh sách cho người dùng.

Các điều kiện fallback của AI Enhanced Ranking
Điều kiệnĐiểm được dùngMetadata response
Policy AI tắt100% StandardHYBRID · modelVersion=null · rankingMode=HYBRID
Model chưa sẵn sàng hoặc không có artifact thật100% StandardHYBRID · ghi nhận Standard/Fallback
Timeout, lỗi HTTP hoặc response sai schema100% StandardHYBRID · modelVersion=null · rankingMode=HYBRID
Artifact thật trả prediction hợp lệBlend theo λML_HYBRID · modelVersion · rankingMode=ML_HYBRID
  • Không ghi nhận nhầm: model trả ranking-fallback-v1 không được xem là AI treatment.
  • Không làm hỏng response: lỗi AI chỉ làm mất phần đóng góp AI, không làm mất recommendation.
2.3Khi thiếu dữ liệu hoặc có lỗi, hệ thống làm gì?Nguồn lỗi thì bỏ riêng, AI lỗi thì dùng Standard; xem tiếp giới hạn danh sách và cách event cập nhật cho lượt gợi ý sau.
2.3.1Dự phòng theo từng bước trong requestMỗi bước có giới hạn và đường dự phòng riêng. Khi một phần thiếu dữ liệu, hệ thống giữ phần còn dùng được thay vì buộc toàn luồng thất bại.

01 · TÌM SẢN PHẨM

Một nguồn lỗi, nguồn khác vẫn chạy

Đầu vào
Hồ sơ, phiên hiện tại, sản phẩm đang xem và các nguồn catalog/vector/hành vi.
Xử lý → đầu ra
Các nguồn chạy độc lập. Nguồn rỗng hoặc lỗi bị bỏ qua; nguồn còn lại được gộp, bỏ trùng thành tối đa 300 sản phẩm chờ xếp hạng.
Đánh đổi: vẫn trả được gợi ý khi một nguồn lỗi, nhưng danh sách có thể ít lựa chọn hơn.

02 · CHẤM ĐIỂM

AI chậm thì quay về Standard

Đầu vào
Danh sách sản phẩm chờ xếp hạng và các điểm tiêu chí đã chuẩn hóa.
Xử lý → đầu ra
Standard luôn tạo điểm nền. Nếu bật AI, hệ thống chờ tối đa 150ms mặc định. Điểm AI không hợp lệ thì món đó giữ Standard; nếu lần gọi AI lỗi hoặc quá hạn, cả danh sách dùng Standard.
Đánh đổi: timeout ngắn giữ request nhanh nhưng có thể fallback thường xuyên hơn. Lượt fallback không bị tính nhầm là AI khi fallback.

03 · TRẢ KẾT QUẢ

Giới hạn list, có phương án hiển thị

Đầu vào
Danh sách sản phẩm đã chấm điểm, chưa áp giới hạn hiển thị.
Xử lý → đầu ra
Áp quy tắc đa dạng rồi trả danh sách theo trang. Nếu API recommendation lỗi, Web dùng catalog có sẵn ở trang chủ hoặc món bán chạy ở trang chi tiết.
Đánh đổi: giới hạn bảo vệ tốc độ và payload, nhưng món ở sâu trong danh sách có thể không được trả về.
2.3.2Ghi nhận tương tác hợp lệ, cập nhật hồ sơ ở nềnĐo tương tác có căn cứ mà không bắt người dùng chờ hệ thống ghi event.

01 · GHI NHẬN

Có thấy hoặc có nhấp thật

Impression chỉ ghi khi ít nhất 50% thẻ sản phẩm hiện trong màn hình. Click mang token đã ký để xác định đúng món, thứ hạng, nguồn và ranking mode.

02 · XÁC THỰC

Gắn event với đúng gợi ý

Token giúp đối chiếu item và attribution. Thiếu attribution hợp lệ thì event có thể còn là hành vi chung, nhưng không được tính vào phép đo recommendation.

03 · CẬP NHẬT

Dùng cho request kế tiếp

Client gom tối đa 20 event mỗi lần gửi; Kafka consumer cập nhật hồ sơ sau đó. Vì xử lý bất đồng bộ, event mới không làm đổi ngay danh sách đang xem.

Đánh đổi: ngưỡng 50% tránh tính thẻ chỉ vừa ló vào màn hình là đã được thấy, nhưng có thể bỏ sót lượt nhìn rất nhanh. Gửi theo lô và xử lý nền giảm request/chờ đợi, đổi lại feedback cập nhật trễ.