(high) QuartirographyChart.tsx/portfolioMap: портфель по числу комнат наложен на ось площади (м²) — сравнение в разных единицах #1406

New issue

Closed

opened 2026-06-15 05:53:36 +00:00 by bot-backend · 1 comment

bot-backend commented

2026-06-15 05:53:36 +00:00

Collaborator

Severity: high · Категория: numeric · Файл: frontend/src/components/analytics/QuartirographyChart.tsx:26-35

frontend/src/components/analytics/QuartirographyChart.tsx:26-35. Ось графика — диапазоны ПЛОЩАДИ ("1-к 30-45" … "80+ м²" — это м²). Ряд deals корректно строится по area_per_unit (analytics_queries.py:113-158: CASE по площади на юнит). Но ряд portfolio набирается из portfolioMap (стр.27-30), который тянет бакеты портфеля ПО ЧИСЛУ КОМНАТ: backend (analytics_queries.py:88-95) маппит room_count_type ONE/TWO/THREE/FOUR → "1-к"/"2-к"/"3-к"/"4+". portfolioMap прямо приравнивает "4+" (4+ комнаты) к ячейке "80+ м²" (≥80 м²) — стр.30, "3-к"(3 комнаты)→"3-к 60-80"(60-80 м²) и т.д. Это сравнение несопоставимых метрик: «4+ комнатные» ≠ «≥80 м²» (3-к нередко ≥80 м², малометражная 4-к бывает <80 м²). В одном баре на одной горизонтали наложены доля портфеля по комнатности и доля сделок по площади, и это подаётся как «парадокс портфеля» (page.tsx:102, Section title). Вывод «37% покупают 80+ м² vs перекос портфеля» (page.tsx:114-116) опирается на этот некорректный оверлей. Импакт: ключевой инсайт всей секции методологически некорректен. Как чинить: привести портфель к той же площадной бакетизации (area_sqm/flat_count по бакетам площади) на backend, либо явно подписать, что левый ряд — по комнатности, и не накладывать на площадную ось.

Почему баг: Это сравнение несопоставимых метрик: «4+ комнатные» ≠ «≥80 м²». Трёхкомнатная нередко ≥80 м², а малометражная 4-к бывает <80 м². В одном баре на одной горизонтали график ставит долю портфеля по числу комнат против доли сделок по площади и подаёт это как «парадокс портфеля» (что строят vs что покупают). «37% покупают 80+ м²» (page.tsx:114, подтверждено backend insights:562) сравнивается с долей «4+ комнат» в портфеле — разные оси. Вывод о дефиците средне-большого жилья опирается на этот некорректный оверлей.

Как чинить: Приводить обе серии к одной метрике. Для portfolio брать распределение по площади (DOM.РФ domrf_flat_area_distribution.area_bucket уже существует в схеме 10_schema_domrf.sql:44), а не по числу комнат; либо честно подписать ось как «по комнатности» и сравнивать с deals, тоже сгруппированными по комнатности. Сейчас оси-категории портфеля и deals семантически разные.

_{deep-audit «армия ботов 2» · verify+harden, confidence 0.85 · unit U72}

**Severity:** high · **Категория:** numeric · **Файл:** `frontend/src/components/analytics/QuartirographyChart.tsx:26-35` frontend/src/components/analytics/QuartirographyChart.tsx:26-35. Ось графика — диапазоны ПЛОЩАДИ ("1-к 30-45" … "80+ м²" — это м²). Ряд deals корректно строится по area_per_unit (analytics_queries.py:113-158: CASE по площади на юнит). Но ряд portfolio набирается из portfolioMap (стр.27-30), который тянет бакеты портфеля ПО ЧИСЛУ КОМНАТ: backend (analytics_queries.py:88-95) маппит room_count_type ONE/TWO/THREE/FOUR → "1-к"/"2-к"/"3-к"/"4+". portfolioMap прямо приравнивает "4+" (4+ комнаты) к ячейке "80+ м²" (≥80 м²) — стр.30, "3-к"(3 комнаты)→"3-к 60-80"(60-80 м²) и т.д. Это сравнение несопоставимых метрик: «4+ комнатные» ≠ «≥80 м²» (3-к нередко ≥80 м², малометражная 4-к бывает <80 м²). В одном баре на одной горизонтали наложены доля портфеля по комнатности и доля сделок по площади, и это подаётся как «парадокс портфеля» (page.tsx:102, Section title). Вывод «37% покупают 80+ м² vs перекос портфеля» (page.tsx:114-116) опирается на этот некорректный оверлей. Импакт: ключевой инсайт всей секции методологически некорректен. Как чинить: привести портфель к той же площадной бакетизации (area_sqm/flat_count по бакетам площади) на backend, либо явно подписать, что левый ряд — по комнатности, и не накладывать на площадную ось. **Почему баг:** Это сравнение несопоставимых метрик: «4+ комнатные» ≠ «≥80 м²». Трёхкомнатная нередко ≥80 м², а малометражная 4-к бывает <80 м². В одном баре на одной горизонтали график ставит долю портфеля по числу комнат против доли сделок по площади и подаёт это как «парадокс портфеля» (что строят vs что покупают). «37% покупают 80+ м²» (page.tsx:114, подтверждено backend insights:562) сравнивается с долей «4+ комнат» в портфеле — разные оси. Вывод о дефиците средне-большого жилья опирается на этот некорректный оверлей. **Как чинить:** Приводить обе серии к одной метрике. Для portfolio брать распределение по площади (DOM.РФ domrf_flat_area_distribution.area_bucket уже существует в схеме 10_schema_domrf.sql:44), а не по числу комнат; либо честно подписать ось как «по комнатности» и сравнивать с deals, тоже сгруппированными по комнатности. Сейчас оси-категории портфеля и deals семантически разные. --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.85 · unit U72</sub>

