AI Engineering
We build retrieval systems that cite the passage they used, fail loudly when the evidence is thin, and hold their accuracy after the corpus changes. For teams whose proof of concept demoed beautifully and started lying in month two.
Retrieval augmented generation puts your own documents in front of a language model at query time, so answers come from your contracts, tickets and policy manuals rather than the model's memory. ZenMagix provides RAG development services and LLM integration for enterprises in Mumbai and abroad, and we build for the part everyone underestimates: the retrieval, not the model. We arrived here from blockchain — years of smart contracts, wallet infrastructure and exchange systems where an unverifiable claim was a defect, not a rough edge. That work was about provenance: every value traceable to the record it came from, every state change auditable after the fact. Retrieval is the same discipline wearing different clothes. A citation that points at a passage which does not support the sentence is a data integrity bug, and it is the bug that quietly kills RAG deployments. We build the ingestion, the chunking, the hybrid retrieval and — the step most projects skip — the evaluation harness that tells you when accuracy starts sliding.
Almost no RAG project fails because the model was too weak. They fail on data quality and chunking — the corpus that worked at 200 curated PDFs collapses at 200,000 real ones.
A demo corpus is clean, small, and topically separated, so naive fixed-size chunking and cosine similarity look excellent. Production corpora are not that. They are scanned contracts where the table structure is lost in extraction, policy documents where the meaning lives in a heading three pages up that the chunk no longer carries, twelve near-identical versions of the same SOP with no recency signal, and acronyms the embedding model has never seen used the way your business uses them.
Retrieval then returns passages that are semantically adjacent and factually wrong — plausible enough that the model writes a confident answer over them, and no reviewer catches it because the citation looks legitimate. Add embedding drift when you upgrade models without re-indexing, and stale indexes where a rate changed in January but the vector store still serves December, and you have a system that is quietly wrong in ways no error log records. We fix this at ingestion: parse structure properly, chunk on semantic and document boundaries, attach metadata that filters before the vector search ever runs, and version the index so a re-embed is a deployment, not an accident.
Grounding is not a prompt instruction — it is enforced. Every claim is checked against the retrieved passage before the answer is returned, and an answer with no supporting evidence is refused rather than improvised.
Telling a model to only use the provided context reduces hallucination; it does not eliminate it. We add verification after generation. Sentences are matched back to the spans they claim to cite, and an answer whose support falls below threshold is either regenerated with different retrieval or escalated as unanswerable. That refusal path is a feature — a system that says the policy does not cover this case is worth far more to a compliance team than one that invents a clause.
The provenance layer comes straight from our ledger work: each response carries the document ID, version, chunk offsets and retrieval scores that produced it, stored so any answer given six months ago can be reconstructed exactly, including which version of the document was live at the time. That matters when a customer disputes what your assistant told them. We also treat retrieved content as untrusted input, because a document containing instructions is an injection vector, not a source. Confidence is surfaced honestly: users see when retrieval was weak, instead of receiving the same assured tone regardless of evidence.
Evaluation is the step almost every RAG project skips, and it is the reason nobody can tell you whether last week's change helped. We build the harness before we tune anything, because untested tuning is guesswork with a bill attached.
We start by assembling a golden set from your real questions — typically 150 to 400 pairs drawn from support tickets, analyst queries and the edge cases your team already argues about — each with the passage that genuinely answers it. Retrieval is then scored separately from generation, which is the distinction that makes debugging possible: recall@k and MRR tell you whether the right passage was even fetched, while faithfulness and answer relevance tell you what the model did with it.
Most teams discover their failures are 80% retrieval, and stop blaming the model. The suite runs in CI, so an embedding model swap, a chunk size change or a prompt edit produces a diff in numbers rather than a vibe. In production we sample live traffic, log retrieval scores, and alert when score distributions shift — the early signal of embedding drift or a corpus that has moved on. Cost per query is tracked in the same dashboard alongside accuracy, because the two trade against each other and the decision is a business one, not an engineering preference.
Which model you use is the least interesting decision, and the easiest to reverse. What matters is where your data goes, how you route between models, and what a query costs at ten thousand a day.
We design integrations so the model is a swappable component behind a gateway — provider changes are configuration, not a rewrite. For organisations that cannot send documents to a hosted API, we deploy open-weight models on vLLM inside your VPC or on-prem, with embeddings generated locally so no proprietary text crosses the boundary. Hybrid patterns are common and defensible: sensitive retrieval and embedding stay internal while a frontier model handles final phrasing on redacted context, under data-processing terms you have actually read.
Cost is engineered, not hoped for. Routing sends routine queries to a small model and escalates only what needs reasoning; semantic caching absorbs repeat questions; reranking a shortlist beats stuffing forty chunks into a long context window, and usually improves accuracy while cutting tokens. On fine-tuning: it is the right tool for format, tone and domain vocabulary, and the wrong tool for facts that change. If your answers must reflect a document updated yesterday, retrieval is the mechanism and fine-tuning is at best a complement. We will say so before you fund a training run.
What you get
A written assessment of your actual documents — extraction quality, structure, duplication, update frequency and access rules — followed by the chunking, embedding, indexing and retrieval design chosen for that corpus rather than a default template.
Structure-aware parsing, chunking, enrichment and embedding, running on a schedule with incremental updates, deletions honoured, and versioned indexes that can be rebuilt and rolled back without downtime.
Vector plus keyword retrieval with metadata pre-filtering, reranking, span-level citations, groundedness verification and an explicit refusal path, exposed as an API your applications call.
Your questions, your adjudicated answers, scored on retrieval and generation metrics separately, wired into CI with pass thresholds so every change to the system is measured before it reaches users.
Tracing on every query, dashboards for accuracy and cost per query, drift alerting, plus documentation and working sessions so your engineers can tune chunking and retrieval without us in the room.
How we work
Two weeks on your real documents and the questions people actually ask. We extract a sample, measure baseline retrieval on it, and tell you honestly which questions your corpus cannot answer at any budget.
Golden set assembled with your experts, metrics chosen, harness built and a deliberately simple pipeline scored against it. Every later decision is compared to this number instead of to an opinion.
Chunking, hybrid search, filters and reranking iterated against the harness until recall stops moving. Prompting, citation enforcement and refusal thresholds come after — in that order, because retrieval sets the ceiling.
Production rollout with logging and sampled human review, drift alerts on retrieval scores, and a scheduled re-index. Weekly accuracy and cost-per-query review until the numbers are predictable.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
Usually the corpus, not the model. Test sets are small, clean and topically separated; production adds near-duplicate versions, poorly extracted tables and questions whose answer spans several documents. Retrieval starts returning plausible-but-wrong passages and the model writes confidently over them. We diagnose by scoring retrieval separately from generation, which locates the failure in days.
Fine-tuning teaches format, tone and domain vocabulary. It does not reliably teach facts, and it cannot teach facts that change, because updating them means retraining. If your answers must reflect a document edited yesterday, retrieval is the mechanism. Many production systems use both: RAG for the facts, a light fine-tune for house style and structured output.
Layered. Retrieval is filtered and reranked so weak evidence rarely reaches the model. Generated sentences are then verified against the passages they cite, and answers below a support threshold are refused rather than improvised. Every response stores its document versions and chunk offsets, so any answer can be reconstructed and audited later.
Yes. We deploy open-weight models on vLLM and run embedding generation locally, inside your VPC or on-prem, so no proprietary text reaches a third party. Accuracy on complex reasoning is below frontier models, so we often run hybrid: retrieval and embeddings internal, final phrasing on a hosted model over redacted context.
Naive implementations stuff long context windows and cost several rupees per query, which breaks at volume. Reranking a shortlist, routing simple questions to smaller models and semantic caching typically cut that by five to ten times while improving accuracy. We report cost per query alongside accuracy from the first week, so scaling decisions have numbers.
A single well-defined corpus with an evaluation harness generally reaches production in eight to twelve weeks: two for the corpus audit, two to build the baseline and eval suite, then iteration on retrieval before rollout. Messy document estates, multiple access-control tiers or several source systems extend this to four or five months.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
A paid diagnostic that tells you what is worth building and what is not.
The pipelines and quality layer every AI project stalls on.
A working AI product in weeks, scoped to prove one thing to investors or users.
See also: let agents act on what retrieval finds with AI agent development · fix the pipelines and document quality upstream with data engineering · decide where retrieval is worth building at all with AI consulting
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
