AI berechnet den Wohnungspreis nicht. Das allein macht die Bewertung noch nicht richtig

Ein Sprachmodell um eine Wohnungsbewertung zu bitten liefert schnell eine Zahl mit guten Manieren. Dazu können selbstsichere Erklärung, Faktorenliste und fast keine überprüfbare Grundlage kommen.

In LiveDXB Analytics nutze ich einen eigenen Rechenkern. Er holt Transaktionen aus der Datenbank, wählt Vergleichsobjekte, berechnet die Preisverteilung pro Quadratfuß und vergleicht sie mit dem Angebotspreis. Der AI-Kommentar folgt nach der Rechnung. Das Zahlenergebnis entsteht durch TypeScript-Code.

Doch man kann sich zu früh beruhigen: Ein Programm kann den Median schlecht ausgewählter Wohnungen fehlerfrei berechnen.

Wie die Berechnung funktioniert

Die Oberfläche nutzt React, die API Hono in einem Cloudflare Worker. D1 speichert normalisierte Daten und Prüfergebnisse, R2 ursprüngliche Uploads. Zum Ergebnis gehören Eingaben, Zeitpunkt und Methodenversion.

Der Kern bestimmt Median und Quartile und filtert statistische Ausreißer über den Interquartilsabstand. Der Objektpreis wird mit dem Korridor verglichen. Bei weniger als drei ursprünglichen Vergleichstransaktionen ist INSUFFICIENT DATA vorgesehen.

Im archivierten Bewertungsformular ist ein fiktives Objekt ausgewählt. Eingaben und verfügbarer Weg zum Ergebnis lassen sich ansehen. Das ist eine autonome Demo, keine Abfrage des aktuellen Markts.

Bewertungseingaben

Archivierte Oberfläche · Demodaten

Das ist eine sinnvolle Form der Ablehnung. Die Oberfläche funktioniert weiter, ohne so zu tun, als müsse jeder Klick einen Preis liefern.

Hier ist ein vorbereitetes Demo-Ergebnis zu sehen. Es zeigt die Darstellung der Berechnung, seine Zahlen bestätigen aber keinen Marktpreis einer echten Wohnung.

Bewertungsergebnis

Archivierte Oberfläche · Demodaten

Welche Transaktionen verglichen werden

Die aktuelle Auswahl verwendet Flächentoleranzen von 18 und 30 Prozent. Transaktionen werden nach Datum sortiert, doch die Abfrage hat keine ausdrückliche Zeitgrenze. Die frühere Methode beschrieb 180/365 Tage und 15/25 Prozent; der Code entspricht ihr noch nicht.

Bei breiterer Auswahl werden auch Übereinstimmungsbedingungen gelockert. Das hilft Daten zu finden, verändert aber den Sinn des Ergebnisses. Ältere, weniger ähnliche Transaktionen werden nicht präzise, nur weil genug für die Berechnung da sind.

Daher nenne ich das System keine garantiert genaue Bewertung und wiederhole das frühere Versprechen „null Halluzinationen“ nicht. Ein eigener Algorithmus macht die Arithmetik reproduzierbar. Auswahlqualität, Aktualität und Eignung des Schlusses brauchen eigene Prüfungen.

Welches Produkt daraus werden soll

Ein Werkzeug, das zeigt, warum diese Transaktionen gewählt wurden, welche Grenzen gelockert sind und wo Sicherheit endet. Als Nächstes müssen Code und Methode abgeglichen sowie Aktualität und Qualität geprüft werden. Ein weiterer schöner Modellabsatz kann warten.

Dieses Projekt ist nicht der pausierte Comps Engine im Makler-CRM. Es hat eine eigene Umsetzung; vorhandener Code und früheres Deployment beweisen keine aktuelle Vollständigkeit der Marktdatenbank.

LiveDXB Analytics besitzt einen eigenen Rechenkern. Es ist eine separate Umsetzung nach Comps Engine mit eigenen Daten- und Methodengrenzen. Reproduzierbarkeit prüft die Arithmetik, ersetzt aber keine Prüfung der Vollständigkeit und Aktualität der Auswahl.

Verwandte Geschichten: Comps-Engine-Untersuchung · Hypothekenrechner.