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

Автоматическая журналистика: где ломается ручной конвейер

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

Отсюда главная издержка — задержка публикации. Материал выходит через часы после события, когда окно спроса уже закрыто, а сам текст описывает состояние, которого больше нет. При этом каждое обновление требует новой правки, и на объёме потоков редакция либо теряет часть событий, либо публикует их с опозданием и устаревшими цифрами.

Второй класс сбоев — дубли и расхождения в данных. Один и тот же факт приходит из нескольких источников, попадает к разным авторам и превращается в два материала с несовпадающими числами. Расхождение копится незаметно: разный период выборки, разная валюта свёртки, разные правила округления. Читатель видит два текста про одно событие с разными цифрами, и доверие к обоим падает.

Попытка закрыть это «писать быстрее» не работает: узкое место не в скорости человека, а в самой схеме — ручной конвейер не масштабируется по частоте событий и не удерживает единый источник истины для цифр. Разбираем, как это закрывается.

Что даёт автоматическая журналистика редакции и продукту

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

Скорость выпуска и охват тем

Материал, который раньше ждал свободного корреспондента, выходит через минуты после обновления источника: задержку определяет регламент проверки, а не загрузка людей. Шаблон с переменными и правилами подстановки закрывает типовые сюжеты — локальную статистику, итоги тура, динамику показателей по районам.

Охват растёт без потери качества: там, где редакция писала о десяти крупнейших городах, конвейер отдаёт черновик по всем, а фильтр по аномалиям выносит наверх то, что действительно стоит внимания.

Прозрачность источников и устранённые ошибки

Каждое утверждение в черновике привязано к полю исходных данных с временем получения: при разборе видно, откуда взялась цифра и какое правило привело её в текст. Это закрывает класс ошибок, который в ручной работе ловится поздно — перепутанная единица, устаревший срез, значения не за тот период.

Правки смещаются в стиль и заголовки, а не в факты: доля материалов, доходящих до публикации без правки по существу, растёт, и время редакции уходит на темы, где нужен живой репортёр. Такой порядок эффектов фиксируют и отраслевые обзоры — Обзор практик автоматической генерации текстов из структурированных данных.

Режимы генерации: шаблонный, гибридный и модельный

Режим генерации выбирают не по вкусу, а по структуре входных данных и цене ошибки. Чем предсказуемее сигнал на входе — тем жёстче можно зафиксировать формулировки; чем разнороднее источники и сложнее сюжет, тем больше свободы нужно модели. Мы настраиваем режим под поток, а не наоборот.

Когда шаблонный режим достаточен

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

Когда нужен гибридный режим

Гибрид берут там, где модель пишет связный текст, но числа и имена собственные подставляются из проверенного источника, а спорные места уходят редактору. Так сохраняется скорость выпуска при контроле над фактами — мы ограничиваем автоматизацию теми темами, где цена ошибки ниже стоимости проверки.

Этапы внедрения: от аудита данных до публикации

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

Подготовка и аудит источников

1. Аудит источников данных. Инвентаризируем ленты, выгрузки и внутренние хранилища: полнота записей, задержка появления события, дубли, стабильность формата. По каждому источнику отмечаем поля, пригодные для машинной обработки.

2. Схема сущностей. Сводим разрозненные записи в единую модель: люди, организации, места, события и числовые показатели. Без неё шаблон подставляет число не тому субъекту — типовая причина фактических ошибок.

3. Правила отбора событий. Задаём пороги значимости, дедупликацию и приоритеты: что идёт в генерацию, что объединяется, что отсекается как шум. Правила согласуем с редакцией, а не выводим из данных автоматически.

Проверка фактов и приёмка

• Настройка генерации. Собираем шаблоны под каждый тип события, задаём длину, тон и вариативность формулировок, чтобы поток не выглядел клонированным.

• Приёмка качества текстов. Прогоняем систему на исторических событиях и сверяем каждое число, имя и дату с источником. Отдельно считаем долю публикаций, ушедших без правок редактора.

