Forem: Hoàng Mạnh Khiêm

THUẬT TOÁN DỰ ĐOÁN HÀNH VI NGƯỜI DÙNG

Hoàng Mạnh Khiêm — Fri, 22 May 2026 06:04:28 +0000

THUẬT TOÁN DỰ ĐOÁN HÀNH VI NGƯỜI DÙNG

Các thuật toán giúp dự đoán hành vi, tìm similar users, và recommend pages tiếp theo

I) COSINE SIMILARITY (ĐO LƯỜNG ĐỘ TƯƠNG ĐỒNG)

🎯 Mục đích

Cosine Similarity TRẢ LỜI:

User A và User B có giống nhau không?
Tìm users có hành vi tương tự
Recommend dựa trên similar users

1. Nguyên lý

Đo độ tương đồng giữa hai vectors bằng góc giữa chúng (không phải khoảng cách):

CosineSimilarity(A, B) = cos(θ) = (A · B) / (||A|| ||B||)
                       = Σ(Ai × Bi) / (√Σ(Ai²) × √Σ(Bi²))

Trong đó:

A · B: Tích vô hướng (dot product)
||A||: Độ dài (magnitude) của vector A
θ: Góc giữa hai vectors

Kết quả:

cos(θ) = 1 → Hoàn toàn tương đồng (cùng hướng)
cos(θ) = 0 → Độc lập (vuông góc)
cos(θ) = -1 → Hoàn toàn đối lập (ngược hướng)

2. Quy trình áp dụng

Bước 1: Tạo vector hành vi cho mỗi user

User_i = [count_Profile,
          count_DealHot,
          count_Voucher,
          count_Mission,
          ...]

Ví dụ:

User A: [10, 50, 30, 5, 2, 15, 8]
User B: [8, 45, 28, 3, 1, 12, 6]

Bước 2: Tính Cosine Similarity

Tính similarity cho tất cả cặp users
Tạo similarity matrix (2666 × 2666)

Bước 3: Tìm similar users

Với mỗi user, sort theo similarity score
Lấy top N users có similarity cao nhất

3. Đặc điểm quan trọng

Magnitude-Invariant (không bị ảnh hưởng độ lớn):

User A: [1, 2, 3]
User B: [10, 20, 30]  (B = 10 × A)

Cosine(A, B) = 1.0  (perfect similarity)

→ Tốt cho user behavior: User vào 5 lần vs 50 lần nhưng cùng tỷ lệ → similar

So với Euclidean Distance:

Euclidean Distance(A, B) = 33.7 (rất lớn!)
Cosine Similarity(A, B) = 1.0 (perfect!)

→ Cosine tốt hơn khi quan tâm xu hướng chứ không phải số lượng tuyệt đối

4. Ứng dụng

Tìm Similar Users

User A vào: DealHot(50), Voucher(30), Profile(10)
Tìm users có pattern tương tự
Top 5 similar users: B, C, D, E, F

Collaborative Filtering Recommendation

Logic:

Tìm 20 users giống User A nhất
Đếm pages mà 20 users đó hay vào
Loại bỏ pages User A đã vào
Recommend top 5 pages còn lại

Ví dụ:

User A đã vào: {DealHot, Voucher}
Similar users thích: {DealHot, Voucher, FlashsaleEmbedded, Mission}
→ Recommend: {FlashsaleEmbedded, Mission}

User-User Clustering

Dùng similarity matrix làm input
Hierarchical Clustering dựa trên (1 - similarity)

5. Ưu điểm

✅ Dễ triển khai - Công thức đơn giản
✅ Không bị ảnh hưởng magnitude - Focus vào xu hướng
✅ Phù hợp sparse data - Nhiều 0 không ảnh hưởng nhiều
✅ Interpretable - Similarity [0, 1] dễ hiểu

6. Nhược điểm

❌ Không hiểu semantic - "Mission" và "CreateMission" được coi là độc lập
❌ Cold start problem - Users mới (ít data) → similarity không chính xác
❌ Memory intensive - Matrix 2666 × 2666 = 7.1M cells
❌ Popularity bias - Similar users đều thích pages phổ biến

II) TF-IDF (TERM FREQUENCY - INVERSE DOCUMENT FREQUENCY)

🎯 Mục đích

TF-IDF TRẢ LỜI:

Page nào quan trọng để phân biệt user?
Page phổ biến vs page đặc trưng?

Không phải thuật toán, là kỹ thuật Feature Engineering

1. Công thức

TF-IDF(t, d) = TF(t, d) × IDF(t)

TF (Term Frequency):

TF(t, d) = (số lần term t xuất hiện trong document d) / (tổng số terms trong document d)

IDF (Inverse Document Frequency):

IDF(t) = log(tổng số documents / số documents chứa term t)

2. Áp dụng cho User Behavior

Mapping:
| NLP | User Behavior |
|-----|---------------|
| Term (từ) | Page (DealHot, Mission,...) |
| Document | User (mỗi user = 1 document) |
| Corpus | Tất cả users |

Ví dụ tính toán:

User A: [DealHot: 50, Profile: 10, Voucher: 30, Mission: 5]
Total visits: 95

TF(DealHot, UserA) = 50/95 = 0.53

IDF(DealHot) = log(2666 / 2274) = 0.16  (85% users vào → IDF thấp)
IDF(RequestPassword) = log(2666 / 1) = 7.89  (chỉ 1 user → IDF cao)

TF-IDF(DealHot, UserA) = 0.53 × 0.16 = 0.08  (THẤP - page phổ biến)
TF-IDF(RequestPassword, UserA) = 0.25 × 7.89 = 1.97  (CAO - page rare)

3. Ý nghĩa

TF-IDF cao = Page quan trọng để phân biệt user

Các trường hợp:

TF cao, IDF cao → Quan trọng
- User vào page này nhiều VÀ page này rare
- Đặc trưng duy nhất của user
TF cao, IDF thấp → Ít quan trọng
- User vào page này nhiều NHƯNG ai cũng vào
- Không phân biệt user này với users khác
TF thấp, IDF cao → Trung bình
- User vào page rare 1 lần
TF thấp, IDF thấp → Không quan trọng
- Noise

4. Ứng dụng

Feature Weighting cho Clustering

Raw counts: DealHot(50), Mission(5) → DealHot dominates
TF-IDF: DealHot(0.08), Mission(0.35) → Mission quan trọng hơn!
K-Means trên TF-IDF features → clusters tốt hơn

Tìm Đặc trưng của User

User 664402 - Top 3 pages by TF-IDF:
1. RequestPassword: 1.97  (rare page, đặc trưng)
2. UpdateProfile: 0.89
3. Mission: 0.35

→ User này có behavior độc đáo (vào RequestPassword)

Kết hợp với Cosine Similarity

TF-IDF vectors thay vì raw counts
Cosine similarity trên TF-IDF → better recommendations

5. Ưu điểm

✅ Giảm nhiễu - Loại bỏ ảnh hưởng của pages phổ biến
✅ Tìm unique behaviors - Highlight pages đặc trưng
✅ Better clustering - Features tốt hơn raw counts
✅ Scalable - Tính toán nhanh

6. Nhược điểm

❌ Không phải thuật toán - Chỉ là feature engineering
❌ Bỏ qua thứ tự thời gian - Bag-of-words approach
❌ Giả định independence - Pages không liên quan nhau
❌ Sparse high-dim data - 40 pages × 2666 users nhiều 0

III) SEQUENTIAL PATTERN MINING (KHÁM PHÁ CHUỖI HÀNH VI)

🎯 Mục đích

Sequential Mining TRẢ LỜI:

User đi theo đường nào? (user journey)
Sau page A, user thường vào page B?
Dự đoán next page?
Funnel nào có drop-off cao?

Khác biệt chính:

Association Rules: {A, B, C} - không quan tâm thứ tự
Sequential Mining: <A → B → C> - giữ nguyên thứ tự thời gian

1. Nguyên lý

Tìm chuỗi patterns xuất hiện thường xuyên theo thứ tự thời gian:

<Profile → DealHot → Voucher> 
≠ 
<DealHot → Profile → Voucher>

Subsequence:

S = <A, B, C, D, E>
S' = <B, D> là subsequence của S (bỏ qua A, C, E nhưng giữ thứ tự)

Support của Sequential Pattern:

Support(<Profile → Mission → CreateMission>) 
= số users có subsequence này / tổng users
= 450 / 2666 = 0.169 (16.9%)

