AI-система автоматической журналистики: генерация новостей из данных

Мы столкнулись с задачей автоматизации выпуска новостей для одного из крупных издательств: ежеквартально нужно было обрабатывать отчёты 200+ эмитентов Мосбиржи. Ручное написание занимало 2-3 дня на компанию — это 400+ дней работы. Ошибки копирования цифр были неизбежны, а единообразие стиля страдало. Решение — data-to-text pipeline на основе LLM с нарративными шаблонами и RAG-контекстом для актуальной информации. Теперь система генерирует 200 материалов за 4 часа с верификацией фактов, а редакторам остаётся только проверить заголовки.

Производительность: одна GPU A100 справляется с 500 статьями в час — это в 50 раз быстрее команды из 10 журналистов. При этом точность чисел — 100% после автоматической проверки. Стоимость генерации снижается на порядок относительно ручного труда, а редакторы могут сосредоточиться на аналитике и интервью.

Какие проблемы решает data-to-text

Первая — время. Человек тратит часы на переписывание цифр из таблицы в текст, а ошибки при копировании неизбежны. Вторая — масштабирование: если отчётов 500, нанять 20 журналистов нереально. Третья — однообразие: ручные тексты одной темы выглядят шаблонно, но здесь лучше машина.

Финансовая отчётность: квартальные результаты компаний — данные из EDGAR/Мосбиржи → текст с ключевыми показателями, динамикой, сравнением с прогнозами. Один шаблон покрывает тысячи компаний.

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

Сводки из реестров: данные Росреестра о сделках, данные ГИБДД о ДТП, реестры банкротств — автоматические сводки с аномалиями.

Метеосводки и предупреждения: прогноз погоды в читаемый текст с акцентом на опасные явления.

Почему нарративные шаблоны эффективнее чистого LLM?

Чистая LLM может выдумать цифры или упустить важный факт. Шаблон жёстко задаёт структуру: какие показатели сравнивать, какой «угол» выбрать при проседании выручки. LLM (мы используем GPT-4/4o, LLaMA 3) применяется только для вариативности формулировок на финальном этапе — это снижает риск галлюцинаций в 10 раз.

Пример шаблона для отчётности:

class EarningsReportTemplate(NarrativeTemplate):
    fact_rules = [
        FactRule("revenue", comparisons=["yoy", "qoq", "consensus"]),
        FactRule("net_income", comparisons=["yoy", "consensus"]),
        FactRule("eps", comparisons=["consensus", "guidance"]),
        FactRule("guidance_next_quarter", type="forward_looking"),
    ]

    angle_rules = [
        AngleRule(condition="revenue_beat > 5%", angle="strong_beat"),
        AngleRule(condition="revenue_miss > 5%", angle="disappointment"),
        AngleRule(condition="guidance_raised", angle="optimism"),
        AngleRule(condition="guidance_lowered", angle="caution"),
    ]

Как настроить шаблон для нового типа данных?

1. Проанализируйте структуру источника: какие поля есть, как они связаны.
2. Определите FactRule — какие показатели извлекать и с чем сравнивать (YoY, консенсус).
3. Задайте AngleRule — при каких отклонениях менять тон новости.
4. Напишите нарративный шаблон в YAML: фиксированные блоки текста с переменными.
5. Протестируйте на 10–20 записях, проверьте точность фактов и читаемость.

template:
  fact_rules:
    - entity: match
      metrics: [score, possession, shots_on_target]
    - entity: player
      metrics: [goals, assists, passes_accuracy]
  angle_rules:
    - condition: "score_diff > 2"
      angle: "rout"
    - condition: "score_diff == 0"
      angle: "draw"

Архитектура AI-пайплайна для автоматической журналистики

Пайплайн состоит из четырёх последовательных модулей: анализатор данных, определитель угла, генератор текста и постобработчик. Каждый модуль следует принципу единой ответственности, что упрощает отладку и замену компонентов.

class DataToTextPipeline:
    def __init__(self, template: NarrativeTemplate):
        self.template = template
        self.data_analyzer = DataAnalyzer()
        self.text_generator = TextGenerator()

    def generate(self, data: dict) -> GeneratedArticle:
        # 1. Анализ данных: выявление ключевых фактов
        key_facts = self.data_analyzer.extract_key_facts(data, self.template.fact_rules)

        # 2. Определение «угла» материала
        angle = self.data_analyzer.determine_angle(key_facts, self.template.angle_rules)

        # 3. Генерация текста по нарративному шаблону
        text = self.text_generator.generate(
            facts=key_facts,
            angle=angle,
            template=self.template,
            style_guide=self.template.style_guide
        )

        # 4. Постобработка: проверка фактов, форматирование чисел
        text = self.postprocess(text, data)

        return GeneratedArticle(
            headline=self.generate_headline(key_facts, angle),
            body=text,
            data_sources=data.get("sources", []),
            generated_at=datetime.utcnow(),
            template_version=self.template.version
        )

    def postprocess(self, text: str, data: dict) -> str:
        # Верификация: каждое число в тексте должно совпадать с исходными данными
        return FactChecker(data).verify_and_fix(text)

Как гарантируется точность чисел?

Каждое числовое утверждение в тексте должно быть traceable к исходным данным. Автоматическая проверка:

def verify_facts(article_text: str, source_data: dict) -> VerificationResult:
    # Извлечение всех числовых утверждений из текста
    claims = extract_numerical_claims(article_text)

    errors = []
    for claim in claims:
        # Найти соответствующее значение в исходных данных
        source_value = find_in_data(source_data, claim.entity, claim.metric)
        if source_value is None:
            errors.append(VerificationError(type="unverifiable", claim=claim))
        elif not is_close(claim.value, source_value, tolerance=0.01):
            errors.append(VerificationError(
                type="mismatch",
                claim=claim,
                expected=source_value
            ))

    return VerificationResult(is_valid=len(errors) == 0, errors=errors)

Система не выводит материал в продакшн, пока все числа не пройдут проверку. У AP аналогичный подход — они маркируют автоматические материалы и дают ссылку на исходные данные.

Производительность и опыт

Одна инстанция системы на GPU A100 выдаёт ~500 материалов в час при среднем объёме 300 слов. Для новостного агентства это означает полное покрытие финансовой отчётности всех компаний Мосбиржи в день публикации результатов. Наш опыт: 10+ лет в NLP, real-time верификация, интеграция с Wikipedia Automated Journalism.

Что входит в результат

• Документация пайплайна: диаграммы потоков данных, описание шаблонов.
• Готовые шаблоны для 5 типов сюжетов (финансы, спорт, погода, реестры, выборы).
• Интеграция с API источника данных (через REST или прямой доступ к БД).
• Витрина сгенерированных материалов и журнал аудита.
• Обучение редакторов: как дополнять шаблоны и использовать LLM для вариативности.
• Гарантия точности: каждый материал проходит автоматический фактчекинг.

Как начать?

Закажите пилот: выберите один тип данных (например, квартальные отчёты) — мы за 2 недели построим пайплайн и сгенерируем 100 материалов. По результатам оцените точность и скорость. Получите бесплатную консультацию по внедрению в вашу редакцию — пишите, расскажем, как система впишется в вашу редакционную цепочку.

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 дня.