Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang xây một tính năng tìm kiếm cho ứng dụng thương mại điện tử. Người dùng gõ "áo khoác giữ ấm mùa đông", nhưng trong kho sản phẩm của bạn lại đặt tên là "áo phao lông vũ" hay "jacket chống lạnh". Nếu hệ thống chỉ tìm theo từ khóa trùng khớp chính xác, kết quả sẽ trống trơn — dù rõ ràng các sản phẩm đó chính là thứ khách hàng muốn. Đây là giới hạn cốt tử của tìm kiếm truyền thống: máy tính không hiểu ý nghĩa, nó chỉ so khớp ký tự.
Embeddings ra đời để giải quyết đúng vấn đề này. Đây là kỹ thuật biến mọi loại dữ liệu — văn bản, hình ảnh, âm thanh — thành những dãy số mà máy tính có thể đo "khoảng cách ý nghĩa" giữa chúng. Với vai trò AI Product Manager, bạn không cần tự tay huấn luyện mô hình embedding, nhưng bạn bắt buộc phải hiểu nó hoạt động ra sao. Bởi vì embeddings là nền tảng kỹ thuật cho hàng loạt tính năng AI mà bạn sẽ thiết kế: tìm kiếm ngữ nghĩa, hệ thống gợi ý, phân loại nội dung, phát hiện trùng lặp, và đặc biệt là RAG — chủ đề bạn sẽ học sâu ở các bài tiếp theo. Hiểu embeddings giống như hiểu "tế bào" của các sản phẩm AI hiện đại: không nắm được nó, bạn sẽ ra quyết định mù mờ về chi phí, độ chính xác và trải nghiệm.
Bài này tập trung hoàn toàn vào embeddings và biểu diễn vector — bản chất là gì, cách đo độ tương đồng, và cách một PM đọc hiểu để ra quyết định sản phẩm. Chúng ta chưa đi vào vector database (Bài 21) hay kiến trúc RAG (Bài 22); ở đây ta xây nền móng vững chắc trước.
Khái niệm cốt lõi
Embedding là gì
Embedding là cách biểu diễn một mẩu dữ liệu dưới dạng một vector — tức một dãy số. Ví dụ, câu "Tôi yêu Hà Nội" sau khi đi qua một mô hình embedding có thể trở thành một dãy như [0.021, -0.534, 0.187, ..., 0.092], dài chừng 768 hoặc 1.536 con số. Mỗi con số (gọi là một chiều / dimension) nắm giữ một phần ý nghĩa nào đó của câu — dù con người không đọc trực tiếp ra được "chiều thứ 200 nghĩa là gì".
Điều kỳ diệu nằm ở quy luật trung tâm: những thứ gần nghĩa nhau thì vector của chúng nằm gần nhau trong không gian; những thứ khác nghĩa thì nằm xa nhau. Câu "Tôi yêu Hà Nội" và "Tôi thích thủ đô Việt Nam" sẽ cho hai vector rất gần nhau, dù không chia sẻ từ nào giống hệt. Trong khi đó "Giá xăng tăng cao" sẽ nằm tận một góc khác của không gian.
Không gian nhiều chiều — hình dung thế nào
Não người chỉ hình dung được 3 chiều, còn embedding sống trong không gian 768 hay 1.536 chiều. Bạn không cần tưởng tượng nổi điều đó. Hãy dùng phép loại suy đơn giản: hình dung mỗi từ là một điểm trên bản đồ. Các thành phố "Hà Nội", "Hải Phòng", "Đà Nẵng" nằm cụm gần nhau (đều là địa danh Việt Nam); cụm "cà phê", "trà sữa", "nước cam" nằm ở khu khác (đồ uống). Khoảng cách giữa hai điểm chính là thước đo độ khác nghĩa. Embedding chỉ là phiên bản "bản đồ" đó nhưng có hàng trăm chiều thay vì hai.
Đo độ tương đồng — cosine similarity
Để biết hai vector gần nhau cỡ nào, kỹ thuật phổ biến nhất là cosine similarity (độ tương đồng cosin). Thay vì đo khoảng cách thẳng, nó đo góc giữa hai vector:
- Cosine = 1: hai vector chỉ cùng một hướng → ý nghĩa gần như giống hệt.
- Cosine = 0: vuông góc → không liên quan.
- Cosine = -1: ngược hướng → trái nghĩa hoàn toàn.
Vì sao embedding "biết" ngữ nghĩa
Mô hình embedding được huấn luyện trên lượng văn bản khổng lồ. Trong quá trình đó, nó học được rằng các từ xuất hiện trong ngữ cảnh giống nhau thì có nghĩa gần nhau ("bác sĩ" và "y tá" hay đi cùng các từ như "bệnh viện", "khám", "thuốc"). Kết quả là mô hình tự sắp xếp ý nghĩa thành cấu trúc hình học. Một ví dụ kinh điển: vector("vua") − vector("đàn ông") + vector("phụ nữ") ≈ vector("nữ hoàng"). Embedding nắm bắt được cả quan hệ ngữ nghĩa lẫn quan hệ tương tự, chứ không chỉ "từ nào giống từ nào".
Embedding đa phương thức (multimodal)
Embedding không chỉ dành cho văn bản. Mô hình như CLIP của OpenAI đặt cả ảnh và văn bản vào cùng một không gian vector. Nghĩa là ảnh một chú mèo và dòng chữ "a photo of a cat" sẽ có vector gần nhau. Đây là nền tảng cho tìm kiếm ảnh bằng câu mô tả, hay kiểm duyệt nội dung bằng AI. Là PM, bạn nên biết rằng "embedding" là một khái niệm rộng, áp dụng cho mọi loại dữ liệu, không riêng chữ.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán tìm kiếm "hiểu ý"
Giả sử đội sản phẩm tìm kiếm của Tiki nhận thấy khoảng 18% lượt tìm kiếm trả về kết quả trống hoặc không liên quan, dù sản phẩm phù hợp có trong kho. Nguyên nhân: người dùng gõ tiếng Việt tự nhiên ("đồ chơi cho bé 3 tuổi tập viết") còn tên sản phẩm lại là "bảng học chữ thông minh Montessori". Tìm theo từ khóa không bắc được cây cầu này.
Đội ngũ thử nghiệm thêm một lớp tìm kiếm ngữ nghĩa: với mỗi sản phẩm, họ tạo embedding từ tên + mô tả; với mỗi truy vấn, tạo embedding tương ứng rồi tính cosine similarity. Kết quả thử nghiệm A/B trên 5% lưu lượng: tỷ lệ tìm kiếm trống giảm từ 18% xuống còn khoảng 6%, và tỷ lệ nhấp vào kết quả tăng 11%.
Bài học rút ra: Embedding không thay thế tìm kiếm từ khóa mà bổ sung cho nó. Người dùng tìm "iPhone 15 256GB" cần khớp chính xác model, còn người tìm mô tả mơ hồ cần khớp ngữ nghĩa. PM giỏi hiểu rằng hai cơ chế phục vụ hai loại nhu cầu khác nhau (đây chính là tiền đề cho hybrid search bạn sẽ học ở Bài 24).
Tình huống 2 — Startup EdTech và chi phí ẩn của embedding
Một startup EdTech ở TP.HCM xây trợ lý học tập, muốn cho học viên hỏi đáp dựa trên 50.000 bài giảng. Bước đầu họ cần "embed" toàn bộ kho này. Mỗi bài giảng dài trung bình 1.200 từ (~1.600 token). Với mô hình embedding của OpenAI (text-embedding-3-small, giá khoảng 0.02 USD cho 1 triệu token tại thời điểm đó), chi phí embed toàn bộ kho chỉ rơi vào khoảng 1,6 USD — rất rẻ.
Nhưng họ vấp phải hai cú sốc. Thứ nhất, mỗi lần học viên đặt câu hỏi, hệ thống lại phải embed câu hỏi đó (chi phí nhỏ nhưng nhân với hàng trăm nghìn lượt/tháng thì đáng kể). Thứ hai, khi họ muốn đổi sang mô hình embedding khác để cải thiện chất lượng tiếng Việt, họ buộc phải embed lại toàn bộ 50.000 bài — vì vector từ mô hình A và mô hình B không tương thích, không thể so sánh chéo.
Bài học rút ra: Chọn mô hình embedding là một quyết định có "chi phí chuyển đổi" cao. Một khi đã embed cả kho và lưu vào database, đổi mô hình đồng nghĩa làm lại từ đầu. PM cần cân nhắc kỹ ngay từ vòng chọn mô hình — đặc biệt với tiếng Việt, nơi chất lượng giữa các mô hình chênh nhau rõ rệt.
Tình huống 3 — Phát hiện nội dung trùng lặp ở một tòa soạn báo
Một tòa soạn online tại Việt Nam gặp vấn đề: phóng viên đôi khi đăng lại tin gần giống tin cũ, gây trùng lặp. Đội kỹ thuật dùng embedding để giải quyết: mỗi bài viết mới được embed, rồi so cosine similarity với các bài đã đăng trong 7 ngày. Nếu có bài nào đạt similarity ≥ 0.92, hệ thống cảnh báo biên tập viên "bài này rất giống bài X".
Họ phát hiện một điều thú vị khi tinh chỉnh ngưỡng: ở mức 0.85, hệ thống báo nhầm quá nhiều (hai bài cùng chủ đề thời sự nhưng khác nội dung vẫn bị gắn cờ); ở mức 0.95 thì bỏ sót các bài "xào" có sửa câu chữ. Mức 0.92 là điểm cân bằng tốt nhất sau nhiều vòng thử.
Bài học rút ra: Ngưỡng similarity không có giá trị "đúng" tuyệt đối — nó phụ thuộc vào bài toán cụ thể và phải được hiệu chỉnh bằng dữ liệu thật. Đây là quyết định sản phẩm điển hình mà PM phải dẫn dắt, không thể phó mặc hoàn toàn cho kỹ sư.
Hướng dẫn từng bước
Dưới đây là quy trình tư duy khi bạn — với vai trò PM — thiết kế một tính năng dựa trên embedding:
- Xác định "đối tượng" cần embed. Bạn đang muốn so sánh cái gì với cái gì? Câu hỏi với tài liệu? Sản phẩm với sản phẩm? Ảnh với mô tả? Định nghĩa rõ "đơn vị" được embed (một câu, một đoạn, một sản phẩm) trước khi bàn kỹ thuật.
- Chọn mô hình embedding phù hợp. Cân nhắc ba yếu tố: chất lượng (đặc biệt với tiếng Việt), số chiều (vector càng nhiều chiều càng tốn bộ nhớ và chậm hơn), và chi phí. Các lựa chọn phổ biến gồm mô hình của OpenAI, Cohere, hoặc mô hình mã nguồn mở chạy nội bộ nếu cần bảo mật dữ liệu.
- Chuẩn hóa và cắt dữ liệu (chunking). Văn bản dài cần được chia thành đoạn nhỏ vừa với giới hạn token của mô hình. Cách bạn cắt đoạn ảnh hưởng lớn đến chất lượng — cắt giữa câu sẽ làm "vỡ" ngữ nghĩa. (Chi tiết chunking sẽ học sâu hơn ở phần RAG.)
- Tạo và lưu trữ vector. Mỗi đơn vị dữ liệu được đưa qua mô hình để sinh vector, sau đó lưu lại để tái sử dụng — bạn không muốn embed lại cùng một tài liệu mỗi lần truy vấn.
- Triển khai cơ chế đo độ tương đồng. Khi có truy vấn mới, embed nó rồi tìm các vector gần nhất bằng cosine similarity. Đây là bước "tìm hàng xóm gần nhất" (nearest neighbor search).
- Định ngưỡng và đánh giá. Chạy thử trên dữ liệu thật, đo độ chính xác, tinh chỉnh ngưỡng similarity cho đến khi cân bằng giữa "bỏ sót" và "trả rác". Luôn có một tập ví dụ kiểm thử để so sánh khách quan.
Lỗi thường gặp & mẹo
Lỗi 1 — So sánh vector từ hai mô hình khác nhau. Vector của mô hình A và mô hình B sống trong hai không gian hoàn toàn riêng biệt. Cosine giữa chúng vô nghĩa. Luôn dùng cùng một mô hình để embed cả dữ liệu lưu trữ lẫn truy vấn.
Lỗi 2 — Quên rằng embedding "đóng băng" tại thời điểm tạo. Nếu nội dung tài liệu thay đổi, vector cũ không tự cập nhật. Bạn phải embed lại. Nhiều đội quên bước này và để kho vector lệch khỏi nội dung thật.
Lỗi 3 — Kỳ vọng embedding hiểu được những gì nó chưa từng học. Mô hình huấn luyện chủ yếu trên tiếng Anh thường embed tiếng Việt kém — đặc biệt với từ chuyên ngành, tên riêng, hoặc tiếng lóng. Với sản phẩm phục vụ người Việt, hãy kiểm thử kỹ chất lượng tiếng Việt thay vì tin vào điểm benchmark tiếng Anh.
Lỗi 4 — Dùng khoảng cách Euclid mà quên chuẩn hóa. Nhiều mô hình khuyến nghị cosine similarity; nếu bạn vô tình dùng độ đo khác mà không chuẩn hóa vector, kết quả có thể sai lệch. Hãy theo đúng khuyến nghị của nhà cung cấp mô hình.
Mẹo 1 — Cache embedding của truy vấn lặp lại. Nếu nhiều người dùng hỏi câu giống nhau, lưu lại vector để tiết kiệm chi phí gọi API.
Mẹo 2 — Bắt đầu với mô hình nhỏ, rẻ. Vector ít chiều thường đã đủ tốt cho nhiều bài toán, lại nhanh và rẻ hơn. Chỉ nâng cấp khi đo được rằng chất lượng chưa đạt.
Mẹo 3 — Luôn có "bộ ví dụ vàng". Chuẩn bị sẵn 20–30 cặp truy vấn–kết quả đúng để mỗi khi đổi mô hình hay ngưỡng, bạn có thước đo khách quan so sánh.
Bài tập thực hành
- Trực giác về similarity. Cho ba câu: (A) "Quán cà phê này view đẹp", (B) "Tiệm cà phê có không gian sống ảo lý tưởng", (C) "Giá điện tháng này tăng mạnh". Hãy dự đoán cặp nào có cosine similarity cao nhất và cặp nào thấp nhất, rồi viết một câu giải thích vì sao — bằng ngôn ngữ "khoảng cách ý nghĩa".
- Thiết kế tính năng. Bạn là PM của một app tuyển dụng. Hãy mô tả cách dùng embedding để gợi ý "công việc phù hợp" cho ứng viên dựa trên CV của họ. Nêu rõ: bạn embed cái gì, so sánh với cái gì, và đặt ngưỡng similarity ra sao.
- Phân tích chi phí. Một kho gồm 200.000 đoạn văn bản, mỗi đoạn ~500 token. Với giá embedding 0.02 USD/1 triệu token, hãy tính chi phí embed toàn bộ kho lần đầu. Sau đó ước tính chi phí một tháng nếu có 100.000 truy vấn, mỗi truy vấn ~50 token.
- Tình huống ra quyết định. Đội của bạn muốn đổi từ mô hình embedding hiện tại sang mô hình mới chất lượng cao hơn. Hãy liệt kê ba câu hỏi quan trọng bạn phải trả lời trước khi đồng ý, dựa trên những gì học được trong bài.
Tóm tắt
Embedding biến văn bản, hình ảnh, âm thanh thành những vector số — dãy số nhiều chiều — sao cho dữ liệu gần nghĩa nằm gần nhau trong không gian. Công cụ đo độ gần phổ biến nhất là cosine similarity, chạy từ -1 (trái nghĩa) đến 1 (gần như đồng nghĩa). Nhờ vậy, máy tính lần đầu có thể "so khớp ý nghĩa" thay vì chỉ so khớp ký tự, mở đường cho tìm kiếm ngữ nghĩa, gợi ý, phát hiện trùng lặp và RAG.
Với vai trò AI Product Manager, ba điều cần khắc cốt: (1) vector chỉ so sánh được khi đến từ cùng một mô hình; (2) chọn mô hình là quyết định có chi phí chuyển đổi cao, đặc biệt quan trọng với tiếng Việt; (3) ngưỡng similarity là quyết định sản phẩm phải hiệu chỉnh bằng dữ liệu thật, không có con số "đúng" sẵn. Nắm vững những điều này, bạn đã sẵn sàng bước vào Bài 21 về vector database — nơi ta học cách lưu trữ và truy vấn hàng triệu vector một cách hiệu quả.