2. Các thuật toán

AprioriAll

Tìm frequent itemsets
Mở rộng dần thành sequences
Nhược điểm: Chậm với data lớn

GSP (Generalized Sequential Pattern)

Tương tự AprioriAll
Tối ưu hơn bằng pruning
Ưu điểm: Nhanh hơn AprioriAll

PrefixSpan ⭐ (Đề xuất)

Divide and Conquer + Prefix Projection
Ưu điểm: Rất nhanh, không generate quá nhiều candidates
Phù hợp nhất cho piggi_metrics.csv

Cách hoạt động PrefixSpan:

1. Scan database, tìm frequent 1-sequences: <Profile>, <DealHot>, <Mission>
2. Với mỗi prefix (vd: <Profile>):
   - Tạo projected database (chỉ chứa phần sau <Profile>)
   - Đệ quy tìm patterns: <Profile, DealHot>, <Profile, Mission>,...
3. Repeat cho đến khi không còn frequent patterns

3. Kết quả ví dụ

Frequent Sequential Patterns:

<Profile → DealHot>                     : 35% users (930 users)
<Mission → CreateMission>               : 25% users (666 users)
<DealHot → Voucher>                     : 18% users (480 users)
<Loyalty → RankMember → LoyaltyHistory> : 12% users (320 users)

Long Patterns (user journeys):

<Profile → Mission → CreateMission → Mission>         : 16.9% users
<DealHot → Voucher → DealHot → FlashsaleEmbedded>    : 14.3% users
<Loyalty → RankMember → LoyaltyHistory → Loyalty>    : 11.2% users

4. Phân loại User theo Pattern

Pattern	User Type	Behavior
`<DealHot → FlashsaleEmbedded>`	Quick Buyer	Mua nhanh, không so sánh
`<Profile → DealHot → Voucher → DealHot → Voucher>`	Browser	So sánh nhiều trước khi quyết định
`<Mission → CreateMission → MissionSwap → Mission>`	Mission Player	Thích features mission, loop
`<Loyalty → RankMember → LoyaltyHistory → LoyaltyProduct>`	Loyalty Enthusiast	Quan tâm điểm thưởng, ranking

5. Ứng dụng

a) Dự đoán Next Page

Input: User vừa vào <Profile → DealHot>

Phân tích từ patterns:

Pattern <Profile → DealHot → Voucher>: 35% support
Pattern <Profile → DealHot → FlashsaleEmbedded>: 25% support
Pattern <Profile → DealHot → DealHot>: 20% support (quay lại)

Dự đoán tiếp theo:

40% khả năng → Voucher
25% khả năng → FlashsaleEmbedded
20% khả năng → DealHot (quay lại)

Action: Recommend/highlight 3 pages này

b) Tối ưu UX (Drop-off Detection)

Phát hiện:

Nhiều users dừng tại: <Profile → DealHot> (không đi tiếp)

Phân tích:

UX chưa tốt (khó tìm Voucher?)
CTA (Call-to-Action) chưa rõ ràng
Deal chưa hấp dẫn

Action: Redesign flow từ DealHot → Voucher

Thêm prominent button "Xem Voucher"
A/B testing different layouts

c) Funnel Analysis

Conversion Funnel:

Profile → DealHot → Voucher → FlashsaleEmbedded → Order

100%  →   70%    →   50%    →        30%         →  15%

Insights:

Drop-off lớn nhất: Voucher → FlashsaleEmbedded (20% drop)
Drop-off thứ 2: FlashsaleEmbedded → Order (15% drop)

Action:

Cải thiện transition Voucher → FlashsaleEmbedded
Simplify order process

d) Personalized Recommendation

Pattern của User A:

<Mission → MissionSwap → Mission> (lặp lại nhiều lần)

Recommendation strategy:

✅ Ưu tiên hiển thị Mission mới
✅ Push notification về Mission events
❌ Giảm hiển thị Deal/Voucher (user không quan tâm)

6. Ưu điểm

✅ Capture thứ tự hành vi - Hiểu user journey đầy đủ
✅ Tìm được pattern dài - Multi-step behaviors
✅ Dự đoán next action tốt - Based on historical patterns
✅ Phát hiện funnel bottlenecks - Drop-off analysis
✅ Actionable insights - UX improvements

7. Nhược điểm

❌ Tính toán nặng - Với dữ liệu lớn, chậm
❌ Cần nhiều data - Patterns có ý nghĩa cần support cao
❌ Không capture duration - Thời gian giữa các bước
❌ Dễ sinh quá nhiều patterns - Cần filter, min_support cao
❌ Không biết WHY - Chỉ biết WHAT (patterns) không biết WHY

8. Session Definition (quan trọng!)

Vấn đề:

User vào Profile lúc 9h sáng
User vào DealHot lúc 10h tối
Có phải 1 sequence <Profile → DealHot> không?

Giải pháp: Định nghĩa Session

Session gap = 30 phút

Events cách nhau > 30 phút → sessions khác nhau

Ví dụ:

User 664402:
- 09:00 Profile
- 09:05 Mission
- 09:10 CreateMission
  [gap > 30 min]
- 22:00 DealHot

→ 2 sequences:
  Session 1: <Profile → Mission → CreateMission>
  Session 2: <DealHot>

IV) ASSOCIATION RULES (APRIORI / FP-GROWTH)

🎯 Mục đích

Association Rules TRẢ LỜI:

Page A và B có xuất hiện cùng nhau không?
Nếu user vào A, khả năng vào B là bao nhiêu?
Pages nào nên đặt gần nhau trong UI?

Khác Sequential Mining:

Không quan tâm thứ tự - {A, B} = {B, A}
Chỉ quan tâm co-occurrence

1. Metrics

Support (Độ hỗ trợ)

Support(A → B) = (số users vào cả A và B) / (tổng số users)

Ý nghĩa: Tỷ lệ % users có cả A và B

Confidence (Độ tin cậy)

Confidence(A → B) = (users vào cả A và B) / (users vào A) = P(B|A)

Ý nghĩa: Trong số users vào A, bao nhiêu % vào B

Lift (Độ nâng)

Lift(A → B) = Confidence(A → B) / Support(B) = P(B|A) / P(B)

Ý nghĩa:

Lift > 1: Positive correlation (A và B xuất hiện cùng nhiều hơn ngẫu nhiên)
Lift = 1: A và B độc lập
Lift < 1: Negative correlation (A và B xuất hiện cùng ít hơn ngẫu nhiên)

2. Ví dụ cụ thể

Rule 1:

{DealHot} → {Voucher}

Support = 0.30 (30% users vào cả 2)
Confidence = 0.70 (70% users vào DealHot cũng vào Voucher)
Lift = 2.3

Giải thích:

30% tất cả users vào cả DealHot và Voucher
Trong số users vào DealHot, 70% vào Voucher
Lift = 2.3 > 1 → Correlation mạnh

Action:

Đặt Voucher button gần DealHot
Recommend Voucher khi user xem DealHot

Rule 2:

{Mission} → {CreateMission}

Support = 0.25 (25% users)
Confidence = 0.51 (51%)
Lift = 2.8

Action:

Đặt CreateMission button prominent trong Mission page
51% users vào Mission quan tâm CreateMission

3. Thuật toán

Apriori

Nguyên lý Apriori:

Nếu itemset I không frequent (Support < min_support),
thì mọi superset của I cũng không frequent.

Ví dụ:

{Mission, CreateMission} Support = 0.05 < 0.1 (min_support)
→ {Mission, CreateMission, Profile} cũng < 0.1
→ Không cần kiểm tra (pruning)

Nhược điểm: Sinh nhiều candidates, chậm

FP-Growth (Frequent Pattern Growth)

Ưu điểm:

Dùng FP-Tree (compressed representation)
Không cần generate candidates
Nhanh hơn Apriori nhiều

Phù hợp: Dữ liệu lớn, nhiều items

4. Ứng dụng

UI/UX Design

Rule: {DealHot} → {Voucher} (confidence 70%, lift 2.3)

Action:
- Đặt Voucher tab ngay cạnh DealHot tab
- "Xem thêm Voucher" button trong DealHot page

Cross-Selling

Rule: {Mission} → {CreateMission, MissionSwap}

Action:
- Bundle recommendation
- "Users also interested in..." section

Page Layout Optimization

Rules với Lift cao:
- {DealHot, Voucher} → Đặt gần nhau
- {Mission, CreateMission} → Đặt gần nhau
- {Loyalty, RankMember} → Đặt gần nhau

