kasra.page · project demo

Job search in plain language

Ask for the job you want, the way you would say it. An LLM works out what you mean, finds matching jobs among 9,458 remote postings from 13 October 2026, and tells you which fit best and why. Follow up to refine.

Try:

How it works

  1. Understand. Claude Haiku turns your message into filters (level, job family, location, contract, minimum salary). Follow-ups update them.
  2. Retrieve. Jobs that contradict a filter are dropped; the rest are ranked by meaning with OpenAI embeddings. Jobs that do not state a detail stay in, after the sure matches.
  3. Answer. Haiku reads the top 20 and picks the best fits with a reason. The cards, links and facts come from the job data, not from the model, and every amount the model writes is checked against that data.

How well does it work?

Judging search results usually means reading them by hand. Here the answers are known in advance: 1,464 test searches were built from the jobs' own fields (for example senior · Developer · open to Canada · at least $140k), rewritten into everyday language by one LLM and checked against their fields by another. Every system is scored on the same searches, by precision@10: the share of its top ten results that meet everything the search asked for. This measures the retrieval step; follow-ups are not part of it.

Share of the top 10 results that meet the whole search Precision@10, mean over 1,464 test searches
Show as table

What the 99% means

The demo filters on the same fields the test answers come from. Once it understands a search, everything it returns qualifies, so the score mostly measures understanding: 98% of test searches are read perfectly. Most misses are "management role", which the job board uses both as a job family and as a level. What this test cannot see is how well a job fits the topic inside a broad family such as "Developer". So the claim is "it applies what you asked for", not "every result is perfect".

Without the structured fields

Many job sites only have the posting text. In that setting the LLM reads every description and records what it states, leaving the rest unknown. That more than doubles precision over meaning-based search, but stays far below the version with structured fields, and the reason is missing information: salary appears in 85% of descriptions that have one, location in about half, contract type in a third.

Precision@10 by what the search asks for Searches that include each field
Show as table

Checks and limits