• Промышленный запуск. Переводим конвейер на расписание, добавляем контроль задержек, очередь повторной обработки и остановку выпуска при расхождении с источником.

• Передача и обучение. Отдаём документацию, регламент правок и точки контроля, чтобы поток сопровождался без нашего участия.

Что остаётся у заказчика после внедрения

После сдачи проекта в контуре заказчика остаётся не только работающий сервис, но и весь набор настроек, по которым его можно развивать, передавать смене и проверять. Ниже — что фиксируется в документации и репозитории, а не остаётся в переписке с командой.

• Конфигурации генерации: шаблоны запросов под каждый жанр — новость, дайджест, сводка по данным, — правила длины, структуры заголовка и обязательных блоков, пороги вариативности формулировок.
• Схема источников и связей: перечень подключённых каналов данных, приоритет между ними, частота опроса, правила дедупликации и признаки, по которым запись считается недостоверной.
• Шаблоны и правила тональности: словари допустимых и запрещённых формулировок, стоп-листы, правила цитирования и раскрытия источника данных.
• Политики доступа и роли: кто правит шаблоны, кто публикует, кто только читает журнал; разделение прав между редакцией, аналитикой и подрядчиком.
• Регламент выпуска: путь материала от поступления данных до публикации, точки обязательной проверки человеком, условия автоматического выпуска и порядок отзыва.
• Журналы выпусков и инструкции: кто, что и на основании каких данных опубликовал, какие правки внёс редактор, как подключить новый источник и что делать при сбое канала.

Регламенты и документация

Передача документации идёт вместе с обучением: прогоняем с редакцией и инженером сценарии — подключение источника, откат шаблона, разбор ошибочной публикации. После этого команда меняет конфигурации генерации и правила тональности сама, без обращения к разработчику.

Отдельно фиксируем, что считается инцидентом, в какой срок он разбирается и по каким метрикам проверяется качество выпусков. Так система остаётся управляемой, когда её развивает уже внутренняя команда.

Кейс: поток новостей из открытых данных вместо ручной ленты

Проект — генератор новостей из открытых данных: сервис сам забирает обновления, проверяет их на аномалии, подставляет значения в шаблон и кладёт готовый черновик в очередь редактора. Источник — порталы открытой статистики, в основе Единая платформа открытых данных. Ниже — метрики до и после перевода ленты на такой поток.

Что было до

Дежурный редактор собирал ленту вручную: скачивал выгрузку, сверял показатели, писал текст и заполнял карточку. Один материал занимал около 40 минут, за сутки выходило 8 выпусков, и лента замолкала к вечеру. При ручной сверке в 12% публикаций находили расхождения в цифрах — их снимали или правили уже после выпуска, а каждый четвёртый материал возвращался на доработку. Дежурство означало постоянное присутствие у экрана.

Что стало после

Данные приходят потоком, проверка на аномалии и сверка значений выполняются до попадания в шаблон, редактор видит очередь готовых черновиков. Подготовка материала сократилась до 2-3 минут — в основном на вычитку формулировок, число выпусков выросло до 60 в сутки без расширения смены. Доля публикаций с расхождениями в цифрах опустилась ниже 1%: значения сверяются с первоисточником автоматически. Возвраты на доработку — около 5%, нагрузка на дежурного редактора свелась к часовой проверке очереди.

Лента перестала зависеть от одного человека: выпуски идут и в выходные, а редактор занят смыслом и формулировками, а не переносом цифр.

Чем отличается шаблонная генерация от модельной?

Шаблонная генерация — это детерминированная подстановка данных в заранее написанные конструкции: одна и та же новость при одних и тех же входных числах собирается в один и тот же текст. Предсказуемость здесь максимальная, проверка сводится к сверке подстановок, а любое отклонение входных данных от ожидаемого формата выявляется сразу — либо пропуском выпуска, либо явной ошибкой в поле, а не правдоподобной выдумкой. Плата за это — вариативность формулировок почти нулевая: на серии однотипных событий читатель видит одну и ту же фразу, и лента начинает выглядеть механической.