5. Ưu điểm

✅ Tự động tìm patterns - Không cần define trước
✅ Phát hiện correlations ẩn - Unexpected patterns
✅ Actionable insights - Trực tiếp apply vào UI/UX
✅ Dễ giải thích - Rules IF-THEN rõ ràng

6. Nhược điểm

❌ Sinh quá nhiều rules - Cần filter bằng Lift, min_confidence
❌ Không hiểu thứ tự - {A, B} không biết A trước hay B trước
❌ Chỉ co-occurrence, không causation - Correlation ≠ Causation
❌ Sparse data - Users vào ít pages → ít frequent itemsets

📊 SO SÁNH TỔNG QUAN

Thuật toán	Trả lời câu hỏi	Giữ thứ tự?	Dự đoán next?	Complexity	Output
Cosine Similarity	Users giống nhau?	❌	⚠️ Gián tiếp	O(n² × d)	Similarity matrix
TF-IDF	Page nào quan trọng?	❌	❌	O(n × d)	Feature vectors
Sequential Mining	User journey? Next page?	✅	✅✅	Cao	Patterns + probabilities
Association Rules	A và B cùng xuất hiện?	❌	⚠️	Trung bình	IF-THEN rules

🚀 ỨNG DỤNG THỰC TẾ

Recommendation System (Collaborative Filtering)

Workflow:

TF-IDF → Loại bỏ pages phổ biến, tập trung vào preferences độc đáo
Cosine Similarity → Tìm top 20 users tương tự
Recommend pages mà similar users thích nhưng user hiện tại chưa vào

Ví dụ:

User A: Profile(10), Mission(30), CreateMission(15)
Similar users: B, C, D cũng thích Mission
Users B, C, D còn thích: MissionSwap
→ Recommend MissionSwap cho User A

Next Page Prediction

Workflow:

Sequential Mining → Phát hiện patterns <A → B → C>
Association Rules → Tính correlations giữa pages
Kết hợp cả 2 → Dự đoán với confidence scores

Ví dụ:

User vừa vào: Profile → DealHot
Sequential: <Profile → DealHot → Voucher> xuất hiện 40% cases
Association: {DealHot} → {Voucher} có confidence 70%
→ Dự đoán: User sẽ vào Voucher tiếp theo (high confidence)

UX/UI Optimization

Workflow:

Sequential Mining → Hiểu user journeys đầy đủ
Funnel Analysis → Tìm điểm drop-off cao
Association Rules → Pages nào nên đặt gần nhau

Ví dụ:

Funnel: Profile → DealHot → Voucher → Order
Drop-off lớn nhất: DealHot → Voucher (30% users rời đi)
Association Rule: {DealHot} → {Voucher} có lift cao
→ Action: Làm nổi bật "Xem Voucher" button trong DealHot page

Personalization

Workflow:

Cosine Similarity → Phân loại user vào nhóm tương đồng
TF-IDF → Tìm unique preferences
Sequential → Dự đoán hành động tiếp theo
Personalize: Homepage, notifications, emails theo từng nhóm

Ví dụ:

User A: TF-IDF cho thấy thích Mission (score cao)
Pattern: <Mission → CreateMission → Mission> (lặp lại)
→ Homepage: Hiển thị Mission content ở top
→ Push notification: Mission events, competitions
→ Email: Mission-related updates

THUẬT TOÁN PHÂN LOẠI NGƯỜI DÙNG

Hoàng Mạnh Khiêm — Fri, 22 May 2026 05:29:55 +0000

🎯 BÀI TOÁN

Có: 2,666 users, mỗi user vào các pages khác nhau (DealHot, Mission, Voucher,...)

Muốn: Chia users thành các nhóm có hành vi giống nhau

Ví dụ:

Nhóm 1: Thích săn deal (hay vào DealHot, Voucher)
Nhóm 2: Thích chơi mission (hay vào Mission, CreateMission)
Nhóm 3: Thích chat (hay vào ChatRoom, ReferralFriend)

I) K-MEANS - PHÂN NHÓM ĐƠN GIẢN NHẤT

💡 Ý tưởng chính

Giống như phân học sinh thành các nhóm học:

Thầy giáo chọn 5 bạn làm nhóm trưởng (ngẫu nhiên)
Các bạn còn lại tìm nhóm trưởng "giống mình nhất" để vào nhóm đó
Nhóm trưởng mới = trung bình của các bạn trong nhóm
Lặp lại bước 2-3 đến khi không ai đổi nhóm nữa

📖 Ví dụ thực tế

Từ data piggi_metrics.csv, lấy 7 users:

User 664402: Profile(3), UpdateProfile(1)                    → 4 lượt
User 581242: EmbeddedBrowser(1)                              → 1 lượt
User 665300: GetMissionPoint(1), Mission(2), Profile(1)      → 4 lượt
User 273471: Voucher(1), DealHot(1)                          → 2 lượt
User 184423: Profile(1), ReferralFriend(1)                   → 2 lượt
User 665302: Mission(1), CreateMission(1)                    → 2 lượt
User 121:    DealHot(1)                                      → 1 lượt

Chuyển sang vector (đếm lượt vào từng page):

              Mission  DealHot  Profile  Voucher  Social
User 665300:    3        0        1        0        0
User 665302:    2        0        0        0        0
User 664402:    0        0        4        0        0
User 273471:    0        1        0        1        0
User 121:       0        1        0        0        0
User 184423:    0        0        1        0        1
User 581242:    0        0        0        0        0

Chạy K-Means với k=3:

Bước 1: Chọn 3 nhóm trưởng ngẫu nhiên
  - Nhóm trưởng 1: User 665300 (Mission nhiều)
  - Nhóm trưởng 2: User 273471 (Deal)
  - Nhóm trưởng 3: User 664402 (Profile nhiều)

Bước 2: Các user tìm nhóm trưởng giống mình
  - User 665302 giống User 665300 → Nhóm 1 (Mission)
  - User 121 giống User 273471 → Nhóm 2 (Deal)
  - User 184423 giống User 664402 → Nhóm 3 (Profile/Social)
  - User 581242 (ít tương tác) → Nhóm 3

Bước 3: Tính nhóm trưởng mới
  - Nhóm 1: Mission trung bình cao
  - Nhóm 2: DealHot, Voucher trung bình cao
  - Nhóm 3: Profile, social features

Bước 4: Lặp lại cho đến khi hội tụ...

Kết quả cuối:

Nhóm 1 (Mission Players): User 665300, 665302
Nhóm 2 (Deal Hunters): User 273471, 121
Nhóm 3 (Profile/Social Users): User 664402, 184423, 581242

✅ Ưu điểm

Nhanh - Chạy với 2,666 users trong vài giây
Đơn giản - Dễ hiểu, dễ code
Kết quả rõ ràng - Mỗi user chỉ thuộc 1 nhóm duy nhất

❌ Nhược điểm

Phải biết trước số nhóm (k) - Muốn chia thành mấy nhóm?
Nhạy với "outliers" - User lạ sẽ kéo nhóm lệch
Kết quả khác nhau mỗi lần chạy - Do chọn nhóm trưởng ngẫu nhiên

🎯 Khi nào dùng?

✅ Khi bạn biết muốn chia thành bao nhiêu nhóm (vd: 5 nhóm)
✅ Khi cần kết quả nhanh
✅ Khi users khá đồng đều (không có user quá lạ)

II) DBSCAN - TÌM NHÓM BẠN ĐÔNG ĐÚC

💡 Ý tưởng chính

Giống như tìm nhóm bạn trong lớp học:

Nếu bạn có ít nhất 5 người bạn thân (trong bán kính gần) → Bạn là "người nổi"
Bạn của "người nổi" → Cùng nhóm
Nếu bạn không có đủ 5 bạn thân và cũng không phải bạn của "người nổi" → Loner (outlier)

Không cần biết trước số nhóm!

📖 Ví dụ thực tế với data piggi_metrics.csv

Từ 21 dòng data đầu tiên, ta có:

User 665300: Mission(2), GetMissionPoint(1), Profile(1)      → Mission-focused
User 665302: Mission(1), CreateMission(1)                    → Mission-focused
User 200165: Mission(1)                                      → Mission-focused
  ↓ 3 users này "gần nhau" vì đều thích Mission

