AI Agent Development

RAG & LLM Integration

RAG systems that answer from your company documents and show their sources — retrieval quality measured on a test set, permissions preserved, in a 4–12 week band.

Book an intro call30 min · same-business-day reply

or fill in the form

Tell us about your project, we reply the same business day

Your details are used only to answer your request. Privacy policy

RAG (retrieval-augmented generation) integration means building the system that lets a language model find the relevant passages in your own document pool and put them in context before it writes an answer — so it answers from a document it can cite rather than from memory. GG Tech Teknoloji's RAG & LLM Integration service designs and measures retrieval before it picks a model: how documents are split, how search handles Turkish, who may see which document, and a test set that shows whether the right passage comes back. Our planning band is 4–12 weeks.

GG Tech Teknoloji estimation model — RAG & LLM Integration · Last reviewed: 2026-10-14
Typical team1 AI engineer + 1 backend developer
Calendar band4–12 weeks
Phase split20% data source analysis · 40% pipeline development · 25% evals & quality · 15% rollout

What grows the budget

  • Source variety and data dirtiness
  • Per-user access control
  • Update frequency
  • Hallucination tolerance

Signs of underbudgeting

  • No eval set
  • A "works in the demo" quality bar

These are GG Tech Teknoloji planning bands, not a quote; starting prices are on each service page. Every project is different, so the bands are deliberately wide; they assume a senior, focused team and typical scope, and your project is estimated individually.

AI Agent Development

Who is it for?

  • Companies whose people hunt for the same answers across internal documents, the wiki and old email threads.
  • Support teams that want reply drafts built from product documentation, with the source attached.
  • Legal, procurement and engineering teams working with text that changes often — regulation, contracts, technical specifications.
  • Organisations that do not want their data to leave their infrastructure and need their permission rules to hold inside the assistant too.

When is it the wrong choice?

  • What you really need is to change the model's style or output format (every answer in a fixed JSON schema, say): that is a fine-tuning job, not RAG.
  • The document pool is a few pages and rarely changes: putting the text straight into the prompt costs less than building a retrieval layer.
  • The source documents contradict each other and nobody owns them: RAG does not fix the mess, it spreads it faster — settle content ownership first.

How do we work?

  1. 1

    Document and permission inventory

    We list which sources go in (PDFs, wiki, support tickets, databases), how often each changes and who is allowed to see what. Add permissions later and the assistant can answer from a document the user was never allowed to open.

  2. 2

    Golden question set

    A set of 50–100 questions is drawn from real user questions, and for each one the document and section holding the answer is marked by hand. Every later decision is measured against this set.

  3. 3

    Chunking and metadata

    Documents are split along their own heading structure first and, where needed, by fixed size a second time; tables and code blocks stay whole. Each chunk carries its source, heading path and date.

  4. 4

    Hybrid search that handles Turkish

    Semantic search and keyword search run side by side, with stemming added on the keyword side for Turkish content. Which runs first, and whether a re-ranker is needed, is decided from the golden set's results.

  5. 5

    Answer layer and citations

    The model answers only from the retrieved chunks, shows which document it used and says so when it cannot find the answer. The model is chosen on cost, latency and whether the data may leave your infrastructure.

  6. 6

    Monitoring in production

    Unanswered questions, low-rated answers and updated documents are tracked. A new document means re-indexing, never retraining.

What do we deliver?

RAG & LLM Integration

Source and permission inventory
Golden question set and retrieval report (recall@k, MRR)
Indexing pipeline: chunking, metadata, embeddings, updates
Hybrid search, with a re-ranking layer where the numbers call for one
An answer API or assistant interface that cites its sources
Monitoring dashboard and re-indexing procedure

What sets the timeline and cost?

