Hire a RAG Engineer
Hire a RAG engineer to build retrieval-augmented generation over your own data — chunking, embeddings, pgvector/HNSW, hybrid search, reranking, and evals. Remote, senior.
Want to hire a RAG engineer to make an LLM answer from your data instead of making things up? I’m Kuldeep Pisda — a senior backend engineer and former startup CTO in Bengaluru who has built retrieval and semantic search in production, including Hindi-language semantic search on PostgreSQL with pgvector.
What I build
- Retrieval pipelines — ingestion, chunking that respects document structure, embedding, and the storage/index choice that fits your recall and latency targets.
- pgvector and vector stores — HNSW/IVFFlat indexes on PostgreSQL (so your vectors live next to your data), or a dedicated vector DB when that’s genuinely warranted.
- Hybrid search — combining keyword/full-text with vector similarity, because pure embeddings miss exact matches and pure keyword misses meaning.
- Reranking — a second-stage reranker so the top results are the most relevant, not just the nearest vectors.
- Grounding and citations — answers tied back to source passages, so users (and you) can verify what the model claimed.
- Evals — a retrieval/answer eval set so you can tell whether a change helped, instead of guessing from a handful of demos.
Why PostgreSQL-native RAG is often the right call
I’ve published the full build log: Hindi semantic search on pgvector, in production on a 30,000-user platform. It’s exactly RAG-shaped retrieval — an Indic-SBERT embedding sidecar, roughly 1.2 million passage-level chunks under an HNSW index, and hybrid search that fuses full-text-plus-trigram with vector similarity via reciprocal rank fusion. The results are measured, not vibes: on ~200 hand-labelled real queries, top-3 relevance went from 0.41 to 0.87, the fused query settled around 240ms at p95, and the HNSW index took the vector arm from a 31-second sequential scan to 204ms. If your data already lives in Postgres, pgvector lets retrieval sit beside it — one database, transactional consistency, no sync job — and I’ll tell you honestly when your scale genuinely justifies a dedicated vector store instead. If you want the concepts before the code, start with my plain-language RAG explainer.
How engagements work
A focused build of a retrieval feature, a rescue of a RAG prototype that hallucinates or returns junk, or a review of an existing pipeline’s chunking, indexing, and eval strategy. Remote, IST, US/EU overlap.
FAQ
Why does our RAG return irrelevant answers? Usually chunking or retrieval, not the model — bad chunk boundaries, no hybrid search, or no reranking. That’s the first thing I’d look at.
pgvector or a dedicated vector database? Depends on scale and ops appetite. For most teams already on Postgres, pgvector is simpler and plenty fast; I’ll be honest about where it stops being enough.
Can you cut hallucinations? Better retrieval, grounding with citations, and refusing to answer when confidence is low all help. It’s an engineering problem, not a prompt trick.
How do we know it’s improving? Evals — I’ll set up a retrieval/answer eval set so changes are measured, not vibes.
What does it cost? Most RAG builds start with a $4,000 audit of your pipeline — written findings with ranked fixes in 7 calendar days plus a 60-minute walkthrough call — after which the build is quoted in writing, with the audit fee credited if we start within 60 days. A second opinion on one decision is $500: a 90-minute call and a written recommendation within 48 hours. All prices in USD plus GST where applicable, and the cost is in writing before we start.
Do you also do agents and general LLM work? Yes — see hire an LLM engineer.
Let’s talk
Tell me what you want the model to answer from — get in touch, or grab a time below:
Related: Hire an LLM Engineer · Hire an AI Engineer in India · Hire a PostgreSQL Expert · Hire a Python Consultant