User 273471: Voucher(1), DealHot(1)                          → Deal-focused
User 121:    DealHot(1)                                      → Deal-focused
User 82777:  FlashsaleEmbedded(1)                            → Deal-focused
  ↓ 3 users này "gần nhau" vì đều thích săn deal

User 664402: Profile(3), UpdateProfile(1)                    → OUTLIER
  ↓ Chỉ vào Profile, không giống ai → Lẻ loi

User 581242: EmbeddedBrowser(1)                              → OUTLIER
User 294132: ChatRoom(1)                                     → OUTLIER

DBSCAN tự động phát hiện:

Set parameters: eps=0.5, min_samples=3

Bước 1: Tìm vùng đông đúc
  - Vùng Mission: 3 users gần nhau → Nhóm 1 ✅
  - Vùng Deal: 3 users gần nhau → Nhóm 2 ✅

Bước 2: Đánh dấu outliers
  - User 664402: Không có đủ 3 neighbors → Outlier ⚠️
  - User 581242: Không thuộc nhóm nào → Outlier ⚠️
  - User 294132: ChatRoom độc lập → Outlier ⚠️

Kết quả:

Nhóm 1 (Mission Players): User 665300, 665302, 200165
Nhóm 2 (Deal Hunters): User 273471, 121, 82777
Outliers: User 664402, 581242, 294132 (hành vi lạ, không thuộc nhóm chính)

✅ Ưu điểm

Không cần biết số nhóm trước - Tự động tìm
Tìm được outliers - User có hành vi lạ (VIP, bot, test accounts)
Nhóm hình dạng bất kỳ - Không bắt buộc hình tròn

❌ Nhược điểm

Khó chọn tham số - "Bao xa là gần?" "Bao nhiêu bạn là đủ đông?"
Chậm hơn K-Means - Với 2,666 users vẫn OK
Không tốt nếu mật độ khác nhau - Vùng đông ít khác biệt quá

🎯 Khi nào dùng?

✅ Khi KHÔNG biết có bao nhiêu nhóm
✅ Khi muốn tìm users lạ (VIP, bot)
✅ Khi các nhóm có kích thước/mật độ tương đương

III) GMM - MỖI NGƯỜI CÓ NHIỀU MẶT

💡 Ý tưởng chính

Khác với K-Means (mỗi user chỉ thuộc 1 nhóm), GMM cho phép:

User A có thể:

60% là "Deal Lover"
35% là "Mission Player"
5% là "Social User"

Giống như một người có nhiều sở thích:

Bạn An: 70% thích bóng đá, 30% thích game
Bạn Bình: 50% thích bóng đá, 50% thích đọc sách

📖 Ví dụ thực tế với data piggi_metrics.csv

User 664402 từ data thực:

2026-05-20 15:56:44  →  Profile
2026-05-20 15:56:45  →  UpdateProfile
2026-05-20 15:56:46  →  Profile

Hành vi thực tế: Profile(3), UpdateProfile(1)

Giả sử user này còn có thêm data:

- Profile: 15 lần
- Mission: 8 lần
- DealHot: 3 lần

K-Means nói: User này thuộc nhóm "Profile User" (100%)

GMM nói: User này có nhiều mặt:

60% Profile/Settings User (quan tâm cài đặt)
35% Mission Player (thỉnh thoảng chơi mission)
5% Deal Hunter (ít quan tâm deals)

Insight:
→ User này chủ yếu vào chỉnh sửa profile, NHƯNG cũng thích missions
→ Recommend: Personalization features + Mission notifications
→ Không nên spam Deal notifications vì chỉ 5% quan tâm

✅ Ưu điểm

Linh hoạt - User có thể thuộc nhiều nhóm
Realistic - Người thật thường có nhiều sở thích
Cung cấp xác suất - Biết độ tin cậy

❌ Nhược điểm

Phức tạp hơn - Khó hiểu hơn K-Means
Chậm hơn - Tính toán nhiều hơn
Vẫn cần biết số nhóm - Như K-Means

🎯 Khi nào dùng?

✅ Khi users có nhiều sở thích (không rõ ràng 1 nhóm)
✅ Khi cần recommendation đa dạng
✅ Khi muốn xác suất thay vì nhóm cứng

IV) PHÂN LOẠI THEO RFD - ĐÁNH GIÁ MỨC ĐỘ TƯƠNG TÁC

💡 Ý tưởng chính

Không phân loại theo "thích gì" mà phân loại theo "tương tác như thế nào":

3 tiêu chí:

R (Recency): Lần cuối vào app cách đây bao lâu?
F (Frequency): Vào app bao nhiêu lần?
D (Diversity): Vào bao nhiêu pages khác nhau?

📖 Ví dụ thực tế với data piggi_metrics.csv

Phân tích 3 users từ data thực:

User 665300:

Từ data: GetMissionPoint(1), Mission(2), Profile(1) trong ngày 2026-05-20

- Recency: 2026-05-20 (hôm nay = data mới nhất) → R = 5 ✅
- Frequency: 4 lượt trong data này → F = 3 (trung bình) ⚠️
- Diversity: 3 pages khác nhau (Mission, GetMissionPoint, Profile) → D = 3 ⚠️
→ Xếp hạng: 5-3-3 = "Potential Loyalist"
   (Active gần đây, nhưng chưa dùng nhiều features)

User 664402:

Từ data: Profile(3), UpdateProfile(1) trong ngày 2026-05-20

- Recency: 2026-05-20 (hôm nay) → R = 5 ✅
- Frequency: 4 lượt → F = 3 ⚠️
- Diversity: 2 pages (Profile, UpdateProfile) → D = 2 ⚠️
→ Xếp hạng: 5-3-2 = "Loyal but Focused"
   (Active, nhưng chỉ quan tâm Profile features)

User 581242:

Từ data: EmbeddedBrowser(1) trong ngày 2026-05-20

- Recency: 2026-05-20 (hôm nay) → R = 5 ✅
- Frequency: 1 lượt duy nhất → F = 1 ❌
- Diversity: 1 page → D = 1 ❌
→ Xếp hạng: 5-1-1 = "New User"
   (Mới vào lần đầu hoặc người dùng thụ động)

Insight:

Tất cả đều active (R=5) vì data chỉ có 1 ngày (2026-05-20)
User 665300 explore nhiều nhất → Tiềm năng cao
User 664402 chỉ focus vào Profile → Cần khuyến khích dùng features khác
User 581242 mới vào → Cần onboarding

🎭 Các nhóm users

Nhóm	Đặc điểm	Action
Champions (5-5-5)	Active, hay vào, explore nhiều	VIP treatment, early access
Loyal Customers (5-5-2)	Active, hay vào, nhưng chỉ thích vài tính năng	Giữ chân, đừng thay đổi features họ thích
New Users (5-1-1)	Mới vào lần đầu	Onboarding, hướng dẫn
At Risk (2-4-3)	Lâu không vào, nhưng từng active	Gửi email "We miss you", tặng voucher
Lost (1-1-1)	Đã bỏ app	Win-back campaign, hoặc để yên

✅ Ưu điểm

Đơn giản - Chỉ 3 con số, dễ hiểu
Business-friendly - Marketing team hiểu ngay
Nhanh - Tính toán 2,666 users trong < 1 giây
Actionable - Biết ngay làm gì với từng nhóm

❌ Nhược điểm

Không nói user thích page nào - Chỉ nói mức độ tương tác
Quá đơn giản - Bỏ qua nhiều thông tin chi tiết
Cần data dài hạn - Recency cần ít nhất vài tuần data

🎯 Khi nào dùng?

✅ Khi cần phân loại nhanh để marketing
✅ Khi muốn kết quả dễ giải thích
✅ KẾT HỢP với thuật toán khác để biết user thích gì

V) RULE-BASED - LẬP LUẬT THỦ CÔNG

💡 Ý tưởng chính

Bạn tự quy định luật, không dùng AI:

NẾU user vào DealHot > 30 lần
  → Gắn nhãn "Deal Lover"

NẾU user vào Mission > 20 lần
  → Gắn nhãn "Mission Player"

NẾU user không vào app > 30 ngày
  → Gắn nhãn "Churn Risk"

Giống như thầy cô chấm điểm theo thang điểm cố định.

📖 Ví dụ thực tế với data piggi_metrics.csv

Áp dụng rules cho users thực:

Rule 1: Mission Player

IF count_Mission >= 2 THEN "mission_player"

User 665300: Mission(2) + GetMissionPoint(1) → Tổng 3 → ✅ "mission_player"
User 665302: Mission(1) + CreateMission(1) → Tổng 2 → ✅ "mission_player"
User 200165: Mission(1) → ❌ Không đủ

