Tìm kiếm bằng từ khoá thất bại ở đúng một chỗ mà con người lại làm rất tự nhiên: khi người hỏi và tài liệu dùng những từ khác nhau cho cùng một ý. Gõ "xe hơi tiết kiệm xăng" vào một công cụ tìm từ khoá, và nó sẽ bỏ sót một bài viết hay nói về "ô tô ít hao nhiên liệu" — dù đó chính xác là thứ bạn cần, chỉ vì không có từ nào trùng nhau. Embedding sinh ra để vượt qua đúng rào cản này, và nó là nền móng lặng lẽ của gần như mọi hệ thống RAG.
Ý tưởng cốt lõi

Một mô hình embedding biến mỗi đoạn văn bản thành một vector — một dãy vài trăm tới vài nghìn con số. Bản thân dãy số đó vô nghĩa với mắt người, nhưng điều kỳ diệu nằm ở quan hệ giữa chúng: hai đoạn có ý nghĩa gần nhau sẽ cho ra hai vector nằm gần nhau trong không gian nhiều chiều đó, dù chúng không chia sẻ một từ nào. "Xe hơi tiết kiệm xăng" và "ô tô ít hao nhiên liệu" rơi vào cùng một vùng; "công thức nấu phở" rơi ở một góc trời khác. Ý nghĩa được biến thành vị trí.
Để đo hai vector gần nhau đến đâu, cách phổ biến nhất là tính cosin của góc giữa chúng: bằng 1 nghĩa là cùng hướng — gần nghĩa nhất; bằng 0 nghĩa là vuông góc — không liên quan. Tìm tài liệu liên quan giờ trở thành một bài toán hình học: tìm những vector có cosin lớn nhất với vector của câu hỏi.
Quy trình một hệ RAG điển hình

Ghép các mảnh lại, một hệ RAG chạy theo bốn bước: cắt tài liệu thành những đoạn vừa phải — thường vài trăm từ, có phần gối lên nhau để không mất mạch ở ranh giới; tính embedding cho từng đoạn và lưu vào một cơ sở dữ liệu vector; khi có câu hỏi, tính embedding của câu hỏi rồi tìm các đoạn có vector gần nhất; cuối cùng đưa những đoạn đó kèm câu hỏi cho mô hình ngôn ngữ để nó soạn câu trả lời dựa trên tài liệu thật thay vì trí nhớ mờ.
Chỗ hay hỏng trong thực tế
Cắt đoạn sai chỗ. Đây là lỗi âm thầm và phổ biến nhất. Cắt giữa một câu, hoặc tách một bảng số liệu khỏi cái tiêu đề giải thích nó, làm đoạn văn mất ngữ cảnh — và một đoạn mất ngữ cảnh sinh ra một embedding vô nghĩa, không nằm gần bất cứ câu hỏi hợp lý nào. Nên cắt theo ranh giới tự nhiên: đề mục, đoạn, mục danh sách, chứ không theo số ký tự đếm được.
Chỉ dựa vào ngữ nghĩa. Embedding mạnh ở sự gần nghĩa, nhưng chính vì thế nó yếu ở những thứ cần khớp chính xác: mã lỗi, tên riêng, mã sản phẩm. Với "lỗi E-404" hay "model XPS-9310", tìm kiếm từ khoá truyền thống vẫn chính xác hơn hẳn, vì ở đây ý nghĩa nằm ở ký tự khớp đúng chứ không ở sự tương tự. Kết hợp cả hai kiểu tìm rồi xếp hạng lại cho kết quả tốt hơn nhiều so với dùng một mình embedding.
Lấy quá nhiều đoạn. Có một cám dỗ tự nhiên: cứ nhồi thật nhiều đoạn vào cho chắc. Nhưng nhồi hai mươi đoạn vào ngữ cảnh thường làm câu trả lời tệ đi, vì thông tin đúng bị chôn giữa mười chín đoạn nhiễu, và mô hình loãng chú ý. Ít mà đúng thắng nhiều mà tạp.
Sợi chỉ xuyên suốt cả ba lỗi, và cũng là bài học quan trọng nhất: chất lượng của RAG phụ thuộc vào khâu tìm kiếm nhiều hơn khâu sinh văn bản. Nếu bước tìm không lấy được đúng đoạn chứa câu trả lời, thì mô hình ngôn ngữ giỏi đến mấy cũng đành chịu — nó không thể trích dẫn thứ nó chưa từng được đưa. Đầu tư vào embedding tốt, cắt đoạn khéo, và tìm kiếm lai thường trả lại nhiều hơn là đổi sang một mô hình sinh đắt tiền hơn.
Thảo luận