Train for your task. Test before and after.
Fine-tuning is additional training of an existing model on examples from your task. First we test whether changing the prompt is enough, then compare training against answer quality and running cost.
Who this is for
- Your examples reveal a task, terminology or output-format gap.
- You need to evaluate Hebrew or another workload-specific requirement before committing to training.
What you receive
- Held-out evaluation examples and agreed quality checks.
- A comparison of the baseline and tested candidates.
- Training artifacts and configuration where training is approved and licensing permits delivery.
- Deployment measurements and operating instructions within the agreed scope.
How it runs
Build the evaluation
Separate training examples from the examples used to judge the result.
Test the intervention
Compare prompt changes and training against the starting model.
Check the deployment
Measure quality, memory and response time together before selecting the result.
Hebrew quality starts with your examples
We research Hebrew models and how they split text into tokens, the text units a model processes. Fewer tokens do not guarantee better answers. Answer quality needs testing on examples from your task. What are tokens, prompts and fine-tuning?
Measurement can change the decision to train
Before we recommend training, we measure the base model on your task. Our published notes show how we separate a measurement artefact from a real gap before anyone spends on a fine-tune.
Browse the researchScope, handover and support
Your proposal sets out the work, price, start and handover dates, and what is needed from you. Hardware, cloud charges, engineering and ongoing operation belong in the cost discussion. On-site days and continuing support are agreed as part of the engagement. Our engineers keep supporting the systems they build under those terms.
Questions about the work
How is the price decided?
From your workload, hardware and the implementation and support scope we agree together. Your proposal separates the engineering work from hardware, cloud and ongoing operating costs.
Who keeps supporting the system?
We agree support coverage, on-site work and how to handle problems before starting.
Do I need to buy hardware first?
No. Start with your workload and budget. We compare the options before recommending a purchase or deployment.