RAG đơn giản hơn bạn nghĩ: Đừng phức tạp hóa hệ thống tìm kiếm

Chào các bạn, tôi là Rafael đây - mỗi tuần tôi đều chia sẻ về những thách thức và sự phát triển thú vị mà tôi bắt gặp dưới góc nhìn của một kỹ sư xây dựng các hệ thống AI.

Hãy đăng ký để nhận những bài viết hàng tuần của tôi 👇

Ngày nay, hầu hết mọi người dường như đang làm quá phức tạp hóa RAG stack của mình. Họ nhảy thẳng vào embeddings, vector databases và các reranking pipeline. Trong khi đó, người dùng của họ chỉ đơn giản muốn tìm tài liệu có nội dung “Làm thế nào để đặt lại mật khẩu của tôi.”

Trong kỹ thuật, luôn có công cụ phù hợp cho từng vấn đề cụ thể. Trong các hệ thống AI Retrieval, điều này cũng không ngoại lệ.

Trước khi đi sâu vào các công thức, hãy xác định khi nào bạn nên sử dụng từng phương pháp. Các yếu tố then chốt bao gồm:

1. Yêu cầu về độ mới của dữ liệu - Các cập nhật theo thời gian thực (tin tức, mạng xã hội) ưu tiên những phương pháp dễ dàng lập chỉ mục lại (re-indexing). Các cập nhật hàng ngày hoặc hàng tuần hoạt động tốt với các phương pháp lai (hybrid). Một kho dữ liệu ổn định (cập nhật hàng tháng hoặc hàng quý) sẽ khiến việc pre-embedding trở nên hợp lý.

2. Đặc điểm của kho dữ liệu - Tỷ lệ thay đổi cao (hơn 10% mỗi ngày) đồng nghĩa với việc bạn nên tránh pre-embedding toàn bộ. Các tài liệu ổn định hoạt động tốt với pre-embedding. Phân phối đuôi dài (90% không bao giờ được truy cập) có nghĩa là phương pháp on-the-fly sẽ chiếm ưu thế.

3. Mô hình truy vấn - Các truy vấn nặng về từ khóa nên bắt đầu bằng tìm kiếm toàn văn (full-text search). Các truy vấn ngữ nghĩa hoặc hội thoại sẽ hưởng lợi từ embeddings. Các mô hình hỗn hợp cần đến các phương pháp lai.

4. Quy mô & Hiệu năng - Dưới 1000 truy vấn mỗi ngày thì các phương pháp đơn giản là đủ dùng. Từ 1K đến 10K truy vấn mỗi ngày đòi hỏi sự tối ưu hóa có chọn lọc. Hơn 10K truy vấn mỗi ngày mới cần đến sự tối ưu hóa toàn diện.

5. Năng lực của đội ngũ - Không có chuyên môn về ML thì hãy gắn bó với full-text kết hợp viết lại truy vấn (query rewriting). Có một chút kinh nghiệm về ML sẽ giúp việc quản lý hybrid search trở nên khả thi. Có sẵn một đội ngũ ML sẽ giúp các phương pháp nâng cao trở nên khả thi.

Bây giờ, hãy xem qua cuốn sách công thức. Hãy bắt đầu từ trên xuống dưới. Chỉ di chuyển xuống dưới khi bạn có dữ liệu chứng minh rằng mình cần làm vậy.

BM25 truyền thống. Elasticsearch. Postgres full-text search. Những thứ đã tồn tại trước khi “embedding” trở thành một động từ.