Модель работает наоборот: она перестраивает формулировку под конкретное событие и держит связность на нестандартных сюжетах, но её ошибки другого класса. Вместо отказа выходит уверенный текст с подменённой ролью, смещённым числом или дописанной причиной, которой в источнике не было. Поэтому модельный режим без привязки сущностей и чисел к исходным данным и без проверки утверждений по источнику в новостном конвейере не применяется — гибкость формулировок здесь покупается только ограничением свободы.

Выбор режима привязан к типу события, а не к пожеланию редакции. Табличные поводы — результаты, котировки, статистика, протоколы — уходят в шаблон, потому что там важна точность, а не стиль. Описательные и обзорные сюжеты, где важен контекст, идут через модель с обязательным подтверждением каждого факта, пометкой об источнике и стоп-условием на выпуск, если проверка не прошла. Смешанный случай — когда основу даёт шаблон, а модельный слой только перефразирует готовую фактуру, не добавляя ничего от себя.

В поддержке это две разные дисциплины. Шаблонное решение живёт на библиотеке конструкций и наборах тестовых входов: приёмка измеряет долю корректных подстановок и число отказов на нетиповых данных. Модельное — на наборе эталонных событий с известными правильными ответами, на проверке фактологии и на фиксации параметров, при которых результат воспроизводится; любая смена модели или инструкции означает повторную приёмку. Поэтому в проекте обычно гибрид: шаблон как режим по умолчанию, модель как расширение там, где нужна вариативность формулировок — и понятная граница между ними.

Технические сомнения и ограничения подхода

Ограничения выносим отдельно: автоматическая журналистика — не кнопка «сделать новость», а контур с чёткими границами. Ниже — пять вопросов, которые чаще всего задают редакции.

Что делать с неполными и противоречивыми данными?

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

Как отделяются факты от оценок и прогнозов?

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

Как это встраивается в редакционную систему?

Через штатные интерфейсы: материалы попадают в очередь редакции обычными черновиками с полями и пометками. Автор правит их там же, где остальную выдачу, без второго окна и ручного переноса. Права доступа, история правок и статусы публикации сохраняются как есть.

Тексты не станут однотипными?

Однотипность — реальное ограничение шаблонной генерации, поэтому вариативность закладываем в структуру: несколько схем подачи, разный порядок блоков, разные формулировки одного факта. Для авторских жанров с живой интонацией редактор остаётся обязательным звеном.

Обсудим задачу: что нужно для старта

Чтобы старт проекта не растянулся на месяцы переписки, на входе достаточно того, что у вас уже есть. Чистовое техническое задание готовить не нужно — важнее понять, из каких данных рождается материал и кто отвечает за выпуск.

Полезно иметь на входе:

• Перечень источников: выгрузки из учётных систем, таблицы, пресс-релизы, статистика — с примерами реальных записей, а не только описанием структуры.
• Пять-десять примеров текущих материалов с пометкой, что в них собрано вручную, а что хочется отдать автоматике.
• Требования к тональности и запретам: обязательные формулировки, недопустимые темы, правила ссылки на источник и упоминания партнёров.
• Кто принимает решения по тексту и в какие сроки смотрит выпуск: редактор, аналитик, юридическая служба.
• Желаемый ритм выпусков: сколько материалов в час, есть ли пиковые окна под события и отчётные периоды.
• Ограничения по доступам и персональным данным: какие системы можно читать, где нужны согласования.
• Точки публикации: сайт, приложение, рассылка, внешние площадки — и в каком виде отдаётся готовый текст.

Этого хватает, чтобы провести короткий разбор: посмотреть данные заказчика, разобрать примеры, зафиксировать, что уходит в автоматику и что остаётся за редактором. После разбора возвращаемся с оценкой сроков, планом работ и составом первой итерации. Опишите задачу — обсудим объём и точку старта.