AI and machine learning development
Almost all the business value in AI right now comes from wiring good models into a product properly — retrieval, evaluation, guardrails, permissions, cost control — not from training a model of your own. We build that layer, and we say plainly when a rules table or a SQL query would do the job better.
Who this is for
- You have a corpus — contracts, tickets, manuals, claims, lecture notes — and people spend their day reading it to find one paragraph.
- You shipped an LLM feature quickly, it demos well, and now nobody can tell whether last week's prompt change made it better or worse.
- Your token spend is growing faster than usage and you cannot attribute a rupee of it to a feature or a customer.
- Someone above you wants AI in the product and you need an engineer who will tell you which parts of the idea are real.
What usually goes wrong
The problems this work exists to solve
The notebook demo works. Production does not.
A model call is a slow, non-deterministic, occasionally failing network dependency — closer to a third-party payment API than to a function call. We treat it that way: explicit timeout budget, bounded retries with idempotency so a retried generation does not double-charge or double-write, a circuit breaker and a fallback model for provider overload, streaming for anything a human waits on, and a queue for anything that takes longer than a request should. Structured output is validated against a schema with a bounded repair loop, and a parse failure is a handled outcome rather than a stack trace.
Nobody can say whether a change improved it.
Before we tune anything, we build a labelled evaluation set from real traffic, including the ambiguous cases and the ones where the correct answer is "this is not in the documents". Retrieval and generation are measured separately — recall on the retrieval step, faithfulness and correctness on the answer — because when quality drops you need to know which half broke. The harness runs in CI on every prompt, chunker or model change, an LLM judge is calibrated against a human-labelled subset rather than trusted on its own, and new versions ship behind a flag so live traffic can be compared instead of guessed at.
The retrieval is the problem, not the model.
Most RAG failures we are called in to fix are search failures. Fixed-size chunking splits a table across two chunks, so the number and its header never appear together. An embedding model that has never seen your product vocabulary ranks a marketing page above the spec. Nothing filters on document status, so a superseded policy answers a live question. We chunk on document structure rather than token count, run hybrid search (keyword plus vector) with a reranker over the merged candidates, carry metadata filters — tenant, role, effective date, document state — as first-class predicates inside the query, and return the source span with every answer so a reviewer can check it in one click.
Hallucination is being treated as a prompt-writing problem.
Asking a model politely not to invent things is not a control. Constraint is. Grounded answers must cite retrieved spans, and a post-generation check confirms each claim maps back to retrieved text. Abstention is a designed, tested output path, not a failure — a system that says "not in the documents" is more useful than one that is confident and wrong. Extraction is validated against a schema and against character offsets in the source, so a field that cannot be located in the document is flagged rather than filled. Free text never triggers an irreversible action: the model proposes, a deterministic rule or a human decides.
Token spend with no unit economics.
Cost is attributed per request, per feature and per tenant in the same trace that carries latency, so spend is a metric you can alert on rather than an invoice you read later. Stable system prefixes use provider prompt caching. Small models handle routing, classification and extraction; the expensive model is reserved for synthesis. Context is capped by retrieval quality rather than by stuffing the top fifty chunks, because more context costs more, answers slower, and often scores worse. Offline work runs in batches. Where a task recurs at volume, we test whether an embedding plus a small classifier beats a model call outright — frequently it does, for a fraction of the price.
The model was the wrong tool for the job.
This is the most over-sold category in software, so we start every engagement by asking which decision changes and who acts on it. If eligibility is "income above X and age under Y", that is a rules table with unit tests: cheaper, instant, explainable to a regulator, and it does not drift. If the question is "which customers churned last quarter", that is SQL. If a keyword index answers it, we ship the index. Machine learning earns its place when the rule cannot be written down — unstructured text, images, ranking under many weak signals, patterns that shift with data. We would rather scope you out of an AI project than build one that quietly underperforms a spreadsheet.
Scope
What you actually get
Retrieval pipeline you can debug
Ingestion and change detection, structure-aware chunking, embedding generation, a hybrid index with a reranker, and a retrieval API that returns citations. Plus the part usually missing: a trace view that shows, for any answer a user complains about, exactly which chunks were retrieved, in what order, and what the model was sent.
Evaluation harness
A versioned golden set drawn from your real data, per-case assertions, retrieval and generation metrics reported separately, pairwise comparison between candidate versions, and a CI job that fails a pull request which regresses quality. This is what turns prompt work from opinion into engineering.
Document extraction with human review
Layout-aware parsing and OCR, field extraction to a defined schema with source offsets, validation rules, and confidence thresholds that route uncertain documents to a review queue. Reviewer corrections are captured as labelled data, which becomes the next evaluation set and, where it is worth it, fine-tuning data.
Classification, ranking and recommendation
Supervised models where you have labels, candidate generation plus a ranking stage where you have interactions, cold-start handling that does not embarrass the product on day one, and a deterministic business-rules layer over model output so merchandising, compliance or pedagogy can override the score.
Model gateway and integration layer
One interface in front of every provider: key management, per-tenant rate limiting and budgets, retries and fallbacks, response caching, redaction before egress, and an audit log of prompts, retrieved chunk ids, model version and output. Swapping a provider becomes a config change instead of a refactor.
Serving and MLOps for your own models
Training and feature pipelines, experiment tracking, model registry and versioning, batch versus online inference split, GPU or CPU serving sized to actual traffic, and drift and quality monitoring on live predictions with a documented rollback to the previous model version.
A written assessment when the answer is no
If the shortest path to the outcome is a rules engine, a better search index, or fixing the data upstream, you get that written up with the reasoning and the rough shape of the alternative — not a model built to justify the engagement.
Technology
Technology options
We are technology-agnostic. These are the choices we reach for, and how the decision actually gets made.
Model access
The trade-off is data path against operating burden. Hosted APIs give you the strongest models with no GPU capacity planning, but your data leaves your network and cost scales linearly with tokens forever. Self-hosted open weights keep everything inside your VPC and turn a per-token bill into a fixed GPU bill, at the price of owning batching, upgrades and idle capacity. Region-pinned cloud-vendor endpoints sit in between. The decision is usually made by data residency rules and steady-state volume, not by benchmark scores.
Vector and search storage
If you already run PostgreSQL and the corpus is moderate, pgvector avoids a second datastore and — more importantly — lets permission filters and business predicates sit in the same query as the similarity search, which is where post-filtering systems leak. A dedicated vector store earns its place at high vector counts, heavy filtered-ANN workloads, or when index rebuilds must not touch the transactional database. Almost every serious system ends up hybrid: keyword search catches exact identifiers and part numbers that embeddings blur.
Python and modelling stack
For tabular problems, gradient-boosted trees usually beat a neural network, train in minutes on a laptop, and give you feature importances a business owner can argue with. Deep learning earns its place on text, images, audio, and anywhere you need embeddings. Between the two frameworks there is no meaningful capability gap for applied work — we write PyTorch for new models and maintain TensorFlow and Keras where your existing pipelines, TF Serving deployments or TFLite targets already live.
Document and data processing
Cloud OCR is markedly better on forms, tables and poor scans, but it is a per-page cost and a data-egress decision that has to survive your privacy review. Open-source parsing keeps every page inside your infrastructure and is fine on born-digital PDFs, weaker on handwriting and complex tables. Many builds split the corpus: cheap local parsing for the clean majority, paid OCR for the awkward tail.
Orchestration and serving
We are deliberately conservative about heavy agent frameworks. Anything that hides the prompt, the retrieval call and the control flow behind abstraction makes a 2am incident much harder to diagnose, and the abstraction rarely survives the second real requirement. Plain Python with explicit steps, typed inputs and traces at every hop is easier to debug, cheaper to change, and no slower to write.
How it runs
The shape of the engagement
- 01
Name the decision, not the technology
First conversation is about what someone does today by hand, how long it takes, what happens when they get it wrong, and what accuracy would be good enough to change the workflow. If that turns out to be a rule, a query or a search index, we say so before anyone writes a prompt. This is the step most AI projects skip and the reason most of them stall.
- 02
Look at the real data and set a baseline
We read actual documents, tickets or events — not a sanitised sample — and build the least clever thing that could work: keyword search, a regex, the majority class, or a measurement of how accurate the humans currently are. That number is recorded. Everything built afterwards is judged against it, which prevents the common outcome of an impressive-looking model that does not beat what you already had.
- 03
Build the evaluation set before tuning anything
Cases are drawn from real traffic with a domain expert, including the ambiguous ones, the adversarial ones and the ones that should return an abstention. This takes real hours from someone on your side and is non-negotiable — without it, prompt and retrieval work is opinion exchange with a bill attached.
- 04
Ship one thin vertical slice
One path from ingestion through retrieval to the interface, with citations, permissions and tracing in place from the start. It goes in front of the people who currently do the task by hand, behind a feature flag. Their complaints are more informative than any benchmark, and the traces tell us whether each complaint was a retrieval failure or a generation failure.
- 05
Tune against measurements, one variable at a time
Chunking strategy, embedding model, hybrid weighting, reranker, context size, prompt, model tier — each changed on its own and scored against the evaluation set, with latency and cost per request recorded next to the quality number. This is how you find out that a smaller model with better retrieval beats a larger model with worse retrieval, which it often does.
- 06
Harden, monitor, hand over
Abstain paths, human review queues, per-tenant budgets and rate limits, redaction on egress, an audit log, and drift monitoring on live traffic. Then documentation your team can act on: how to add a document source, how to change a prompt safely, how to read a trace, and how to roll back a prompt or model version in one step.
Engineering
Architecture, security and performance
The decisions that are expensive to change later, and where we stand on them.
Architecture
- The model is a dependency, not the application
- Every model call sits behind one internal interface. Business rules, permissions, persistence and workflow stay deterministic code around it. That single boundary is what lets you run two providers side by side during an evaluation, fall back when one is overloaded, replay a production trace offline, and unit-test the entire feature with a stubbed model and no network. Applications where prompts are scattered through the codebase cannot do any of those things.
- Retrieval is a permissioned query, not a post-filter
- Tenant, role, document status and effective date are predicates inside the search, applied before candidates are scored. Filtering after generation is not a control: a chunk the user was not entitled to see has already influenced the answer once it reaches the context window, and no amount of output scrubbing undoes that. This is the single most common design flaw we find in internal RAG tools built in a hurry.
- Prompts, chunkers and indexes are versioned artefacts released together
- Changing the embedding model is a re-index, not a configuration toggle — vectors from two different models in one index silently wreck recall while every dashboard stays green. We pin the chunker version, embedding model and prompt as a set, build the new index alongside the old one, compare both against the evaluation set, then cut over. Rollback restores the previous set intact.
- Non-determinism is constrained at the edge of the domain
- Model output is validated, coerced to a schema or an enum, and range-checked before it becomes a domain object. Anything consequential — money moving, a record being amended, a message going to a customer — passes through a deterministic rule or a human approval. The model drafts and ranks; it does not execute. This also keeps the audit story simple when someone eventually asks why the system did what it did.
- Split the request path from the batch path
- Embedding, enrichment, summarisation, classification backfills and re-indexing all move to queues and scheduled jobs. Only what a waiting human needs stays in the request path. This keeps tail latency predictable, lets slow work retry without a user watching a spinner, and makes it possible to use cheaper batch pricing for the bulk of your token volume.
Security
- Decide explicitly what leaves your network
- Per feature, we map which fields reach which provider, in which region, under what retention and training terms. That map is a document your privacy reviewer can sign, not a vague assurance. It frequently produces a split design: a self-hosted open-weight model for the regulated subset of data and a hosted API for everything else, rather than one compromise applied to both.
- Redact or tokenise before the call, not after
- A model summarising a support ticket does not need the customer's full name, card number, Aadhaar or account identifier. Those fields are stripped or replaced with reversible tokens before egress and rehydrated in your own systems afterwards. It reduces the blast radius of a provider incident and often takes a workflow out of the scope of the strictest control set entirely.
- Prompt injection is an authorisation problem
- Any text pulled from a document, an email, a web page or a user upload is untrusted input, and model output derived from it is untrusted too. So: no tool executes on the model's say-so with the application's privileges, tools are allow-listed and narrow, secrets and credentials never enter a context window, and every action the model proposes is re-authorised against the actual caller's permissions. Instruction-hardening the system prompt is a mitigation, never the control.
- Audit trail for every generation
- Prompt, retrieved chunk ids, model and version, parameters, output and reviewer decision are stored with a defined retention period. You need this for incident review, for regulated workflows where someone will ask how a conclusion was reached, and because it is the raw material for the next evaluation set. That log contains customer data by definition, so it gets the same access controls and retention discipline as your production database.
- Output governance inside the product
- Machine-generated content that lands in a record is labelled as such, with its source citation attached, so downstream readers and future models can tell the difference between an extracted fact and a generated one. Customer data is kept out of shared training, and any fine-tuning corpus is built from explicitly permitted data with its provenance recorded.
Performance
- Latency measured per stage, with time-to-first-token separated out
- Retrieval, reranking, prompt assembly, first token and full completion are timed independently in the trace. They fail differently and are fixed differently. For anything a person watches, time-to-first-token with streaming is the number that governs perceived speed — a response that starts in under a second and takes eight to finish feels faster than one that appears whole after four.
- Context length is a quality lever before it is a cost lever
- Padding the context with the top fifty chunks lowers precision, buries the relevant passage in the middle, raises latency and multiplies spend. The fix is a better reranker and fewer, better chunks. We tune retrieval depth against the evaluation set rather than assuming more retrieved text produces better answers, because measurably it often does the opposite.
- Caching at three distinct levels
- Provider prompt caching for stable system prefixes and long shared instructions; an application-level cache for repeated and near-duplicate queries, keyed on normalised text or embedding similarity with a sane freshness window; and content-hashed embedding caching so re-ingestion only re-embeds documents that actually changed. The third one is what stops a nightly re-index costing more than the feature earns.
- Provider quota is your real capacity ceiling
- Autoscaling application servers does nothing when the token-per-minute limit is the constraint. Capacity planning is done against provider rate limits, with a queue and backpressure in front, per-tenant fair-share so one bulk job cannot starve interactive users, and a smaller or alternative model as the degraded path on overload responses instead of a failed request.
- Measure cost per successful outcome, not per token
- The right denominator is a resolved ticket, a correctly extracted document, an accepted recommendation. A cheaper model that needs three attempts and a human correction is not cheaper. Tracking spend per outcome is also what tells you when a small fine-tuned model or a classical classifier should replace a general model on a high-volume path.
Size of work
Where your project probably sits
A rough map so you can locate yourself before talking to us. Actual scope comes from a conversation, not a table.
| Level | Example | Engagement shape |
|---|---|---|
| Focused task | A classifier that routes an existing intake queue, an internal search over one document set with citations, or an evaluation harness and cost audit for an AI feature you already shipped. | One engineer, days to a couple of weeks, working against a data sample you provide and ending with an evaluation you can read rather than a demo you have to trust. From about Rs 25,000. |
| Feature inside an existing product | A grounded assistant over your knowledge base with tenant permissions, citations, an abstain path, an evaluation set and per-customer token budgets. | Several weeks to a couple of months. One or two engineers, plus committed review hours from someone in your team who knows the domain well enough to label answers. Weekly demos against the evaluation set. |
| Production pipeline | Document extraction at volume with human review and a correction loop, or a ranking and recommendation system with offline evaluation and online experiments, integrated into an existing operational workflow. | Multi-month engagement, a small cross-functional team including data engineering, with a named domain owner on your side and a defined path to production monitoring and handover. |
| Platform | A shared AI capability across a product suite: model gateway, provider routing and fallback, per-tenant budgets and metering, evaluation running as CI, self-hosted inference for regulated data. | Long-term engagement with a stable core team and specialists rotating in for inference infrastructure, data pipelines or fine-tuning as the roadmap needs them. |
Honest limits
When this is not what you need
Telling you this early is cheaper for both of us than discovering it in month two.
- You want a foundation model trained from scratch on your data. Almost no business needs this, and the ones that do are funding research, not buying software. Better retrieval, a fine-tuned open-weight model, or simply better data handling will get you further for a fraction of the money — and if you genuinely need original model research, you want a research lab, not us.
- The task is a rule you could write down. Eligibility checks, pricing tiers, routing by category, threshold alerts: put those in a rules table with tests. They will be faster, cheaper, explainable to an auditor, and they will not drift when the data shifts. We will tell you this on the first call rather than three months in.
- There is nobody available to judge whether an answer is correct. Evaluation needs real hours from a domain expert to label cases and settle disputes. Without that commitment, quality is unmeasurable, and we would both be guessing while the invoices continue.
- You need a consequential decision made autonomously with no human or deterministic rule in the loop — rejecting a loan, a clinical conclusion, an irreversible payment. We will design the workflow where the model drafts, ranks or extracts and something accountable decides. If autonomous action is a hard requirement, we are not the right fit.
Related work
Projects in this space
Adaptive learning platform
Content sequencing driven by learner signals rather than a fixed syllabus — the ranking and personalisation layer this page describes.
Read the case study: Adaptive learning platformClinical records integration
The kind of permissioned, structured clinical data source that document extraction and retrieval have to fit into safely.
Read the case study: Clinical records integrationHeadless commerce storefront
A catalogue and storefront migration — the layer where search, ranking and recommendation surfaces live.
Read the case study: Headless commerce storefront
Questions
Common questions
Do we need to train our own model?
Usually not. For most product problems, the ordering is: fix retrieval, then improve prompting and structure, then fine-tune a small open-weight model on your labelled data, and only then consider training anything substantial. Fine-tuning is worth it when you need a consistent output format, a narrow domain vocabulary, or lower cost on a high-volume task — not to teach a model facts, which retrieval does better and keeps current. We will tell you which rung of that ladder your problem is on.
Can you keep our data out of third-party model providers?
Yes, with trade-offs we will lay out before you choose. Options are open-weight models served inside your own VPC on GPU nodes, region-pinned cloud endpoints such as Bedrock, Vertex AI or Azure OpenAI with no-training terms, or hosted APIs with redaction and tokenisation applied before egress. Self-hosting gives you the strongest data-residency position and predictable cost at volume, but you take on capacity planning, batching and model upgrades. Many builds split the data by sensitivity rather than picking one answer for everything.
How do you stop it making things up?
By constraining rather than requesting. Answers are grounded in retrieved passages and must carry citations that a reader can check; a post-generation check verifies claims trace back to retrieved text. Extraction is validated against a schema and against character offsets in the source document, so an unlocatable field is flagged rather than invented. Abstention is a tested output path. Honest limit: this reduces and detects fabrication, it does not eliminate it, which is why anything consequential keeps a human or a deterministic rule in the decision.
How will we know it actually works?
With an evaluation set built from your real cases before any tuning starts, scored in CI on every change. Retrieval and generation are measured separately so a regression points at a cause instead of a vibe. Once live, quality is tracked on sampled real traffic alongside abstention rate, human-correction rate and cost per successful outcome. If we cannot define what "working" means numerically for your use case, that is a signal worth taking seriously before spending further.
What will the token spend look like?
It depends on tokens per request and requests per period, both of which we measure during the first working slice rather than guess at up front. Once there is a real number, the levers are known: prompt caching on stable prefixes, smaller models for routing and classification, tighter retrieval instead of oversized context, batch pricing for offline work, and caching repeated queries. We instrument cost per feature and per tenant from the start and can enforce hard budgets that degrade the feature rather than surprise you at month end.
Can you work alongside our existing Python or data team?
Yes, and it is often the better arrangement — your team knows the data and the domain, which is the expensive knowledge. We can take a defined piece such as the retrieval pipeline, the evaluation harness or the serving infrastructure, work as embedded engineers inside your workflow, or pair with your team while the practices around evaluation and cost control take root. Embedded arrangements are covered on our dedicated development team page.
PyTorch or TensorFlow — which do you use?
Both, chosen by what your team will maintain rather than by preference. PyTorch is where most new work and most published research lands, so new models default there. TensorFlow and Keras remain very much alive in production systems, especially where TF Serving, TFX pipelines or TFLite on-device deployment are already in place, and we work in them without trying to talk you into a rewrite. For tabular prediction the honest answer is neither: gradient-boosted trees will usually win, train faster and explain themselves better.
Keep reading
Related work and reading
Related services
- API development
An AI feature reaches the rest of your system as an API. Contract design, versioning, rate limiting and long-running job patterns are covered there.
- SaaS development
If the AI capability sits inside a multi-tenant product, read how tenant isolation, metering and usage-based billing are handled.
- Cloud & DevOps
GPU node pools, queue workers, batch pipelines and the tracing that makes model spend and latency visible in production.
- Software architecture consulting
When the real question is whether to build the capability at all, or where it belongs in a system you already have.
- MVP development
For an AI-first product idea that still needs its first working version in front of users.
Tell us what the model is supposed to decide
Send the workflow you want changed, a sample of the real data, and what accuracy would make it worth doing. We will come back with an honest read on whether this needs a model, a rules table, or a better search index — and what the first working slice would look like either way. Mon-Fri, 10:00-19:00 IST, from Ravet, Pune.