The post has been translated automatically. Original language: Russian
The problem you cannot see in a demo
Every analytics platform has dashboards, filters and exports. Ours is no exception: twelve sections, a market map with four levels of depth, scoring, developer portfolios, snapshot history.
And yet an obstacle remains between an analyst and an answer that no interface fully removes: to get an answer, you have to know where it lives.
The question «who leads the luxury segment in Almaty» sounds simple. Answering it through an interface requires opening the right section, filtering by city, working out which attribute in the data corresponds to «luxury», grouping by brand rather than by legal entity, choosing a metric for leadership — inventory volume, units sold, or sales pace — and only then reading the result. Five steps and three judgement calls, each requiring knowledge of the data structure.
An analyst who works with the platform daily will do this in a minute. A head of sales who came in with one specific question before a meeting will not do it at all — they will call the analyst, and the question joins a queue for half a day.
We built the AI analysis section for the second scenario. The question is asked in plain words, the answer arrives as a chart and a table within seconds, with the option to drill into a specific project.
The principle everything rests on
The key decision sounds like this: the model parses the question, but the register does the maths.
The language model never receives data in order to compute something from it. It performs exactly one job — translating a question asked in human language into a structured query against the database: which city, which segment, which metric, which grouping, which period between snapshots. From there the query goes to the same computation layer that serves the platform's dashboards and reports.
This produces the property we consider the most important thing about this section: the figures in the assistant's answer always match the figures in the reports. Not «roughly match», not «match in most cases» — it is literally the same calculation, invoked two different ways. Through filters in the interface, or through a sentence in a chat.
Why a model cannot be trusted with arithmetic
The temptation was obvious: feed the model an export and ask it to calculate. Many products do exactly this; it is faster to build and looks more impressive in a demo.
We refused for one reason. In property analytics, an error in a number does not stay an error in a number — a credit committee makes project finance decisions on these figures, and a developer builds a quarterly sales strategy on them.
Worse, a language model's arithmetic error does not look like an error. It looks like a confident answer containing a plausible number. If the assistant says «sell-through in this district is 34%» while the platform's report shows 31%, the user receives no warning — they receive two sources of truth inside one product. After the first such discrepancy, trust is lost in the entire platform, including the sections where everything was calculated correctly.
So the boundary is drawn hard: the model is responsible for comprehension, the database for content. Not a single number in an answer is generated.
What can be asked
The phrasings the section was tuned for are ordinary working questions, not queries in a special language:
- who leads the luxury segment in Almaty;
- where is the most expensive square metre under the «Nauryz» programme;
- which projects in Shymkent sold fastest over the past two weeks;
- how many unsold units a particular brand holds nationwide;
- in which cities sell-through sits below the market average.
A separate class of questions concerns dynamics: «whose sales grew», «where have sales stalled». These work only thanks to the dated snapshots the platform accumulates daily. The official register itself keeps no history and shows only the current state, so any question containing the word «changed» simply has no answer elsewhere.
The answer arrives not as prose but as a chart and a table, with the option to open a residential complex or developer profile and continue working by hand.
Engineering decisions worth mentioning
Consolidation of legal entities happens before the model, not after. Large holdings in Kazakhstan build through dozens of separate companies. The question «how much did this developer sell» returns a meaningless answer about one subsidiary unless entities are merged into a brand first. We solve this at the data level rather than asking the model to guess.
Multilingual queries. A question may arrive in Russian, in Kazakh or in a mix of both, using colloquial names for market segments and local district names that appear in no official directory — districts are not recorded in the register at all, so we derive them from project coordinates.
An honest «I don't know». When a question falls outside the register's data, the assistant says so directly rather than assembling a plausible answer from whatever is at hand. A question about unit prices outside the subsidised mortgage catalogue, for instance, has no answer: developers do not submit prices to the register at all, and admitting that is more honest than estimating.
What AI analysis deliberately does not do
The same set of constraints that governs the platform as a whole, and it does not soften because the question was asked in a chat.
It does not rate developer reliability. The assistant works with register data and the official list maintained by the Kazakhstan Housing Company. Asked «is this developer reliable», it will show the guarantee scheme, sales pace, sell-through and whether the company appears on the official list — but it will not deliver a verdict. The verdict stays with the user.
It does not turn a planned date into an accusation. The register holds only the planned completion date and does not know whether a building was actually handed over. «The date arrived and units remained on sale» is a description of data. «The developer missed the deadline» is a claim the data does not contain.
It does not forecast. Everything the platform can do is describe the past and present accurately. Extrapolating from a month of history would be fortune-telling with an analytics interface.
Why this is not «chat with your data»
The «upload a spreadsheet and ask questions» format has existed for a while and solves a different task — a one-off analysis of an arbitrary file. The user is responsible for data quality, metric definitions and correct interpretation.
Here it is the reverse. The data is fixed: the official register of shared-equity construction and the subsidised mortgage catalogue. Metric definitions are set and identical across every section of the platform. Brand consolidation, district derivation and dynamics between snapshots are computed in advance, identically for the chat and for the dashboard.
The assistant here is not a universal analyst but a fast way to put a question to one specific database whose structure the user need not know. It is a narrow task — and precisely because of that, it could be solved in a way that makes the answers trustworthy.
What comes next
Near-term development: expanding the set of supported cuts, handling follow-up questions within a single conversation (where the next question builds on the previous answer), and deepening support for Kazakh-language phrasing.
The broader idea we are testing in this section: the value of an analytics platform depends less and less on the number of dashboards and more and more on how quickly a person gets an answer to their own question. An interface you have to learn loses to a question asked out loud — on one condition: the answer must be calculated, not generated.
Developers is an analytics platform for Kazakhstan's shared-equity construction market: the official register, sales dynamics from dated snapshots, scoring, a market map and prices from the subsidised mortgage programme.
Проблема, которой не видно в демо
У любой аналитической платформы есть дашборды, фильтры и выгрузки. Наша не исключение: двенадцать разделов, карта рынка с четырьмя уровнями вложенности, скоринг, портфели застройщиков, история срезов.
И всё равно между аналитиком и ответом стоит препятствие, которое ни один интерфейс не убирает полностью: чтобы получить ответ, надо знать, где он лежит.
Вопрос «кто лидер по элитному сегменту в Алматы» звучит просто. Чтобы ответить на него через интерфейс, нужно: открыть нужный раздел, отфильтровать по городу, понять, какой признак в данных соответствует «элитке», сгруппировать по бренду, а не по юридическому лицу, выбрать метрику лидерства — по объёму витрины, по проданным квартирам или по темпу продаж, — и только потом прочитать результат. Пять шагов и три решения, каждое из которых требует знания структуры данных.
Аналитик, работающий с платформой ежедневно, проделает это за минуту. Руководитель отдела продаж, который зашёл с одним конкретным вопросом перед совещанием, не проделает вообще — он позвонит аналитику, и вопрос уйдёт в очередь на полдня.
Раздел AI-анализа мы сделали для второго сценария. Вопрос задаётся своими словами, ответ приходит графиком и таблицей за несколько секунд, с возможностью провалиться в карточку конкретного проекта.
Принцип, на котором всё держится
Ключевое решение звучит так: модель разбирает вопрос, но числа считает реестр.
Языковая модель не получает данные, чтобы что-то в них посчитать. Она выполняет ровно одну работу — переводит вопрос, заданный человеческим языком, в структурированный запрос к базе: какой город, какой сегмент, какая метрика, какая группировка, какой период между срезами. Дальше запрос уходит в тот же вычислительный слой, который обслуживает дашборды и отчёты платформы.
Отсюда свойство, которое мы считаем главным в этом разделе: цифры в ответе ассистента всегда совпадают с цифрами в отчётах. Не «примерно совпадают» и не «совпадают в большинстве случаев» — это буквально один и тот же расчёт, вызванный двумя разными способами. Через фильтры в интерфейсе или через фразу в чате.
Почему модели нельзя доверять арифметику
Соблазн был очевиден: скормить модели выгрузку и попросить посчитать. Так делают многие продукты, это быстрее в разработке и выглядит эффектнее в демо.
Мы отказались от этого по одной причине. В аналитике недвижимости ошибка в цифре не остаётся ошибкой в цифре — на этих числах кредитный комитет принимает решение о проектном финансировании, а застройщик строит стратегию продаж на квартал.
Хуже того, ошибка языковой модели в арифметике не выглядит как ошибка. Она выглядит как уверенный ответ с правдоподобным числом. Если ассистент говорит «в этом районе распроданность 34%», а в отчёте платформы стоит 31%, пользователь не получает предупреждения — он получает два источника правды внутри одного продукта. После первого такого расхождения доверие теряется ко всей платформе, включая те разделы, где всё считалось корректно.
Поэтому граница проведена жёстко: модель отвечает за понимание, база — за содержание. Ни одно число в ответе не сгенерировано.
Что можно спрашивать
Формулировки, под которые раздел затачивался, — обычные рабочие вопросы, а не запросы на специальном языке:
- кто лидер по элитному сегменту в Алматы;
- где самый дорогой квадратный метр по программе «Наурыз»;
- какие проекты в Шымкенте продавались быстрее всего за последние две недели;
- сколько квартир в остатке у конкретного бренда по стране;
- в каких городах распроданность ниже среднерыночной.
Отдельный класс вопросов — про динамику: «у кого продажи выросли», «где продажи встали». Он работает только благодаря датированным срезам, которые платформа накапливает ежедневно. Сам официальный реестр истории не хранит и показывает только текущее состояние, поэтому любой вопрос со словом «изменилось» в других источниках просто не имеет ответа.
Ответ приходит не текстом, а графиком и таблицей — с возможностью перейти в карточку жилого комплекса или застройщика и продолжить работу руками.
Инженерные решения, о которых стоит сказать
Консолидация юрлиц происходит до модели, а не после. Крупные холдинги в Казахстане строят через десятки отдельных компаний. Вопрос «сколько продал этот застройщик» без сведения юридических лиц в бренд даёт бессмысленный ответ по одной из компаний холдинга. Мы решаем это на уровне данных, а не просим модель догадаться.
Многоязычие запроса. Вопрос может прийти на русском, на казахском или в смешанном виде, с разговорными обозначениями сегментов и локальными названиями районов, которых нет ни в одном официальном справочнике — в реестре районы не указаны вообще, мы вычисляем их по координатам объекта.
Честное «не знаю». Если вопрос выходит за пределы данных реестра, ассистент говорит об этом прямо, а не собирает правдоподобный ответ из того, что есть под рукой. Например, вопрос о ценах на квартиры за пределами каталога субсидированной ипотеки ответа не имеет: застройщики цены в реестр не подают вообще, и признать это честнее, чем оценить.
Чего AI-анализ не делает принципиально
Тот же набор ограничений, что и у платформы в целом, и он не смягчается оттого, что вопрос задан в чате.
Не оценивает надёжность застройщиков. Ассистент оперирует данными реестра и официальным перечнем Казахстанской жилищной компании. На вопрос «надёжный ли этот застройщик» он покажет схему гарантии, темп продаж, распроданность и наличие компании в официальном перечне, но не выдаст вердикт. Вердикт остаётся за пользователем.
Не превращает плановую дату в обвинение. Реестр содержит только плановый срок ввода и не знает, сдан ли дом фактически. «Срок наступил, а квартиры в продаже остались» — это описание данных. «Застройщик сорвал сроки» — это утверждение, которого в данных нет.
Не прогнозирует. Всё, что платформа умеет, — точно описывать прошлое и настоящее. Экстраполяция на месячной глубине истории была бы гаданием с интерфейсом аналитики.
Почему это не «чат с данными»
Формат «загрузите таблицу и задавайте вопросы» существует давно и решает другую задачу — разовый разбор произвольного файла. Пользователь сам отвечает за качество данных, определения метрик и корректность интерпретации.
Здесь всё наоборот. Данные фиксированы: официальный реестр долевого строительства и каталог субсидированной ипотеки. Определения метрик заданы и одинаковы для всех разделов платформы. Консолидация брендов, вычисление районов, расчёт динамики между срезами сделаны заранее и одинаково для чата и для дашборда.
Ассистент здесь не универсальный аналитик, а быстрый способ задать вопрос конкретной базе, устройство которой пользователь может не знать. Это ограниченная задача — и именно поэтому её удалось решить так, чтобы ответам можно было доверять.
Что дальше
Ближайшие направления развития — расширение набора поддерживаемых разрезов, работа с уточняющими вопросами внутри одного диалога (когда следующий вопрос опирается на предыдущий ответ) и углубление казахоязычных формулировок.
Более общая мысль, которую мы проверяем на этом разделе: ценность аналитической платформы всё меньше определяется количеством дашбордов и всё больше — скоростью, с которой человек получает ответ на свой собственный вопрос. Интерфейс, который надо изучать, проигрывает вопросу, заданному вслух, — при одном условии: ответ должен быть посчитан, а не сгенерирован.
Developers — аналитическая платформа по рынку долевого строительства Казахстана: официальный реестр, динамика продаж по датированным срезам, скоринг, карта рынка и цены по субсидированной ипотеке.
Share
