AI & Data
Custom AI models, judged on your test set
Public models know a little about everything. Yours has to know your contracts, your products and your edge cases. We build the evaluation set first, run the best off-the-shelf models against it, and train a custom one only where they fall short.
What We Build
Six ways to make a model yours.
Few problems need a model trained from scratch. Most need one or two of these, chosen after we measure where the baseline falls short.
Custom Training
Training or continued pre-training on proprietary data, for domains where public models have nothing to learn from.
Fine-tuning (LoRA/RLHF)
Parameter-efficient tuning that teaches an open model your terminology, output format and house rules, at a fraction of full-training cost.
RAG Architecture
Retrieval over your documents, tickets and databases. Answers cite a source you control and change when the source does.
Agentic AI
Agents that call your tools and APIs to finish multi-step tasks. Every action is logged; high-stakes steps wait for a human.
MLOps
Training, evaluation and release pipelines. A new model version ships only after it clears the same test set as the last one.
System Integration
Connectors into ERP, CRM and internal tools, so output lands where people already work. ERP is one of our own lines of business.
Custom vs Off-the-shelf
When custom wins, and when it doesn't.
A public model is often the right call. These are the dimensions that tip the decision one way or the other.
Dimension | Off-the-shelf model | Nujtech custom model |
|---|---|---|
| Where data goes | Processed on the vendor's infrastructure | Your cloud, a private VPC or an air-gapped site |
| Domain fit | Broad public knowledge | Tuned on your terminology and edge cases |
| Release control | Changes on the vendor's schedule | Versions promoted when your tests pass |
| Cost shape | Per call, rising with usage | Build cost first, then infrastructure |
| Best when | The task is general and the data isn't sensitive | The task is specific, high-stakes or data-restricted |
Read This First
Three reasons not to build a custom model.
Custom models cost money to build and attention to run. If any of these hold, stop and fix that first.
A prompt already clears the bar
If a well-prompted public model passes your evaluation set, training adds cost, not accuracy. The audit will show it.
Nobody can define a right answer
A model can't be judged without examples of correct output. If your experts disagree on what correct looks like, settle that before any training run.
No one will own it after launch
Models drift as your data moves. Without someone watching the metrics and approving retraining, a custom model decays into a liability.
DOMAIN DEPTH
Where a wrong answer costs more than a slow one
Regulated data, specialist vocabulary, decisions someone has to sign. These are the sectors where a custom model earns its cost.
Clinical and operational systems for healthcare
Clinical documentation, claims and connected patient data, with a clinician approving anything that affects care.
Banking, insurance and risk systems
Fraud, KYC, underwriting and claims models that risk and compliance teams can review, explain and sign off.
Engineering for automotive
Connected-vehicle data, telematics and dealer analytics, built around functional-safety and cybersecurity requirements.
Plant-floor systems for manufacturing
Predictive maintenance, vision inspection and forecasting that connect plant data to the business.
Data and AI for agriculture
Crop, sensor and imagery analytics designed for patchy connectivity and one growing season a year.
Retail operations and customer data
Demand forecasting, personalisation and unified customer data, tuned to the trading calendar.
FAQs
What buyers ask before a build.
That depends on how ready your data is and how deep the integration goes, so we don't quote a duration before the audit. The audit produces a phased plan instead: what gets built, in what order, and what has to be true before each phase begins.
Real examples of the task, and someone who can say which outputs are right. Database exports, documents, tickets and audio all work, alone or mixed. Cleaning and labelling are part of the build, so the dataset doesn't need to be perfect on day one.
The test set decides. Retrieval fixes knowledge that is missing or goes stale. Fine-tuning fixes tone, format and terminology. Training from scratch is for domains with no public equivalent, and it is rarely the first answer.
A deployed model, the evaluation set it was judged on, the training and deployment code, a model card describing where it works and where it doesn't, and runbooks for monitoring and retraining. The exact list is written into the scope before work starts.
Yes. Open-weight models can run on your own GPUs, inside a private VPC, or in an air-gapped environment. Hosted model APIs are one option among several, not a requirement.
Pick one decision.
Measure before you build.
Tell us which decision a model should support and what a wrong answer costs. The first conversation covers your data and how the result will be judged. If an off-the-shelf model already passes, that is the answer you get.
Have a project in mind?
Bring the problem. The first call is about specifics, not slides.