bot-backend added the

week ревью 1

label 2026-06-15 05:53:36 +00:00

bot-backend added the

scope/frontend

label 2026-06-15 11:01:59 +00:00

lekss361 commented

2026-06-15 11:23:13 +00:00

Owner

🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)

Текущее состояние кода: frontend/src/components/analytics/QuartirographyChart.tsx:26-35. Ось buckets (стр.19-25) — диапазоны площади ("1-к 30-45" … "80+ м²", м²). dealsPercents строится по тем же площадным меткам (стр.32-34). А portfolioMap (стр.27-30) тянет бакеты портфеля ПО ЧИСЛУ КОМНАТ: r.bucket === "1-к"/"2-к"/"3-к"/"4+", причём "4+" (4+ комнаты) приравнен к ячейке "80+ м²" (≥80 м²) на стр.30.

Корень: на одной горизонтали наложены доля портфеля по комнатности и доля сделок по площади — несопоставимые метрики («4+ комнат» ≠ «≥80 м²»). Это подаётся как «Парадокс портфеля» (app/analytics/page.tsx:102), а вывод «37% покупают 80+ м² vs перекос портфеля» (page.tsx:114-115) опирается на некорректный оверлей.

Что править:

Привести обе серии к одному измерению. Предпочтительно: backend отдаёт распределение портфеля по площади (DOM.РФ area-bucket уже есть в схеме — data/sql/10_schema_domrf.sql, domrf_flat_area_distribution.area_bucket), маппить по площадным меткам. Либо честно подписать ось портфеля как «по комнатности» и не накладывать на площадную ось сделок.
Единый фикс с #1405/#1436 (одна первопричина).

Что посмотреть:

Код: QuartirographyChart.tsx:26-35, backend analytics_queries.py (portfolio CASE по room_count_type vs deals CASE по area_per_unit), data/sql/10_schema_domrf.sql (domrf_flat_area_distribution), app/analytics/page.tsx:102,114-115.
Vault: релевантных заметок не найдено.

**🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)** **Текущее состояние кода:** `frontend/src/components/analytics/QuartirographyChart.tsx:26-35`. Ось `buckets` (стр.19-25) — диапазоны площади (`"1-к 30-45"` … `"80+ м²"`, м²). `dealsPercents` строится по тем же площадным меткам (стр.32-34). А `portfolioMap` (стр.27-30) тянет бакеты портфеля ПО ЧИСЛУ КОМНАТ: `r.bucket === "1-к"/"2-к"/"3-к"/"4+"`, причём `"4+"` (4+ комнаты) приравнен к ячейке `"80+ м²"` (≥80 м²) на стр.30. **Корень:** на одной горизонтали наложены доля портфеля по комнатности и доля сделок по площади — несопоставимые метрики («4+ комнат» ≠ «≥80 м²»). Это подаётся как «Парадокс портфеля» (`app/analytics/page.tsx:102`), а вывод «37% покупают 80+ м² vs перекос портфеля» (`page.tsx:114-115`) опирается на некорректный оверлей. **Что править:** - Привести обе серии к одному измерению. Предпочтительно: backend отдаёт распределение портфеля по площади (DOM.РФ area-bucket уже есть в схеме — `data/sql/10_schema_domrf.sql`, `domrf_flat_area_distribution.area_bucket`), маппить по площадным меткам. Либо честно подписать ось портфеля как «по комнатности» и не накладывать на площадную ось сделок. - Единый фикс с #1405/#1436 (одна первопричина). **Что посмотреть:** - Код: `QuartirographyChart.tsx:26-35`, backend `analytics_queries.py` (portfolio CASE по room_count_type vs deals CASE по area_per_unit), `data/sql/10_schema_domrf.sql` (`domrf_flat_area_distribution`), `app/analytics/page.tsx:102,114-115`. - Vault: релевантных заметок не найдено.