RAG development measured, not guessed

Most RAG projects fail at retrieval, not at generation. We build the ingestion and search layer first, then measure it.

RAG development means building retrieval-augmented generation: a pipeline that ingests your documents, chunks and embeds them, searches the resulting index at query time, and gives a language model the right context so its answers are grounded in your data and can cite sources. It is for teams whose knowledge lives in PDFs, help centres, CMS content, product catalogues or support tickets. M Tech Solutions, a software studio founded in 2023 in Craiova, Romania, delivers this for clients in the EU and North America, in English and Romanian. We run about a week of discovery, prove retrieval quality on a measured evaluation set, then build in two-week sprints with a demo every Friday and stay on call for the first month after launch. Discovery and MVP scopes have a fixed price.

What we build

  • Ingestion for PDFs, HTML, CMS exports, product catalogues and support tickets, with incremental re-indexing.
  • Chunking strategies tuned per content type, not one global setting.
  • Embeddings and vector indexing in Postgres/pgvector, Pinecone or Weaviate.
  • Hybrid search — keyword plus semantic — with re-ranking and citation surfacing.
  • Permission-aware retrieval so users only ever see their own tenant data.
  • Retrieval evaluation sets so quality is a number you can watch, not a feeling.
EXISTING PRODUCTUser questionone surfaceEmbedquery → vectorHybrid retrievalpgvector + tsvectorRe-rank20 → 5 chunksPrompt + LLMchunks with stable IDsTenant + permission filterinside the same queryRetrieval trace loggedquery · filters · IDs · scores · promptAnswer with citationsrefuses outside the corpus
Anatomy of one RAG request inside an existing product

How we work

Discover takes about a week: we look at the corpus, the questions people actually ask and how the answers will be used. Then we build a retrieval baseline and measure it before any interface exists.

Shape defines the index, the chunking and the answer format. Build runs in two-week sprints with a Friday demo. Launch adds observability for retrieval hit rate, latency and token usage, plus a runbook — and we stay on call for a month.

~1 WEEKDiscoverproblem, users, constraintsspike for the risky part01DECISIONSShapewhat is built, what is cutmodels and infrastructure022-WEEK SPRINTSBuildshippable incrementslive demo every Friday031 MONTH ON CALLLaunchhardening · observabilityrunbook · a month on call04kickoffweek 1sprint 1sprint 2sprint 3go-live+1 month
How an engagement runs: discovery, shaping, two-week sprints, launch with a month on call

The stack we use

Python and TypeScript services, Postgres with pgvector as the default store, Pinecone or Weaviate when the workload calls for it, Redis for caching, Kafka for durable ingestion pipelines. Models from OpenAI and Anthropic, orchestrated directly or through LangChain.

Deployment on AWS, GCP or Vercel, with the retrieval layer treated like any other production service.

When we are a fit

  • You have a large body of content and a chatbot that keeps inventing answers.
  • Answers must cite their source, and wrong answers have a real cost.
  • The corpus changes often and re-indexing has to be incremental and boring.
  • Multiple tenants share one index and must never see each other’s documents.

How engagements work

A retrieval discovery — corpus review, baseline pipeline, evaluation set — is fixed-price and gives you a number for quality before you commit to a product build. Ongoing work runs time and materials.

We kick off within 7–10 days and reply to your enquiry within one business day.

Frequently asked questions

How do you know whether the retrieval is good?

We build an evaluation set from real questions and expected sources, then measure retrieval before and after every change. Quality becomes a number in a dashboard rather than an opinion in a meeting.

Which vector database should we use?

Postgres with pgvector is our default because it keeps one database and one backup process. We move to Pinecone or Weaviate when scale or specific index features justify it.

Can RAG work on multi-tenant data?

Yes — retrieval is filtered by tenant and permissions, so a query can only reach documents the user is allowed to see. We treat that as a security requirement, not a feature flag.

Can you add RAG to a product we already run?

That is the usual case. We start with a spike inside your stack and a vertical slice in production, not a separate demo environment.

How long does a first RAG build take?

It depends on the corpus, but we work in two-week sprints with a live demo every Friday, so you see the retrieval layer working early rather than at the end.

Tell us what you are building

We reply within one business day, and most projects kick off within 7–10 days.