Elasticsearch

Most search failures we are called in to fix are not missing infrastructure. They are a perfectly good Elasticsearch cluster behind an interface that never asked what people were looking for. We work on both halves.

What we do

  • Relevance tuning — analysers, synonyms, boosting and field weighting against real queries, not a demo corpus.
  • Facets and filters that match how the material is actually catalogued.
  • Per-language analysers, with the document language stored as a field and queries routed accordingly.
  • Scaling and cost work: faster queries on the same hardware rather than a bigger cluster.
  • The search UI itself — the half that usually decides whether people find anything.

In production

  • HM Land Registry 1862 Register — register search underpinned by Elasticsearch: faster response times, reduced CPU and memory, and faceted search that scales on the same hardware.
  • NSW State Transit intranet — integrated for search relevance so staff find documents by what they mean rather than what they are titled.
  • Multicultural Health Communications Service — per-language analysers with a query-time pivot that returns the reader's preferred language when it exists and falls back when it does not.

If you publish in Welsh, Mandarin, Arabic or Hindi, stemming and tokenisation decide whether search works at all. This is the part most platforms skip, and it is covered in more depth under multilingual platforms.

For question-answering over the same material rather than ranked results, see Onyx enterprise search.

One of four things we do under AI integration — where it sits alongside AI search over the same material.