trade_in_pdf.py:256 — бейдж достоверности печатает n_analogs=объявления+сделки, завышая «N аналогов» и противореча заголовку стр.2 #1589

New issue

Closed

opened 2026-06-16 17:13:06 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-16 17:13:06 +00:00

Collaborator

Severity: low · Категория: ложь в отчёте / неверный агрегат · Файл: backend/app/services/exporters/trade_in_pdf.py:256

Файл: backend/app/services/exporters/trade_in_pdf.py:256. На обложке бейдж достоверности рендерит {estimate.n_analogs} аналогов. Поле заполняется в backend/app/api/v1/trade_in.py:192 как n_analogs=n_analogs + n_deals (объявления randint(7,10) + сделки randint(3,5)). Но стр.2 'Объявления-аналоги' (trade_in_pdf.py:273) показывает только len(estimate.analogs), а стр.3 'Фактические сделки' (стр.301) отдельно len(estimate.actual_deals). Импакт: на обложке рядом с «Достоверность: ...» клиент видит, например, «12 аналогов», тогда как объявлений-аналогов в отчёте 8 — детерминированное завышение выборки и внутреннее противоречие документа. Контекст: mock-MVP (футер 'mock-данные (Phase 1 MVP)'), что ограничивает прод-импакт. Фикс: на обложке показывать только число объявлений-аналогов (len(estimate.analogs)), либо явно подписать «N объявлений + M сделок»; в идеале не использовать суммирующее поле n_analogs для подписи «аналогов». Корневая правка — разделить счётчики в API/модели.

Почему баг: Бейдж стоит вплотную к «Достоверность: Высокая/Средняя» и читается клиентом как объём выборки аналогов, обосновывающий оценку. Фактически в число подмешаны сделки Росреестра, которые в отчёте идут отдельной сущностью (стр. 3) и отдельно посчитаны. Цифра доказательной базы, показываемая клиенту, детерминированно завышена на число сделок и противоречит собственному заголовку стр. 2 того же документа. Примечание: корень — в API (суммирование n_analogs), но симптом проявляется именно как мислейбл «N аналогов» на обложке PDF.

Как чинить: В бейдже выводить именно число объявлений-аналогов: {len(estimate.analogs)} аналогов либо развести явно «N аналогов · M сделок». Альтернатива — не суммировать сделки в n_analogs на стороне API, хранить раздельные счётчики.

_{deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.82 · unit B20}

**Severity:** low · **Категория:** ложь в отчёте / неверный агрегат · **Файл:** `backend/app/services/exporters/trade_in_pdf.py:256` Файл: backend/app/services/exporters/trade_in_pdf.py:256. На обложке бейдж достоверности рендерит `{estimate.n_analogs} аналогов`. Поле заполняется в backend/app/api/v1/trade_in.py:192 как `n_analogs=n_analogs + n_deals` (объявления randint(7,10) + сделки randint(3,5)). Но стр.2 'Объявления-аналоги' (trade_in_pdf.py:273) показывает только `len(estimate.analogs)`, а стр.3 'Фактические сделки' (стр.301) отдельно `len(estimate.actual_deals)`. Импакт: на обложке рядом с «Достоверность: ...» клиент видит, например, «12 аналогов», тогда как объявлений-аналогов в отчёте 8 — детерминированное завышение выборки и внутреннее противоречие документа. Контекст: mock-MVP (футер 'mock-данные (Phase 1 MVP)'), что ограничивает прод-импакт. Фикс: на обложке показывать только число объявлений-аналогов (`len(estimate.analogs)`), либо явно подписать «N объявлений + M сделок»; в идеале не использовать суммирующее поле n_analogs для подписи «аналогов». Корневая правка — разделить счётчики в API/модели. **Почему баг:** Бейдж стоит вплотную к «Достоверность: Высокая/Средняя» и читается клиентом как объём выборки аналогов, обосновывающий оценку. Фактически в число подмешаны сделки Росреестра, которые в отчёте идут отдельной сущностью (стр. 3) и отдельно посчитаны. Цифра доказательной базы, показываемая клиенту, детерминированно завышена на число сделок и противоречит собственному заголовку стр. 2 того же документа. Примечание: корень — в API (суммирование n_analogs), но симптом проявляется именно как мислейбл «N аналогов» на обложке PDF. **Как чинить:** В бейдже выводить именно число объявлений-аналогов: `{len(estimate.analogs)} аналогов` либо развести явно «N аналогов · M сделок». Альтернатива — не суммировать сделки в n_analogs на стороне API, хранить раздельные счётчики. --- deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.82 · unit B20