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

History/sonnet/2026-08-20-sonnet-query-llm-followup.md

@@ -0,0 +1,46 @@
+# Промпт для Sonnet — уточнения по LLM-чанкингу (перед внедрением)
+
+Ты дал рекомендуемую схему (чанкинг 6000 chars, overlap 500, параллельность 4–8,
+дедуп + верификация). Перед внедрением уточни практические детали. Отвечай КРАТКО,
+по пунктам, с конкретикой (алгоритм/числа). Без воды.
+
+## У.1 — Разбивка на чанки: по чему резать
+Ты сказал «разбивать по абзацам/предложениям, не по символам». Но в PDF-выгрузках
+текст часто сливается в один-два гигантских «абзаца» (нет \n). Дай КОНКРЕТНЫЙ алгоритм
+разбивки произвольного текста (в т.ч. без \n) на чанки ~6000 символов с overlap 500:
+- по каким границам резать в приоритете (\n\n, \n, '. ', '? ', '; ', потом символы)?
+- как применить overlap без разрыва слова?
+- псевдокод функции split_into_chunks(text, size=6000, overlap=500).
+
+## У.2 — Дедупликация при overlap и некорректном форматировании
+LLM может вернуть один и тот же value из двух чанков с РАЗНЫМ форматированием
+(лишние пробелы, регистр, тире/дефис). Проверки `strip().lower()` недостаточно.
+Как нормализовать перед дедупом (например, сжать пробелы, унифицировать кавычки/тире)?
+Дай конкретный набор нормализаций для русских деловых текстов.
+
+## У.3 — Верификация против исходника
+Проверку «найденного значения нет в исходном тексте → отбросить (галлюцинация)» делать
+против ИСХОДНОГО извлечённого текста файла (до обфускации), верно? Или против чанка?
+Уточни, что есть «источник истины» для верификации, и как быть, если value найден в
+нескольких чанках, но слегка отличается (нормализованное сравнение).
+
+## У.4 — Малые файлы: нужен ли батчинг в первую итерацию
+Набор сотен мелких файлов (<1000 символов). Батчинг 5–8 в один вызов ускорит, но усложнит
+(деградация разметки, больший ответ). Для ПЕРВОЙ итерации можно ли обойтись «1 файл = 1 вызов»
+без батчинга, даже если файлов сотни? Оцени, насколько медленнее будет без батчинга.
+
+## У.5 — Промпт при пофайловом чанкинге
+Текущий промпт (в коде) содержит блоки «Already captured by regex» + большой список правил.
+При пофайловом/почанковом вызове эти блоки повторяются в каждом запросе. Оставить промпт
+как есть (меняя только текст), или его надо упростить под чанк (одна папка уже нашла — regex)?
+Повлияет ли повтор правил на качество/токены?
+
+## У.6 — Прогресс и общее время
+300 файлов, многие >6000 символов → сотни LLM-вызовов × по 1–2с = минуты-десятки минут.
+Пользователь готов ждать (LLM своя). Но оцени: с параллельностью 4 и ~5 вызовов/файл на
+крупных — реальное общее время для набора ~300 файлов (в т.ч. 270 мелких + 30 крупных).
+И: не упрёмся ли в rate-limit своего LLM-эндпоинта при 4-8 параллельных.
+
+## Формат
+- По каждому У.1–У.6: короткий ответ + конкретика (алгоритм/числа/решение).
+- Если что-то некритично для первой итерации — скажи явно «можно первым шагом упростить так».