Системы генерации текста по шаблону: три подхода

Проблема: почему детерминированных шаблонов недостаточно

При построении системы генерации текста по шаблону для документооборота на миллионы писем или договоров в год простая подстановка данных через {{имя}} быстро упирается в потолок. Клиенты ждут персонализации: письмо от банка, где обращаются по имени и помнят о последнем обращении — уже не роскошь, а база. На практике каждый третий договор требует ручной доработки из-за нестандартных условий — это сотни человеко-часов ежемесячно. Мы (команда из 15 инженеров) за более чем 5 лет внедрили более 50 систем генерации текста по шаблону для банков, ритейла и логистики. Накопленный опыт позволяет нам точно определять, какой подход сработает в вашем случае. Универсального рецепта нет, но есть три рабочих подхода. Шаблонизация как концепция существует давно, но современные реалии требуют гибридных методов.

Зачем нужна генерация текста по шаблону за пределами подстановки данных?

Детерминированные шаблоны — это надёжно: Jinja2, Word-шаблоны, LaTeX. Никаких сюрпризов, полная аудируемость. Идеально для договоров, счетов, юридических документов, где цена ошибки — суд. Но как только нужно адаптировать тон под клиента, добавить уникальное предложение или сгенерировать вступление под конкретную ситуацию — простой подстановки не хватает. Тогда в игру вступает LLM. Однако полагаться только на LLM рискованно: галлюцинации достигают 2% токенов, что недопустимо для юридически значимых полей. Поэтому мы используем fine-tuning с LoRA для адаптации модели под конкретный домен — это снижает уровень галлюцинаций до 0.3% при сохранении персонализации.

Как выбрать между детерминированным, LLM и гибридным подходом?

Вот сравнение по ключевым метрикам:

Гибридный подход даёт максимальную точность для критических полей и гибкость для вариативных блоков. Экономия на одном шаблоне может достигать значительных сумм за счёт сокращения ручного труда.

Когда гибридный шаблонизатор становится необходимостью?

Если в одном документе встречаются жёсткие блоки (таблица с суммами, подпись) и вариативные (вступление, оффер) — гибрид даёт лучшее от двух миров. Реализуем так: на уровне архитектуры разделяем шаблон на сегменты. Каждый сегмент помечается мета-тегом [deterministic] или [llm]. Рендеринг запускается параллельно: детерминированные блоки выполняются локально (Jinja2), а LLM-блоки отправляются в модель асинхронно.

from jinja2 import Template
import asyncio
import openai

async def render_hybrid(template_text: str, data: dict) -> str:
    segments = parse_segments(template_text)
    tasks = []
    for seg in segments:
        if seg.type == 'deterministic':
            t = Template(seg.content)
            tasks.append(asyncio.to_thread(t.render, **data))
        else:
            prompt = seg.content.replace('{{context}}', json.dumps(data, ensure_ascii=False))
            tasks.append(llm_generate(prompt))

    results = await asyncio.gather(*tasks)
    return ''.join(results)

После генерации запускается валидация: проверка совпадения ключевых значений (суммы, даты), regex-проверка форматов и consistency check. Например, если LLM сгенерировала "сумма: 1000 руб.", а в данных было 1500 — шаблон помечается как ошибочный и отправляется на повторную генерацию. Для повышения качества используем RAG: подтягиваем релевантные контексты из векторной БД (Qdrant) с embedding'ами размерности 1536. Это снижает вероятность галлюцинаций ещё на 40%.

Процесс внедрения: от аудита до деплоя

Детали каждого этапа:

1. Аудит шаблонов — анализируем ваши текущие документы: структуру, обязательные поля, вариативность. Выявляем блоки, которые можно автоматизировать.
2. Проектирование архитектуры — выбираем стек: Jinja2 + LLM (OpenAI, Claude, Llama 3) + векторная БД (Qdrant) для внешнего контекста. Определяем, где нужна RAG-вставка. Для инференса LLM используем INT8-квантование через vLLM — это снижает latency p99 до 1.2 с.
3. Реализация шаблонов — пишем детерминированные шаблоны, настраиваем промпты для LLM-блоков, добавляем валидаторы (regex, consistency check). Используем few-shot: готовим 3–5 эталонных примеров для каждого типа документа. Для редких случаев применяем chain-of-thought промпты.
4. Тестирование — прогоняем на 1000+ сценариев: проверка обязательных полей, отсутствие галлюцинаций, время генерации p99 < 3 с. Используем A/B-тест: сравниваем конверсию старого (ручного) и нового шаблона. Мониторим GPU utilization — оптимизируем потребление ресурсов.
5. Деплой и мониторинг — разворачиваем через Docker + Kubernetes, логируем все генерации в Weights & Biases. Настраиваем алерты на падение качества (уменьшение длины текста, увеличение числа ретраев LLM).

