#23 - recommend_mix v3.2: конкуренты двумерно — расстояние И принадлежность к району - lekss361/gendesign

lekss361 commented

2026-05-10 14:19:37 +00:00

(Migrated from github.com)

Контекст

Сейчас в recommend_mix поиск конкурентов работает только по радиусу: ST_DWithin(point, :p, 3000). Юзер указал что этого недостаточно: часть покупателей выбирает по району (хотят жить именно в Академическом, или именно на Эльмаше — даже если это дальше 3км). Алгоритм должен учитывать обе оси:

Радиус 3км (геометрические соседи — текущее поведение)
Тот же район (даже если за 3км пределами — например, Академический растянут на 6км)

И давать разные веса этим двум множествам.

Что делать

Backend

В analytics_queries._BUCKET_SQL (где сейчас competitors filter) сделать UNION:
- Set A: ST_DWithin(point, :p, 3000) — радиус
- Set B: district_name = :dn И ST_Distance(point, :p) > 3000 — далёкие в том же районе
Добавить weight_radius=1.0, weight_district=0.6 (или сделать настраиваемыми) — далекий конкурент в том же районе имеет 60% вес ближнего.
В scope отдавать оба числа: competitors_radius_n, competitors_district_only_n — для прозрачности UI.
При расчёте per-bucket elasticity использовать union с весами для регрессии.

Frontend

В RecommendVelocityPanel в блоке «соседи» показать 2 цифры:
- «В радиусе 3км: N ЖК»
- «В районе X (за пределами 3км): M ЖК»
В тултипе пояснить что оба учитываются с разными весами.

Acceptance

Для участка в центре Академического (56.79, 60.55) количество «дальних» конкурентов (Set B) должно быть >0 (раньше игнорировались).
Headline tempo для такой точки немного снижается (так как добавились конкуренты района за пределами радиуса).
Видны 2 числа в UI: радиус-N и район-M.

Зависит от

v3.1 (#TBD) — до hard-cap по границам района
ekb_districts geom (Sprint 0)

Live verification

Открыть Академический — проверить что badge показывает существенное число «district-only» конкурентов (район большой, должны быть). Сравнить с компактным районом типа Втузгородок — там дальних конкурентов в районе быть мало.

## Контекст Сейчас в `recommend_mix` поиск конкурентов работает только по радиусу: `ST_DWithin(point, :p, 3000)`. Юзер указал что этого недостаточно: **часть покупателей выбирает по району** (хотят жить именно в Академическом, или именно на Эльмаше — даже если это дальше 3км). Алгоритм должен учитывать обе оси: 1. **Радиус 3км** (геометрические соседи — текущее поведение) 2. **Тот же район** (даже если за 3км пределами — например, Академический растянут на 6км) И давать **разные веса** этим двум множествам. ## Что делать ### Backend - [ ] В `analytics_queries._BUCKET_SQL` (где сейчас competitors filter) сделать UNION: - Set A: `ST_DWithin(point, :p, 3000)` — радиус - Set B: `district_name = :dn` И `ST_Distance(point, :p) > 3000` — далёкие в том же районе - [ ] Добавить `weight_radius=1.0`, `weight_district=0.6` (или сделать настраиваемыми) — далекий конкурент в том же районе имеет 60% вес ближнего. - [ ] В `scope` отдавать оба числа: `competitors_radius_n`, `competitors_district_only_n` — для прозрачности UI. - [ ] При расчёте per-bucket elasticity использовать union с весами для регрессии. ### Frontend - [ ] В `RecommendVelocityPanel` в блоке «соседи» показать 2 цифры: - «В радиусе 3км: N ЖК» - «В районе X (за пределами 3км): M ЖК» - [ ] В тултипе пояснить что оба учитываются с разными весами. ## Acceptance - Для участка в центре Академического (56.79, 60.55) количество «дальних» конкурентов (Set B) должно быть >0 (раньше игнорировались). - Headline tempo для такой точки **немного снижается** (так как добавились конкуренты района за пределами радиуса). - Видны 2 числа в UI: радиус-N и район-M. ## Зависит от - v3.1 (#TBD) — до hard-cap по границам района - ekb_districts geom (Sprint 0) ## Live verification Открыть Академический — проверить что badge показывает существенное число «district-only» конкурентов (район большой, должны быть). Сравнить с компактным районом типа Втузгородок — там дальних конкурентов в районе быть мало.

lekss361 commented

2026-05-10 14:20:55 +00:00

(Migrated from github.com)

Часть пакета recommend_mix v3: см. #22 #24 #25. Зависит от #22 (hard-cap по району должен быть применён до того как считать union с весами).

Часть пакета **recommend_mix v3**: см. #22 #24 #25. Зависит от #22 (hard-cap по району должен быть применён до того как считать union с весами).

lekss361 commented

2026-05-11 16:38:37 +00:00

(Migrated from github.com)

Частично закрыто. /parcels/{cad}/analyze возвращает competitors с полями distance_m + district_name. Frontend подсвечивает синим строки где (Maxim point 2 — район важен помимо радиуса). На recommend page (/analytics/recommend) тоже добавлен district hint и cad_quarter в comparables (#22 связано).

lekss361 commented

2026-05-11 19:24:08 +00:00

(Migrated from github.com)

Реализовано в commit c31da62.

Что добавлено:

_competitors_two_dim в analytics_queries: возвращает (radius_n, district_only_n, scope). ST_DWithin 3км radius + остальные в районе НО >3км.
competitors_weighted = radius_n × 1.0 + district_only_n × 0.6 — взвешенный divisor для velocity нормализации
scope добавлены: competitors_radius_n, competitors_district_only_n

Verification (Академический):

75 ЖК в радиусе 3км (близких конкурентов)
29 ЖК в районе но >3км (дальних, с весом 0.6)
Velocity normalization теперь учитывает 75 + 29×0.6 = 92.4 эффективно

Frontend: В радиусе 3км: 75 ЖК · Дальше по району: 29 ЖК (вес 0.6) с tooltip про weighting.

Реализовано в commit c31da62. **Что добавлено:** - `_competitors_two_dim` в analytics_queries: возвращает `(radius_n, district_only_n, scope)`. ST_DWithin 3км radius + остальные в районе НО >3км. - `competitors_weighted = radius_n × 1.0 + district_only_n × 0.6` — взвешенный divisor для velocity нормализации - scope добавлены: `competitors_radius_n`, `competitors_district_only_n` **Verification (Академический):** - 75 ЖК в радиусе 3км (близких конкурентов) - 29 ЖК в районе но >3км (дальних, с весом 0.6) - Velocity normalization теперь учитывает 75 + 29×0.6 = 92.4 эффективно **Frontend:** `В радиусе 3км: 75 ЖК · Дальше по району: 29 ЖК (вес 0.6)` с tooltip про weighting.