Custom large language model training, fine-tuning and production deployment. We produce domain-specialised models that understand and speak your business with accuracy, context and authority.
Fizon Tech builds and fine-tunes large language models for businesses that need AI which understands their domain, not a generic chatbot. We work end to end: preparing and labelling your proprietary data, fine-tuning open or commercial foundation models (GPT-4/4o, LLaMA 3, Mistral), building Retrieval-Augmented Generation (RAG) pipelines so the model can answer from your live documents, and deploying a low-latency API your team can use in production.
This service suits support teams automating responses, operations teams building internal knowledge assistants, and product teams embedding AI features into their apps. Where data privacy matters, we deploy open-weight models on your own cloud or on-premise so nothing sensitive leaves your environment. Every model is benchmarked for accuracy, relevance and safety before launch, with guardrails and preference tuning to reduce hallucinations, and we retrain it as your data and needs evolve.
Most projects that reach us have already tried a prompt-only prototype and hit a wall. The answers drift, the tone is wrong, cost climbs with traffic, or the model states policy that does not exist. Those are four different problems with four different fixes, and choosing the wrong one can waste a quarter. The sections below set out how we work out which lever to pull, and what each one involves in practice.
We are a Trichy and Dubai team, founded in 2022, with 150+ projects delivered across 12+ countries, a Smart India Hackathon 2022 Grand Finale (Hardware) national win, and support from STPI Umagine Chennai. When the model work needs a product around it, our custom AI software development service and our web and mobile engineering team pick up the application layer once the model behaves the way you want.
From data preparation and fine-tuning to deployment and monitoring, we handle the full AI pipeline end to end.
We structure, clean, de-duplicate and label your proprietary data, then convert it into instruction pairs that match how the model will be prompted in production.
Starting from foundation models (GPT, LLaMA 3, Mistral and others), we run supervised fine-tuning, LoRA or QLoRA to produce a model specialised for your exact use case.
API-ready deployment on cloud infrastructure or on-premise, with continuous batching, autoscaling, latency dashboards and per-tenant cost controls.
Custom AI assistants including customer support bots, internal knowledge bases and document Q&A systems, all grounded in your actual business data.
Hybrid retrieval pipelines with reranking, so your model answers from live documents, databases and knowledge stores and cites where each claim came from.
Preference tuning, input and output guardrails and refusal paths, so the model stays on topic, declines what it should not answer and logs every decision.
Model quality tracks data quality far more closely than it tracks model size. This is where most of the work sits.
We inventory what you already hold: support tickets and their resolutions, product manuals, standard operating procedures, CRM notes, email threads, wiki pages, contracts and call transcripts. Everything is pulled into one staging store with its origin, date and access level recorded, because provenance decides what can be trained on and what can only be retrieved at query time. PDFs go through layout-aware extraction rather than a plain text dump, since tables and headings carry meaning that a naive parser destroys.
Cleaning covers near-duplicate removal, boilerplate stripping (signatures, disclaimers, navigation text), language filtering and length filtering. A PII pass detects and masks names, phone numbers, Emirates ID and Aadhaar numbers, account numbers and addresses, either redacting them or replacing them with consistent placeholders so the model learns the pattern without memorising a real person. Contradictory records are flagged rather than silently included; if two documents state different refund windows, training on both teaches the model to be inconsistent.
Supervised fine-tuning needs paired examples, not raw prose. We convert cleaned sources into instruction, input and response triples that mirror the way the model will be prompted in production, including the system prompt it will run with. Where gold answers do not exist, your subject-matter experts write or correct a first batch, and that batch is used to bootstrap the rest with review rather than blind generation. Edge cases, refusals and out-of-scope questions are labelled deliberately, because a model that has never seen "I do not have that information" will not produce it.
Before any training run we hold out a stratified test set the model never sees, covering each query type and each difficult category in proportion. Alongside it we keep a smaller frozen golden set of questions written by your team with agreed correct answers. Release decisions are made against that set later, so it is worth an afternoon of your experts' time at the start.
Fine-tuning changes how a model behaves. It is a poor and expensive way to insert facts that change weekly.
Full-parameter supervised fine-tuning updates every weight. It produces the strongest behavioural shift and needs the most memory: an 8B model in bf16 with optimiser states realistically wants an 80GB card or a multi-GPU setup, and a 70B model wants a node. We reach for it when the target behaviour is a long way from the base model and the data volume justifies the spend. Typical runs are two to three epochs at a learning rate around 1e-5, with sequence packing so tokens are not wasted on padding, and evaluation at every checkpoint to catch overfitting before it is baked in.
Low-Rank Adaptation freezes the base weights and trains small adapter matrices injected into the attention and MLP projections. Trainable parameters fall to a fraction of one per cent, so a run that would have needed a cluster fits on a single card. Ranks between 8 and 64 cover most commercial cases, with higher ranks reserved for genuinely new capabilities rather than a change of style, and learning rates an order of magnitude higher than full fine-tuning, usually 1e-4 to 2e-4. QLoRA adds 4-bit NF4 quantisation of the frozen base, which brings an 8B fine-tune within reach of one 24GB card such as an RTX 4090 and a 70B fine-tune onto a pair of A100 80GBs. Adapters are small enough to version, swap and A/B test at serving time, so one base model in memory can serve several specialised behaviours.
Supervised tuning teaches the model what a good answer looks like. Preference tuning teaches it which of two acceptable answers is better, which is how you fix tone, hedging, verbosity and refusal behaviour. Classic RLHF trains a reward model on ranked pairs and then optimises the policy against it with PPO. Direct Preference Optimisation removes the separate reward model and trains on the preference pairs directly, which is cheaper and more stable, and is usually enough for commercial work. Either route depends on the same input: a few thousand honest comparisons from people who know the domain, collected under a rubric that stops annotators drifting apart.
If the complaint is that the model does not know this month's pricing, the fix is retrieval, not training. If it will not hold to your JSON schema, try constrained decoding and a stricter system prompt first. If it is too slow or too costly, the answer is model size, caching and quantisation. We will say so before quoting for a training run, because an unnecessary fine-tune is a recurring cost, not a one-off.
A retrieval pipeline is a search system with a language model on the end. Most RAG failures are search failures.
Documents are split so a retrieved chunk carries enough context to answer without dragging in noise. We usually land between 400 and 800 tokens per chunk with 10 to 15 per cent overlap, but structure beats arithmetic: splitting on headings, clauses or ticket boundaries and keeping tables whole works better than a fixed window. Each chunk carries metadata (source, section, effective date, access group) so retrieval can filter before it ranks and so an answer can cite a real location rather than a document name.
Chunks are embedded with a model chosen for your language mix and domain, then indexed. For Arabic and English content in the UAE, or Tamil and English content in India, a multilingual embedding model earns its place. We index in pgvector when you already run PostgreSQL and the corpus is modest, and in a dedicated store such as Qdrant, Milvus or Weaviate when you need filtered search at scale, sharding or heavy write throughput. HNSW is the usual index, tuned for recall rather than raw speed, because a fast answer from the wrong chunk is worse than a slightly slower correct one.
Pure vector search misses exact identifiers, part numbers and rare terms, so we run hybrid retrieval: BM25 keyword search alongside dense vectors, fused with reciprocal rank fusion. The top 30 to 50 candidates then pass through a cross-encoder reranker, which scores the query and the chunk together and is markedly more accurate than the recall stage that fed it. Only the best three to eight survive into the prompt. For conversational use, a query rewriting step sits in front of all this, turning "what about the second one" into a self-contained question before retrieval runs.
Generation receives the retrieved passages, an instruction to answer only from them, and a defined behaviour for when the passages do not contain the answer. Every claim carries a citation back to its source chunk so a reviewer can verify it in one click. Ingestion runs on a schedule or on document-change webhooks, with deletions propagated through the index, because a retrieval store quietly serving last year's policy is a compliance problem rather than a bug.
Public leaderboards tell you very little about your use case. We benchmark on your questions.
Retrieval and generation are scored separately, because they fail for different reasons and need different fixes. Retrieval is measured on recall at k and context precision: did the right passage make it into the prompt at all. Generation is measured on faithfulness to the retrieved context, answer relevance, and exact match or F1 where the task is extraction. Separating the two tells you whether a wrong answer came from the search or the writing, which is the single most useful thing an evaluation harness can do.
For open-ended answers we score with a stronger model acting as judge against a written rubric, calibrated against a few hundred human-scored examples so we know how far that judge can be trusted. Pairwise comparison against the current production version is more reliable than absolute scoring, and it maps directly onto the decision you actually face, which is whether to ship the new version. Human review stays in the loop for the highest-risk categories.
Input filtering catches prompt injection and jailbreak patterns before they reach the model. Output filtering catches PII leakage, off-brand language and unauthorised commitments on pricing, refunds or legal matters. Topic allow-lists keep the assistant inside its remit, and any tool call with a side effect requires explicit confirmation rather than model discretion. Grounded answers with a defined refusal path handle most hallucination risk; the remainder is caught by checking generated claims against the retrieved context before the response is returned. Every request, retrieval and response is logged so an incident can be reconstructed rather than guessed at.
Nothing ships on impressions. A candidate build has to beat the current version on the golden set, hold or improve its safety-category scores, and stay inside the agreed latency and cost budgets. Failed cases are versioned alongside the model, so a regression that was fixed once cannot quietly return three releases later.
Throughput comes from batching and caching, not from raw model speed. Cost follows the same levers.
We serve with vLLM or Text Generation Inference, which use paged attention and continuous batching to keep the GPU busy across concurrent requests, and we enable prefix caching so shared system prompts and repeated context are not recomputed on every call. Quantisation to 8-bit or 4-bit (AWQ or GPTQ on GPU, GGUF where CPU or edge serving is involved) cuts memory and raises the batch size a card can hold, with an accuracy cost we measure on your golden set rather than assume. Speculative decoding with a small draft model helps latency-sensitive chat. We report time to first token and tokens per second separately, since streaming makes the first of those the number users actually feel.
Four levers do most of the work. Route by difficulty, sending everything to a small model first and escalating only when a classifier or confidence check says to. Cache identical and near-identical queries. Trim context, because better retrieval reduces token spend more than any pricing negotiation and a tight three-passage prompt costs a fraction of a twenty-passage one. Set per-key rate limits and per-tenant budgets so one runaway integration cannot produce a surprise invoice. Managed APIs bill per million tokens and suit spiky, low-volume traffic; self-hosting converts that into a fixed hourly GPU cost that gets cheaper as utilisation rises. We model both curves against your projected volume before you commit to either.
Cloud APIs ship fastest and need no capacity planning, in exchange for a third party processing your prompts and a per-token cost that scales with your success. Self-hosted open-weight models inside your own VPC or your own rack keep data within your boundary, make cost predictable, and let you pin a version so behaviour does not shift under you when a provider updates a model. The trade is that you now own uptime, GPU supply and upgrades. Many clients settle on a hybrid: sensitive workloads on self-hosted LLaMA 3 or Mistral, everything else on a commercial API. Where on-premise is the answer, our hardware sourcing and IT procurement team handles GPU server sourcing and delivery across India and the UAE.
For Indian deployments we design around the Digital Personal Data Protection Act, 2023. For UAE deployments we work to Federal Decree-Law No. 45 of 2021 on personal data protection, plus any free-zone rules that apply to you in DIFC or ADGM. In practice that means documented data flows, retention limits on prompt logs, regional hosting where residency is required, role-based access carried through into the retrieval index, and a deletion path that removes a record from the source system, the index and the logs together.
We map your exact requirements, covering what the model must know, how it communicates and where it integrates within your systems.
Collecting, cleaning and structuring your proprietary data. We select the right base model and architecture for your domain.
Fine-tuning with iterative evaluation cycles, benchmarking accuracy, relevance and safety against your real-world success criteria.
Production-ready API deployment with dashboards, usage analytics and ongoing retraining as your data and needs evolve.
A first engagement typically takes eight to twelve weeks from kick-off to production, depending on how ready the data is.
You get the dataset, the evaluation harness, the adapters or model weights and the deployment scripts. Nothing about the work is locked to us, which is the point: if you later hire an internal ML team, they inherit something they can run.
Fine-tuning adapts a foundation model such as GPT, LLaMA 3 or Mistral by further training it on your proprietary data, so it answers in your domain's terminology, your brand tone and within your rules, instead of giving generic responses.
It depends on the goal. Retrieval-Augmented Generation (RAG) is best when answers must come from live or frequently changing documents. Fine-tuning is best for consistent tone, format and behaviour. We often combine both for accuracy and control.
We work with GPT-4/4o, LLaMA 3, Mistral and other open-source models. We recommend the right base model for your use case based on accuracy needs, budget and data-privacy requirements.
Yes. For sensitive data we deploy open-source models on your own cloud or on-premise infrastructure, so your data never leaves your environment.
We ground responses with RAG, run iterative evaluation cycles against your success criteria, and apply guardrails and RLHF alignment so the model stays accurate, on-topic and safe.
Less than most teams expect, provided it is clean. For tone, format and domain vocabulary, a few hundred to a few thousand carefully written instruction pairs usually beat a large, noisy export. Volume matters more when you are teaching a genuinely new capability rather than a new style. Coverage of your awkward edge cases, including the questions the model should refuse, matters more than raw row count.
Your data stays yours, and so do the training set, the evaluation harness and the LoRA adapters or fine-tuned weights we produce. What sits underneath depends on the base model licence: some open-weight models are Apache 2.0, others such as the LLaMA family carry a community licence with conditions attached. We confirm those terms in writing before recommending a base model, so there are no surprises at commercial launch.
Send us four things: what the model should do, roughly how much material you hold, whether that material can leave your infrastructure, and what the traffic is likely to look like. We will come back with an honest read on whether retrieval, fine-tuning or simply a better prompt is the right lever, an outline plan and a cost range, usually within two working days. The quickest route is the contact form on our home page, or a call to the Trichy office if you would rather talk it through.
If you are a school or college looking for AI and robotics teaching rather than a production system, our IoT, robotics and STEM programme for students is the better place to start.
Costs in this space vary enormously, and most published figures are vague on purpose. These guides set out the real ranges and what moves them.
Stop using generic AI and get a model that knows your industry, your tone and your data.
