slorg vs Algolia vs Meilisearch vs Typesense: Deliberative vs Traditional Search

The problem

Traditional search retrieves documents that match the query and then ranks them. For ambiguous or complex queries, this gives mediocre results because the engine doesn’t know what the user actually wants.

Deliberative search (or agentic search) uses a language model to reason about the query intent first, then issues targeted retrievals. For complex queries, this dramatically improves precision.

slorg is Skelf’s deliberative search engine. This post is the comparison we wish we had when we started slorg.

What slorg is

slorg is a SvelteKit-based search engine that implements deliberative search. The flow:

1. User submits a query.
2. A small language model interprets the query, generating a structured understanding of intent.
3. slorg issues targeted retrievals based on the interpreted intent (not just keyword match).
4. A second model synthesises the retrieved results into an answer with citations.
5. The user sees the answer, with links to the sources.

The key design choice: the LLM reasons before retrieving, not after. This is what “deliberative” means.

What each option is

slorg is a deliberative search engine for web and document corpora. SvelteKit, Svelte 5 runes, with on-device LLM option via llamafu.

Algolia is the de-facto hosted search-as-a-service. Strong on typo tolerance, ranking, and faceting. The default for “search on a website.”

Meilisearch is the open-source, lightweight, self-hostable search engine. Fast, easy to deploy, with a good default ranking. The de-facto open-source choice for typical search workloads.

Typesense is the open-source, typo-tolerant search engine. Similar to Meilisearch in scope; focuses on instant search. The right choice for autocomplete and type-as-you-search.

Elasticsearch + LLM is the heavyweight option. Powerful but operationally complex. The right choice for log analytics + search.

The five dimensions

Dimension	slorg	Algolia	Meilisearch	Typesense	Elasticsearch + LLM
Architecture	Deliberative (LLM-first)	Traditional (retrieval-first)	Traditional	Traditional	Traditional + post-processing
Reasoning	Yes (LLM)	No	No	No	DIY
Typo tolerance	Yes (via the LLM)	Yes (built in)	Yes (built in)	Yes (built in)	Yes (configurable)
Faceting	Yes (via structured intent)	Yes (rich)	Yes	Yes	Yes (rich)
Self-hostable	Yes	No	Yes	Yes	Yes
Operational complexity	Medium (SvelteKit + LLM)	None (managed)	Low	Low	High
Cost	Free (self-host) + LLM cost	Pay-per-query	Free (self-host)	Free (self-host)	Free (self-host) + ops cost
Best for	Ambiguous, complex queries	General website search	General search	Type-as-you-search	Log analytics + search
License	MIT	Proprietary	MIT	GPL-3.0	Apache-2.0 (mostly)

When to use which

Use slorg when:

• The queries are ambiguous and require understanding intent before retrieving.
• You are building a Q&A interface over a document corpus (internal docs, knowledge base, etc.).
• You are willing to pay the LLM cost for better precision.
• You want citations in the answer.

Use Algolia when:

• You have a general website search need and want zero operational complexity.
• You are willing to pay for the service.
• The queries are typical (keyword-based).

Use Meilisearch when:

• You want the open-source, self-hostable, lightweight default.
• You don’t need LLM reasoning.

Use Typesense when:

• You need type-as-you-search (autocomplete).
• You want a small, fast, focused engine.

Use Elasticsearch + LLM when:

• You need log analytics + search.
• You have the operational team to manage it.

A concrete example: corporate knowledge base

Imagine a 10,000-document internal knowledge base. Users ask questions like “How do I expense a client dinner?” or “What’s the policy on remote work from abroad?”

With slorg:

1. The query “How do I expense a client dinner?” is interpreted: intent = “expense policy”, entities = {“client_dinner”: true}, topic = “finance”.
2. slorg issues targeted retrievals to the expense-policy section, scoped to “client entertainment” subcategory.
3. The synthesised answer: “Client dinners are expensible up to £100 per person with manager approval. See [link to policy]. The reimbursement form is at [link].”
4. Citations: the policy and the form are linked.

With Algolia / Meilisearch:

1. The query is matched against the index by keyword.
2. Top results: the “Expense Policy” doc, the “Travel Policy” doc, the “Remote Work Policy” doc.
3. The user picks the right one and reads it.

The slorg experience is one click faster (no result-list scanning) and more accurate (the answer is synthesised, not retrieved). The Algolia experience is simpler to implement.

The cost of deliberative search

slorg is more expensive than traditional search: every query costs an LLM call (or several) plus the retrieval. For a search-as-you-type interface, this is prohibitive. For a Q&A interface, it’s the right trade-off.

A hybrid approach: use a traditional search engine for the “type and find” interface, and slorg for the “ask a question” interface. Both can share the same underlying index.

A 10-minute slorg eval

# Install
npm install -g slorg

# Ingest a corpus
slorg ingest --dir ./docs --format markdown

# Query
slorg query "How do I expense a client dinner?"
# Returns: synthesised answer with citations

# Or start the dev server
slorg dev --bind 0.0.0.0:5173
# → open http://localhost:5173

The SvelteKit UI is built in; you can customise the LLM choice (Claude, GPT-4o, local llamafu, etc.) via environment variables.

What to read next

• Deliberative Search: When the Engine Reasons Before It Retrieves — the full slorg architecture
• Running Language Models on Your Phone: The llamafu Experiment — the on-device LLM option
• slorg repository
• Algolia
• Meilisearch
• Typesense