DEV Community

Charles Wu for seekdb

Posted on

seekdb Core Features: Hybrid Search & AI Functions

Vector search finds “what it’s like.” Full-text search finds “what it says.” Relational filters handle “who” and “where.” With seekdb, you can combine all three in a single query and run embedding and reranking inside the database. The fusion logic (e.g., RRF) and the AI Functions API are open on GitHub (https://github.com/oceanbase/seekdb) — you can review, modify, and send PRs. This post walks through how it works and how to use it in RAG and knowledge-base setups, and how you can contribute.

1. Hybrid Search: Why One SQL Beats Multi-Stage Retrieval

The usual approach: hit a vector store, hit a full-text store, and then normalize, fuse scores (e.g., RRF), and rerank in the application layer. The catch: extra network hops, custom fusion logic, and filter conditions that can drift between systems (e.g.,“only this user’s data” has to be expressed in both stores).

seekdb’s hybrid search is different: one table has both a vector index and a full-text index. One query sends vector conditions, full-text conditions, and relational filters, and the database does the fusion and ranking. You get:

  • Consistency — Filters are defined once. No “vector side filtered, full-text side didn’t.”

  • Low-latency — No application-layer fusion hop; results are ranked inside the DB.

  • Simplicity — No glue code for multi-stage retrieval.

In SQL, you typically use DBMS_HYBRID_SEARCH.SEARCH() with full_text_query, vector_query, and optional relational filters to get relevance-ranked results. The Python SDK’s hybrid_search() supports more options (e.g., separate top_k for vector/full-text, filter expressions). Fusion is often done with RRF (Reciprocal Rank Fusion), combining vector similarity and full-text scores into one ranking.

2. How to Configure and Tune Hybrid Search

  • Schema — The table needs a VECTOR column (with a VECTOR INDEX) and text columns you want to search (with FULLTEXT INDEX). When you insert a row, both indexes are updated; no extra sync step.

  • Queries — Pass both vector (or column name + query vector) and full-text query string, and add relational filters (e.g. WHERE user_id = ?) as needed.

  • Tuning — On the vector side: top_k and similarity thresholds. On the full-text side: tokenization and match mode. When merging with RRF, watch the ratio of results from each side so one doesn’t dominate (the docs have examples and suggested ranges).

Community experience (e.g. Experience seekdb’s Hybrid Search) shows that semantic + keyword together is more reliable than vector-only or full-text-only, especially with proper nouns, numbers, and code.

3. AI Functions: Embedding, Reranking, and LLM Inside the Database

Hybrid search alone isn’t enough for RAG — you still need embedding, reranking, and an LLM. Doing all of that in the app via remote services adds latency and dependencies. seekdb’s AI Functions move part of that into the database: call in-DB embedding and rerank at write or query time, and even LLM inference and prompt handling, so the “retrieve → rerank → generate” pipeline is shorter and some logic lives in the DB.

  • Embedding — Vectorize text at write time or at query time; no need to call an external API from the app before writing.

  • Reranking— Rerank hybrid search results with a model inside the DB, cutting down app-layer round-trips.

  • LLM / Prompt — Run simple inference or prompt templates in the DB for rule-heavy flows; keep complex chat in your application LLM.

Compared with “everything via external services”: in-DB AI reduces network hops and centralizes permissions and config; it fits when you care about latency and privacy and are fine using seekdb’s built-in or configured models. If you’re already tied to external embedding/LLM services, you can keep them and use seekdb purely as the retrieval layer.

For details and configuration, see seekdb docs.

4. Summary: What You Gain

Once you’re comfortable with these, the next step is RAG and knowledge bases: use seekdb for storage and retrieval, and Dify or your own front end for chat and workflows. The next post will cover getting started with building RAG and a knowledge base using seekdb and Dify.

If you or your team are building an AI application/workflow— what do you expect from a database? Let’s chat in the comments.

Our team is building some cool new features, and we might just solve your pain points. Open source is about collaboration — share your challenges and let’s build better together!

Top comments (0)