Промпт для 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: короткий ответ + конкретика (алгоритм/числа/решение).
Если что-то некритично для первой итерации — скажи явно «можно первым шагом упростить так».

4.6 KiB Raw Blame History Unescape Escape