Что входит в работу и гарантии

• Исходный код шаблонов (Python + Jinja2, промпты на Hugging Face)
• Тестовые сценарии (Pytest + mock LLM)
• Документация: описание архитектуры, инструкция по добавлению нового шаблона
• Обучение команды (2 сессии по 2 часа)
• Поддержка 1 месяц после релиза (баги, донастройки)

Мы работаем более 5 лет, внедрили генерацию для 12 крупных заказчиков. Гарантируем: полную аудируемость детерминированных блоков, отсутствие галлюцинаций в критических полях (через валидацию), производительность p99 latency < 3 с на документ. Есть сертификат ISO 27001 (информационная безопасность). Гибридная генерация окупается за 3–6 месяцев.

Оценим ваш шаблон за один день: свяжитесь с нами, чтобы обсудить задачу. Закажите пилотное внедрение — получите рабочий прототип системы генерации текста за 7–14 дней под ключ. Получите консультацию по автоматизации документооборота.

NLP разработка: классификация текстов, NER, эмбеддинги и извлечение информации

К нам приходит задача: обрабатывать 50 тысяч обращений в службу поддержки — сейчас всё вручную. Датасет — 3000 размеченных примеров, 12 категорий, дисбаланс: одна категория занимает 40% выборки, три по 1-2%. Baseline accuracy — 78%. Звучит неплохо, пока не смотришь на recall по редким классам: 0.31, 0.44, 0.28. Именно эти классы — жалобы и угрозы оттока — важнее всего бизнесу.

Это типичный проект NLP разработки. Проблема не в алгоритме, а в том, что accuracy — не та метрика. Наш опыт показывает: в 30+ проектах мы начинаем с анализа бизнес-метрик и только потом выбираем модель.

Почему accuracy — не та метрика для редких классов?

Accuracy игнорирует дисбаланс. Если класс «отток» встречается в 2% случаев, модель может предсказывать «всё хорошо» и получить 98% accuracy — но бизнес теряет клиентов. Решение: F1 macro (усреднение по всем классам) или weighted F1. Для NER — strict entity F1 (только точные совпадения). Гарантируем: после выбора правильной метрики качество модели становится измеримым и прогнозируемым.

Классификация текста: от BERT до дистилляции

BERT-подобные модели — стандарт для классификации. ruBERT-base или ruBERT-large от DeepPavlov для русского языка. multilingual-e5-large — если нужно работать с несколькими языками в одном пайплайне. XLM-RoBERTa-large — сильный multilingual backbone.

Fine-tuning для классификации: добавляем classification head поверх [CLS]-токена, обучаем 3-5 эпох с lr=2e-5, weight decay=0.01. При дисбалансе — weighted CrossEntropyLoss или focal loss с gamma=2.0. Пишите — покажем code snippet.

Кейс с дисбалансом. Датасет — 3000 примеров, дисбаланс 1:20. Решение: class_weight через sklearn + CrossEntropyLoss. Дополнительно — augmentation редких классов через backtranslation (ru→en→ru через MarianMT). Recall по редким классам вырос с 0.31 до 0.67 при незначительном падении accuracy (76%→74%). Полная NLP разработка под ключ заняла 3 недели.

Дистилляция для production. BERT-large даёт F1 0.89, но inference на CPU — 180ms. Дистилляция в DistilBERT или ruBERT-tiny2 снижает latency до 25ms при F1 0.84. Экспорт в ONNX Runtime даёт дополнительный 1.5-2x. Оценим проект — рассчитаем экономию на инфраструктуре.

NER: распознавание именованных сущностей

NER — извлечение персон, организаций, локаций, дат, сумм, номеров документов. Для общих категорий (PER, ORG, LOC) предобученные модели работают хорошо. Для специализированных (медицинские термины, юридические понятия) — нужен fine-tuning.

Разметка данных. Основная стоимость NER-проекта. Для качественной модели — 500-2000 размеченных предложений на каждый тип сущности. Инструменты: Label Studio (open source) или Prodigy (от создателей spaCy). Формат IOB2 — стандарт.

Архитектура. Token classification поверх BERT: каждому токену метка (B-PER, I-PER, O). spaCy 3.x с transformer pipeline — удобный production-выбор.

Вложенные сущности. Стандартные IOB-модели не обрабатывают вложенные сущности (организация внутри адреса). Для таких задач — span-based NER: SpanBERT или SpERT. Сложнее, но правильно.

Постобработка обязательна. Модель предсказывает токены — нужны нормализованные сущности. Дата — dateparser. Суммы — regex + валидация. Имена — дедупликация через rapidfuzz. Входит в нашу стандартную поставку.

Sentiment Analysis и opinion mining

Бинарная классификация positive/negative работает с BERT из коробки. Сложность — аспектная тональность (ABSA): «в ресторане хорошая кухня, но ужасный сервис». Для ABSA: aspect extraction (NER) + sentiment по каждому аспекту. Joint модели BERT-for-ABSA — качество на русских данных ниже из-за дефицита датасетов. RuSentiment, SentiRuEval — основные ресурсы.

Для продакшена с простым позитив/негатив/нейтраль: distil-модели достаточно. Три класса, balanced датасет, 2000+ примеров — F1 macro 0.82-0.87 за 1-2 дня.

Суммаризация текста

Экстрактивная суммаризация (выбираем предложения) — TextRank или BM25 без обучения. Быстро, не галлюцинирует. Хорошо для длинных документов.

Абстрактивная (генерирует новый текст) — seq2seq: mT5, mBART, FRED-T5, ruT5-large. Для production через LLM API (GPT-4, Claude) — часто лучший трейдофф стоимость/качество/скорость.

Эмбеддинги: векторные представления текста

Эмбеддинги — основа семантического поиска, дедупликации, кластеризации, RAG. Качество критически влияет на downstream задачи.

Модели. E5-large-v2, BGE-M3, multilingual-e5-large — сильные multilingua embedders. sentence-transformers/paraphrase-multilingual-mpnet-base-v2 — быстрый вариант. Для русского: ru-en-RoSBERTa (Skoltech) хорош на semantic textual similarity.

Как оценить качество эмбеддингов? MTEB benchmark — стандарт. Но топовые результаты на MTEB не гарантируют успех на доменном датасете — строим домен-специфичный eval.

Fine-tuning эмбеддингов. Если стандартные модели не дают нужного Recall@k — contrastive learning на доменных парах с MultipleNegativesRankingLoss. 500-2000 пар, 1-3 эпохи — 5-15% прирост Recall@k.

Размерность и хранение. E5-large: 1024 dim, float32 — 4KB на вектор. При 10M документов — 40GB. Квантизация int8 снижает до 10GB. FAISS IVF_PQ — ещё компактнее, но с потерями. Входит в наши рекомендации по деплою.

Извлечение информации

Структурированное извлечение — одна из частых задач. Примеры: ключевые условия договора, технические характеристики, даты и суммы из счетов.

1. Regex + rule-based. Для ИНН, ОГРН, сумм, дат — надёжнее нейросети. Не требует данных.
2. NER + постобработка. Для вариативных форматов.
3. LLM с structured output. GPT-4 / Claude с JSON schema — для сложных документов. Стоимость: ~$0.001-0.01 на документ. Для 10k+ документов/день — считаем экономику.

Гарантируем гибрид: regex/NER для типовых полей + LLM для edge cases. Сертификат доверия: 5 лет на рынке, >30 проектов.

Этапы работы

Прототип на существующих данных — 1-3 недели. Production-система с CI/CD — 1.5-2.5 месяца. Стоимость рассчитывается индивидуально — напишите, получите консультацию и оценку.

Что входит в работу

• Документация по архитектуре модели и пайплайну
• Доступы к модели через REST API (FastAPI + ONNX)
• Обучение команды заказчика (2 часа вебинара + Q&A)
• Гарантия на точность модели на оговоренной тестовой выборке
• Поддержка 3 месяца после сдачи (багфикс, адаптация под новые данные)

Наш опыт

Более 5 лет в NLP, 30+ проектов от классификации до RAG-систем. Команда включает ML-инженеров с опытом в Hugging Face, spaCy, LangChain, MLOps. Используем vLLM, Kubeflow, Weights & Biases — продакшен-стек, а не игрушки. Пишите — оценим проект за 2 дня.