In our estimation model, RAG and LLM integration sits in a 4–12 week calendar band. Four things move it most: the variety and dirtiness of the sources, per-user access control, how often documents change, and how much tolerance there is for a wrong answer. A RAG system built without an eval set and accepted because "it works in the demo" is the clearest sign that the budget went to the wrong place. An assistant on your own data starts at $10,000 (excl. VAT); you get the exact budget in a written proposal after the source inventory. The Cost Drivers page explains how to read the bands.

See the cost drivers

Proof from production

2

search methods side by side: semantic via pgvector, keyword via a GIN index (the knowledge-base assistant in one of our internal tools)

1536

dimensions per embedding, searched by cosine distance on an HNSW index (same assistant)

3

open-weight models to switch between: Llama 3.1 70B, DeepSeek R1 14B, Gemma 3 27B (GG AI Assistant, our own product)

The knowledge-base assistant is described in our article "RAG or fine-tuning?". GG AI Assistant is our own product, not client work (September 2026).

Read the case study

Frequently asked questions

RAG or fine-tuning?

RAG if you want to add knowledge, fine-tuning if you want to change the model's behaviour or output format. With a document set that changes often, fine-tuning means retraining on every update; with RAG the same update is just indexing a new chunk. RAG can also show which document an answer came from. The two are not rivals: in most production systems knowledge comes from RAG and style from the prompt.

What makes RAG harder on Turkish documents?

Three things. Turkish is agglutinative: "yazılımın" and "yazılımlarımızdan" share a root, but keyword search without stemming treats them as different terms. Embedding models are unevenly balanced across languages: multilingual models are trained mostly on English, so the model has to be chosen with Turkish test questions. Case conversion: lower-casing "İ/ı" with the wrong locale makes matches fail silently. Turkish text also produces more tokens for the same number of characters, so chunk size has to be measured with the real tokenizer.

Can you build RAG without our data leaving our infrastructure?

Yes. Embeddings, search and the language model can all run on servers inside your organisation or in your own cloud account, so document content is never sent to an outside API. Our own product, GG AI Assistant, was designed on that closed-circuit principle and can switch between open-weight models. GG Tech holds ISO/IEC 27001 (information security) and ISO/IEC 42001 (AI management system) certification.

Do we need a separate vector database?

Not necessarily. PostgreSQL's pgvector extension stores vectors and runs similarity search on an HNSW index, which is often enough for small and mid-sized document pools. The knowledge-base assistant in one of our internal tools keeps 1536-dimensional vectors this way; when semantic search returns fewer than three results, keyword matching on a separate GIN index steps in.

How do we know a RAG system is working?

Measure retrieval before you judge the answers. For every question in the golden set, check whether the right chunk comes back in the first few results (recall@k) and at what rank (MRR), with the language model switched off. That separates retrieval errors from generation errors. When retrieval is right, answer quality largely follows.

Which language model do you use?

We are not tied to one. The choice depends on whether data may leave your infrastructure, the latency target, the cost per query and results on Turkish test questions. Where a closed circuit is required we look at open-weight models (the Llama, DeepSeek and Gemma families in GG AI Assistant); where it is not, commercial APIs are in the running. The decision is delivered in writing with its reasoning.

Related services

AI Agent Development

Multi-Agent Orchestration

Systems that split a job across specialist agents, each seeing only its own tools, behind one router — with approval tiers and monitoring, in an 8–20 week band.

Voice AI Agents

Real-time, low-latency voice agents and call automation.

Agentic Workflow Automation

Speed up internal processes with agent-driven automation.

Custom AI Agent Development

An AI agent that does real work in your systems, under your rules — tool catalogue, approval modes and an eval set, in a 10–24 week planning band.

AI Governance & Compliance

Policies, guardrails, and audit workflows to keep AI systems safe, explainable, and regulation-ready.

Work we delivered with this service

Related reading

Last updated:

Let's talk about your project, we reply the same business day.

A 30-minute intro call: scope, timeline band and the right team.

Clutch 5.0 · team of 20 · Çekmeköy Municipality, NSC Soft, UKX

Book an Intro Call
Write for a Quote
Message on WhatsApp
Book a callWhatsApp