[Case Study] From ₹20 Lakh to ₹3 Lakh a Month: Rebuilding Enterprise RAG for Real Estate

Industry: Real estate, property operations, and enterprise services
Client: Large integrated real-estate group, identity withheld
Use case: Enterprise retrieval-augmented generation across real-estate documents and internal workflows
Delivered scope: Replacement of the major ingestion, parsing, retrieval, and model layers of an existing managed-cloud RAG system with domain-aware retrieval and an on-premise small language model
Disclosure: The client has been anonymized. The architecture and ₹20 lakh to ₹3 lakh monthly run-rate figures come from the Conscious Engines engagement record. The figures are presented as reported run-rates, not as an independently audited comparison of matched production periods.

1. Outcome at a Glance

The client's enterprise RAG system already worked. The problem was that its economics did not scale.

Conscious Engines rebuilt the major layers of the system around the client's real-estate language, document structures, and expected outputs. The replacement combined domain-specific ingestion and retrieval with an on-premise SLM, reducing dependence on usage-priced external model services.

The engagement record reports a reduction in monthly run-rate from approximately ₹20 lakh to approximately ₹3 lakh.

The reduction is economically significant. The previous run-rate was approximately 6.7 times the new reported run-rate. But cost alone does not establish success. A valid comparison must show that the rebuilt system processed a comparable workload and maintained an agreed level of answer quality, latency, availability, security, and human-review effort.

This distinction matters because RAG cost can be made artificially low by answering fewer questions, retrieving less evidence, using stale indexes, accepting lower quality, or moving work to employees. The credible claim is therefore not merely “85% cheaper.” It is:

The system's reported monthly run-rate fell by approximately 85% after the core RAG architecture was rebuilt. The public claim is limited to the reported run-rate change because matched traffic, quality, and full-cost data are not disclosed.

That wording is specific, strong, and defensible.

2. Why a Working RAG System Became Too Expensive

Enterprise RAG has several cost centers. The language-model API is visible, but it is not the whole bill.

total RAG cost = ingestion + parsing + embeddings + storage + retrieval + reranking + generation + orchestration + observability + human review

In a real-estate organization, documents are numerous, heterogeneous, and frequently versioned. A corpus can include agreements, technical reports, operating procedures, property records, vendor documents, project material, commercial correspondence, policies, presentations, and structured system exports. The exact corpus for this engagement is confidential, but the engineering problem is consistent across large property businesses.

Generic ingestion creates hidden waste

Real-estate documents do not behave like clean web pages. They contain repeated headers, schedules, annexures, scanned pages, tables, drawings, footnotes, cross-references, signature pages, and nested commercial definitions.

A generic parser can create several forms of waste:

• duplicate chunks from headers, footers, and repeated schedules;
• fragmented tables with lost row and column relationships;
• clauses separated from the definitions that control their meaning;
• page-level chunks that are too broad for precise retrieval;
• sentence-level chunks that lose document structure;
• repeated re-embedding when only a small part of a document changed;
• poor metadata that forces the retriever to search the entire corpus;
• longer retrieved contexts sent to expensive models.

Every weak ingestion decision creates downstream cost. Bad chunks increase the number of retrieval candidates. Poor retrieval increases reranking and context size. Oversized context increases generation cost and latency. Weak answers create more retries and human review.

A general model can be expensive in two ways

The first cost is direct: input tokens, output tokens, requests, provisioned throughput, and related managed services.

The second cost is architectural. If the model is expected to compensate for poor parsing, weak metadata, missing business rules, and generic retrieval, every request becomes larger and more complex than necessary.

For bounded enterprise tasks, the strongest general model may be used because the surrounding system is weak. That is an expensive substitute for better system design.

Cost should be normalized by useful work

Monthly cloud spend is a useful finance number, but it does not explain unit economics. A production system should measure:

• cost per query;
• cost per successfully completed retrieval;
• cost per grounded answer;
• cost per answer accepted without rework;
• cost per document ingested or refreshed;
• cost per active user;
• cost per business workflow completed.

The most useful denominator is usually cost per accepted answer or cost per completed business task. This prevents the team from declaring victory after reducing tokens while answer quality declines.

The problem in this case was therefore not simply that a cloud bill was high. The existing architecture coupled enterprise usage to a high variable cost without using enough domain structure to control retrieval and inference.

3. What Was Rebuilt

Conscious Engines replaced the expensive path through the system rather than applying a single optimization to the existing stack.

The high-level flow became:

enterprise documents and records

-> domain-aware parsing and metadata

-> structured chunks and embeddings

-> retrieval and optional reranking

-> on-premise SLM

-> grounded response for the authorized user

Domain-aware ingestion did more work before inference

The redesign moved intelligence earlier in the pipeline. Instead of sending loosely relevant content to a large model and asking it to resolve ambiguity, ingestion and retrieval prepared a smaller, better evidence set.

For real-estate content, a domain schema can include fields such as document type, property or project, counterparty, jurisdiction, department, effective date, version, confidentiality level, approval status, and source system. The exact schema used in this engagement is not disclosed. These are representative controls that make a production corpus easier to filter and audit.

The principle is simple:

better metadata -> smaller search space -> fewer retrieved tokens -> lower inference cost -> clearer citations

The SLM handled the bounded language task

The on-premise SLM did not need to reproduce the full capability of a frontier model. It needed to perform the client's recurring retrieval and response task at the required quality.

Suitable SLM work can include:

• classifying the user's question;
• selecting a retrieval route;
• identifying properties, dates, parties, document types, and other entities;
• reformulating a query using domain terminology;
• extracting structured fields;
• summarizing retrieved evidence;
• producing a response in the required format;
• abstaining or escalating when evidence is insufficient.

This is the practical reason a smaller model can create a large cost reduction. The system narrows the task before the model sees it.

On-premise did not mean “free”

Private inference replaces one cost structure with another. The complete post-migration cost should include:

• compute hardware or cloud-reserved capacity;
• depreciation or lease treatment;
• power, networking, and storage;
• inference-serving software;
• monitoring and security;
• model updates and evaluation;
• platform engineering and support;
• idle capacity and peak-capacity headroom;
• any external-model fallback traffic.

If the reported ₹3 lakh figure excludes material components that were included in the ₹20 lakh baseline, the comparison must be restated. A finance-approved total-cost model is more persuasive than a narrow API comparison.

The model was one part of the saving

It would be misleading to attribute the entire reduction to moving inference on-premise. The engagement scope describes a replacement across ingestion, parsing, retrieval, and model layers. Savings can come from fewer indexed duplicates, fewer retrieved tokens, fewer retries, smaller prompts, lower external-model usage, better caching, and more efficient model serving.

This is why enterprise AI cost reduction is an architectural problem, not merely a model-pricing exercise.

4. How Production Economics Should Be Measured

Before the headline becomes a public claim, the old and new systems should be compared over matched periods or through a controlled replay.

Normalize the workload

At minimum, record:

A controlled replay is particularly useful. The team can run the same representative query set through both architectures, then compare cost and quality under the same traffic distribution.

Measure quality by failure mode

One blended “accuracy” number is inadequate for enterprise RAG. The evaluation should separate:

• retrieval recall: did the correct evidence enter the candidate set?
• ranking quality: did the system place the best evidence high enough?
• citation correctness: does each citation support the associated claim?
• groundedness: is the answer limited to retrieved evidence?
• completeness: did the answer include every required element?
• abstention: did the system refuse when evidence was absent or conflicting?
• access correctness: did retrieval respect the user's permissions?
• format compliance: did the response match the workflow's required structure?
• human acceptance: was the result usable without material correction?

The model should be evaluated on the client's own difficult questions, not generic benchmarks. A useful test set includes common queries, rare clauses, conflicting versions, scanned documents, tables, ambiguous entity names, missing evidence, and requests the user is not authorized to answer.

This is the same principle behind treating the enterprise evaluation set as a strategic asset.

Report a unit-economics scorecard

The engagement record supports the monthly run-rate figures. The operating measures required to normalize those figures are not public:

A fully normalized result would read: 85% lower monthly cost at comparable production traffic and accepted-answer quality. Until that matched comparison is available, “reported” and “approximately” are essential parts of the claim.

Extend the platform only after the base economics are verified

The rebuilt system can support additional real-estate and facilities workflows, but the following are roadmap opportunities, not claims about the delivered scope.

Each additional workflow should reuse the platform but own its evaluation set, permission rules, and business KPI. A common RAG layer does not make every use case equally safe.

5. What Enterprise Buyers Should Take Away

This case is useful because the original system was not a failed prototype. It was a functioning RAG implementation with an unsustainable cost structure. The improvement came from rebuilding the system around the actual task rather than continuing to pay a general-purpose architecture to absorb every inefficiency.

There are six practical lessons.

1. Start with cost per accepted answer. Monthly spend is the symptom. Unit economics show whether the system becomes more efficient as adoption grows.
2. Fix ingestion before buying more model capacity. Poor parsing and chunking increase every downstream cost.
3. Use domain structure to reduce model work. Metadata, filters, document hierarchy, and expected-output schemas create cheaper and more reliable prompts.
4. Give each model a defined job. A private SLM can handle frequent bounded work. Larger external models can remain available for justified exceptions.
5. Compare full costs. On-premise compute, platform labor, fallbacks, and human review belong in the new baseline.
6. Prove quality on the enterprise's own difficult cases. Generic benchmarks cannot establish production fitness for proprietary real-estate documents.

Production evidence standard

The immediate next step is not another feature. It is a matched production scorecard that turns an impressive cost number into a durable business case.

For a buyer evaluating the same problem, the useful diagnostic is straightforward: export 30 to 90 days of model, retrieval, ingestion, infrastructure, and human-review activity; build a cost-per-outcome baseline; replay a representative evaluation set; and identify which layers create cost without improving acceptance quality.

Related Conscious Engines research

• The intelligent property portfolio
• From work order to first-time fix
• The building that explains its energy use
• Cut the AI bill before it scales
• Build AI FinOps around cost per outcome
• Why one model is not an enterprise AI strategy
• Why your evaluation set is your AI moat

Sources and evidence boundaries

• Conscious Engines engagement record. It is the source for the previous architecture, rebuilt layers, on-premise SLM, and ₹20 lakh to ₹3 lakh monthly run-rate. The client's identity is intentionally withheld.
• The 85% reduction, ₹17 lakh monthly difference, and annualized figures are mathematical derivations from the internally reported monthly run-rates. They are not independently audited or evidence of 12 completed months at the new cost.
• Production traffic, answer quality, latency, availability, hardware cost, and human-review comparisons are not publicly disclosed. The headline should therefore be read as a reported run-rate change rather than a normalized independent audit.