Rule 2: Deal Hunter

IF (count_DealHot >= 1 OR count_Voucher >= 1) THEN "deal_hunter"

User 273471: DealHot(1) + Voucher(1) → ✅ "deal_hunter"
User 121: DealHot(1) → ✅ "deal_hunter"
User 82777: FlashsaleEmbedded(1) → ✅ "deal_hunter"

Rule 3: Profile Focused

IF count_Profile >= 2 AND count_other_pages < 2 THEN "profile_focused"

User 664402: Profile(3) + UpdateProfile(1) → ✅ "profile_focused"
User 184423: Profile(1) → ❌ Không đủ

Rule 4: Chuỗi hành vi (Sequence)

Từ data thực:
2026-05-20 15:56:44  User 664402  Profile
2026-05-20 15:56:45  User 664402  UpdateProfile
2026-05-20 15:56:46  User 664402  Profile

Rule: IF path = ["Profile" → "UpdateProfile" → "Profile"]
      THEN "edit_then_verify" (Sửa profile rồi check lại)
→ User 664402: ✅ Match pattern này

Kết quả phân loại:

Mission Players: 665300, 665302
Deal Hunters: 273471, 121, 82777
Profile Focused: 664402
Uncategorized: 581242, 184423, 294132, 568861, 145593, 200165

🎯 Case Study

Công ty muốn tìm users "sắp mua hàng":

Rule: "Ready to Buy"
  IF (vào DealHot > 5 lần trong 3 ngày qua
      AND vào Voucher > 2 lần
      AND chưa Order trong 7 ngày qua)
  THEN gửi push notification "Flash Sale 50% - Chỉ 2 giờ!"

→ Conversion rate tăng vì đúng timing!

✅ Ưu điểm

Dễ hiểu 100% - Ai cũng đọc được
Kiểm soát hoàn toàn - Bạn quyết định mọi thứ
Không cần training - Viết rule là xong
Giải thích được cho sếp - "Em làm theo logic này..."

❌ Nhược điểm

Không tự học - Không tìm ra patterns mới
Cần domain knowledge - Phải hiểu business sâu
Khó maintain - 100 rules sẽ rối loạn
Rules có thể conflict - Rule 1 nói A, Rule 2 nói B

🎯 Khi nào dùng?

✅ Khi business logic rõ ràng
✅ Khi cần giải thích cho non-tech team
✅ Khi bắt đầu (chưa có data để train ML)
✅ KẾT HỢP với ML - ML tìm patterns, Rules finalize

VI) HIERARCHICAL - XÂY DỰNG CÂY GIA PHẢ

💡 Ý tưởng chính

Giống như vẽ cây gia phả:

                    Tất cả Users
                    /          \
            Active Users    Inactive Users
            /        \
    Deal Lovers   Mission Players
       /    \
   Heavy  Light

Bắt đầu từ mỗi user = 1 nhóm riêng, merge dần các user giống nhau.

📖 Ví dụ thực tế với data piggi_metrics.csv

Lấy 6 users từ data thực:

User 665300: Mission(3), Profile(1)               → Mission-heavy
User 665302: Mission(1), CreateMission(1)         → Mission-heavy
User 273471: DealHot(1), Voucher(1)               → Deal-heavy
User 121:    DealHot(1)                           → Deal-heavy
User 664402: Profile(3), UpdateProfile(1)         → Profile-heavy
User 184423: Profile(1), ReferralFriend(1)        → Mixed

Quá trình merge (từ dưới lên):

Ban đầu: [665300] [665302] [273471] [121] [664402] [184423]

Bước 1: 665300 và 665302 giống nhất (cùng Mission) → Merge
        [665300,665302] [273471] [121] [664402] [184423]

Bước 2: 273471 và 121 giống nhất (cùng Deal) → Merge
        [665300,665302] [273471,121] [664402] [184423]

Bước 3: 664402 và 184423 gần nhau (cùng Profile) → Merge
        [665300,665302] [273471,121] [664402,184423]

Bước 4: Mission group và Deal group merge
        [665300,665302,273471,121] [664402,184423]

Bước 5: Merge tất cả
        [665300,665302,273471,121,664402,184423]

Dendrogram (cây phân cấp):

User:  665300  665302  273471  121  664402  184423
         |       |       |      |      |       |
         └───────┘       └──────┘      └───────┘
             │               │              │
             └───────────────┘              │
                     │                      │
                     └──────────────────────┘

Cắt cây ở độ cao khác nhau:

Cắt cao (2 nhóm):
- [665300, 665302, 273471, 121] = Active Users
- [664402, 184423] = Profile Users
Cắt trung bình (3 nhóm):
- [665300, 665302] = Mission Players
- [273471, 121] = Deal Hunters
- [664402, 184423] = Profile Users
Cắt thấp (6 nhóm): Mỗi user riêng lẻ

📊 Dendrogram (Cây phân cấp)

User:  A    B    E    C    D
       |    |    |    |    |
       └────┘    |    └────┘
          │      │       │
          └──────┘       │
               │         │
               └─────────┘

→ Nhìn vào cây, quyết định cắt ở đâu!

✅ Ưu điểm

Không cần biết số nhóm trước - Cắt ở đâu cũng được
Visualization đẹp - Dendrogram trực quan
Hiểu được hierarchy - Nhóm con, nhóm cha
Deterministic - Chạy lại kết quả giống nhau

❌ Nhược điểm

Chậm - Với > 10,000 users sẽ rất lâu
Không thể undo - Merge sai không rollback được
Memory lớn - Phải lưu toàn bộ relationships

🎯 Khi nào dùng?

✅ Khi muốn khám phá (exploratory analysis)
✅ Khi cần hiểu structure/hierarchy
✅ Khi data nhỏ-trung bình (< 5,000 users)
✅ Khi cần present cho leadership (dendrogram đẹp!)

VII) HDBSCAN - BẢN NÂNG CẤP CỦA DBSCAN

💡 Ý tưởng chính

DBSCAN nhưng thông minh hơn:

DBSCAN: "Bao xa là gần?" → 1 con số cố định
HDBSCAN: "Tự động điều chỉnh cho từng vùng"

Giống như:

DBSCAN: "Trong bán kính 5m có ≥ 5 người → nhóm bạn"
HDBSCAN: "Ở chỗ đông → 3m, ở chỗ vắng → 10m cũng OK"

📖 Ví dụ thực tế với data piggi_metrics.csv

Từ 21 dòng data, giả sử có thêm nhiều users tạo ra 2 vùng mật độ khác nhau:

Vùng đông đúc - Mission Players (10 users gần nhau):
  665300: Mission(3), Profile(1)
  665302: Mission(1), CreateMission(1)
  200165: Mission(1)
  ... + 7 users khác cũng thích Mission

Vùng thưa thớt - VIP/Diverse Users (3 users xa nhau):
  664402: Profile(3), UpdateProfile(1), DealHot(5), Mission(8), ChatRoom(2)
         → User đa dạng, vào nhiều thứ
  581242: EmbeddedBrowser(8), ChatRoom(5), Loyalty(3)
         → User đa dạng khác
  294132: ChatRoom(10), ReferralFriend(8), Mission(4)
         → User xã hội hóa

DBSCAN với eps=0.5, min_samples=3:

✅ Tìm được vùng Mission (10 users đông đúc)
❌ Bỏ sót 3 VIP users (xa nhau, không đủ min_samples=3)
→ 3 VIP users bị gán là outliers (sai!)

HDBSCAN tự động:

Bước 1: Phát hiện vùng Mission đông đúc
  → Tạo Cluster 1 với 10 users

Bước 2: Phát hiện 3 VIP users tuy xa nhau nhưng có pattern riêng
  → Tự điều chỉnh: "Ở vùng này, chỉ cần 2 users gần nhau cũng OK"
  → Tạo Cluster 2 với 3 VIP users

Bước 3: Các users lẻ loi thật sự (EmbeddedBrowser(1), ...) → Outliers

Kết quả:

DBSCAN: 1 cluster (Mission) + 3 VIP bị nhầm outliers
HDBSCAN: 2 clusters (Mission + VIP) + outliers thật sự ✅

→ HDBSCAN thông minh hơn, tự thích nghi với mật độ khác nhau!

✅ Ưu điểm

