RAG only route
Use approved sources, retrieval and context window rules when the model should cite evidence rather than learn new behaviour.
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.
RAG routesLoRAQLoRARL / preferenceEval harnesses
Choose the model route from the workload, not the vendor slide.
The route starts with approved sources and decision criteria: data volume, behaviour gap, latency, risk and cost. It then selects RAG, LoRA, QLoRA, full fine tune, RL/preference or a hybrid path.
The model is only one component. The repeatable system is boundary, adapter, inference stack, evals, reviewer queue and feedback.
Intake boundaryApproved corpus, restricted data and workflow owner.
Route decisionData volume, behaviour gap, latency, risk and cost.
Adaptation pathRAG, LoRA, QLoRA, fine tune, RL/preference or hybrid.
OperateEval 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.
LoRA adapter
Adapt style, terminology or task behaviour with a lightweight adapter while keeping the base model route controlled.
QLoRA adapter
Use quantized adapter training when GPU memory, cost or local experimentation makes full precision tuning impractical.
Full fine tune
Reserved for strong datasets, stable requirements and enough evaluation evidence to justify changing more of the model behaviour.
RL / preference tuning
Apply preference or reward based tuning when reviewer choices and policy trade offs need to shape the output pattern.
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 generalistPrompt led route
Tuned open weight routeAdapter + eval route
Format adherenceRequired structure
Prompt dependentRestated each run
Adapter + eval gateTrained and checked
Policy wordingApproved language
Broad model habitGeneric phrasing
Reviewed patternTerms locked in
Correction rateReviewer fixes
Found during reviewAfter the output
Tracked into datasetImproves next route
Release controlRepeatable route
Provider route variesOutside your release
Fixed stack/versionPinned and testable
Domain vocabularySpecialist terms
Context supplied each runPrompt/RAG carried
Tuned terminologyEmbedded 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.
LM Studio and local API runners help teams test open weight models, prompts and GGUF routes before platform engineering begins.
Unsloth Studio, LoRA and QLoRA paths help turn small, clean datasets into controlled behaviour changes.
Axolotl style YAML pipelines support full fine tunes, preference tuning, RL routes, dataset prep and evaluation stages.
Fixed eval sets, reviewer rubrics, sidecar checks and release comparisons show whether the tuned route is improving.
Local, private hosted, isolated and hybrid serving routes keep deployment aligned to source policy and support reality.
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 proofEvery 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.