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

2026-08-24 15:23:31 +03:00
parent 25e4b46e76
commit db7cdbdd84
69 changed files with 0 additions and 0 deletions
@@ -0,0 +1,30 @@
+# Промпт для Sonnet — вопрос по использованию LLM (без ссылок на файлы)
+
+## Контекст
+У нас сервис обфускации документов (удаление персональных данных из русских деловых документов).
+Двухступенчатый детект ПДн:
+1. Regex-паттерны (телефоны, ИНН, email, типовые формы — быстро, локально, дёшево).
+2. LLM (общая NER-подстраховка) — сейчас обрабатывает только урезанный фрагмент:
+   - от каждого файла берутся первые ~3000 символов,
+   - всё вместе обрезается до ~8000 символов,
+   - выполняется ОДИН вызов LLM на весь набор.
+
+Пользователь хочет, чтобы LLM обрабатывал ВСЕ данные (ВСЕ файлы целиком), не только первые 8000 символов.
+LLM — своя, стоимость не важна. Важно качество распознавания ПДн и разумная архитектура вызова.
+
+## Вопрос
+Как лучше организовать вызов LLM, чтобы он БЕЗ потерь покрывал все документы (набор из сотен файлов, каждый до нескольких десятков страниц), сохраняя качество распознавания русских деловых документов?
+
+Ограничения/требования к ответу:
+- Не предлагай менять модель/external API — LLM своя, она остаётся.
+- Подумай про: пакетирование файлов (размер батча), максимальную длину контекста на запрос,
+  как избежать обрезки данных, как не потерять качество при больших объёмах,
+  параллельность запросов (если релевантна), дедупликацию найденного между пакетами.
+- Дай конкретную рекомендуемую схему (числа: размер батча, лимит символов на файл/пакет, параллельность).
+- Оцени риски: токены/время, качество, риск пропуска.
+- Сухо, по делу, без воды.
+
+## Формат
+- Секция «Рекомендуемая схема» — конкретный план с числами.
+- Секция «Риски» — что может пойти не так и как смягчить.
+- Секция «Минимум для старта» — если хочется просто и быстро, что достаточно сделать первым шагом.