Tự động hóa cao - Ít cần tune parameters
Tốt nhất cho density-based - State-of-the-art
Handle varied density - Mật độ khác nhau OK
Outlier scores - Cho điểm từ 0-1 (không chỉ yes/no)

❌ Nhược điểm

Phức tạp - Khó hiểu thuật toán
Cần thư viện riêng - Không có sẵn trong sklearn
Chậm hơn K-Means - Nhưng nhanh hơn DBSCAN

🎯 Khi nào dùng?

✅ Thay thế DBSCAN - Better version
✅ Khi có nhóm đông/thưa khác nhau
✅ Khi muốn tự động hóa (ít tune)
✅ Đề xuất cho production - Robust, chất lượng cao

📊 SO SÁNH BẰNG VÍ DỤ HẰNG NGÀY

Thuật toán	Giống như...	Khi nào dùng?
K-Means	Chia lớp thành các tổ học	Biết cần mấy nhóm, cần nhanh
DBSCAN	Tìm nhóm bạn trong quán cafe đông người	Tìm outliers, không biết số nhóm
GMM	Phân loại người có nhiều sở thích	User không rõ ràng 1 nhóm
RFD	Xếp hạng khách hàng thân thiết	Marketing, đơn giản, nhanh
Rule-Based	Quy định của công ty	Logic business rõ ràng
Hierarchical	Vẽ cây gia phả	Khám phá, visualization
HDBSCAN	Tìm nhóm bạn thông minh (tự động)	Production, chất lượng cao

Meilisearch

Hoàng Mạnh Khiêm — Thu, 21 May 2026 12:15:50 +0000

1. Giới thiệu

Meilisearch là một search engine mã nguồn mở, tốc độ cao, tập trung vào trải nghiệm developer. Được viết bằng Rust, thiết kế theo hướng search-as-you-type (tìm kiếm ngay khi gõ).

2. Điểm nổi bật:

Tính năng	Mô tả
Siêu nhanh	Phản hồi dưới 50ms ngay cả khi xử lý lượng dữ liệu lớn
Typo Tolerance	Tự động xử lý lỗi chính tả và từ khóa gần đúng
Full-text Search	Hỗ trợ tìm kiếm toàn văn bản với độ chính xác cao
Faceted Search	Hỗ trợ lọc dữ liệu theo danh mục, thuộc tính (facet)
RESTful API	Dễ dàng tích hợp thông qua giao tiếp HTTP API
Self-hosted	Triển khai trên server riêng, không phụ thuộc dịch vụ bên thứ ba
Multi-language	Hỗ trợ đa ngôn ngữ, bao gồm cả tiếng Việt

3. Header bắt buộc

Content-Type: application/json Authorization: Bearer <token>

4. Các loại Search

4.1. Single Index Search — Tìm kiếm trong một index

Tìm kiếm thông thường trong một index cụ thể.

POST /indexes/{indexUid}/search

4.2. Multi-Search — Tìm kiếm nhiều index cùng lúc

Cho phép gửi nhiều query trong một request duy nhất, giảm số lần gọi API.

POST /multi-search JSON { "queries": [ { "indexUid": "movies", "q": "action" }, { "indexUid": "books", "q": "thriller" } ] }

4.3. Federated Search — Tìm kiếm liên hợp

Tìm kiếm trên nhiều index và gộp kết quả thành một danh sách duy nhất, có ranking đồng nhất.

POST /multi-search JSON { "federation": {}, "queries": [ { "indexUid": "movies", "q": "batman" }, { "indexUid": "comics", "q": "batman" } ] }

4.4. Search with Filters — Tìm kiếm kết hợp lọc

Dùng thuộc tính filter để thu hẹp kết quả tìm kiếm theo điều kiện.

4.5. Faceted Search — Tìm kiếm phân loại

Dùng facets để lấy thống kê số lượng theo từng nhóm giá trị (ví dụ: bao nhiêu phim thuộc thể loại "Action").

4.6. Search with Geo (Geosearch) — Tìm kiếm theo vị trí địa lý

Tìm kiếm và sort theo tọa độ GPS.

JSON { "q": "restaurant", "sort": ["_geoPoint(48.8566, 2.3522):asc"] }

5. Các tham số trong Search API

Endpoint: GET\POST /indexes/{indexUid}/search

5.1. Tham số truy vấn cơ bản

Tham số	Kiểu	Default	Mô tả
`q`	`string`	—	Chuỗi tìm kiếm. Để trống → placeholder search (trả về tất cả documents). Dùng `"..."` cho phrase search. Dùng `-word` để loại trừ từ khóa. Chỉ xét tối đa 10 từ đầu tiên
`limit`	`integer`	`20`	Số kết quả tối đa trả về. Không được vượt quá `maxTotalHits`. Bị bỏ qua khi sử dụng `page` / `hitsPerPage`
`offset`	`integer`	`0`	Bỏ qua N kết quả đầu tiên (phân trang thủ công). Bị bỏ qua khi sử dụng `page` / `hitsPerPage`
`page`	`integer`	—	Số trang hiện tại (bắt đầu từ `1`). Dùng kèm với `hitsPerPage`. Khi thiết lập → response trả về `totalHits` và `totalPages` thay vì `estimatedTotalHits`
`hitsPerPage`	`integer`	`20`	Số kết quả trên mỗi trang. Đặt `0` để chỉ lấy `totalHits` chính xác mà không trả về documents

5.2. Tham số lọc & sắp xếp

Tham số	Kiểu	Default	Mô tả
`filter`	`string`	—	Biểu thức lọc kết quả. Tất cả attributes dùng trong filter bắt buộc phải có trong `filterableAttributes`. Hỗ trợ geo filter: `_geoRadius()`, `_geoBoundingBox()`, `_geoPolygon()`
`sort`	`string[]`	—	Sắp xếp kết quả. Format: `["attribute:asc", "attribute:desc"]`. Attribute phải có trong `sortableAttributes`. Hỗ trợ geo sort: `_geoPoint(lat,lng):asc`
`facets`	`string[]`	—	Trả về số lượng match theo từng giá trị facet. Dùng `["*"]` để lấy tất cả `filterableAttributes`. Response sẽ có thêm `facetDistribution` và `facetStats`
`distinct`	`string`	—	Chỉ trả về 1 document đại diện cho mỗi giá trị unique của field này. Attribute phải có trong `filterableAttributes`. Override `distinctAttribute` của index
`matchingStrategy`	`enum`	`last`	Chiến lược match khi thiếu kết quả: `last` (bỏ bớt từ từ cuối), `all` (chỉ lấy kết quả khớp hoàn toàn), `frequency` (bỏ bớt từ phổ biến nhất trước)
`attributesToSearchOn`	`string[]`	—	Giới hạn tìm kiếm chỉ trong các attributes được liệt kê. Mỗi attribute phải tồn tại trong `searchableAttributes`. Thứ tự không ảnh hưởng đến relevancy
`rankingScoreThreshold`	`float`	—	Loại bỏ các kết quả có điểm ranking thấp hơn ngưỡng này (`0.0 – 1.0`). Các hits bị loại sẽ không được tính vào `estimatedTotalHits`, `totalHits`, hoặc facet
`locales`	`enum[]`	—	Chỉ định ngôn ngữ của query theo chuẩn ISO-639. Override auto-detection. Ví dụ: `["vi", "en"]`

Ví dụ filter nâng cao:

{ "filter": "genre = 'Action' AND rating > 7 AND NOT country = 'US'", "sort": ["release_date:desc"] }

5.3. Tham số hiển thị kết quả

Tham số	Kiểu	Default	Mô tả
`attributesToRetrieve`	`string[]`	`["*"]`	Danh sách fields trả về trong mỗi document. Dùng `["*"]` để lấy tất cả. Attributes không có trong `displayedAttributes` sẽ bị bỏ qua
`attributesToHighlight`	`string[]`	—	Bôi đậm từ khóa match trong các attributes chỉ định. Kết quả xuất hiện trong `_formatted`. Dùng `["*"]` để highlight tất cả fields trong `attributesToRetrieve`. Hỗ trợ cả synonyms và stop words
`highlightPreTag`	`string`	`"<em>"`	Chuỗi chèn trước từ được highlight. Có thể là HTML tag hoặc ký tự bất kỳ
`highlightPostTag`	`string`	`"</em>"`	Chuỗi chèn sau từ được highlight. Dùng cùng với `highlightPreTag` để tránh tạo HTML không hợp lệ
`attributesToCrop`	`string[]`	—	Cắt ngắn nội dung và trả về đoạn trích (snippet) trong `_formatted`. Hỗ trợ syntax `attribute:length` để override theo từng attribute. Đoạn cắt được căn giữa quanh từ khóa match
`cropLength`	`integer`	`10`	Số từ tối đa trong đoạn trích. Cả query terms và stop words đều được tính vào độ dài này
`cropMarker`	`string`	`"…"`	Ký hiệu đánh dấu vị trí bị cắt. Đặt `null` hoặc chuỗi rỗng nếu không muốn hiển thị marker. Chỉ xuất hiện khi có nội dung thực sự bị cắt
`showMatchesPosition`	`boolean`	`false`	Khi đặt `true`, mỗi hit sẽ có thêm `_matchesPosition` chứa byte offset (`start` + `length`) của từng term match. Hữu ích cho custom highlighting. Đơn vị là `bytes`, không phải `characters`

