zone_regulation._RE_FLOORS требует литерал 'этаж' после числа → документированная форма 'предельное количество этажей – N' (голое число) не извлекаетс… #1651

New issue

Closed

opened 2026-06-16 18:46:58 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-16 18:46:58 +00:00

Collaborator

Severity: low · Категория: regex/data-extraction · Файл: backend/app/services/site_finder/zone_regulation.py:76-83, 75

Файл: backend/app/services/site_finder/zone_regulation.py:76-83 (_RE_FLOORS), документация-комментарий строка 75.

Проблема: regex заканчивается на + _NUM + r'\s*этаж' — обязательное слово 'этаж' ПОСЛЕ захваченного числа. Реальная формулировка ПЗЗ 'предельное количество этажей – 5' содержит слово 'этажей' ДО числа, а после числа — голая цифра/конец строки, поэтому не матчится.

Эмпирическая проверка (прогон скомпилированного regex):
'предельная этажность застройки – 5 этажей' → ['5'] (ok)
'предельное количество этажей – 5' → [] (промах)
'предельная этажность – 16' → [] (промах)
'предельное количество этажей застройки – 16 этажей' → ['16'] (ok)

Импакт: комментарий строка 75 явно заявляет поддержку обеих форм ('предельная этажность ... – 5 этажей' / 'предельное количество этажей ... – 5'). Вторая документированная форма даёт max_floors=None → most-permissive headline (агрегатор max, строка 97) теряет реальный лимит этажности → занижение capacity-оценки застройки. На текущих EKB-пробах не стреляет (единственное числовое значение в форме '– 5 этажей'), но латентно при вариации формулировок ЕКБ или расширении на прочие МО (что прямо упомянуто для _RE_HEIGHT, строка 84).

Фикс: сделать хвост 'этаж' необязательным, напр. заменить + _NUM + r'\s*этаж' на + _NUM + r'(?:\s*этаж|\s*$|\s*[;\n])' или просто + _NUM (число уже привязано к предельной-этажность/количество-этажей через начальный якорь и [^\n]*?). Добавить тест-кейс с голым числом в test_zone_regulation_extract.py.

Почему баг: Комментарий-документация прямо заявляет поддержку обеих форм: строка 75 — "# этажность — 'предельная этажность ... – 5 этажей' / 'предельное количество этажей ... – 5'". Вторая документированная форма не извлекается из-за обязательного хвоста 'этаж'. Для текущих EKB-проб (#1067 C8b, тест test_zone_regulation_extract.py) баг не стреляет: единственное числовое значение этажности там в форме '– 5 этажей', а форма с голым числом встречается лишь в 'не подлежат установлению' (числа нет). Но это латентный дефект: при вариации формулировок ЕКБ или расширении на прочие МО (что прямо упомянуто для _RE_HEIGHT, строка 84) max_floors будет молча None, занижая capacity-оценку застройки (most-permissive headline теряет реальный лимит этажности).

Как чинить: Сделать хвост 'этаж' опциональным, опираясь на лидирующий якорь: ...(?:предельн\w*\s+этажност\w*|предельн\w*\s+количеств\w*\s+этажей)[^\n]*? DASH \s* NUM (?:\s*этаж\w*)?. Якорь по 'этаж' в начале уже отделяет этажность от высоты, так что опциональный хвост безопасен.

_{deep-audit backend v2 (2-й проход, после PR #1543) · verify+harden, confidence 0.92 · unit B39}

**Severity:** low · **Категория:** regex/data-extraction · **Файл:** `backend/app/services/site_finder/zone_regulation.py:76-83, 75` Файл: backend/app/services/site_finder/zone_regulation.py:76-83 (_RE_FLOORS), документация-комментарий строка 75. Проблема: regex заканчивается на `+ _NUM + r'\s*этаж'` — обязательное слово 'этаж' ПОСЛЕ захваченного числа. Реальная формулировка ПЗЗ 'предельное количество этажей – 5' содержит слово 'этажей' ДО числа, а после числа — голая цифра/конец строки, поэтому не матчится. Эмпирическая проверка (прогон скомпилированного regex): 'предельная этажность застройки – 5 этажей' → ['5'] (ok) 'предельное количество этажей – 5' → [] (промах) 'предельная этажность – 16' → [] (промах) 'предельное количество этажей застройки – 16 этажей' → ['16'] (ok) Импакт: комментарий строка 75 явно заявляет поддержку обеих форм ('предельная этажность ... – 5 этажей' / 'предельное количество этажей ... – 5'). Вторая документированная форма даёт max_floors=None → most-permissive headline (агрегатор max, строка 97) теряет реальный лимит этажности → занижение capacity-оценки застройки. На текущих EKB-пробах не стреляет (единственное числовое значение в форме '– 5 этажей'), но латентно при вариации формулировок ЕКБ или расширении на прочие МО (что прямо упомянуто для _RE_HEIGHT, строка 84). Фикс: сделать хвост 'этаж' необязательным, напр. заменить `+ _NUM + r'\s*этаж'` на `+ _NUM + r'(?:\s*этаж|\s*$|\s*[;\n])'` или просто `+ _NUM` (число уже привязано к предельной-этажность/количество-этажей через начальный якорь и [^\n]*?). Добавить тест-кейс с голым числом в test_zone_regulation_extract.py. **Почему баг:** Комментарий-документация прямо заявляет поддержку обеих форм: строка 75 — "# этажность — 'предельная этажность ... – 5 этажей' / 'предельное количество этажей ... – 5'". Вторая документированная форма не извлекается из-за обязательного хвоста 'этаж'. Для текущих EKB-проб (#1067 C8b, тест test_zone_regulation_extract.py) баг не стреляет: единственное числовое значение этажности там в форме '– 5 этажей', а форма с голым числом встречается лишь в 'не подлежат установлению' (числа нет). Но это латентный дефект: при вариации формулировок ЕКБ или расширении на прочие МО (что прямо упомянуто для _RE_HEIGHT, строка 84) max_floors будет молча None, занижая capacity-оценку застройки (most-permissive headline теряет реальный лимит этажности). **Как чинить:** Сделать хвост 'этаж' опциональным, опираясь на лидирующий якорь: `...(?:предельн\w*\s+этажност\w*|предельн\w*\s+количеств\w*\s+этажей)[^\n]*? DASH \s* NUM (?:\s*этаж\w*)?`. Якорь по 'этаж' в начале уже отделяет этажность от высоты, так что опциональный хвост безопасен. --- <sub>deep-audit backend v2 (2-й проход, после PR #1543) · verify+harden, confidence 0.92 · unit B39</sub>