Healthcare & Clinical

A Natural-Language Candidate Search Platform That Replaces Boolean Query Building

How Pfactorial Technologies built TalentGPT, a recruiting search platform that turns plain-English candidate descriptions into precise, ranked Elasticsearch results - with caching and zero-result analytics built in from day one.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Pfactorial_Case_Study_TalentGPT_Candidate_Search image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client's recruiters were building Boolean search strings by hand to find candidates - a skill barrier that slows down search and makes query quality dependent on individual recruiter expertise rather than the underlying candidate data.

Replacing Boolean syntax with plain English isn't just a UI change - it means reliably extracting structured filters, inferring AND/OR/complex logic from phrasing, resolving experience requirements, and turning all of that into a precise Elasticsearch query, without the LLM parsing step becoming a bottleneck at scale.

Pfactorial built TalentGPT: recruiters type a plain-English description, an LLM extracts structured filters while a dedicated NER model resolves experience ranges, the combination becomes a tuned Elasticsearch query, and a write-through cache means repeated searches skip the expensive parsing step entirely.

Why this engagement is representative This engagement demonstrates Pfactorial's approach to applying LLMs precisely where they add value - structured extraction from ambiguous language - while keeping the actual search execution in a purpose-built search engine, with caching and analytics engineered around the LLM's real cost.

THE CHALLENGE

Replacing Boolean search with natural language required solving accuracy, cost and diagnosability problems a naive LLM-wrapper wouldn't address.

1. Boolean search is a real skill barrier

Query-string syntax gates search quality behind individual recruiter expertise rather than making the underlying candidate data equally accessible to everyone.

2. Free text hides real structured intent

A phrase like “Python and Django” or “Testing and (Selenium or Cypress)” encodes precise Boolean logic that has to be extracted correctly, not just passed through as a fuzzy text match.

3. LLM parsing on every query doesn't scale economically

Each structured-query parse costs an LLM API call; without caching, popular or repeated searches would pay that cost every single time.

4. A silent zero-result query is a diagnostic dead end

When a search returns nothing, that's either a coverage gap in the candidate database or a query-comprehension miss - and without logging the full parsed structure, there's no way to tell which.

The real brief Not “add an AI search bar” but “extract precise structured filters from natural language reliably, cache the expensive part, and make every zero-result search diagnosable.”

THE SOLUTION

Pfactorial built the platform around a single-prompt LLM extraction step, a dedicated NER model for experience-range parsing, a two-layer write-through cache, and comprehensive zero-result logging for ongoing coverage diagnosis.

Pfactorial_Case_Study_TalentGPT_Candidate_Search image 2

Figure 2 - From plain English to ranked, faceted candidate results.

Architectural principles

LLM extracts structure, not the search itself - GPT-4o-mini converts free-text queries into a structured JSON filter object via a single-prompt call; the actual search execution happens in Elasticsearch, not the model.
Dedicated NER for what general language models generalize poorly - GLiNER2, a zero-shot NER model loaded once at startup, is used specifically for experience-range extraction - a narrow, high-precision task suited to a specialized model rather than the general-purpose LLM.
Cache aggressively, normalize before comparing - A write-through cache - in-memory dict backed by an Elasticsearch index - stores every parsed query keyed by its normalized text, so identical or near-identical queries skip LLM parsing entirely.
Every zero-result query is a diagnostic event - The original query, the full structured filter object, and the executed Elasticsearch DSL query are all logged whenever a search returns nothing, turning zero-result events into an ongoing coverage-gap signal rather than a dead end.

CAPABILITIES DELIVERED

Each capability moves the platform beyond literal keyword or Boolean-string search.

