Why we built recall-first search on PostgreSQL

The careers page search on the company's website often produced inaccurate results. Searching for terms like "Java" could yield JavaScript roles, and misspellings might return no results at all. Searching for the word "manager" could collect assistant-manager vacancies from unrelated departments without distinguishing the specific job requirements.

This search implementation simply matched words within job metadata, without considering spelling variations, equivalent terminology, or the actual work a candidate wanted to do. Relevant vacancies could disappear if the candidate and employer used different words to describe the position. Replacing the keyword-based search with a hybrid retrieval approach solved part of the problem but also exposed a new challenge.

While the hybrid evaluation achieved an NDCG@10 of 0.9944, precision@5 on semantic queries was only 55%. This meant that while the new system could find relevant jobs that literal matching missed, it still needed to decide how many weaker matches should accompany the relevant ones. The team eventually built selective hybrid retrieval inside their existing Next.js and PostgreSQL stack, using their existing OpenAI integration for embeddings.

Before choosing this design, they considered alternative options such as dedicated search engines, managed search, and self-hosted inference. Each alternative would have solved parts of the problem but would have introduced additional systems that the team would have to operate and keep consistent. Choosing the smaller architecture meant that the team would have to do significant engineering work to implement the solution.

The evaluation process would force the team to define what a useful result set meant for the search, and production would test whether that definition could withstand stale data, late responses, and provider failures.