Semantic search vs keyword search

TL;DR: Semantic search thắng khi hai câu diễn đạt khác nhau nhưng cùng nghĩa (bài 01), nhưng thua trắng trước định danh chính xác — mã lỗi, tên endpoint, số phiên bản, số hoá đơn. Lý do nằm ở gốc: những chuỗi đó không có khái niệm "gần nghĩa", chỉ có trùng hoặc không trùng, còn semantic lại đi tìm thứ nghe giống. Keyword search (BM25 — xếp hạng theo tần suất và độ hiếm của từ khoá) khớp CHUỖI CHÍNH XÁC nên thắng tuyệt đối ở loại truy vấn này. Hybrid chạy song song cả hai đường tìm kiếm rồi hoà điểm, ăn được cả hai thế mạnh thay vì chọn một trong hai.

Nhóm nghỉ phép ở bài 01 mừng ra mặt vì semantic search cuối cùng cũng tìm ra tài liệu HR dù nhân viên gõ khác hẳn từ khoá. Tự tin, họ mở rộng cùng công cụ đó sang toàn bộ tài liệu kỹ thuật nội bộ — runbook, API doc, changelog. Tuần đầu tiên, một kỹ sư gõ "mã lỗi ERR-PAYMENT-4023 là gì" vào ô tìm kiếm, kỳ vọng ra đúng trang runbook xử lý mã đó. Kết quả trả về: một bài hướng dẫn cấu hình cổng thanh toán — không nhắc tới mã lỗi nào cả, mà điểm similarity vẫn cao, vì cả hai đoạn đều "nói về thanh toán". Vài ngày sau, một truy vấn khác — "/api/v2/transfers dùng để làm gì" — trả về tài liệu của /api/v2/withdrawals, một endpoint hoàn toàn khác, chỉ giống nhau ở chỗ cùng nằm trong cụm "chuyển khoản".

Cùng một công cụ vừa thắng đậm ở bài 01, giờ thua trắng. Bài này giải thích vì sao — và quan trọng hơn, giúp bạn đoán trước loại truy vấn nào sẽ hỏng, thay vì phát hiện ra sau khi người dùng report bug.

1. Analogy — danh bạ điện thoại: mô tả mập mờ và số gọi chính xác

Bạn nhớ mang máng "anh nào bên vận hành, tên có chữ Minh, hay gọi lúc nửa đêm" — mô tả mập mờ này vẫn giúp đồng nghiệp đoán ra đúng người, dù mỗi người kể một kiểu. Nhưng khi cần BẤM một số điện thoại, không có khái niệm "số gần đúng" nào chấp nhận được: bấm sai một chữ số cuối, bạn gọi trúng một người hoàn toàn xa lạ — không phải "gần đúng người cần gọi", mà là SAI HẲN, không liên quan gì.

Analogy hỏng ở chỗ số điện thoại luôn là 10 chữ số cùng một khuôn, còn định danh trong hệ thống thật đa dạng hình dạng hơn nhiều (chữ, số, dấu gạch ngang, dấu chấm) — nhưng bản chất "không có gần đúng, chỉ có trùng hoặc sai" thì giữ nguyên ở cả hai.

2. Truy vấn nào sẽ hỏng?

3. Vì sao ranh giới là "có định danh", không phải "chủ đề"?

Đối chiếu với dự đoán của bạn: câu 1 và 3 semantic làm tốt, câu 2, 4, 5 hỏng. Để ý câu 3 và câu 4 hỏi cùng một endpoint, chỉ khác cách hỏi — đó chính là ranh giới của cả bài. Câu 3 diễn đạt tự nhiên, không chứa chuỗi định danh; đúng bài toán semantic được huấn luyện để giải, giống cơ chế "xin nghỉ phép năm" ở bài 01. Câu 4 chứa nguyên văn /api/v2/transfers — một chuỗi định danh literal — và đó là chỗ semantic gãy.

Nhắc lại từ bài 01: không gian nghĩa được học từ việc kéo gần các cặp được huấn luyện coi là liên quan. Nhưng ERR-PAYMENT-4023 và ERR-PAYMENT-4024 không phải hai cách diễn đạt của cùng một ý — chúng là hai khoá tra cứu độc lập, có thể trỏ tới hai lỗi không liên quan. Chưa tập huấn luyện nào dạy model "hai mã liền số thì cùng nghĩa", vì bản thân chúng không mang nghĩa để học. Vị trí của chúng trong không gian vector là hệ quả ngẫu nhiên của việc tokenizer băm chúng ra sao, không phải bằng chứng chúng có liên quan hay không.

embed("ERR-PAYMENT-4023 timeout khi goi cong thanh toan")
    -> tokenizer bam thanh cac manh subword: ["ERR", "-", "PAY", "MENT", "-", "402", "3", ...]
    -> embedding gop cac manh do lai thanh MOT vector chu de "thanh toan"
-- Doi 4023 thanh 4024, ranh gioi cat subword co the đoi khac hoan toan
-- => khoang cach vector giua hai ma KHONG phan anh dang tin cay "cung loi hay khac loi"

Điểm cosine similarity (bài 02) vẫn tính ra một con số hợp lệ cho cặp (câu hỏi, tài liệu) chứa mã lỗi — chỉ là con số đó đo đúng thứ semantic đã học được (chủ đề "thanh toán"), không đo thứ bạn thật sự cần (khớp đúng khoá tra cứu).