Bạn chỉ mới bắt đầu. Người dùng của bạn viết các truy vấn kiểu từ khóa (”pandas merge dataframe”). Khớp chính xác là rất quan trọng (”hóa đơn #12345”). Bạn muốn độ phức tạp về ML bằng không. Kho dữ liệu của bạn có các thuật ngữ độc quyền (sẽ nói thêm về điều này sau).

Chi phí API bằng không. Nhanh (dưới 10ms). Dễ gỡ lỗi (bạn có thể thấy chính xác lý do tại sao một tài liệu khớp). Hiệu quả đến bất ngờ (xử lý được nhiều trường hợp sử dụng). Không cần chiến lược chunking – hoạt động với toàn bộ tài liệu. Không phức tạp về đánh giá – dễ kiểm thử và xác thực. Không có rủi ro lỗi thời của mô hình (BM25 không thay đổi).

Bỏ lỡ các từ đồng nghĩa (”car” so với “automobile”). Thất bại với các truy vấn ngữ nghĩa (”Làm thế nào để...?”). Không thể hiểu ý định ngoài các từ khóa.

Theo kinh nghiệm của tôi, cách này xử lý được một phần đáng kể các trường hợp sử dụng. Đừng bỏ qua bước này. Bạn có thể sẽ ngạc nhiên về những gì mình đạt được.

Khi bạn nhảy thẳng vào embeddings, bạn sẽ ngay lập tức đối mặt với các câu hỏi như: Kích thước chunk là bao nhiêu? (512 tokens? 1024?) Độ chồng lấp (overlap) là bao nhiêu? (50 tokens? 100?) Semantic chunking hay kích thước cố định? Làm sao để đánh giá chunking của tôi có tốt không?

Với full-text search, bạn bỏ qua tất cả những điều này. Tài liệu của bạn vẫn là tài liệu của bạn. Tìm kiếm chỉ đơn giản là hoạt động.

Cảm ơn bạn đã đọc Lighthouse AI! Bài viết này là công khai nên hãy thoải mái chia sẻ nó.

Chia sẻ

Sử dụng LLM để chuyển đổi các truy vấn lộn xộn của người dùng thành các truy vấn từ khóa sạch sẽ.

Hầu hết các vấn đề về “semantic search” thực chất là vấn đề về cách đặt câu hỏi (query formulation).

Người dùng đặt câu hỏi theo kiểu hội thoại. Sự không khớp về từ vựng (người dùng nói “fix bugs”, tài liệu nói “debugging”). Bạn có thuật ngữ nội bộ (framework của bạn tên là “Atlas”). Bạn muốn sự linh hoạt để lặp lại nhanh chóng các chiến lược truy vấn.

~$0.001 mỗi truy vấn (sử dụng GPT-4o-mini để viết lại truy vấn)

Một LLM có thể loại bỏ các từ dừng (stopwords) (”how do I” trở thành không có gì). Nó có thể thêm từ đồng nghĩa (”car” trở thành “car automobile vehicle”). Nó có thể dịch các thuật ngữ chuyên ngành (”speed up code” trở thành “optimize performance”). Nó có thể phân tách các truy vấn phức tạp (”read CSV and plot” trở thành [”read CSV”, “plot data”]). Nó có thể học từ bảng thuật ngữ của bạn (thông qua system prompt).

Với embeddings, nếu kết quả không tốt, bạn cần điều chỉnh chiến lược chunking, nhúng lại toàn bộ kho dữ liệu, chạy các bài kiểm tra hồi quy trên tập đánh giá của mình và hy vọng nó cải thiện.

Với query rewriting, nếu kết quả không tốt, bạn chỉ cần điều chỉnh system prompt. Thế thôi. Kiểm thử ngay lập tức.

Thậm chí tốt hơn, bạn có thể tạo một vòng lặp:

Tác nhân (agent) có thể lặp lại, học hỏi và thích nghi – tất cả mà không cần nhúng lại bất cứ thứ gì.

Giả sử công ty bạn có một framework Python tên là “Atlas.” Nếu bạn sử dụng các embeddings mục đích chung:

Mô hình không hề biết “Atlas” của bạn tồn tại. Nó quay lại với những gì đã học trong quá trình đào tạo. Nhưng với query rewriting:

Đối với các thuật ngữ độc quyền, khớp từ khóa chính xác sẽ vượt trội hơn so với hiểu biết ngữ nghĩa.

Sử dụng BM25 để lấy các ứng viên (top 50-100), sau đó rerank bằng embeddings (top 10).

BM25 nhanh và tuyệt vời trong việc khớp từ khóa. Embeddings giỏi trong việc hiểu ngữ nghĩa. Cùng nhau, chúng bù đắp những điểm yếu của nhau.

Người dùng đặt các câu hỏi ngữ nghĩa (”tìm các lựa chọn thay thế cho X”). BM25 cộng với query rewriting đơn thuần là không đủ (bạn có dữ liệu chứng minh điều này). Bạn có thể chấp nhận độ trễ 100-500ms. Kho dữ liệu của bạn tương đối ổn định (không thay đổi mỗi phút).

Hãy làm phép tính với bảng giá hiện tại (OpenAI text-embedding-3-small với giá $0.02 cho mỗi 1 triệu tokens):