Search-as-a-Service

Managed full-text and vector search with relevance tuning

View the interactive project page →

Search-as-a-Service

Part of the worlds-biggest-software-project initiative.

Managed full-text and vector search with relevance tuning, delivered as an AI-native open-source platform.

Search-as-a-Service is a managed search platform that handles full-text (lexical), vector (semantic), and hybrid retrieval behind a single API. It is aimed at product teams who need production-grade search and RAG retrieval but do not have the in-house expertise to operate inverted indexes, ANN structures, and embedding pipelines themselves.


Why Search-as-a-Service?

  • Building production search requires inverted indexes, tokenisation, stemming, ANN tuning, and embedding synchronisation — specialist skills most product teams lack.
  • The 2025–2026 rise of retrieval-augmented generation (RAG) has forced even keyword-focused applications to add vector search, doubling the operational burden.
  • Incumbent SaaS options are proprietary (Algolia, Azure AI Search, Amazon OpenSearch Serverless) or carry restrictive licences (Elasticsearch under Elastic Licence + SSPL, Weaviate under BSL, ParadeDB under Elastic Licence, Typesense under AGPL v3).
  • Existing platforms expose few cost-prediction tools, no document-to-searchable latency SLAs, and limited transparency into hybrid ranking — gaps the research identifies as genuine differentiation opportunities.
  • Hybrid search using Reciprocal Rank Fusion has become the dominant 2026 pattern, but custom fusion logic, learned-to-rank, and relevance explanation remain underserved.

Key Features

Core Retrieval

  • Full-text search with BM25 scoring
  • Vector search with approximate nearest-neighbour (ANN) indexing for dense embeddings
  • Hybrid search combining lexical and vector results via Reciprocal Rank Fusion (RRF)
  • Typo tolerance with configurable thresholds
  • Sub-second query latency at scale

Indexing & Ingestion

  • Near-real-time document ingestion
  • Multi-field indexing with per-field boosting
  • Automatic embedding generation with pluggable models
  • Filtering and faceting for navigation

Relevance Tuning

  • Field weighting and ranking rules
  • Query-time parameter configuration without reindexing
  • Weighted RRF for tuning lexical-vs-vector contribution
  • Semantic ranking as an L2 reranking step over initial results
  • A/B testing framework for relevance experiments

AI & Semantic Capabilities

  • Sparse vector search (ELSER-like) without external ML infrastructure
  • Intent detection that converts natural-language queries into filters and sorts
  • Optional RAG integration with built-in generative search
  • Multi-vector support: multiple embeddings per document

Operations & Integration

  • REST API and SDKs for JavaScript and Python at MVP, expanding from there
  • Multi-tenancy with per-tenant index isolation
  • Basic analytics dashboard covering queries, latency, and errors
  • CloudWatch / Prometheus integration for observability

AI-Native Advantage

Where incumbents rely on manually configured ranking rules, synonym lists, and field weights, this project treats relevance as a learning problem: ML-driven inference of optimal field weights and lexical-vs-vector ratios from query logs, LLM-powered synonym discovery and intent classification, and natural-language explanation of why each result ranked where it did. AI is also applied to operations — predicting query cost, suggesting cheaper retrieval strategies (sparse vs dense), and recommending embedding models for a given workload.


Tech Stack & Deployment

The platform is designed for self-hosted and managed cloud deployment, with a REST API and SDKs as the primary integration surface. Hybrid retrieval uses RRF (published 2003, patent-free) for fusion, with optional weighted variants. Sparse-vector retrieval follows the ELSER pattern so customers do not need external GPU inference. Embedding model choice is pluggable, supporting both hosted providers (OpenAI, Cohere) and local models from Hugging Face. A PostgreSQL-native deployment mode (akin to ParadeDB's BM25 + pgvector approach) is on the backlog for teams that prefer search colocated with their primary database.


Market Context

The search-as-a-service market spans proprietary SaaS (Algolia, Azure AI Search, Amazon OpenSearch Serverless), commercial open source (Elasticsearch, Weaviate, ParadeDB, Typesense), and permissively licensed open source (Meilisearch under MIT). Candidate-projects.md scores this project at complexity 7, with High domain availability and High demand. Primary buyers are product engineering teams adding search or RAG retrieval to applications, and platform teams consolidating multiple search backends behind one managed service.


Project Status

This project is in the research and specification phase.
Contributions, feedback, and domain expertise are welcome.


Contributing

We welcome contributions from developers, domain experts, and potential users. See CONTRIBUTING.md for guidelines.

Important: All contributions must be your own original work or clearly attributed open-source material with a compatible licence. Copyright infringement and licence violations will not be tolerated and will result in immediate removal of the offending contribution. If you are unsure whether a piece of code, text, or other material is safe to contribute, open an issue and ask before submitting.


Licence

Licence to be determined. See discussion for context.