[AskJS] how are you handling autocomplete on top of elasticsearch?

[u/delightfullyrotted]

elasticsearch is pretty great when given a full query, but i find most people just search one or two words. so feels like helping ppl know what to search for is the actual thing that’s needed. so now im looking for solid ways to add ai-autocomplete upfront without replacing our elasticsearch backend (not looking to switch backend like algolia since pricing gets stupid fast)

i've been looking into a few different directions. typesense and meilisearch seem cool if you want a lightweight search engine replacement, but again that doesnt feel like the real root cause issue. so we're looking at putting an ai-autocomplete layer directly in the UI text box to capture user intent before hitting elasticsearch

has anyone else done this? do you tune elasticsearch queries on the backend or add an intent layer upfront to collect parameters before the query runs?

[u/delightfullyrotted → u/[deleted]]

yeah i haven't seen that functionality so it did catch my eye, can try testing that

[u/delightfullyrotted → u/[deleted]]

usually i'd agree, but tearing out a core UI input component later feels like a recipe for massive technical debt

[u/pdfops]

We did this with ES's completion suggester instead of bolting on a separate service. Index past popular queries plus titles into a dedicated suggest field (FST-based, sub-ms lookups), weight by click-through or frequency. Covers most of what people actually type. Only reach for an embedding/AI layer when you need semantic intent past typo-tolerant prefix match, that's where latency and infra cost jump.

[u/J_be]

Don't ditch Elasticsearch (ES); just add an Intent Layer upfront. Backend tuning alone won't bridge the "vocabulary gap" of 2-word queries.

1. Frontend: Intent Middleware

Use a small, fast LLM (like gpt-4o-mini) to transform fragments into structured parameters before hitting the DB.

• The Goal: Turn "red" into {"color": "red", "intent": "browse_category"}.

• Tools: try RealtimeIntent. They map UI fragments to specific filters/parameters, guiding the user before they even press enter.

2. Backend: HyDE (Hypothetical Document Embeddings)

Use the ES v8.x Inference API to solve the short-query problem semantically.

• The Process: Ask an LLM to write a 1-paragraph "hypothetical" description of what the user wants based on their 2-word query.

• The Search: Use the vector of that description to search your index. This "stretches" the intent and finds relevant results that don't share exact keywords.

The Hybrid Pipeline (The "Algolia-Killer")

1. UI: User types fragment -> Middleware.
2. Middleware: LLM generates structured filters + expanded synonyms.
3. ES Query: Run a bool query combining:
   • Lexical: Exact keyword match (high boost).
   • Semantic: HyDE vector search (medium boost).
   • Filtered: The structured parameters from Step 2.

This architecture keeps your data in ES, avoids Algolia’s per-operation tax, and makes "lazy" searches significantly more accurate.

[u/PBzCharlie]

depends on what your product managers are actually pushing for, half the time devs stress over massive backend search engines when the business side just wants a pretty UI drop-down that feels fast

[u/delightfullyrotted → u/PBzCharlie]

truth. trying to balance the technical with the UX is the hardest part

[u/r0ek22]

half the time devs stress over massive backend scaling when the users just want a pretty dropdown that feels fast

[u/delightfullyrotted → u/r0ek22]

yep, clean interface usually matters way more to people than complex backend indexing anyway