How embeddings match your resume to jobs is the core of Zorlya’s matching. Most of it depends on one idea that sounds more technical than it is. A computer program can turn a piece of text into a list of numbers so that texts about similar things get similar lists. That list is an embedding. This post explains what one is, how your resume is cut up before it gets one, where the closeness is used, and what it cannot tell you.
What an embedding is
Think of a map where every piece of text has a location. A paragraph about building payment APIs sits near a paragraph about integrating billing providers, even if they share few words. A paragraph about pastry sits far away. An embedding is the coordinates of that location. Zorlya’s coordinates are a long list of numbers produced by an embedding model, and closeness is measured by the angle between two lists (cosine similarity).
Two things follow. Closeness works on meaning, so “built REST services” and “designed HTTP APIs” can be neighbours. And a vector is a summary. It keeps the general subject of a text and loses detail, which matters in the limits below.
Keyword match and meaning match, side by side
| Keyword match | Embedding closeness | |
|---|---|---|
| Asks | Does this word appear? | Is this text about similar work? |
| “Project manager” against “programme lead” | No match | Close |
| “Python” against “Python 3” | Depends on how the words are split | Close |
| “Requires travel” against “no travel” | Matches the word “travel” | Close, wrongly |
| Speed over thousands of jobs | Fast | Fast, once stored |
| Explains itself | Shows the word | Shows nothing |
Zorlya’s deeper pass uses both, so each covers some of the other’s gaps. The keyword side catches an exact tool name that a summary might blur, such as a specific version of a framework. The meaning side catches the same work described in other words, such as a title another employer would use for your role. Neither one alone reads a posting the way a person does, which is why a language model reads the shortlist and the facts the scorer computes sit beside both.
A small worked example
Illustrative: the numbers are invented and much shorter than real ones. Imagine each text had only two coordinates, one for “how much it is about data” and one for “how much it is about people”.
| Text | Data | People |
|---|---|---|
| Your role: “Built monthly sales reports and dashboards” | 0.9 | 0.2 |
| Job A: “Data analyst, reporting and dashboards” | 0.95 | 0.1 |
| Job B: “Team lead, customer success” | 0.2 | 0.95 |
Your role points almost the same way as job A and in a very different direction from job B, so job A is near and job B is far. A real embedding does the same with many more coordinates, none of which has a name like “data” or “people”.
Why your resume is split into chunks
One embedding for a whole resume would average everything you have done into a single point. A backend career with a year of design work would land in the middle of nowhere. So Zorlya cuts a profile into passages first:
- one for your summary
- one for each role, with the title, company, dates and what you did
- skills grouped by category, with at most 15 skills in a chunk so a passage stays about one area
Each chunk is embedded and stored. Job postings are embedded too, from the title, the company and the description turned into plain text, cut to a limit of 8,000 characters before they are sent to the model.
The same text always gives the same vector for the same model, so Zorlya stores embeddings and does not pay to compute one twice. Because every stored vector must have the same width, one embedding model is used for the whole instance.
Where closeness is used
A quick first pass. After new jobs arrive, Zorlya builds a short query for you from your track’s keywords, your headline and up to 15 of your skills, embeds it, and finds the nearest jobs by cosine. This pass uses no chat model at all. It writes a provisional resume-fit number, the cosine scaled so that a perfect match would score 70, and it never replaces a score that already has an explanation.
The deeper pass, when you press refresh. Zorlya runs a hybrid search. A job’s retrieval score is 60% embedding closeness and 40% keyword match against the posting text. By default it takes 50 candidates per track, and a language model reads them against your profile and rates the fit. The model is shown your three longest resume chunks. The final resume fit blends the model’s reading and the embedding closeness, 65% and 35%, as described in the scoring post.
Cover letters. A letter takes the five resume chunks nearest in meaning to the job, which is why the same resume gives different letters for different jobs.
What embeddings do well
They find a candidate pool without matching words. A posting that says “platform engineer” can surface for a resume that says “infrastructure developer”. They scale: comparing your query to thousands of postings is a database lookup, not thousands of model calls. And they are cheap enough that Zorlya can run the first pass for everyone after each ingest.
What embeddings cannot do
- Count or compare numbers. A closeness score does not know that a posting wants 8 years of experience and you have 3, or that the range tops out below your floor. Zorlya scores salary, location and seniority separately, from stored fields, for this reason.
- Read negation or requirements. “Must not require travel” and “requires travel” are near neighbours, because they are about the same thing.
- Tell a nice-to-have from a must-have. A skill in a footer and a skill in the first line carry similar weight in a summary.
- Know what you want. Two roles can be equally close to your resume while only one fits the arrangement you asked for. That comes from your profile settings.
- Explain themselves. A number says that two texts are near. It does not say why. The explanation under each score comes from the language model and the facts the scorer computed, not from the vector.
A strong match can also be missed if the query is thin. The first-pass query is built from keywords, headline and skills, not from the full text of your roles. A resume with an empty headline and few listed skills gives the first pass little to find.
How to give the matching more to work with
- Write a headline that names the work you want, in the words postings use.
- Describe each role in full sentences about the work, not a list of tools.
- List your skills, since up to 15 of them go into the first pass query.
- Make sure your resume has real text. A scanned file has nothing to embed.
- Refresh after you change your profile, so the deeper pass reads the new version.
Questions people ask
Does an embedding read my whole resume at once?
No. Each passage is embedded on its own: the summary, each role and groups of skills. That keeps a long career from blurring into one average.
Why did a job with none of my words score well?
Because it is about similar work in different words. Read the posting to check the closeness is real.
Why did an obvious match score low?
The posting may be thin, or your profile may give the first pass little to search with. Add a headline and skills, and refresh.
Can an embedding see years of experience or salary?
No. Those are scored separately from stored fields.
What we know and what we do not
We know the mechanism from the code. Zorlya has no published figure for how often the first pass surfaces a job a person would have rated highly, and no comparison of the first pass against a person’s own ranking. The plan for the later reranking changes sets the test it would take, which is a hand-rated sample, and that sample has not been collected yet. So there is no accuracy claim here. What this post gives you is the mechanism, which you can check against your own feed: if a strong role is missing, add the skills and headline it uses and refresh.