CAPABILITY	WHAT IT DOES
Natural language search	Plain-English queries parsed into structured filters - skills, locations, roles, experience.
Boolean logic inference	AND/OR/complex nested logic inferred from query phrasing and applied as Elasticsearch bool queries.
Negative filters	Prefix-based exclusion (e.g. "-location") for filtering out unwanted values.
Contact-availability filtering	Restrict results to candidates with verified phone, email, or both.
Aggregated facets	Location, company and city aggregations returned alongside results for refinement.
CSV bulk export & feedback	Streaming export of up to 1,000 records, plus thumbs-up/down feedback tracked per query.

Pfactorial_Case_Study_TalentGPT_Candidate_Search image 3

Figure 3 - Raw candidate profiles to a searchable, deduplicated index, tuned for ingestion throughput.

Design note The cache key is the normalized query text, not the raw string - two queries differing only in whitespace or capitalization hit the same cache entry. That single normalization decision is most of what makes the cache actually effective at scale.

ENGINEERING FOR SCALE AND RELIABILITY

Five decisions keep extraction accurate and ingestion fast as the candidate database and query volume grow.

Engineered semantic query mapping prompt

A carefully constructed system prompt instructs the LLM to distinguish required from optional skills, infer negative filters from exclusion phrasing, and explicitly reject non-recruitment queries with a structured error rather than a malformed filter object.

Startup-loaded NER model

GLiNER2 is loaded once at application startup - a blocking operation accepted upfront so every subsequent request reuses the loaded model without re-initialization cost.

Thread-safe, write-through caching

The in-memory cache is protected by a lock and written through to Elasticsearch simultaneously on every new parse, with access counts and last-accessed timestamps tracked per entry.

Throughput-tuned bulk ingestion

Elasticsearch's refresh_interval and replica count are relaxed during ingestion to maximize write throughput, then restored to production defaults once the batch completes.

Deduplication via stable document IDs

Each candidate document's ID is the SHA hash of their LinkedIn URL, with upsert mode and conflict retries, so re-running the ingestion pipeline updates existing records rather than creating duplicates or failing on conflicts.

DELIVERY APPROACH

The engagement built the data ingestion pipeline first, then the query-parsing and search layer on top of a clean, indexed dataset.

1. Data cleaning pipeline - location standardization, contact extraction, and LinkedIn-URL-based deduplication.

2. Elasticsearch ingestion pipeline - experience-duration calculation and throughput-tuned parallel bulk indexing.

3. Semantic query mapper - the engineered LLM prompt for structured filter and Boolean-logic extraction.

4. NER integration - GLiNER2-based experience-range extraction feeding Elasticsearch range queries.

5. Query caching layer - the two-layer write-through cache eliminating repeat LLM parsing cost.

6. Zero-results analytics & API - comprehensive logging plus the full REST API surface for search, export, and feedback.

RESULTS AND IMPACT

Pfactorial_Case_Study_TalentGPT_Candidate_Search image 4

Figure 4 - Key outcomes from this engagement.

Recruiters search using plain English instead of Boolean query strings, with the platform reliably inferring the underlying filter logic from natural phrasing.

The write-through cache eliminates repeat LLM parsing cost for popular or repeated searches, while zero-result logging gives the client an ongoing, queryable signal on candidate-database coverage gaps.

What it enabled commercially

The client's recruiters search candidate data at the speed of typing a plain-English description, removing the Boolean-syntax skill barrier that previously gated effective search to a subset of experienced users.

WHY PFACTORIAL

This engagement reflects Pfactorial's applied AI product engineering service line: using an LLM precisely for structured extraction, a specialized NER model for a narrow high-precision task, and a purpose-built search engine for the actual retrieval - each component doing what it's genuinely best at.

Pfactorial_Case_Study_TalentGPT_Candidate_Search image 5

Figure 5 - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with HR technology and talent acquisition teams that need natural-language search over structured candidate data. If you're evaluating an AI-powered search or retrieval platform, we're happy to give you an honest read on scope and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Pfactorial_Case_Study_TalentGPT_Candidate_Search image 6

© 2026 Pfactorial Technologies. Client identity and product-specific implementation detail are withheld or generalized; no client data, credentials, source code, or infrastructure detail is included in this document.