# Enterprise RAG Systems: Architecture, Pitfalls and What Actually Works in 2026 | Alher Tech

> Most RAG demos look great and fail in production. Learn what separates a $1M failed RAG pilot from a working enterprise deployment: chunking strategy, retrieval, evaluation, and the hybrid architectures that win.

- Canonical page: https://alhertech.com/en/ai-guides/rag-systems-enterprise/
- Site: Alher Tech (custom software, AI agents and SEO engineering, https://alhertech.com/)
- Contact: https://alhertech.com/en/contact/

---

RAG (Retrieval-Augmented Generation) demos are easy. RAG systems that hold up against millions of documents, hundreds of users and adversarial questions are very hard. Most enterprise RAG pilots in 2024-2025 launched, looked great in the boardroom and quietly died at month four. This is the architecture and process we use at Alher Tech to build RAG that survives production, covering chunking, retrieval, evaluation and the hybrid patterns that actually work.

## Why Most Enterprise RAG Fails

The pattern is consistent: pilot succeeds on a curated 100-document set. Production has 100,000+ documents with messy formatting, conflicting versions and PII. The same architecture that wowed the demo silently degrades to 60% accuracy. Three months later the project is shelved.

- Wrong assumption: 'just embed all the docs and search'. Real corpora need preprocessing, deduplication and version control.
- No evaluation: nobody measures retrieval recall, answer faithfulness or hallucination rate over time.
- Single retrieval strategy: pure vector search misses recent docs, structured queries and rare terms.
- Chunking by character count: splits sentences mid-thought, destroys context.
- No re-ranking: top-5 vector hits aren't the top-5 answers.
- Static system: no feedback loop, no fine-tuning of retrieval based on real usage.

## The Reference Architecture That Works

Production RAG in 2026 is a multi-stage pipeline, not a single vector search. The pieces:

- **Document ingestion**: Source connectors (SharePoint, Confluence, Drive, Notion, S3). Conversion to clean text (Unstructured.io, Llama Parse, Docling). Deduplication by content hash. Version tracking so updates don't double-count.
- **Chunking strategy**: Section-aware: respect headings, tables, bullets. Hybrid sizing: small chunks (200-400 tokens) for retrieval, large chunks (1500-3000 tokens) for context. Overlap of 10-20% to handle boundary topics.
- **Multi-vector embedding**: Embed the chunk + a hypothetical question (HyDE) + a summary. Retrieve on any of the three. Hits 20-30% higher recall than single-vector.
- **Hybrid retrieval**: Vector search (semantic) + BM25 (keyword) + structured filters (metadata, dates, categories). Reciprocal rank fusion to combine results. The single biggest accuracy lever.
- **Re-ranking**: Top 50 results from retrieval → cross-encoder re-ranker (Cohere Rerank, Voyage Rerank, BGE-Reranker) → top 5 to LLM. Adds 100-300ms latency but 15-25% accuracy.
- **Generation with citations**: Force the model to cite the retrieved chunks. Forces grounding. Lets users verify and lets you measure faithfulness.
- **Evaluation harness**: Question/answer pairs from real users + synthetic. Measure retrieval recall@k, citation faithfulness, hallucination rate, latency and cost. Every change goes through it.

## Choosing the Right Vector Database

We default to pgvector for new projects under 10M chunks. The operational simplicity outweighs the marginal speed gain of dedicated vector DBs at this scale.

## Chunking: The Underrated Lever

Bad chunking destroys RAG before retrieval even runs. The patterns that work:

- Respect structure: never split mid-paragraph if you can help it. Use document headings to define chunks.
- Tables get their own chunks: don't shred them across boundaries.
- Code blocks get their own chunks: keep them intact.
- Add metadata to every chunk: title, section, doc URL, last-modified date, author. Filterable retrieval depends on this.
- Multi-granularity: index small chunks for retrieval, fetch larger parent chunks (or full doc sections) for the LLM.
- Parent-document retrieval: retrieve at chunk granularity, send the full parent to the LLM. Best of both worlds.

## Evaluation: Without It, You're Guessing

RAG without evals is unmaintainable in production. The components of a real eval suite:

- **Retrieval evaluation**: Recall@k for a curated set of question/relevant-doc pairs. Tracks whether the right docs are even reaching the LLM.
- **Answer evaluation (LLM-as-judge)**: GPT-5 or Claude Opus grading answers for correctness, faithfulness, relevance. Calibrated against human judgments on a sample.
- **Hallucination detection**: Cross-check every claim in the answer against retrieved chunks. Reject answers that include uncited facts.
- **Real-user feedback**: Thumbs up/down + free-text. Flow these back into the eval set so the system improves.
- **Cost + latency tracking**: Per-query cost, p50/p95 latency. RAG that's accurate but takes 8 seconds is unusable in chat UIs.

## Cost Reality

| Component | Setup cost | Monthly run cost |
| --- | --- | --- |
| Ingestion + chunking pipeline | $15K – $80K | $300 – $3K |
| Vector DB (pgvector / Pinecone) | $5K – $30K | $200 – $5K |
| Embedding generation (OpenAI / Voyage / Cohere) | $2K – $20K initial | $200 – $2K |
| Re-ranking (Cohere Rerank, BGE) | $1K – $5K | $200 – $2K |
| LLM generation (Claude / GPT-5) | N/A | $1K – $20K depending on volume |
| Evaluation harness | $20K – $80K | $500 – $3K |
| Frontend / chat UI / orchestration | $30K – $150K | $500 – $5K |

Total first-build budget: $80K – $400K depending on scale and corpus complexity. Annual ongoing: $30K – $300K depending on usage.

## RAG Is an Engineering Discipline

The companies winning with RAG in 2026 treat it like any other production system, with measurement, observability, evaluation and continuous improvement. The ones losing built one prompt, deployed it and hoped.

If you're starting an enterprise RAG project, the playbook above isn't optional. Skipping any of it is how the project ends up shelved.

## Frequently asked questions

### Should I fine-tune a model or use RAG?

RAG for facts that change. Fine-tuning for tone, format, and stable domain knowledge. Most enterprise needs are RAG-shaped. Fine-tuning is rarely the right first move.

### Which embedding model should I use?

OpenAI text-embedding-3-large for general English. Voyage-3 for higher accuracy at higher cost. Cohere embed-multilingual for non-English. Open-source (BGE, E5) when self-hosting matters.

### How long does it take to build a RAG system?

Pilot with 1K-10K docs: 4-6 weeks. Production with 100K+ docs and proper eval: 12-20 weeks. Add 4-8 weeks for full agent integration on top of RAG.

### What's the right chunk size?

Start with 400-800 tokens for retrieval, with 10-20% overlap. Tune based on your domain: code and legal need smaller chunks; narrative content benefits from larger ones. Always validate with your eval set.

### How do I handle PII and access control?

Filter at retrieval time using user-aware metadata. Each chunk has an ACL; retrieval only returns chunks the user can see. Don't rely on the LLM to redact. Redact at ingestion or filter at retrieval.

## Related guides

- [AI agents for business: real use cases and ROI](https://alhertech.com/en/ai-guides/ai-agents-for-business/)
- [AI integration cost: 2026 budget guide](https://alhertech.com/en/ai-guides/ai-integration-cost/)
- [Our AI agent services](https://alhertech.com/en/services/ai-agents/)
- [Discuss your RAG project](https://alhertech.com/en/contact/)