# AI features in your product > LLM features that work on your real data, measured before they ship. - Page: https://deependra.in/services/ai/ai-features - Type: Service, part of Applied AI engineering - Last updated: 2026-11-02 - Line page: [Applied AI engineering (AI)](https://deependra.in/services/ai) - Author: [Deependra Vishwakarma](https://deependra.in/about), senior software engineer in Mumbai ## In short RAG development and LLM integration means building AI features, such as question-answering over your own documents, that are measured on your real data before they ship. It is for product teams who want a feature customers rely on, and starts with a one-week, fixed-price scoping sprint. ## Key facts - Engagement: fixed-price - Price: Fixed-price scoping sprint, then a fixed-scope quote - Timeline: A scoping sprint first, then a timeline agreed per project - First step: **Scoping sprint (one week).** A working spike on your real data, measured against questions your users actually ask, with cost per request. - AI line: A small first step - Works with: Anthropic API, OpenAI API, Open-weight models, Python / FastAPI, Node.js, PostgreSQL + pgvector, Redis - Based in: Mumbai, India · UTC+5:30. I plan my working day around my clients' hours. The overlap with your timezone is shown on the [contact page](https://deependra.in/contact). ## What RAG development and LLM integration cover RAG development and LLM integration means building large language model features that work on your real data and are measured before they ship: search and question-answering over your documents (retrieval-augmented generation, or RAG), structured extraction, classification, drafting and summarizing, streamed into your product's interface. It is for product teams with document collections, support histories or knowledge bases, and for teams whose prototype worked in a demo and failed on real inputs. Every engagement starts with a one-week, fixed-price scoping sprint, so the idea is tested on your data before anyone commits to a build. ## Who it is for, and who it is not ### Who this is for - Product teams who want an AI feature customers will actually use - Companies with large document collections, support histories or knowledge bases - Teams whose AI prototype works in demos and fails on real inputs ### Who this is not for - Training a foundation model from scratch - Features where a wrong answer is dangerous and no person can review it ## What you get 1. A scoping report: the approach, measured quality on your data, cost per request and the risks 2. The feature itself: retrieval, prompts, structured outputs and a streaming interface 3. An evaluation set and a quality report, so changes can't silently make it worse 4. Guardrails against prompt injection and data leakage 5. Cost controls: caching, model routing and usage limits ## Scope of the scoping sprint In the scoping week I build a working spike against a sample of your real documents and run it on questions your users actually ask, collected with you on the first day. The report gives the approach, the measured quality on that set, the cost per request, the latency, and the risks, including what the feature should refuse to do. If the numbers say the feature isn't ready, the report says that too. ## What I measure before an AI feature ships The build covers the retrieval pipeline, the prompts, structured outputs that your code can check, and a streaming interface. Answers are grounded in retrieved passages and cite them, and when the evidence isn't there the feature says so or hands over to a person. Quality is measured, not felt. The evaluation set from the scoping sprint grows into a golden set that runs on every change: did retrieval find the right passages, is every claim in the answer supported by them, did the answer address the question. Exact checks are used where they're possible, model-graded checks where they're not, calibrated against human judgment. Guardrails against prompt injection and data leakage are tested the same way. Cost controls, caching, routing simple steps to smaller models and usage limits, are measured against the same scores so savings don't quietly lower quality. The method is written up in [RAG evaluation sets: what goes in and how to score them](https://deependra.in/writing/rag-evaluation-sets), and [LLM evals, guardrails and cost control](https://deependra.in/services/ai/llm-evals) applies it to a feature already in production. The same discipline ran the Zyrobe pipeline, where cost per image was a design constraint from the first day and an upload became a finished product image in 3–8 s on average. ## What it is not It is not model training: I integrate and deploy models, and build the retrieval, evaluation and safety layers around them. It is not suited to features where a wrong answer is dangerous and no person can review it. And it is not a chatbot for its own sake; the scoping sprint asks first whether a simpler search or a form would serve users better. ## How the engagement runs 1. **Scoping sprint (one week).** A working spike on your real data, measured against questions your users actually ask, with cost per request. 2. **Build.** Retrieval, prompts, structured outputs and the interface, integrated with your product. 3. **Evaluate.** A golden set of questions and expected answers, run on every change. 4. **Ship and watch.** Released behind a flag to a small group first, with quality and cost monitored in production. ## Technologies I use for this Anthropic API, OpenAI API, Open-weight models, Python / FastAPI, Node.js, PostgreSQL + pgvector, Redis ## How this works in your market ### How this works in the European Union For teams in [the European Union](https://deependra.in/markets/europe), where your data goes is decided before the first prompt. Sending personal data to a model provider is processing under the GDPR like any other, so the provider, the region and the contract terms are chosen deliberately, and open-weight models can run inside your own infrastructure when data must not leave it. If the feature talks directly to people, Article 50 of the AI Act requires that they are told they are interacting with an AI system unless that is obvious; I build that disclosure in. Confirm with your counsel which duties apply. [European Union page](https://deependra.in/markets/europe) ### How this works in Japan For teams in [Japan](https://deependra.in/markets/japan), the scoping report doubles as a specification: approach, evaluation method, quality on your data, cost per request and what happens when the answer is wrong, written so it can be translated for stakeholders. Personal data handling follows the APPI's rules on purpose and on providing data to third parties, which includes the model provider; confirm the position with your counsel. [Japan page](https://deependra.in/markets/japan) ## Case studies behind this service - [Zyrobe](https://deependra.in/work/zyrobe-ai-wardrobe): AI wardrobe app. 3–8 s average time per image, upload to result. ## Questions about AI features in your product ### Which models do you use? Whichever fits the job and the budget: Anthropic's Claude models, OpenAI, Google Gemini, or open-weight models on your own infrastructure when data can't leave it. The design keeps the model swappable. ### How do you stop the AI from making things up? Answers are grounded in retrieved sources and cite them, an evaluation set measures accuracy on your real questions, and when the model isn't sure it says so or hands over to a person. ### What will it cost to run? The scoping sprint measures cost per request on your data before you commit. Caching, smaller models for simple steps and usage limits keep it predictable. ### Can the model run on our own servers? Yes. Where data can't leave your infrastructure, I deploy open-weight models privately on your own cloud account or hardware, and compare their quality and cost with hosted APIs on your data before you commit. ### What is retrieval-augmented generation? A design where the system first retrieves relevant passages from your own documents and then gives them to the model to answer from. It keeps answers tied to your sources and lets them cite where each fact came from. ### Do we need a vector database? Often not a separate one. PostgreSQL with the pgvector extension handles many products well and keeps your data in one place. The scoping sprint shows whether search quality needs more. ### RAG or fine-tuning? Start with RAG when the answer must come from your documents: answers cite their sources, and new knowledge is added by updating the documents, without retraining a model. I integrate and deploy models rather than train them from scratch, so the scoping sprint tests the simpler design on your data first and measures it. If the numbers say it is not enough, the report says what to try next. ### How do I add a chat-with-your-documents feature? With retrieval-augmented generation: the system retrieves the relevant passages from your documents and gives them to the model to answer from, citing them. The build covers the retrieval pipeline, the prompts, structured outputs your code can check and a streaming interface, and it starts with a one-week scoping sprint on a sample of your real documents. ### How do I keep an LLM feature from leaking data? Where the data goes is decided before the first prompt: the provider, the region and the contract terms are chosen deliberately, and open-weight models can run inside your own infrastructure when data must not leave it. Guardrails against prompt injection and data leakage are then tested like everything else, with the direct and indirect cases from [prompt injection in RAG and agent systems](https://deependra.in/writing/prompt-injection-rag-agents) in the evaluation set. ## Related services - [LLM evals, guardrails and cost control](https://deependra.in/services/ai/llm-evals) (Applied AI engineering): Know whether your AI feature is getting better or worse, and what it costs. - [AI agents and MCP servers](https://deependra.in/services/ai/agents-mcp) (Applied AI engineering): Agents that act in your tools with permissions, audit logs and a person in the loop. ## Sources 1. [Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv)](https://arxiv.org/abs/2005.11401) 2. [Ragas: available metrics (faithfulness, context precision, context recall)](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/) 3. [Anthropic docs: define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) 4. [Regulation (EU) 2024/1689 (AI Act), Article 50](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) ## Related writing - [RAG evaluation sets: what goes in and how to score them](https://deependra.in/writing/rag-evaluation-sets) (2 November 2026): How to build the set of questions that tells you whether a retrieval-augmented AI feature is getting better or worse, and how to score retrieval and answers separately. - [Prompt injection in RAG and agent systems: direct, indirect, and the tests that catch it](https://deependra.in/writing/prompt-injection-rag-agents) (2 November 2026): What prompt injection is, why retrieval systems and agents are most exposed to the indirect kind, which defences actually reduce the risk, and how to test for it on every change. ## Where this work happens - [European Union](https://deependra.in/markets/europe) (Berlin, Amsterdam, Dublin): A freelance software engineer for European teams, working remotely from Mumbai with most of your working day in common. It is for product teams in Germany, the Netherlands, Ireland and the Nordics that need senior engineering, including the work behind GDPR, the Accessibility Act and the AI Act. - [Japan](https://deependra.in/markets/japan) (Tokyo): A software engineer for Japanese companies, working remotely from Mumbai with my morning in your afternoon. It is for teams modernizing legacy systems and adding AI that want detailed plans, documentation and a predictable process. ## Teams that start here - [New York, US](https://deependra.in/markets/united-states/new-york) - [San Francisco, US](https://deependra.in/markets/united-states/san-francisco) - [London, UK](https://deependra.in/markets/united-kingdom/london) - [Edinburgh, UK](https://deependra.in/markets/united-kingdom/edinburgh) - [Berlin, EU](https://deependra.in/markets/europe/berlin) - [Paris, EU](https://deependra.in/markets/europe/paris) - [Abu Dhabi, UAE](https://deependra.in/markets/uae/abu-dhabi) - [Riyadh, KSA](https://deependra.in/markets/saudi-arabia/riyadh) ## Start Book the scoping sprint: https://deependra.in/contact --- Cite as: Deependra Vishwakarma, "AI features in your product", https://deependra.in/services/ai/ai-features (last updated 2026-11-02). This is the Markdown version of https://deependra.in/services/ai/ai-features; the page is the canonical source. Start a project: https://deependra.in/contact