5.4. Tham số nâng cao

Tham số	Kiểu	Default	Mô tả
`showRankingScore`	`boolean`	`false`	Khi đặt `true`, mỗi document sẽ có thêm field `_rankingScore` (`0.0 – 1.0`). Điểm càng cao → mức độ liên quan càng lớn. Rule `sort` không ảnh hưởng đến giá trị này
`showRankingScoreDetails`	`boolean`	`false`	Khi đặt `true`, mỗi document sẽ có thêm `_rankingScoreDetails` — breakdown điểm theo từng ranking rule. Hữu ích để debug relevancy
`showPerformanceDetails`	`boolean`	`false`	Khi đặt `true`, response sẽ có thêm object `performanceDetails` chứa timing breakdown của từng bước xử lý query

Ví dụ request đầy đủ:

{ "q": "avengers", "limit": 10, "offset": 0, "filter": "genre = 'Action' AND rating >= 7", "sort": ["release_date:desc"], "facets": ["genre", "director"], "attributesToRetrieve": ["title", "poster", "rating", "genre"], "attributesToHighlight": ["title", "description"], "highlightPreTag": "<mark>", "highlightPostTag": "</mark>", "attributesToCrop": ["description"], "cropLength": 20, "showRankingScore": true, "matchingStrategy": "all" }

6. Cấu hình Settings (Index Settings)

Endpoint: GET/PATCH/DELETE /indexes/{indexUid}/settings

6.1. Searchable Attributes

Xác định trường nào được đưa vào full-text search index. Thứ tự trong array = mức độ ưu tiên (trường đầu tiên được ưu tiên cao nhất).

PUT /indexes/{indexUid}/settings/searchable-attributes ["title", "description", "tags"]

6.2. Displayed Attributes: Các trường được trả về trong kết quả search.

PUT /indexes/{indexUid}/settings/displayed-attributes ["title", "poster_url", "rating", "genre"]

6.3. Filterable Attributes: Khai báo các trường có thể dùng trong filter và facets. Bắt buộc phải khai báo trước khi dùng filter.

PUT /indexes/{indexUid}/settings/filterable-attributes JSON ["genre", "rating", "country", "release_year"]

6.4. Sortable Attributes: Khai báo các trường có thể dùng để sort. Bắt buộc phải khai báo trước khi dùng sort.

PUT /indexes/{indexUid}/settings/sortable-attributes JSON ["rating", "release_date", "price"]

6.5. Typo Tolerance: Kiểm soát mức độ chấp nhận lỗi chính tả.

PATCH /indexes/{indexUid}/settings/typo-tolerance JSON { "enabled": true, "minWordSizeForTypos": { "oneTypo": 5, "twoTypos": 9 }, "disableOnWords": ["iphone", "batman"], "disableOnAttributes": ["serial_number"] }

6.6. Synonyms: Cấu hình từ đồng nghĩa để mở rộng khả năng tìm kiếm.

PUT /indexes/{indexUid}/settings/synonyms JSON { "phone": ["smartphone", "mobile", "điện thoại"], "car": ["automobile", "vehicle", "xe hơi"], "ai": ["artificial intelligence", "machine learning"] }

6.7. Stop Words: Loại bỏ các từ không có giá trị tìm kiếm khỏi query.

PUT /indexes/{indexUid}/settings/stop-words JSON ["the", "a", "an", "is", "are", "và", "của", "cho"]

6.8. Distinct Attribute: Chỉ lấy 1 kết quả đại diện cho mỗi giá trị unique.

PUT /indexes/{indexUid}/settings/distinct-attribute JSON "product_id"

6.9. Faceting: Cấu hình tính năng faceted search.

PATCH /indexes/{indexUid}/settings/faceting JSON { "maxValuesPerFacet": 100, "sortFacetValuesBy": { "*": "alpha", "rating": "count" } }

6.10. Pagination: Cấu hình giới hạn phân trang.

PATCH /indexes/{indexUid}/settings/pagination JSON { "maxTotalHits": 1000 }

6.11. Embedders (Semantic Search): Cấu hình vector embedding cho AI/semantic search.

PATCH /indexes/{indexUid}/settings/embedders JSON { "myEmbedder": { "source": "openAi", "apiKey": "sk-...", "model": "text-embedding-3-small", "documentTemplate": "{{doc.title}} {{doc.description}}" } }

7. Ranking Rules

Ranking Rules xác định thứ tự ưu tiên khi tính điểm liên quan của kết quả. Rule đứng trước có độ ưu tiên cao hơn.

Endpoint: GET/PUT /indexes/{indexUid}/settings/ranking-rules

Rule	Mô tả
`words`	Ưu tiên document chứa nhiều từ trong query hơn
`typo`	Ưu tiên document có ít lỗi chính tả hơn
`proximity`	Ưu tiên document có các từ xuất hiện gần nhau hơn trong nội dung
`attribute`	Ưu tiên match ở field có độ ưu tiên cao hơn (theo thứ tự trong `searchableAttributes`)
`sort`	Áp dụng tiêu chí sắp xếp do người dùng truyền vào
`exactness`	Ưu tiên document khớp chính xác với từ khóa hơn

Mặc định:

["words", "typo", "proximity", "attribute", "sort", "exactness"]

Custom ranking rules: Có thể thêm rule tùy chỉnh theo trường cụ thể:

["words", "typo", "proximity", "attribute", "sort", "exactness", "rating:desc", "release_date:asc"]
_
Tips: Đặt sort lên trước nếu muốn ưu tiên tiêu chí sắp xếp của người dùng hơn là độ liên quan ngữ nghĩa. Đặt exactness lên trước nếu cần match chính xác cao._

8. Các API xóa dữ liệu

8.1. Xóa toàn bộ Index

DELETE /indexes/{indexUid} : Xóa cả cấu hình lẫn dữ liệu của index.

8.2. Xóa tất cả Documents trong Index

DELETE /indexes/{indexUid}/documents

8.3. Xóa Document theo ID

DELETE /indexes/{indexUid}/documents/{documentId}

8.4. Xóa nhiều Documents theo danh sách ID

POST /indexes/{indexUid}/documents/delete-batch [1, 2, 3, 42, 100]

8.5. Xóa Documents theo Filter

POST /indexes/{indexUid}/documents/delete { "filter": "genre = 'Horror' AND release_year < 2000" }

8.6. Reset Settings về mặc định

DELETE /indexes/{indexUid}/settings: Reset từng phần setting cụ thể:

DELETE /indexes/{indexUid}/settings/synonyms DELETE /indexes/{indexUid}/settings/stop-words DELETE /indexes/{indexUid}/settings/ranking-rules DELETE /indexes/{indexUid}/settings/filterable-attributes DELETE /indexes/{indexUid}/settings/sortable-attributes DELETE /indexes/{indexUid}/settings/searchable-attributes DELETE /indexes/{indexUid}/settings/typo-tolerance DELETE /indexes/{indexUid}/settings/faceting DELETE /indexes/{indexUid}/settings/pagination DELETE /indexes/{indexUid}/settings/embedders

8.7. Hủy Task đang chờ xử lý

Cho phép hủy các task chưa hoàn thành (enqueued, processing) theo nhiều điều kiện khác nhau.

POST /tasks/cancel?uids=1,2,3 POST /tasks/cancel?indexUids=movies POST /tasks/cancel?statuses=enqueued,processing

Tham số	Kiểu	Mô tả
`uids`	`string`	Danh sách task UID cần hủy, phân tách bằng dấu phẩy
`indexUids`	`string`	Hủy tất cả task thuộc các index được chỉ định
`statuses`	`string`	Hủy task theo trạng thái (`enqueued`, `processing`)

