Private AI engineering
Build private AI where source control and review matter.
Tesrex designs private, local and open weight LLM routes where model behaviour, data boundaries and reviewer control have to be engineered together.
Intake boundary Approved corpus, restricted data and workflow owner.
Route decision Data volume, behaviour gap, latency, risk and cost.
Adaptation path RAG, LoRA, QLoRA, fine tune, RL/preference or hybrid.
Operate Eval harness, reviewer queue, evidence pack and feedback loop.
The private route is selected, not assumed.
Some workflows need retrieval and citations. Some need model behaviour changed. Some need a local run path first, then a private hosted or isolated route once the evidence is strong.
That decision is what separates private AI engineering from a local chatbot experiment.
01
RAG only route
Use approved sources, retrieval and context window rules when the model should cite evidence rather than learn new behaviour.
02
LoRA adapter
Adapt style, terminology or task behaviour with a lightweight adapter while keeping the base model route controlled.
03
QLoRA adapter
Use quantized adapter training when GPU memory, cost or local experimentation makes full precision tuning impractical.
04
Full fine tune
Reserved for strong datasets, stable requirements and enough evaluation evidence to justify changing more of the model behaviour.
05
RL / preference tuning
Apply preference or reward based tuning when reviewer choices and policy trade offs need to shape the output pattern.
06
Hybrid route
Split retrieval, drafting, validation and evaluation across different hosted, private, local or sidecar models.
Where tuning changes the output profile.
For bounded, repeatable work, a tuned open weight route can be more controllable and reproducible because the team can fix the weights, adapter, inference stack, decoding settings, eval set and release version.
This is not a universal claim that open weights are always more deterministic than closed cloud models. It is a design argument for narrow workloads where the route can be owned and tested.
Output control profile
Closed cloud generalist Prompt led route
Tuned open weight route Adapter + eval route
Format adherence Required structure
Prompt dependent Restated each run
Adapter + eval gate Trained and checked
Policy wording Approved language
Broad model habit Generic phrasing
Reviewed pattern Terms locked in
Correction rate Reviewer fixes
Found during review After the output
Tracked into dataset Improves next route
Release control Repeatable route
Provider route varies Outside your release
Fixed stack/version Pinned and testable
Domain vocabulary Specialist terms
Context supplied each run Prompt/RAG carried
Tuned terminology Embedded and checked
The tooling stack is part of the architecture.
Private AI work needs practical tool choices: beginner local runs, adapter training, deeper fine tune or RL routes, evaluation harnesses, private serving and handover.
The point is not tool worship. It is choosing the smallest route that makes the workflow dependable.
Beginner local runs
LM Studio and local API runners help teams test open weight models, prompts and GGUF routes before platform engineering begins.
Adapter training
Unsloth Studio, LoRA and QLoRA paths help turn small, clean datasets into controlled behaviour changes.
Training pipelines
Axolotl style YAML pipelines support full fine tunes, preference tuning, RL routes, dataset prep and evaluation stages.
Evaluation harnesses
Fixed eval sets, reviewer rubrics, sidecar checks and release comparisons show whether the tuned route is improving.
Private serving
Local, private hosted, isolated and hybrid serving routes keep deployment aligned to source policy and support reality.
Handover
Runbooks, model cards, release versions, rollback paths and training keep the workflow usable after the prototype.
What you get back.
A practical engineering workpack that helps leadership decide whether to use RAG, tune an adapter, run a fine tune, apply preference/RL, build a hybrid path or stop.
Engineering proof Every recommendation is tied to source boundary, route decision, eval evidence, reviewer workflow and deployment reality.
Map the private route before choosing the model.
We will separate source governance, customer data boundaries, model routing, context window design and reviewer workflow so the architecture fits the work.