Промпт для Sonnet — follow-up вопросы по ревью (скорость + сбои)

Контекст

Ты дал ревью (файл: History/2026-08-20-sonnet-query-review-speed.md). Часть пунктов приняли, часть — требуют уточнения. Отвечай ТОЛЬКО на вопросы ниже, сухо, конкретно, без воды. Если что-то из твоих утверждений основано на допущении, а не на факте — скажи явно «допущение» и что нужно проверить, чтобы подтвердить.

Вопрос 1. Фильтр `page.lines or page.curves` перед `extract_tables()` (extractor.py)

Ты предложил: не вызывать extract_tables() на страницах без vector-линий, т.к. на сканах это пустой проход. Вопросы: 1.1. Перечисли КОНКРЕТНО типы таблиц, которые extract_tables() находит, но которые НЕ дают page.lines/page.curves (текстовые сетки, таблицы на заливке/fill, встроенные картинки, что ещё?). 1.2. Есть ли в нашем реальном наборе (TMP/спецификации, 0144-03-2023_отчет об оценке.pdf, документы из DownLoads) риск, что фильтр отбросит реальную таблицу? Это надо проверить фактом — предложи точный способ замера: как сравнить число таблиц с фильтром и без на конкретных файлах. 1.3. Насколько page.lines/page.curves дешевле extract_tables()? В pdfplumber они тоже делают парсинг объектов страницы — дай оценку реального выигрыша на скан-PDF, не «в разы», а чем измерить. 1.4. Безопасная альтернатива: может, стоит вызывать extract_tables() только если page.find_tables() вернул непусто? Или это то же самое по стоимости? Уточни, что реально дорого внутри extract_tables().

Вопрос 2. `_decode_name`: попытка decode("utf-8") перед decode("cp866")

Ты предложил порядок: raw.decode("utf-8"), при ошибке — raw.decode("cp866"). 2.1. Оцени риск ложного срабатывания: когда CP866-байты случайно образуют валидный UTF-8 (например, псевдографика 0xC0-0xDF + продолжения 0x80-0xBF). Насколько это реально для имён файлов 1С? Есть ли способ отличить «настоящий UTF-8» от «случайного» (например, проверить диапазон символов после декодирования)? 2.2. Подтверди, что для нашего реального случая (Info-ZIP UTF-8 без флага 0x800) этот порядок даёт корректное имя, а для CP866 1С — не ломает.

Вопрос 3. ProcessPoolExecutor по страницам / по файлам

Ты предложил распараллелить извлечение текста. Вопросы: 3.1. Риск памяти: в контейнере сессия уже держит файлы в памяти (до 500 МБ в session.py). При fork воркеры получают COW-копию памяти родителя. Оцени реальный риск OOM в managed-поде (лимит CPU 2, Memory 4Gi) при 4-8 процессах. Не будет ли хуже, чем текущее последовательное? 3.2. pdfplumber сам по себе уже использует один процесс. Дай конкретный план безопасного распараллеливания: какие данные передавать в воркер (только bytes страницы или весь файл?), как собирать результаты в порядке индексов, как не раздуть память. 3.3. Учитывая CPU 2 (2 ядра) — какой реальный выигрыш даст ProcessPool на 2 ядрах? Стоит ли это сложности, или сначала дёшево (П.1 + П.2)?

Вопрос 4. Что реально тормозит в Spartan10Manual.pdf (70–470с на 14.8 МБ)

Ты утверждаешь: виноват пустой extract_tables() на скане. Но время скачет 70→470с — это подозрительно. 4.1. Как точно измерить, что дороже на ЭТОМ файле: extract_text() по страницам или extract_tables()? Дай конкретный способ замера (тайминги по функциям, по страницам), чтобы не гадать. 4.2. Объясни разброс 70–470с: что в коде/данных может давать такой разброс между запусками (кэши, LLM, сеть к liberta, нагрузка CPU пода)? 4.3. Есть ли в extract_text() внутри pdfplumber скрытый повторный парсинг (например, повторное чтение объекта при каждом вызове), который можно убрать без смены библиотеки?

Формат ответа

По каждому вопросу: короткий ответ + «факт»/«допущение» + что проверить, если допущение.
Без воды, без лирики.

5.9 KiB Raw Blame History Unescape Escape