AI system for real estate: where valuation accuracy drops
Manual property valuation almost always hits the same bottleneck: an analyst collects comparables by hand. Disparate transaction data sits in registries, agency exports, listings, and internal spreadsheets — with different address formats, history depth, and update frequency.
A single property takes several hours, and with a portfolio of hundreds of lots a queue forms, where a fresh valuation arrives later than the property leaves the market.
Valuation accuracy drops where data cannot be reduced to a common key. A house number is written in four variants, some transactions enter the sample twice, some — with the registration date instead of the transaction date, and renovation and floor are described in free text.
A model on such a dataset reproduces noise: two identical properties in the same building get a discrepancy within tens of percent, and price forecast errors in rare segments reach double digits.
Industry reviews on real estate valuation agree on one thing: the bottleneck is not the algorithm but the preparation of comparable data and the rules for selecting comparables.
We start with this layer — normalize addresses, flag duplicates, cut outliers, and identify segments where the sample is actually sufficient for training. Next we break down how this is addressed at the system level and what the client gets.
What changes after implementation: valuation speed and transaction coverage
We do not move valuation entirely to a model.
After implementation, three measurable values change: calculation time, the share of properties the system closes without manual intervention, and the boundaries of segments where forecast accuracy is still sufficient for a transaction.
Property valuation speed
An appraiser spends most of the time not on calculation but on collecting and normalizing comparables: area, condition, bargaining, adjustments.
A model based on CatBoost builds a preliminary value from the address and property parameters, while an engineer adds outlier cutoff rules and checkpoints.
A typical property goes from request to a finished calculation in tens of minutes instead of business days, and the appraisers' queue remains only for non-standard cases.
Forecast accuracy and segment coverage
We measure quality not by average deviation but by the share of properties falling within the target corridor — and separately by segment: new builds, resale, suburban, commercial.
Where data is scarce, the system marks the forecast as low-confidence and routes it to manual review instead of a silent error. A retrospective run on a holdout sample of confirmed transactions shows which segments can already be automated and which cannot yet.
Eliminated manual work and transaction conversion
The share of automatic calculations grows as confirmed transactions accumulate — this is an acceptance metric, not a promise. Appraisers switch to complex and disputed properties, and their throughput grows without hiring.
The client gets an answer at the moment of inquiry, while interest is still hot: response speed directly affects whether a request reaches a transaction.
Ways to build a valuation model: comparison of approaches
The choice of valuation method determines where the model is applicable at all and where it will start making errors.
Automated property valuation rests on three pillars: the volume of comparable transactions, segment homogeneity, and source data quality — area, year built, condition, distance to infrastructure.
If there is little history or it is heterogeneous, no approach will deliver a stable result across the entire portfolio.
| Option | When it fits | Limitations |
|---|---|---|
| Model on your own data | Transaction and property history has accumulated, segment is homogeneous | Requires labeling and regular retuning; makes more errors on rare segments |
| External ready-made model | You have no history of your own, need a start on mass segments | Does not know your specifics — renovation, view, building status; closed to further training |
| Hybrid approach | You have your own data, but it is insufficient for full training | Harder to maintain: monitor source alignment and version consistency |
In practice, the outcome of the comparison is decided by source data quality, not by the complexity of the chosen approach. We start by profiling the export: we check missing values, duplicates, price outliers, and discrepancies between cadastral and actual characteristics.
After such preparation, a model on your own data outperforms an external one on 2–3 segments where it previously produced scatter, and the hybrid covers those segments for which your own history is not yet sufficient.
How we implement a valuation model: stages of work
The starting point is not the choice of algorithm but the answer to what exactly the system should predict: the closed transaction price, the bargaining range, or the time on market.
Then the work proceeds in stages, and at each of them an artifact appears that can be checked before moving to the next step.
- Data audit. We check transaction and listing exports: field completeness, duplicates, discrepancies in area and number of floors, and the share of properties without coordinates. We assess whether the history is sufficient for training and which external sources are needed — transport, schools, neighborhood dynamics.
- Model design. We fix the task type, feature set, and validation method. Separately, we decide how to account for market heterogeneity: by segment, house type, district — otherwise the average error will look good, but in half the segments it will not.
- Training set assembly. We consolidate data into a single table, clean anomalies, and normalize reference data. We document the transaction selection rules in writing: the model must not learn from atypical transactions between related parties.
- Training on transactions. We train on historical closed transactions, not on the listing price — otherwise the system reproduces sellers' expectations rather than the market. We validate on a holdout time period, not on a random sample.
- Forecast quality check. We calculate median percentage error separately by segment and look at where the model errs systematically: new builds, properties without comparables, rare layouts. We translate the error into a clear value — how often the forecast falls within the target corridor.
- Handover of the model to the client. We deliver the configuration, documentation, retraining script, and quality control regulations. We agree on how we track data staleness: when the market shifts, metrics drop, and the model needs updating rather than being "treated" manually.
The acceptance point is not a general metric in a demo but a forecast on your properties, reproducible on the client's side. That is why handover and the update regulation are in the plan on par with training.
What stays with you: model, data, and regulations
A model without documentation lives exactly until the first change of engineer or the first discrepancy between forecast and market.
That is why we hand over not only code and weights but also the rules of how the system works: what counts as input, what data the model was trained on, who has the right to change it, and how to roll back to the previous version.
Below is a set of artifacts you can pass to any contractor without rebuilding the project from scratch.
- Model passport — version, training date, sample composition and period, quality metric on holdout data, known limitations: where the forecast is stable and where it requires human review.
- Data schema — sources, fields, types, units, required status, rules for handling missing values and outliers, and a map of relationships between tables.
- Model documentation — which features influence the forecast and with what sign, how the final valuation is calculated, what the model intentionally does not account for.
- Model update regulation — retraining frequency, triggers for unscheduled runs (price shifts, error growth, changes in the field set), mandatory validation on a holdout period before release.
- Access control — roles: who sees forecasts, who works only with anonymized data, who changes weights and settings, who approves release; plus a separate action log.
- Rollback regulation — how to restore the previous version of the model and data, within what time, and by what signs to understand that the rollback worked.
- Team instructions — environment deployment, pre-release checks, typical failures, and the escalation procedure.
Agency case: valuation time decreased, accuracy increased
The agency handled the flow of residential valuation requests manually: an appraiser collected comparables, checked prices against the cadastre and listings, and transferred the figures into a report.
A typical apartment took three to five business days, in peak season the queue reached two weeks — and during that time some requests went to competing platforms.
Before implementation
The discrepancy between the forecast and the actual transaction price was not measured systematically; when reviewing part of the closed transactions, it remained at 12–15%.
Up to 70% of the appraiser's time was taken up by manual operations: searching for comparables, filtering out outliers, consolidating edits, and preparing the report. A disputed comparable was found at the signing stage, and the request had to be reassembled.
After implementation
We built AVM — an automated valuation model based on transaction history, cadastral data, and property parameters, with mandatory reconciliation of the forecast against closed transactions.
The model returns a valuation as an interval and a list of comparables that justify it, so the appraiser sees the breakdown, not a "black box." Non-standard cases — redevelopment, apartments, transactions with bargaining — are as a rule routed entirely to manual review.
The valuation time for a typical property dropped to minutes: the appraiser approves the result and supplements the report.
The deviation of the forecast from the transaction price fell by half — to 6–8% on the control sample, and the share of reports returned for reassembly dropped many times over.
The load on appraisers stopped growing with the flow of requests: throughput increased through automation of typical properties, and specialists switched to complex ones and to negotiations with owners.
How AI valuation differs from an appraiser's report and the cadastre
These are three different tools for different tasks, not interchangeable formats.
Cadastral value is calculated en masse and serves as the basis for tax; an appraiser's report is a document with an inspection, signature, and legal liability; AI valuation is a calculation based on market data in minutes.
| Option | When it fits | Limitations |
|---|---|---|
| AI valuation | Screening the flow of properties, mortgage and leasing, checking the listing price | Depends on the completeness of transaction data, does not replace a document for court and collateral |
| Appraiser's report | Collateral transactions, disputes, reporting, non-standard properties | Takes days; the valuation captures a snapshot as of the inspection date |
| Cadastral value | Tax, rent, and purchase of state property | Updated rarely and by a mass model, individual characteristics are poorly accounted for |
In practice, they are combined in a single process. AI valuation filters the flow and highlights properties where the listing price diverges from comparables — then the appraiser works only with them and signs a report where legal force is required.
The cadastral figure goes in a separate branch: if it is higher than the market one, this is grounds for revision.
The significance of a valuation is set not by the method but by the decision built on it: loan issuance, a court dispute, or a tax base.
That is why for each property we store both the market range and the source — it is clear where the figure came from and where the calculation diverges from the appraiser.
Concerns about data, forecast quality, and timelines
Concerns about data, forecast, and timelines are valid working concerns: we answer them before the start, not after. Below are the questions most often asked before launching an AI system for real estate, with specifics on each point.
What should be done with incomplete and outdated data?
First we calculate the dataset profile: the share of missing values in key fields, the spread of areas and dates, and how many properties lack coordinates. We do not fill missing values with the mean — some we estimate with a model using related features, and the rest we flag.
We do not delete outdated records but downweight them: they support the market structure without distorting the current level.
How is forecast quality validated?
We separate the control sample by time: we train on past periods and validate on subsequent ones. We look at the median error and the share of properties where the deviation exceeds the threshold.
For commercial real estate, we calculate the metric by segment — office, warehouse, retail space — otherwise the overall portfolio figure hides a failure in one of them.
Is the forecast a "black box"?
No: for each valuation we attach the feature contributions and the nearest comparables from the training dataset. The appraiser sees what provided weight — location, condition, rental rate — and can adjust the inputs.
This same breakdown makes the forecast defensible when coordinating with a bank or an internal committee.
What determines implementation timelines?
Not the model but data readiness: the availability of transaction history, exports from the accounting system, and reference data.
The first working version on a prepared dataset is assembled quickly, while most of the time goes to reconciling sources and labeling segments — that is why we include a separate stage before training in the plan.
How is the model updated?
On schedule and by trigger: if the error on recent transactions exceeds the threshold, we launch retraining without waiting for the scheduled date. We store versions so we can compare results and roll back if the new one underperforms on the control sample.
Let's discuss your task: data, model, work plan
An accurate estimate of the scope of work comes from data, not from general words. If you have exports and access, we calculate timelines and effort based on facts, not analogies; if something is missing, we will immediately say how to replace it and how to assemble it.
- export of listings and transaction history for the available period — it shows whether there is enough data to train the model;
- property characteristics: area, floor, year built, condition, nearby infrastructure;
- geodata — coordinates, district, parcel boundaries, if you maintain them;
- photos and text descriptions of properties, if you plan valuation from images;
- logs of client inquiries and realtors' work: what is asked most often and at what step transactions are lost;
- current pricing and adjustment rules used by your appraisers;
- access to CRM or accounting system — read-only, without the right to change.
This is enough for us to come back with an estimate of the scope of work and an implementation plan: what we do in the first stage, what result it delivers, and by what metrics we will accept it.
The first stage is usually narrow — a value forecast on your historical data and validation on a holdout sample, so that you see the error rate, not promises.
Describe your task in free form — we will come back with an estimate and a plan.