Semantic candidate search finds people by the meaning of your query, not the exact keywords on their resume. On 100Networks it's powered by pgvector embeddings (OpenAI's text-embedding-3-small, 1536 dimensions), so a search for "scalability experience" surfaces the candidate who wrote "built distributed systems that handled millions of requests" — even though they never used the word "scalability." That's the difference between finding who's findable and finding who's right.
The problem with keyword search
Boolean/keyword search has one fatal flaw: it only matches the literal words you type. But people describe the same skill in wildly different ways:
- You search "machine learning" → you miss the candidate who wrote "trained recommendation models."
- You search "team leadership" → you miss "mentored five engineers and ran our hiring."
- You search "scalability" → you miss "re-architected the backend to handle 10× traffic."
So your best candidate is sitting in your database, and your search literally can't see them — because they used different words. You end up sourcing new people while qualified ones go untouched in your own pool.
How semantic search works (in plain terms)
The trick is embeddings. An embedding turns a piece of text — a resume, a query — into a list of numbers (a vector) that captures its meaning. Texts that mean similar things end up with similar vectors, even if the words are different.
100Networks creates these embeddings with OpenAI's text-embedding-3-small model (1536 dimensions) and stores them in pgvector, the vector extension for PostgreSQL. When you search, your query is embedded the same way, and the system finds the candidates whose vectors are closest to it — i.e., whose experience is conceptually nearest to what you're looking for.
The practical effect: you search by intent, and the right people surface regardless of vocabulary.
It's part of a real Talent CRM
Semantic search isn't a standalone gimmick — it sits inside the 100Networks Talent CRM, alongside the things that make a candidate database actually usable:
- Talent pools — organize candidates into groups
- Smart lists — dynamic segments that update themselves
- Custom fields — track what matters for your roles
- Duplicate detection — keep the pool clean
So you build and maintain your pool the normal way, then query it by meaning when you need to.
Why it matters
Two concrete wins:
- You re-use the pipeline you already paid for. Every past applicant, every sourced lead — searchable by skill, not by whether they happened to use your keywords. That's candidates you'd otherwise re-source from scratch.
- You move faster on new roles. Describe the person you need in plain language and get a ranked shortlist from your existing pool in seconds.
It's the same philosophy as the rest of 100Networks — let the system do the heavy lifting so recruiters spend time on people, not on guessing the right boolean string. See it in context in the product overview, and pair it with Pilot to action the shortlist.