4. Vì sao Keyword/BM25 thắng tuyệt đối ở đây?

BM25 (Best Matching 25) là thuật toán xếp hạng cho tìm kiếm từ khoá: chấm điểm một tài liệu dựa trên tần suất từ khoá xuất hiện trong đó (term frequency) và độ hiếm của từ khoá đó trên toàn tập tài liệu (inverse document frequency) — từ càng hiếm mà xuất hiện càng nhiều lần, tài liệu đó càng được chấm cao. Khác semantic, BM25 không đo "gần nghĩa" — nó đo sự có mặt của đúng chuỗi/token.

Khi ERR-PAYMENT-4023 xuất hiện y nguyên trong một trang runbook, BM25 tìm ra ngay: điểm số phụ thuộc mã đó có mặt hay không, không phụ thuộc trang đó "nghe có liên quan" hay không. Đây là mặt lật ngược của điểm yếu keyword từng gặp ở bài 01 — "xin nghỉ phép năm" và "đăng ký ngày nghỉ" không chung từ khoá nên keyword tìm rỗng. Hai công cụ đặt cược ngược nhau: keyword thua ở diễn đạt khác nhau cùng ý, semantic thua ở chuỗi định danh không có "gần nghĩa".

5. Hybrid hoạt động thế nào?

Hybrid search không phải "thêm bộ lọc từ khoá lên trên semantic" — đó là chạy song song hai công cụ độc lập trên cùng truy vấn, rồi hoà hai danh sách kết quả thành một bảng xếp hạng duy nhất:

function hybridSearch(query, docs):
    semanticResults <- semanticSearch(embed(query), docs)    -- xep hang theo cosine similarity
    keywordResults  <- keywordSearch(query, docs)             -- xep hang theo BM25 (khop tu khoa)
    combined <- mergeScores(semanticResults, keywordResults)  -- cong diem hoac hoa theo thu hang
    return topK(combined)
// Time: O(chi phi hai duong tim kiem cong lai)  Space: O(so tai lieu ung vien)

Chưa có benchmark định lượng nào đủ tin cậy cho một con số cụ thể kiểu "hybrid tăng recall X%" — con số đó phụ thuộc quá nhiều vào tỉ lệ truy vấn chứa định danh trong domain thật, nên bài này không trích số. Điều chắc chắn là định tính: trên tập truy vấn có lẫn mã lỗi, endpoint, số phiên bản, hybrid thường vượt vector thuần rõ rệt, vì đường keyword vẫn bắt được đúng những gì đường semantic bỏ lỡ — còn trên truy vấn thuần diễn đạt tự nhiên, phần đóng góp của keyword gần như bằng không.

6. Pitfall tổng hợp

❌ Nhầm 1 — coi hybrid là "semantic trước, lọc từ khoá sau":

✅ Lọc sau chỉ hoạt động trên kết quả semantic đã trả về — nếu semantic không đưa ERR-PAYMENT-4023 vào top-k ban đầu, lọc từ khoá phía sau không còn gì để lọc. Hybrid đúng nghĩa chạy BM25 độc lập, song song, không phụ thuộc semantic tìm thấy trước hay không.

❌ Nhầm 2 — nghĩ thêm hybrid là xong, không cần suy nghĩ gì thêm:

✅ Trọng số hoà điểm giữa hai đường không có công thức mặc định đúng cho mọi domain — hệ nhiều mã định danh (banking, DevOps) cần nghiêng về keyword hơn hệ tài liệu thuần văn bản (HR, chính sách nội bộ).

7. 📚 Deep Dive

8. Liên hệ các bài khác

• Bài 01 — Embedding, không gian nghĩa — nguồn của "gần nghĩa": vì sao semantic mạnh ở diễn đạt khác nhau, và chính giới hạn đó gây ra thất bại ở bài này.
• Bài 02 — Cosine similarity — phép đo "gần" mà bài này chỉ ra: vẫn tính ra điểm số hợp lệ, chỉ là đo sai thứ cần đo khi truy vấn chứa định danh.
• Bài 04 — Chunking — quyết định cắt tài liệu ảnh hưởng cả semantic lẫn keyword, nhưng theo hai cách khác nhau.
• Bài 06 — RAG failure modes — khi retrieval chọn nhầm tài liệu (như ca ERR-PAYMENT-4023 ở đầu bài) chính là gốc của một loại failure mode cụ thể trong RAG.
• Tokenization — cơ chế subword đứng sau lý do định danh "vỡ vụn" trước khi vào embedding.

9. Tóm tắt

• Semantic thắng khi truy vấn diễn đạt tự nhiên; thua khi chứa định danh (mã lỗi, endpoint, version) — định danh không có khái niệm "gần nghĩa", chỉ có trùng hoặc không.
• Cùng nội dung: hỏi tự nhiên thì semantic thắng, hỏi kèm chuỗi định danh literal thì semantic thua — ranh giới là cách hỏi, không phải chủ đề.
• Keyword và semantic đặt cược ngược nhau — mỗi bên thắng đúng chỗ bên kia thua; hybrid chạy song song cả hai rồi hoà điểm.
• Chưa có benchmark định lượng đáng tin cho "hybrid tốt hơn X%" — bằng chứng hiện có là định tính.

10. Tự kiểm tra

Bài tiếp theo: Chunking