On-device semantic, keyword, query-time hybrid
On-device semantic search for edge AI
RetrievalKit runs semantic search inside your app by ranking caller-provided embeddings with exact vector similarity. The same local retrieval SDK can run BM25 keyword search or combine text and embeddings through query-time hybrid ranking over a small, app-owned index.
Responsibilities
What RetrievalKit handles—and what your app supplies.
How on-device semantic search works
Your application turns records and queries into embeddings, then RetrievalKit compares those vectors exactly inside the local process. Semantic search finds passages by meaning rather than requiring the same words, while stable ordering and trace data keep the result inspectable.
The index stays loaded before search, and the Rust core owns filtering, ranking, stable ordering, persistence on native targets, and generation validation. Language wrappers expose the same semantics through native API styles.
Hybrid search combines meaning and exact terms
Embedding-only queries run semantic vector search. Text-only queries run BM25. Supplying both text and an embedding lets query-time alpha combine their scores, so conceptual matches and exact terminology can contribute to one ranked result.
BM25 is a query variation, not a separate database architecture. Filters remain eligibility constraints rather than hidden score signals, and the detailed result trace exposes the vector rank, keyword rank, and matched terms.
Embeddings remain an explicit dependency
The retrieval database does not silently download, select, or call an embedding model. Your application can provide embeddings, or it can use one of RetrievalKit's independent optional embedding packages where that package is supported.
That separation makes the privacy boundary inspectable. If an application sends source text to a remote embedding service, that embedding step is not private even though indexing and search still happen locally.
Exact search is deliberate at the V1 scale
V1 targets small local indexes from 1K to fewer than 50K chunks, commonly with 384- or 768-dimensional vectors and top_k values around 5-10. At that scale, exact search keeps behavior deterministic and avoids the tuning and recall tradeoffs of an approximate index.
HNSW and other ANN indexes are deferred until exact and hybrid retrieval are polished and benchmarked. Their absence is a product boundary, not an invitation to treat RetrievalKit as a hosted vector database.
What edge device retrieval means for RetrievalKit
Edge device retrieval means the index and ranker run inside the end-user application on a qualified target rather than behind a remote retrieval service. In v0.1.0, that boundary follows the published Swift, macOS, browser, and Android packaging records instead of implying universal embedded-device support.
Robotics, IoT hardware, Linux, Windows, and physical mobile browsers are not qualified by this phrase. Check the release evidence for the exact package, runtime, and device status before treating publication as a platform guarantee.
Choose the wrapper that belongs in your app
The v0.1.0 preview publishes native Swift, Node.js, Kotlin/JVM, Android packaging, Python, and dedicated browser Worker packages. Platform qualification is intentionally narrower than package names alone suggest, so check the support record before selecting a target.
- Use base retrieval when a flat local corpus is enough.
- Use the graph aggregate when you also need graph-only or graph-scoped search.
- Add an embedding package independently; graph already includes base retrieval.