Querylight TS Demo

Real-World Recipes

Practical patterns for docs search, blog search, product filtering, related content, and lightweight semantic retrieval.

Back to docs search

Reference Entry

Real-World Recipes

Guides · foundation · order 30

Practical patterns for docs search, blog search, product filtering, related content, and lightweight semantic retrieval.

Relevant APIs

createSimpleTextSearchIndex reciprocalRankFusion termsAggregation VectorFieldIndex GeoFieldIndex

Tags

recipes docs-search facets related-content vector

Real-World Recipes

Querylight TS is a toolkit, which means the most useful question is often “what pattern should I assemble for my use case?”

Here are a few practical recipes.

Use:

  • title, summary, and body fields
  • metadata fields such as section and tags
  • prebuilt serialized index state
  • optional chunked vector search for question-style retrieval

This is the pattern used throughout the demo.

Blog or article search

Use:

  • title and body search
  • tags and date-like metadata
  • a combined field for broad recall
  • highlighting for result snippets

If date ordering matters, keep sortable string representations available for filters or secondary sorting logic.

Use:

  • exact metadata fields for category, brand, and availability
  • free-text fields for title and description
  • facets for drill-down navigation
  • autocomplete for product-name discovery

This is where field separation matters most.

Related content

Use:

  • lexical overlap from tags and title
  • optional vector similarity for semantic relatedness
  • RRF if you want to combine both

This works well for article recommendations and “read next” widgets.

Use:

  • text fields for names and descriptions
  • GeoFieldIndex for geographic constraints
  • optional lexical plus geo fusion when both topic and location matter

A reasonable default architecture

If you are unsure where to start:

  1. model explicit metadata fields
  2. add a combined catch-all field
  3. prebuild and serialize the index
  4. add facets or autocomplete only where needed
  5. add vector features only after lexical search is already solid

That sequence keeps the system understandable while still leaving room for more advanced retrieval later.