LLM features you can measure before they ship
Our generative AI development services put LLM features into the tools your team already uses: document search, assistants, extraction and agents. Every build starts with an evaluation set, so quality is a score on the record, not a demo.
- Evaluation set on every build
- 4–8 week PoC or MVP build
- Guardrails, cost and latency budgets
- Written proposal within two working days
What do Dignep's generative AI development services include?
We do four kinds of LLM work. Each one connects a language model to your data and your systems, then measures how often it gets the answer right. We rarely build a standalone chatbot. Most of the value is in the integration.
Answers from your own documents (RAG)
Retrieval-augmented generation lets staff or customers ask questions and get answers that cite your policies, manuals, contracts or tickets. The hard part isn't the model. It's chunking messy PDFs, keeping the index current and respecting who is allowed to see which document.
Assistants inside existing tools
Copilots that live in Slack, Microsoft Teams, your CRM, helpdesk or internal admin panel. They draft replies, summarise long threads or fill in forms. People use them because they don't have to open another app.
Document extraction and classification
Turning invoices, application forms, KYC documents, contracts or emails into structured data your systems can use. Each field carries a confidence score, and low-confidence items go to a review queue instead of straight into your database.
Agents that take actions
When the model needs to look things up, call your APIs and complete multi-step tasks, it becomes an agent. That needs tighter permissions and more testing. We cover it in detail on its own page.
AI agent developmentHow does an LLM project go from idea to production?
In four stages, and you can stop after any of them. The first two take days, not months. The prototype is where you find out whether the idea works on your real data, and it's priced so that a "no" is affordable.
Use-case scoping
We pick one workflow, name who uses it and agree what "good" looks like in numbers: the share of questions answered correctly, extraction accuracy per field, time saved per case. If we can't define success, we say so before anyone writes code.
Data readiness
We look at the actual documents, tickets or records. Are they accessible through an API? Scanned or text? Who may see what? This is where most projects slip, so we check it early and tell you what needs cleaning.
Prototype with an evaluation set
We build the smallest working version alongside a test set of real questions or documents with known correct answers. You get a score, a list of failure cases and an estimate of running cost per request. This is the PoC or AI MVP stage.
Production hardening
Guardrails on inputs and outputs, permission checks on retrieval, cost and latency budgets with alerts, logging that excludes sensitive data, fallbacks when the provider is down, and monitoring that tracks answer quality over time. Deployment and ongoing operations follow our MLOps and AI infrastructure practice.
Should you use a hosted model API or an open-weight model?
Start with a hosted API unless your data can't leave your control. Hosted models are usually more capable and need no GPUs. Open-weight models make sense when data residency, predictable cost at high volume or offline operation matter more than the last few points of quality.
| Option | Fits when | Watch out for |
|---|---|---|
| Hosted API direct from the model provider | You want the most capable models and fast iteration, and your data agreement allows it | Per-token cost at scale, provider retention terms, model versions being retired |
| Hosted model through your cloud (Azure, AWS Bedrock, Google Vertex AI) | You need a specific region, your existing cloud contract and private networking | Model availability differs by region, and new models arrive later than on the provider's own API |
| Open-weight model on your infrastructure | Data must stay in your environment or country, or volume is high and steady | GPU cost and operations, lower quality on hard reasoning, licence terms that vary by model |
| Small fine-tuned model | One narrow, repetitive task such as routing tickets or tagging documents | Needs labelled data and retraining when the categories change |
Data residency is the question that decides most of these. Some banks and public bodies can't send customer data to a provider outside their jurisdiction. In that case we design for an open-weight model from day one, rather than prototyping on a hosted API and discovering the gap later. We keep the model behind a thin interface, so switching providers means re-running the evaluation set, not a rewrite.
How do you know an LLM feature actually works?
You measure it against an evaluation harness: a fixed set of real inputs with known good outputs, scored automatically every time a prompt, model or retrieval setting changes. Without one, every change is a guess and every demo is cherry-picked.
What we put in a typical harness:
- Real questions or documents from your users, including awkward ones, and questions whose answer isn't in your data at all
- Retrieval checks: did the system find the right source passage?
- Answer checks: is the answer faithful to the source, complete, and in the right format?
- Field-level accuracy for extraction work, reported per field rather than as one average
- Latency at the 95th percentile and cost per request, so budget problems show up before launch
- Safety cases: prompt injection attempts, requests for data the user shouldn't see, off-topic requests
The harness runs in CI. A prompt change that improves one case and quietly breaks ten others doesn't get merged. You keep it after handover.
Where we've done this before
DAIR, the Dignep AI Research Unit
DAIR is our applied AI research wing, led by Dr. Yagya Raj Pandeya of Kathmandu University's Department of Artificial Intelligence. Its generative AI work covers RAG for factual, latency-conscious assistants, hallucination detection and red-teaming, and language models for Nepali and other low-resource languages.
Certifyi AI SaaS GRC platform
We designed and built Certifyi end to end. It maps controls across frameworks such as the EU AI Act, ISO/IEC 42001, NIST AI RMF and SOC 2, and uses AI-assisted workflows for evidence collection, control testing reminders and risk triage. It's a good example of AI inside a product people use daily rather than a separate chat window.
When is generative AI the wrong tool?
More often than vendors admit. If a rule, a database query or a well-designed form solves the problem, it will be cheaper, faster and easier to audit than a language model. We'll tell you when that's the case, even if it means a smaller project.
- Exact calculations and deterministic rules. Tax, pricing, eligibility checks. Use code. A model can explain the result, but it shouldn't produce it.
- Zero tolerance for error with no human review. If one wrong answer is unacceptable and nobody checks the output, don't automate it with an LLM.
- Low volume. If the task happens twenty times a month, the build and running cost rarely pays back.
- Data you can't reach. If the knowledge lives in people's heads or in systems with no export, fix that first.
When we're not the right fit: we don't train foundation models from scratch, and we're not the cheapest option for a quick chatbot on a website builder. If you need a team inside a week, our staff augmentation model starts in 5–10 working days; a full GenAI project needs scoping first.
How is a generative AI project priced?
We quote each project after a free 30-minute discovery call, with a written proposal within two working days. A proof of concept or MVP takes 4–8 weeks to build. After that, production work is either a scoped project or a dedicated team, depending on how much will change after launch.
| Stage | Model | Typical timing |
|---|---|---|
| Discovery call and scoped proposal | Free 30-minute call | Written proposal within two working days |
| PoC or MVP with evaluation set | PoC or MVP, small squad | 4–8 week build |
| Production build | Project-based, ends on milestone acceptance | 1–3 week discovery, then milestones |
| Ongoing development and operations | Dedicated team, 30 days' written notice | Team in place in 2–4 weeks |
What drives the quote: use case, data readiness, integrations, seniority mix and engagement length. Model API and GPU hosting costs are separate from our fees and depend on your usage. We estimate them during the prototype.
Related services: AI MVP development, PoC development, MLOps and AI infrastructure and AI governance and security for the risk and compliance side of an LLM rollout.
Questions about generative AI projects
How much does a generative AI project cost with Dignep?
We quote after a free 30-minute discovery call and send a written proposal within two working days. A proof of concept or MVP usually takes 4–8 weeks to build. Cost depends on the use case, data readiness, integrations, seniority mix and how long the work runs. Model API and hosting costs are separate and depend on your volume.
Can you build on our own documents without sending them to OpenAI or another provider?
Yes. If your data can't leave your infrastructure, we use an open-weight model hosted in your cloud account or on your servers, with the document index stored alongside it. Quality is usually a little lower than the largest hosted models, so we measure the gap on your evaluation set before you commit.
Do you fine-tune models?
Sometimes. Most business use cases are solved with retrieval and good prompts, which are cheaper to change. Fine-tuning makes sense for narrow, high-volume tasks such as classification or a fixed output format, where a smaller tuned model can be faster and cheaper than a large general one. We decide after the prototype, with numbers.
How do you stop the model from making things up?
You can't remove hallucination entirely, so we design around it. Answers are grounded in retrieved sources and cite them, the model is told to say when it doesn't know, and the evaluation set includes questions with no answer in your documents. For high-stakes outputs, a person reviews before anything is sent or saved.
Does it work in Nepali?
It depends on the model and the task. The large hosted models handle Nepali reasonably for reading and summarising, but quality drops for generation and for Romanised Nepali. Our research unit, DAIR, works on low-resource Nepali language models, and we test candidate models on your real Nepali text before choosing one.
Who owns the code, prompts and evaluation sets?
You do. Everything we write for your project, including prompts, evaluation data, pipelines and infrastructure code, is handed over in your repositories. Model weights from third-party providers stay under their own licences, which we review with you before choosing a model.
Have a use case in mind?
Bring one workflow and a sample of the documents or data behind it. In 30 minutes we'll tell you whether an LLM is the right tool, what a prototype would test and roughly what it would cost.