Response

{ "taskUid": 42, "indexUid": null, "status": "enqueued", "type": "taskCancelation", "enqueuedAt": "2026-05-21T10:00:00Z" }

8.8. Xóa lịch sử Task

Cho phép xóa lịch sử task đã hoàn thành hoặc thất bại khỏi hệ thống.

DELETE /tasks?uids=1,2,3 DELETE /tasks?indexUids=movies DELETE /tasks?statuses=succeeded,failed

Query Parameters

Tham số	Kiểu	Mô tả
`uids`	`string`	Danh sách task UID cần xóa
`indexUids`	`string`	Xóa tất cả task thuộc các index được chỉ định
`statuses`	`string`	Xóa task theo trạng thái (`succeeded`, `failed`)

Response trả về thông tin task deletion đã được enqueue:

{ "taskUid": 43, "indexUid": null, "status": "enqueued", "type": "taskDeletion", "enqueuedAt": "2026-05-21T10:05:00Z" }

Full-Text Search Functions

Hoàng Mạnh Khiêm — Mon, 18 May 2026 09:39:52 +0000

I) Cấu trúc chính

MATCH (col1,col2,...) AGAINST (expr [search_modifier])

col1, col2, ...: Các cột chứa dữ liệu văn bản mà bạn muốn tìm kiếm.
expr: Biểu thức tìm kiếm, có thể là một chuỗi hoặc một biến
search_modifier: Tùy chọn để xác định cách thức tìm kiếm, có thể là IN NATURAL LANGUAGE MODE, IN BOOLEAN MODE, hoặc WITH QUERY EXPANSION.

II) Điều kiện dùng FULLTEXT

MySQL hỗ trợ InnoDB hoặc MyISAM
Chỉ mục index dạng FULLTEXT

II) Các loại tìm kiếm FULLTEXT

1) Tìm kiếm bằng ngôn ngữ tự nhiên (A Natural Language)

1.1) Định nghĩa

Tìm kiếm bằng ngôn ngữ tự nhiên được cài đặt mặc định khi dùng câu lệnh:

MATCH() ... AGAINST()
MATCH() ... AGAINST('keyword' IN NATURAL LANGUAGE MODE)

1.2) Đặc điểm

Tìm kiếm bằng ngôn ngữ tự nhiên mặc định không có phân biệt rõ ràng chữ hoa với chữ thường. Để cho phép tìm kiếm bằng ngon ngữ tự nhiên phân biệt rõ ràng các chữ hoa chữ thường thì cần chuyển đổi kiểu utf8mb4 sang utf8mb4_0900_as_cs hoặc utf8mb4_bin.
Có áp dụng danh sách stopwords
MySQL tự động tính độ liên quan (relevance score)
Kết quả thường được sắp xếp theo độ liên quan
Chỉ hoạt động trên cột có FULLTEXT INDEX
Chỉ hỗ trợ các kiểu dữ liệu: CHAR, VARCHAR, TEXT

1.3) Điểm mạnh

Tìm kiếm bằng ngôn ngữ tự nhiên có hiệu suất tìm kiếm full-text hơn cách quét toàn bộ bảng dữ liệu trong MySQL
Hiệu suất tìm kiếm nhanh hơn LIKE '%keyword%'
Tìm kiếm bằng ngôn ngữ tự nhiên giúp không cần sử dụng Order By trong query.

2) Tìm kiếm Boolean (Boolean Search)

2.1) Định nghĩa

Boolean Full-Text Search là kiểu tìm kiếm full-text sử dụng:

MATCH() ... AGAINST('keyword' IN BOOLEAN MODE)

2.2) Đặc điểm

Trong tìm kiếm Boolean cho phép sử dụng các toán tử, cụ thể:

+ : bắt buộc phải có
Ví dụ:

 '+apple +juice' : Tìm các hàng chứa cả hai từ.
 '+apple macintosh' : Tìm các hàng có chứa từ _apple_ , nhưng xếp hạng các hàng cao hơn nếu chúng cũng chứa từ _macintosh _.
 '+apple +juice' : Tìm các hàng chứa cả hai từ.

- : không được có
Ví dụ:

 '+apple -macintosh' : Tìm các hàng có chứa từ “ apple ” nhưng không chứa từ _macintosh_ .

" : tìm chính xác cụm từ
Ví dụ:

 '"some words"' : Tìm các hàng chính xác có từ _some words_

* : wildcard / prefix
Ví dụ:

 'apple*' : Tìm các hàng chứa các từ như _apple_ , _apples_ , _applesauce_ hoặc _applet_

> < : tăng / giảm độ liên quan
Ví dụ:

 '+apple +(>turnover <strudel)' : Tìm các hàng chứa các từ _apple_ và _turnover_ hoặc _apple_ và _strudel_ (theo bất kỳ thứ tự nào), nhưng xếp hạng _apple turnover_ cao hơn _apple strudel_

~ : giảm điểm relevance
Ví dụ:

 '+apple ~macintosh' : Tìm các hàng chứa từ _apple_ , nhưng nếu hàng đó cũng chứa từ _macintosh_ , hãy đánh giá thấp hơn so với trường hợp hàng đó không chứa từ _macintosh_ .

() : nhóm biểu thức
Ví dụ:

 '+apple +(>turnover <strudel)' : Nhóm 2 biểu thức bắt buộc phải có, và độ liên quan.

Không tự động sắp xếp theo độ liên quan
Có áp dụng stopwords
Với InnoDB, tất cả cột trong MATCH() phải có FULLTEXT INDEX
MyISAM có thể search dù không có FULLTEXT INDEX nhưng rất chậm

2.3) Điểm mạnh
Tìm kiếm linh hoạt hơn
Hỗ trợ các logic Or, and, not

3) Tìm kiếm mở rộng truy vấn (Query Expansion Search)

3.1) Định nghĩa

Query Expansion (mở rộng truy vấn) là một biến thể của tìm kiếm full-text trong MySQL, giúp mở rộng kết quả tìm kiếm bằng cách tự động bổ sung thêm từ khóa liên quan từ các kết quả ban đầu.

MATCH(col1, col2, ...)
AGAINST('keyword' WITH QUERY EXPANSION)

3.2) Đặc điểm

Tìm kiếm mở rộng truy vấn hoạt động dựa vào 2 bước chính là:
- Bước 1: Tìm kiếm như tìm kiếm theo ngôn ngữ tự nhiên
- Bước 2: Lấy một số từ quan trọng từ các kết quả đầu tiên và thực hiện lại tìm kiếm với tập từ khóa đã mở rộng.
Tìm kiếm mở rộng truy vấn dựa theo ngữ nghĩa
Tự động mở rộng truy vấn tìm kiếm
Không cần người dùng nhập đủ keywords
Hỗ trợ tốt khi từ để tìm kiếm từ thiếu ngữ nghĩa

3.3) Điểm mạnh

Từ keyword thiếu ngữ nghĩa có thể mở rộng phạm vi kết quả tìm kiếm.
Tăng khả năng tìm kiếm ý định tìm kiếm liên quan

III. Full-Text Stopwords

Định nghĩa

Stopwords là các từ quá phổ biến (như “the”, “a”, “is”, …) sẽ bị bỏ qua khi tạo index và khi tìm kiếm full-text trong MySQL.

IV. Full-Text Restrictions

Định nghĩa

Full-Text Restrictions là tập hợp các giới hạn và điều kiện bắt buộc khi sử dụng tính năng Full-Text Search trong MySQL. Các giới hạn này quy định những trường hợp mà FULLTEXT index và câu lệnh MATCH() ... AGAINST() được phép hoặc không được phép hoạt động.

V. Fine-Tuning MySQL Full-Text Search

Định nghĩa

Fine-Tuning Full-Text Search là quá trình điều chỉnh các tham số và cấu hình của MySQL Full-Text Search nhằm thay đổi hành vi tìm kiếm (như tokenization, stopwords, operator, indexing), tối ưu theo nhu cầu cụ thể.

Cấu hình

1) Cấu hình độ dài từ

innodb_ft_min_token_size
innodb_ft_max_token_size
ft_min_word_len
ft_max_word_len

2) Cấu hình ngưỡng Natural Language (MyISAM)

#define GWS_IN_USE GWS_FREQ

3) Cấu hình ngưỡng Natural Language (MyISAM)

ft_boolean_syntax