Full-text search quay lại — và đây không phải bước lùi

Pinecone vừa tích hợp full-text search cạnh vector search trong cùng một index. Đằng sau tính năng mới là thừa nhận quan trọng: embedding alone chưa bao giờ đủ cho production retrieval.

Ba năm trước, câu chuyện retrieval trong AI gần như chỉ xoay quanh một từ: embedding. Team nào cũng rush embed mọi thứ thành vector, rồi semantic search là xong. Nhưng tuần này Pinecone — nền tảng chuyên vector database — lại ship full-text search (tìm kiếm toàn văn dựa trên keyword) như một tính năng first-class. Một vector database thêm keyword search nghe giống bước lùi, nhưng thực tế thì ngược lại hoàn toàn.

Chuyện gì đang xảy ra phía sau tấm màn

Pinecone vừa đưa full-text search vào public preview với bộ feature khá đầy đủ: BM25 scoring (thuật toán xếp hạng dựa trên tần suất từ), Lucene query syntax, tokenization hỗ trợ 18 ngôn ngữ, stemming (rút gọn từ về gốc), stop-word removal, và phrase matching.

Điểm đáng chú ý: tất cả nằm trong cùng một index với dense vector, sparse vector, và metadata. Không phải hai hệ thống chạy song song rồi merge kết quả bên ngoài.

Trước đây Pinecone đã hỗ trợ sparse index — nhưng developer phải tự lo tokenization, tự tính weight, tự duy trì word count. Nói cách khác, bạn có sân khấu nhưng phải tự kéo phông, tự dựng đạo cụ, tự chạy đèn. Giờ Pinecone đóng gói toàn bộ phần hậu trường đó vào một API duy nhất.

Họ tích hợp thư viện Tantivy (engine full-text search viết bằng Rust, cùng họ với Lucene nhưng nhẹ hơn) chạy song song cùng vector engine. Kiến trúc cho phép text match filter chạy trước, thu hẹp tập ứng viên, rồi mới đến vector ranking — thay vì hai pipeline riêng biệt phải reconcile.

Mổ xẻ: tại sao builder nên quan tâm đến kiến trúc single-index

Nhiều team ở Việt Nam đang chạy stack kiểu: Elasticsearch cho keyword search + Pinecone (hoặc Qdrant, Weaviate) cho semantic search + một layer code bên ngoài để merge và re-rank kết quả từ cả hai.

Stack này hoạt động, nhưng chi phí vận hành không nhỏ:

• Hai hệ thống cần sync data, hai bộ index cần maintain
• Logic merge results nằm trong application code — mỗi lần thay đổi ranking strategy phải deploy lại
• Debugging khi retrieval sai trở nên phức tạp: lỗi ở embedding? Ở keyword matching? Hay ở layer merge?

Kiến trúc single-index giải quyết gọn vấn đề operational này. Một schema định nghĩa text fields (title, body, tags — mỗi field scoring độc lập), dense vectors, sparse vectors, và metadata filterable. Một query duy nhất kết hợp cả keyword lẫn semantic.

Ví dụ thực tế 1: Giả sử team bạn 4 người đang build chatbot hỗ trợ khách hàng cho một sàn thương mại điện tử. Khách hỏi "đơn hàng VN2024-88712 ở đâu rồi?" — embedding sẽ hiểu ý định là hỏi tracking, nhưng không match chính xác mã đơn. Keyword search match đúng mã đơn ngay lập tức. Trong single-index, bạn viết một query duy nhất: text filter trên order_id field + semantic search trên nội dung hội thoại.

Ví dụ thực tế 2: Team đang xây coding agent cần tìm lỗi trong log. Agent muốn tìm các interaction chứa cụm "timeout exceeded" nhưng loại trừ những cái đã tag "resolved" — đồng thời rank theo semantic similarity với mô tả bug hiện tại. Trước đây cần orchestrate hai hệ thống. Giờ là một API call.

Điều đáng giữ lại cho stack của bạn

1. Multi-field schema thay đổi cách nghĩ về indexing

Thay vì nhồi mọi text vào một field rồi embed, bạn tách title, body, metadata thành các text fields riêng. Mỗi field có language setting riêng (ảnh hưởng stemming và tokenization). Điều này quen thuộc với ai từng dùng Elasticsearch, nhưng bây giờ nó sống cạnh vector search mà không cần cluster riêng.

2. Text match filter chạy trước vector ranking

Ba mode: exact phrase, all tokens, any token. Filter thu hẹp candidate set trước khi vector scoring chạy. Với dataset lớn, điều này cải thiện cả tốc độ lẫn precision — vì vector search không phải quét toàn bộ corpus.

3. Agent-friendly query composition

Lucene syntax cho phép agent tự compose query phức tạp: boolean logic, phrase matching, field-specific search. Agent không cần nhiều tool calls riêng lẻ — một structured query là đủ.

Điều nên bỏ qua

Đừng vội thay Elasticsearch chỉ vì Pinecone giờ có FTS.

Nếu workload của bạn 80% là keyword search thuần (logging, analytics, full-text trên corpus lớn không cần semantic), Elasticsearch hay OpenSearch vẫn mature hơn nhiều. Pinecone FTS hợp lý nhất khi bạn đã dùng vector search và cần bổ sung keyword precision — không phải ngược lại.

Đừng nghĩ đây là tính năng chỉ Pinecone có.

Weaviate đã có hybrid search (BM25 + vector) từ lâu. Qdrant cũng hỗ trợ full-text filter. Milvus có keyword index. Nếu đang self-host với một trong các open-source alternatives này, bạn không bắt buộc phải migrate. Giá trị của Pinecone nằm ở managed service và single-API simplicity — không phải ở tính năng exclusive.

Đừng mặc định hybrid là luôn tốt hơn.

Hybrid search thêm complexity vào ranking. Nếu use case của bạn đơn giản (semantic search trên corpus đồng nhất, ít exact-match requirement), thêm keyword scoring có thể gây noise thay vì cải thiện. Hãy đo trước khi bật.

Quyết định cho builder tuần này

Nếu bạn đang maintain hai hệ thống riêng cho keyword và semantic search:

1. Đánh giá bao nhiêu phần trăm query thực sự cần hybrid (không phải "có thì tốt" mà là "thiếu thì sai kết quả")
2. Nếu trên 30% — single-index architecture đáng thử nghiệm, dù Pinecone hay Weaviate hay Qdrant
3. Nếu dưới 30% — hai hệ thống riêng có thể vẫn hợp lý hơn về chi phí

Điều quan trọng không phải Pinecone vừa ship gì. Điều quan trọng là cả ngành đang thừa nhận: vector search không phải vở diễn chính duy nhất — nó cần keyword search đứng cùng sân khấu, dưới cùng ánh đèn, để retrieval thực sự hoạt động trong production.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng