Embedding
Cách biến một đoạn văn bản thành dãy số sao cho hai đoạn gần nghĩa nằm gần nhau. Nhờ vậy máy tìm được theo ý người hỏi chứ không cần trùng từ khoá — nền của tìm kiếm ngữ nghĩa và của RAG.
Định nghĩa
Máy không hiểu chữ, máy chỉ tính được số. Embedding là bước biến một đoạn văn bản thành một dãy số dài — thường vài trăm tới vài nghìn chiều — sao cho hai đoạn nói cùng một ý thì hai dãy số đó nằm gần nhau. Gần tới mức nào thì đo bằng một phép tính đơn giản, hay dùng nhất là cosine similarity: về lý thuyết nó chạy từ −1 tới 1, còn với embedding văn bản thì thực tế gần như luôn rơi vào khoảng 0 tới 1.
Hệ quả thực dụng: máy tìm được "hủy đơn sau khi đã thanh toán" khi người dùng gõ "trả lại hàng đã trả tiền", dù hai câu không chung một từ nào đáng kể.
Hiểu bằng hình dung
Tưởng tượng mọi câu trong tài liệu của bạn được ghim lên một tấm bản đồ khổng lồ. Câu nói về khiếu nại vận chuyển tụ một góc, câu nói về chính sách hoàn tiền tụ góc khác, câu nói về bảo hành nằm đâu đó giữa hai góc vì nó dính cả hai. Tìm kiếm ngữ nghĩa chỉ là: ghim câu hỏi lên cùng tấm bản đồ, rồi lấy mấy cái ghim gần nó nhất.
Có một chỗ hay quên: bản đồ đó do đúng một mô hình embedding vẽ ra. Đổi mô hình là đổi bản đồ, và toàn bộ dữ liệu cũ phải ghim lại từ đầu. Chuyện này thường chỉ lộ ra vào lúc team muốn nâng cấp.
Ví dụ thực tế
Backlog Jira của một nền tảng học trực tuyến: 4.317 item sau ba năm, bốn đời PO, ba lần đổi cách đặt tiêu đề. Ai trong team cũng có cảm giác "chỗ này chắc nhiều cái trùng nhau", và chưa ai đủ kiên nhẫn ngồi rà.
Cách làm mất khoảng hai ngày công:
- Xuất ra CSV gồm khoá, tiêu đề, mô tả, ngày tạo, trạng thái.
- Ghép tiêu đề với đoạn mô tả đầu, tạo embedding cho từng item.
- Tính độ tương đồng từng cặp, giữ lại các cặp trên 0,88.
- Người đọc lại danh sách đó, gán ba nhãn: trùng thật, liên quan nhưng khác phạm vi, không liên quan.
Ra 268 cặp nghi ngờ. Người rà xong xác nhận 91 cặp trùng thật, gộp lại còn 47 item. Trong đó có ba item cùng mô tả một tính năng xuất báo cáo điểm danh, được tạo cách nhau 14 tháng, và một cái đã làm xong từ lâu trong khi hai cái kia vẫn nằm chờ.
177 cặp còn lại mới là chỗ bất ngờ. Chúng không trùng nhưng liên quan chặt, và đọc chúng cạnh nhau giúp PO gom được bốn nhóm chủ đề để làm epic. Giá trị phụ đó lúc lập kế hoạch không ai tính tới.
Việc BA giao được cho embedding
- Tìm yêu cầu trùng trong backlog hoặc trong kho ticket hỗ trợ.
- Gợi ý bài viết trợ giúp liên quan khi khách gõ câu hỏi, không cần khớp từ khoá.
- Nhóm hàng nghìn phản hồi khảo sát mở thành vài chục cụm chủ đề, để đọc theo cụm thay vì đọc từng dòng.
- Đối chiếu một yêu cầu mới với danh mục tính năng đã có, xem có cái nào đáp ứng được rồi không.
- Bước truy xuất trong hệ RAG. Đây là chỗ nó xuất hiện nhiều nhất.
Giới hạn cần biết trước khi tin
Gần nghĩa khác với trùng nghĩa. Hai câu "cho phép người dùng xoá tài khoản" và "không cho phép người dùng xoá tài khoản" nằm cực gần nhau trên bản đồ, vì chúng chỉ khác một chữ. Phủ định là điểm yếu kinh điển của embedding. Đừng dùng nó một mình để đối chiếu business rule.
Số và mã không được xử lý tử tế. Tìm đúng mã hợp đồng hay đúng số điều thì tìm kiếm từ khoá truyền thống làm tốt hơn. Nhiều hệ thống thật chạy song song cả hai rồi trộn kết quả, gọi là hybrid search — nếu team nhắc tới, đó là lý do.
Tiếng Việt có thêm biến số. Người dùng gõ không dấu, gõ teencode, viết tắt kiểu "ck" thay cho chuyển khoản. Chất lượng mô hình embedding với tiếng Việt chênh nhau khá nhiều, nên đừng chốt bằng cảm nhận. Lấy 100 câu hỏi thật của người dùng, chạy thử vài mô hình, đếm xem cái nào lấy đúng đoạn nhiều hơn.
Ngưỡng tương đồng không có con số chuẩn. 0,88 ở ví dụ trên là con số riêng của bộ dữ liệu đó, tìm ra bằng cách thử. Ai đưa cho bạn một ngưỡng "chuẩn ngành" thì nên hỏi lại họ đo trên dữ liệu nào.
