Many products are marketed as a “legal LLM,” “medical LLM,” or “recruitment LLM.” The label can suggest that the team trained an entirely new foundation model from random weights.
That is rarely how practical vertical AI products are built.
Most of them place a general-purpose foundation model inside a larger domain system. Vertical data contributes domain behavior. Retrieval and databases provide facts. Rules handle deterministic decisions. Tools perform actions. Routing selects the right capability. Permissions and evaluation define what the model may see, what it may do, and whether a result is reliable enough to ship.
Shixiseng Atlas, the local AI career system I have been building, follows this pattern.
Atlas is not a new foundation model trained from scratch. Its current development version uses Qwen/Qwen3-0.6B-MLX-4bit as the base, applies an MLX LoRA adapter trained on recruitment relevance data, and combines it with a local job snapshot, resume parsing, retrieval and ranking, eligibility rules, and task workflows.
The central engineering question was not how to put a recruitment-themed interface around a chatbot. It was this: how do we let the model handle understanding and explanation while assigning facts, permissions, and execution to more dependable components?
A vertical LLM starts as a system, not a weight file
A practical vertical AI product usually looks like this:
General-purpose foundation model
+ domain prompts or LoRA fine-tuning
+ enterprise knowledge and operational databases
+ retrieval and ranking
+ deterministic rules
+ tools and task workflows
+ intent routing
+ permission and safety controls
+ offline evaluation and release gates
The model weights are only one layer.
If an LLM is responsible for job counts, degree constraints, relevance ranking, explanations, and the final application action, it can easily invent facts and becomes difficult to audit. Fluent generation does not provide transactional consistency, and confidence in wording cannot prove that an application actually succeeded.
Atlas therefore separates responsibilities:
| Capability | Responsible component in Atlas |
|---|---|
| Job counts and source fields | Local job database |
| Candidate job retrieval | Local vector index and keyword retrieval |
| Degree, city, and internship constraints | Deterministic eligibility rules |
| Resume-to-job relevance | Ranking logic and the Atlas model |
| Match explanations and career advice | Local language model |
| Resume visibility | Context permission controls |
| One-click application | Deterministic workflow after user confirmation |
| Model release decision | Frozen evaluations and quality gates |
The principle is simple: facts come from data sources, rules execute in code, and the language model handles understanding, synthesis, and explanation.
Atlas has an explicit, traceable identity
Atlas must be able to describe what it actually is instead of replying with a generic “I am an AI assistant.” The current identity includes:
- model family:
shixiseng-atlas; - development version:
0.1.0-dev; - base model:
Qwen/Qwen3-0.6B-MLX-4bit; - adapter:
mlx-qwen3-0.6b-relevance-balanced-v1; - training: MLX LoRA, currently trained for 192 iterations;
- inference: local MLX and Metal on Apple Silicon;
- data scope: local job snapshots, resumes, and conversations;
- quality status:
experimental-gate-failed.
The last item matters. A completed training run and a working inference path do not mean the adapter is production-ready. The current data scale, structured-output stability, and independent evaluation results are not sufficient to pass the release gate, so the product labels the model as experimental.
“Training completed” and “safe to ship” are different claims.
Three real application scenarios
Atlas currently supports three local workflows for job seekers. Every screen below comes from a real interaction with the experimental build rather than a design mockup or a static demo response.
1. Find opportunities in one city from a local resume
After selecting a resume stored on the machine, the user can ask Atlas to find opportunities in Shenzhen. Atlas retrieves and ranks records from the local job index, then reports the number of relevant and high-match opportunities together with inspectable match reasons.
2. Compare opportunity volume across two cities
For a question such as “Does Shenzhen or Hangzhou have more opportunities?”, counts come from deterministic statistics over the local job index rather than an LLM guess. The response also states its counting scope so resume-keyword candidates are not mistaken for every job in each city.
3. Compare cities and run a simulated application workflow
Atlas can retrieve matching jobs in two cities, generate a comparison, add the top option from each city to the conversation's application plan, and run a local simulation. The experimental build does not submit a real application to any employer; this workflow validates confirmation, task state, and result reporting.
Four intent routes instead of one universal chat path
Messages inside a career product represent very different tasks:
Find product internships in Beijing
Analyze my resume
How should I prepare for a product manager interview?
Name three famous Tang dynasty poets
Sending every message through one prompt while automatically attaching resumes and previous job results wastes context and creates privacy and task-contamination risks.
Atlas currently classifies requests into four routes:
| Route | Typical task | Reads resume? | Job behavior |
|---|---|---|---|
job_search | Search, recommend, or compare jobs | Yes | Runs a new local retrieval |
resume_analysis | Analyze or improve a resume | Yes | Does not automatically recommend jobs |
career_chat | Interview preparation and career advice | When needed | Reuses existing job context |
general_chat | Non-recruitment questions | No | Does not read job context |
The simplified view below shows how the four business modes and the safety fallback converge on a unified response layer:
After routing, the system chooses the appropriate system prompt, determines whether the candidate profile may be attached, decides whether to access the local job index, and selects between a deterministic response and model generation.
For example, the model should not guess the answer to “How many suitable jobs are available in Beijing?” The system queries the local index for resume-relevant records first. The model may explain why those jobs matter, but it cannot rewrite the count.
Two contexts on one model—and the remaining limitation
The current Atlas MVP uses the same Qwen3 0.6B base and the same Atlas LoRA adapter for both general and career modes. Two system prompts and context isolation provide the behavioral split:
User message
→ intent classification
→ choose the general or career system prompt
→ decide whether resume and job context are permitted
→ answer through the local model or a deterministic bypass
This is inexpensive to build and simple to operate, which makes it appropriate for validating a local MVP. It already provides an important guarantee: general questions do not receive resume content, job lists, or job counts.
There is still a clear limitation: general mode changes the prompt but continues to load the recruitment LoRA. Domain behavior learned by the adapter can leak into otherwise general answers. A prompt can constrain the current task, but it cannot completely erase the adapter’s effect on model behavior.
The more mature design is task-aware adapter loading:
general_chat
→ general Instruct base
→ no recruitment LoRA
→ no resume or job access
resume_analysis / career_chat
→ the same compatible base
→ load Atlas LoRA on demand
→ read only authorized context
job_search
→ local job index and deterministic rules
→ model explains results only
application task
→ explicit user confirmation
→ deterministic business API
→ report the real execution result
This preserves shared tokenization, base weights, and inference infrastructure while preventing the recruitment adapter from continuously influencing general-purpose behavior.
Local execution is not merely a privacy slogan
Atlas keeps resumes, the job index, conversations, and model inference on the machine. Its macOS desktop application uses AppKit and WebKit as a lightweight native shell around the local service, while MLX loads and runs the model on Apple Silicon.
But “local” is not automatically equivalent to “safe.” The data flow still needs enforceable rules:
- general mode must not read resumes or job context;
- an unselected resume must not enter the prompt;
- external links must not inherit local data;
- applications require user confirmation;
- generated text must never impersonate the result of a business API;
- training, evaluation, and release artifacts need traceable versions and digests.
Privacy comes from a verifiable data flow, not from a “local AI” badge in the interface.
Why an experimental small model is still useful
Qwen3-0.6B is an experimental small model. Its knowledge coverage, complex reasoning, and instruction reliability are not comparable to larger production models.
It remains useful at this stage because it:
- runs locally on ordinary Apple Silicon hardware;
- keeps training and iteration costs low;
- avoids sending resumes to an external inference provider;
- forces the architecture to move facts and deterministic logic out of the model;
- lets routing, permission, retrieval, and workflow interfaces survive a future base-model upgrade.
If a product works only when the model is treated as omniscient, its architecture is probably not reliable yet. If a 0.6B model can be limited to controlled language tasks while the system still returns real jobs, explainable matches, and safe actions, the product foundation is much more durable.
The current experiment and the production model plan
The Qwen3-0.6B-MLX-4bit + LoRA configuration shown in this article is only the current local experimental version. At this stage, the goal is not to claim that a 0.6B model already provides production-grade recruitment intelligence. It is to validate the complete engineering path at low cost: data preparation, LoRA training, model loading, intent routing, context isolation, local retrieval, deterministic rules, and quality evaluation.
The planned online version will use the more capable Qwen/Qwen3.5-27B + QLoRA. It will preserve the same system boundaries already tested here: job facts come from databases, hard constraints are evaluated by rules, the model focuses on semantic understanding, relevance analysis, and explanations, and high-risk actions require user confirmation and a deterministic workflow.
The current 0.6B version should therefore be understood as a runnable engineering validation environment, not the final model choice. It helps expose problems in data, training, routing, privacy, and evaluation early. Once the full path is stable, the project can invest the substantially higher training and inference cost in the online model without using a larger model to hide weaknesses in the surrounding system.
What Atlas taught me about vertical AI
A “vertical LLM” is more accurately a product system centered on a domain-adapted model without delegating every responsibility to that model.
Its defensibility does not come from one LoRA training run. It accumulates through the surrounding system:
- lawful, clean, and evaluable vertical data;
- retrieval and tools connected to real business objects;
- explicit boundaries for deterministic rules;
- least-privilege context access;
- frozen evaluation sets and release thresholds;
- visible failures instead of marketing labels that hide them.
The technically accurate description of Atlas is:
A recruitment-focused model system built on Qwen3-0.6B-MLX-4bit, adapted with Atlas recruitment data through LoRA, and combined with local job retrieval, resume parsing, eligibility rules, intent routing, and task workflows.
It is not a new foundation model trained from scratch, and it is not production-ready yet. But it validates a pragmatic direction: use a general model for language, vertical data for domain behavior, databases and rules for facts, and permissions, evaluations, and workflows to turn the model into a real product.