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