Skip to content

Experiment: hybrid (semantic + keyword) retrieval for the livesearch suggestions #127

Description

@reekitconcept

Agreed on the intranet ticket 570 review call (2026-09-08): worth trying as a separate experiment, decided on results — not part of the current alpha stream.

Question

@solr-suggest is pure keyword/ngram today (suggest, suggest_ngram, searchwords fields). @rag-search already does hybrid retrieval (knn vector + BM25, RRF-fused). Should the suggestions also use the hybrid retrieval, so that all three searches (results / suggestions / AI) rank consistently and semantic matches surface while typing?

Why it's cheap to try

All the pieces exist in rag/pipeline.py: embed_query, search_chunks (permission-trimmed, honors path_prefix and extra_conditions), parent_ranking, rrf_fuse. Roughly 1–2 days plus tuning.

Known concerns (to be answered by the experiment)

  • Hot path: suggest fires per (debounced) keystroke; each hybrid call needs an embedding round-trip (latency; and each LLM call occupies a backend worker thread — at keystroke frequency, far more load than per-question RAG).
  • Partial words embed uselessly: typing vaca should complete to vacation (the ngram fields' job), not find semantically-near content of an unfinished word.
  • Explainability: semantic hits can share no text with the query — highlighting breaks, users ask "why is this suggested?".
  • Availability: suggest must keep working with the LLM stack down → silent keyword-only fallback required.

Experiment shape (proposal)

  • knn leg only for complete-looking queries (multi-word, or trailing space); prefixes stay ngram-only.
  • Debounce ≥300 ms; hard embedding budget (~150 ms) with silent keyword-only fallback; per-query-string embedding cache.
  • UI idea (David): keyword suggestions by default, plus an explicit "semantic" toggle/button once the full query is typed.
  • Evaluate on the German intranet corpus: latency, load on the LLM endpoint, and whether the semantic additions match what users would expect — the deciding criterion is user expectation, not technical elegance.

Outcome

A recommendation with examples (including negative ones if it works worse), then the team decides whether to productize.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions