docs: сортировка History по темам (sonnet, opus, llm, sse, ux-frontend, upload, infra, plans, tests, base, code-fixes)

History/sonnet/2026-08-20-sonnet-query-honest-speed.md

@@ -0,0 +1,42 @@
+# Промпт для Sonnet — честный ответ: можно ли ускорить без риска устойчивости?
+
+## Роль
+Отвечай ЧЕСТНО и ПО ДЕЛУ. Без воды, без лирики. Если ускорение невозможно без
+компромисса (устойчивость/таблицы/риск) — прямо скажи «нет» и объясни почему.
+Не предлагай «смену библиотеки» — уже пробовали, PyMuPDF теряет таблицы (40 vs 94),
+ТАБЛИЦЫ КРИТИЧНЫ для пользователя. Учитывай это ограничение железно.
+
+## ФАКТЫ (результаты наших замеров, НЕ догадки)
+1. `Spartan10Manual.pdf` (14.8 МБ, 619 страниц, скан/руководство):
+   - `extract_text()` суммарно = **64.4с** (104мс/стр) — УЗКОЕ МЕСТО
+   - `extract_tables()` суммарно = **0.2с** (0мс/стр) — ничтожно
+   - на 272 страницах без линий extract_tables = 0.0с
+   → Твоё прошлое предположение «на сканах дорогой extract_tables» НЕ подтвердилось.
+     Узкое место — ИЗВЛЕЧЕНИЕ ТЕКСТА, а не таблиц. Не повторяй эту ошибку.
+2. Большой PDF 19 МБ (0144-03-2023_отчет об оценке.pdf, 141 стр, 94 таблицы) — ~25-26с.
+3. CPU пода = 2 ядра, Memory = 4Gi. Воркер один, последовательный.
+4. Разброс времени одного файла между запусками: 70с → 470с (Spartan10). Причины
+   не установлены точно (подозрение: CPU throttling/нагрузка пода, декомпрессия битмапов).
+5. `.doc` обрабатывается через HTTP-сервис liberta (IO-bound).
+6. apply_replacements — один regex из всех ключей (уже оптимизирован).
+7. Сессия хранит файлы в памяти до 500 МБ (session.py). ProcessPool с fork —
+   риск COW-копии памяти.
+
+## Вопрос (ответь честно)
+Можно ли ЗНАЧИТЕЛЬНО ускорить обработку (цель — сократить время на больших PDF/наборах),
+НЕ рискуя:
+- устойчивостью (битые файлы, SSE, память пода 4Gi),
+- потерей таблиц (критично),
+- сложностью поддержки (код должен остаться понятным)?
+
+Требования к ответу:
+- Дай КОНКРЕТНЫЕ пункты, каждый: что менять / где / ожидаемый эффект (с цифрами из фактов выше) / риски.
+- Раздели на:
+  A) безопасно и просто (готов внедрить сейчас, низкий риск),
+  B) заметный выигрыш, но с рисками/сложностью (нужен осознанный выбор),
+  C) рискованно/не стоит (объясни почему).
+- Если для БЕЗОПАСНОГО варианта реального выигрыша нет — так и скажи: «безопасно ускорить
+  значительно нельзя», и предложи что реально можно сделать без риска (даже если эффект мал).
+- НЕ предлагай смену pdfplumber/PyMuPDF и не предлагай то, что ломает таблицы.
+- Оцени РЕАЛЬНО: при CPU=2 параллельность текста по страницам даст хоть что-то?
+  (GIL/процессы, overhead fork/spawn, память). С цифрами.