The short answer
The strongest AI/ML sourcing strategy uses several independent evidence lanes. Search professional titles, but also search code, public model work, datasets, papers, technical writing, package ecosystems, donor companies, and owned recruiting history. Each lane should answer a different question about the market.
The mistake is treating “AI engineer” as a coherent population. A research scientist building novel methods, an MLOps engineer running inference infrastructure, and a product engineer integrating LLM APIs may all contain “AI” in their profile while requiring radically different evidence.
Start by classifying the role mode
Before writing Boolean, decide what kind of AI/ML work the requisition actually needs.
If the hiring manager cannot distinguish these modes, that is an intake problem. Use the Source Pack Methodology to define the evidence standard before building the search.
Build an evidence map before a title map
Model and framework evidence
PyTorch, JAX, TensorFlow, Transformers, diffusion systems, multimodal work, or domain-specific model stacks can be useful signals, but framework mentions alone are weak. Pair them with what the person appears to have built or operated.
Evaluation evidence
Look for eval design, offline and online metrics, benchmark construction, red-team or safety evaluation, retrieval evaluation, experiment design, human evaluation, or production quality measurement. In 2026, evaluation work is often more informative than generic “LLM experience.”
Serving and systems evidence
Inference servers, Triton, vLLM, Kubernetes, Ray, model gateways, batching, latency, GPU utilization, observability, autoscaling, caching, feature or embedding pipelines, and deployment architecture can separate production ML systems work from experimentation-only profiles.
Research evidence
Publications, preprints, datasets, model cards, conference talks, and research repositories can reveal topic depth. For engineering roles, pair them with implementation and systems evidence.
Product evidence
For applied roles, search for shipped features, customer or user context, experimentation, model iteration, cost/latency tradeoffs, guardrails, and collaboration with product or application teams.
Use source lanes that match the evidence
GitHub
GitHub is useful for public repositories, code, README files, issues, packages, and project context. Native code search supports Boolean logic and qualifiers including repository, organization, language, and path. Use it as an evidence surface, not as a substitute resume.
Hugging Face
The Hugging Face Hub exposes public model, dataset, and Space repositories. Model cards, dataset cards, demos, discussions, and linked repos can reveal applied or research work that a normal title search misses.
OpenAlex
OpenAlex organizes scholarly works, authors, institutions, topics, and related research entities. It is especially useful for research-heavy searches, emerging technical topics, and author-to-institution mapping. A paper is a research signal, not automatic evidence of production engineering ownership.
Professional networks and ATS history
Employment history, recruiter notes, prior finalists, referrals, and rediscovery remain important. Open-web sourcing should expand the source stack, not pretend that public artifacts replace every licensed or owned recruiting system.
Six AI/ML search lanes to test
1. TITLE
("Machine Learning Engineer" OR "ML Engineer" OR "AI Engineer") AND (PyTorch OR JAX OR TensorFlow)
2. PRODUCTION ML
(PyTorch OR transformers) AND ("model serving" OR inference OR Triton OR vLLM OR Kubernetes)
3. LLM SYSTEMS
(RAG OR embeddings OR "vector database") AND (evals OR evaluation OR inference OR agents)
4. ML PLATFORM
(MLOps OR "ML Platform" OR "Machine Learning Infrastructure") AND (Kubernetes OR Ray OR Airflow OR Kubeflow)
5. RESEARCH
("machine learning" OR "computer vision" OR NLP) AND (paper OR publication OR arXiv OR OpenAlex)
6. PUBLIC ARTIFACT
site:github.com (PyTorch OR transformers OR JAX) (evaluation OR inference OR "model serving")Run these as separate lanes and compare what each adds. Do not combine them all into a single un-debuggable query.
Review AI/ML evidence with five questions
- What was built? Model, feature, platform, dataset, evaluation system, research result, infrastructure, or integration?
- What appears to be owned? Was the person a contributor, maintainer, lead, author, collaborator, or simply associated with the project?
- What scale or environment matters? Research prototype, internal tool, public open-source project, high-throughput inference, regulated product, consumer application?
- What is recent? AI/ML stacks move quickly. Recency may matter differently for foundational research versus production tooling.
- What remains unknown? Employment context, depth, team role, current location, work authorization, compensation, interest, or another fact that needs recruiter confirmation.
Record those fields explicitly rather than compressing everything into an opaque fit score. The Candidate 360 sample demonstrates that separation.
Build donor companies by AI operating model
A donor map should not be “famous AI companies.” It should map organizations that create the work pattern you need.
- Foundation-model labs: useful for model research, training, eval, inference, safety, and AI infrastructure patterns.
- AI-native product companies: useful for applied model integration, product experimentation, retrieval, agents, and production economics.
- Cloud and infrastructure companies: useful for GPU platforms, orchestration, serving, data systems, and developer tooling.
- Research institutions: useful for research scientists, research engineers, and specialized domain expertise.
- Traditional companies with mature ML platforms: useful for ranking, recommendations, forecasting, fraud, ads, personalization, computer vision, or domain ML at production scale.
Map by environment and work pattern, not brand prestige. The Talent Mapping and Donor Company Strategy guide shows the broader method.
How to know whether an AI/ML lane is actually adding coverage
Track the evidence-fit leads from each lane and deduplicate them against the comparison stack. A technically interesting source that repeatedly surfaces the same people as your primary database may still be useful for evidence enrichment, but it is not adding the same discovery value as a lane that contributes new evidence-fit leads.
Use Unique Contribution Rate to measure additive discovery and the Search Exhaustion framework to decide when the market has actually been tested across independent paths.
Primary-source references
These links document the public evidence surfaces referenced in this playbook.
FAQ
What is the best place to source AI and ML engineers?
There is no single best source. Use the evidence surface that matches the role: GitHub for code and engineering artifacts, Hugging Face for public models, datasets, and Spaces, OpenAlex for research authors and scholarly work, plus normal professional networks, referrals, ATS rediscovery, and donor-company mapping.
Should recruiters search for “AI Engineer”?
Yes, but not as the only lane. AI and ML titles are inconsistent. Build separate title, skill, artifact, research, donor-company, and production-system lanes so the search can surface adjacent profiles whose work matches even when the title does not.
How do I distinguish an AI enthusiast from a production ML engineer?
Look for job-relevant evidence around model development, evaluation, serving, data pipelines, observability, GPU or inference systems, deployment, reliability, product integration, or ownership. Public artifacts support investigation, but depth and role ownership still require recruiter review.
Is a paper enough evidence for an ML engineering role?
A paper can be strong research evidence, but it does not automatically prove production engineering depth. For applied or production roles, pair research evidence with code, systems, deployment, product, or employment context.
Can AI automatically score which ML candidates are best?
SourcingOS does not recommend turning a black-box AI score into a hiring decision. Use AI to structure search and summarize evidence, then keep identity, fit, missing information, and consequential decisions recruiter-owned.