(medium) normalize.py/normalize_address: инициалы 'К.'/'Д.' в названии улицы раскрываются в 'корпус'/'дом' #1535

Closed
opened 2026-06-15 05:59:26 +00:00 by bot-backend · 1 comment
Collaborator

Severity: medium · Категория: logic · Файл: tradein-mvp/backend/app/services/matching/normalize.py:37-38

normalize.py:37-38 (' д '->' дом ', ' к '->' корпус ') в связке с _PUNCT на :56. Точка инициала вырезается до раскрытия аббревиатур -> одиночный токен 'к'/'д' раскрывается безусловно. Проверено: normalize_address('К. Либкнехта 22')='корпус либкнехта 22', normalize_address('Д. Зверева 10')='дом зверева 10'. Канонический 'улица карла либкнехта 22' никогда не совпадёт. Импакт: неверный normalized_address/fingerprint для класса адресов ЕКБ с инициалами в названии улицы -> промах Tier 2a/2b -> дубли houses и неверная привязка объявлений. Как чинить: раскрывать 'д'/'к' в 'дом'/'корпус' только когда за токеном следует число (номер), а не словесный токен (название улицы); либо вести их через числовой контекст. Тест на 'К. Либкнехта', 'Д. Зверева'.

Почему баг: Точка после инициала вырезается _PUNCT раньше (строка 56), оставляя одиночный токен 'к'/'д', который затем безусловно раскрывается. Получается некорректный normalized_address и fingerprint для целого класса реальных адресов ЕКБ. Промах матчинга → дубли houses и неверная привязка объявлений к дому. Импакт прямой для основной фичи cross-source matching на местной географии.

Как чинить: Раскрывать 'д'/'к' как маркер дома/корпуса ТОЛЬКО когда следующий токен — число (regex с lookahead на цифру), а не имя собственное. Либо вообще убрать однобуквенные правила из словаря (они дают больше вреда, чем пользы).


deep-audit «армия ботов 2» · verify+harden, confidence 0.92 · unit U130

**Severity:** medium · **Категория:** logic · **Файл:** `tradein-mvp/backend/app/services/matching/normalize.py:37-38` normalize.py:37-38 (' д '->' дом ', ' к '->' корпус ') в связке с _PUNCT на :56. Точка инициала вырезается до раскрытия аббревиатур -> одиночный токен 'к'/'д' раскрывается безусловно. Проверено: normalize_address('К. Либкнехта 22')='корпус либкнехта 22', normalize_address('Д. Зверева 10')='дом зверева 10'. Канонический 'улица карла либкнехта 22' никогда не совпадёт. Импакт: неверный normalized_address/fingerprint для класса адресов ЕКБ с инициалами в названии улицы -> промах Tier 2a/2b -> дубли houses и неверная привязка объявлений. Как чинить: раскрывать 'д'/'к' в 'дом'/'корпус' только когда за токеном следует число (номер), а не словесный токен (название улицы); либо вести их через числовой контекст. Тест на 'К. Либкнехта', 'Д. Зверева'. **Почему баг:** Точка после инициала вырезается _PUNCT раньше (строка 56), оставляя одиночный токен 'к'/'д', который затем безусловно раскрывается. Получается некорректный normalized_address и fingerprint для целого класса реальных адресов ЕКБ. Промах матчинга → дубли houses и неверная привязка объявлений к дому. Импакт прямой для основной фичи cross-source matching на местной географии. **Как чинить:** Раскрывать 'д'/'к' как маркер дома/корпуса ТОЛЬКО когда следующий токен — число (regex с lookahead на цифру), а не имя собственное. Либо вообще убрать однобуквенные правила из словаря (они дают больше вреда, чем пользы). --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.92 · unit U130</sub>
bot-backend added the
week ревью 1
label 2026-06-15 05:59:26 +00:00
bot-backend added the
scope/backend
label 2026-06-15 11:02:19 +00:00
Owner

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

Текущее состояние кода: tradein-mvp/backend/app/services/matching/normalize.py:37-38 ((' д ', ' дом '), (' к ', ' корпус ')) в связке с _PUNCT на :13, применяемым на :56 ДО раскрытия аббревиатур :60-61.

Корень: Точка инициала вырезается _PUNCT раньше цикла раскрытия → одиночный токен к/д (название улицы) раскрывается безусловно как маркер дома/корпуса.

Эмпирически воспроизведено в этом прогоне:

  • normalize_address('К. Либкнехта 22')'корпус либкнехта 22'
  • normalize_address('Д. Зверева 10')'дом зверева 10'

Канонический 'улица карла либкнехта 22' никогда не совпадёт → промах Tier 2a/2b для класса адресов ЕКБ с инициалами в названии улицы.

Что править:

  • Раскрывать д/к в дом/корпус ТОЛЬКО когда следующий токен — число (regex с lookahead на цифру), а не словесный токен. Либо убрать однобуквенные правила :37-38 из _ABBREV целиком (вреда больше, чем пользы).
  • Совместить с #1534 — это тот же блок :37-38, фиксы пересекаются; делать одним PR с общей канонизацией.

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

  • Код: normalize.py:_ABBREV :20-39, _PUNCT :13/:56; call-sites houses.py:118/:58; тесты в tests/test_matching.py (рядом с :29-55) — 'К. Либкнехта', 'Д. Зверева'.
  • Vault: релевантных заметок не найдено.
**🔍 week ревью 1 — верификация (ПОДТВЕРЖДЕНО)** **Текущее состояние кода:** `tradein-mvp/backend/app/services/matching/normalize.py:37-38` (`(' д ', ' дом ')`, `(' к ', ' корпус ')`) в связке с `_PUNCT` на `:13`, применяемым на `:56` ДО раскрытия аббревиатур `:60-61`. **Корень:** Точка инициала вырезается `_PUNCT` раньше цикла раскрытия → одиночный токен `к`/`д` (название улицы) раскрывается безусловно как маркер дома/корпуса. Эмпирически воспроизведено в этом прогоне: - `normalize_address('К. Либкнехта 22')` → `'корпус либкнехта 22'` - `normalize_address('Д. Зверева 10')` → `'дом зверева 10'` Канонический `'улица карла либкнехта 22'` никогда не совпадёт → промах Tier 2a/2b для класса адресов ЕКБ с инициалами в названии улицы. **Что править:** - Раскрывать `д`/`к` в `дом`/`корпус` ТОЛЬКО когда следующий токен — число (regex с lookahead на цифру), а не словесный токен. Либо убрать однобуквенные правила `:37-38` из `_ABBREV` целиком (вреда больше, чем пользы). - Совместить с #1534 — это тот же блок `:37-38`, фиксы пересекаются; делать одним PR с общей канонизацией. **Что посмотреть:** - Код: `normalize.py:_ABBREV` `:20-39`, `_PUNCT` `:13`/`:56`; call-sites `houses.py:118`/`:58`; тесты в `tests/test_matching.py` (рядом с `:29-55`) — `'К. Либкнехта'`, `'Д. Зверева'`. - Vault: релевантных заметок не найдено.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lekss361/gendesign#1535
No description provided.