54 lines
5.9 KiB
Markdown
54 lines
5.9 KiB
Markdown
# Промпт для 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 скрытый повторный парсинг (например, повторное чтение
|
||
объекта при каждом вызове), который можно убрать без смены библиотеки?
|
||
|
||
## Формат ответа
|
||
- По каждому вопросу: короткий ответ + «факт»/«допущение» + что проверить, если допущение.
|
||
- Без воды, без лирики.
|