Как построить многоэтапный ИИ-пайплайн для мониторинга новостей и проверки источников

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

В эксперименте автора поисковая воронка новостного агрегатора начиналась с общего запроса и выбранного периода. Затем система уточняла направление исследования, составляла тематическую карту, выделяла семейства событий, генерировала поисковые запросы, проверяла страницы и передавала подтверждённые события на редакционный отбор. Автор рассматривает проект как сложный MVP для проверки идеи, а не как готовый самостоятельный продукт.

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

Почему одного промпта недостаточно

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

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

Исходный запрос: предмет, период и границы

Исследование начинается с описания предмета, аудитории и временного интервала. Редактору стоит заранее определить географию, типы событий, допустимые источники, критерии релевантности и стоп-темы. Широкая исходная формулировка повышает риск, что система потратит ресурсы на материалы, не соответствующие задаче.

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

Задание можно оформить так:

• Предмет: какие явления и события исследуются.
• Аудитория: для кого готовится подборка.
• Период: какие даты допускаются.
• География: какие страны, города или рынки входят в охват.
• Релевантность: что делает событие значимым для конкретного проекта.
• Стоп-темы: какие направления нужно исключить.

Тематическая карта управляет охватом

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

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

Для редакционной команды карта должна хранить не только название темы, но и короткое описание, примеры релевантных событий, исключения и приоритет. Иначе модель будет по-разному понимать один и тот же раздел при повторных запусках.

Семейства событий перед поисковыми запросами

Семейство событий объединяет сообщения одного типа: например, запуск продукта, изменение регулирования, сделку, исследование или публичный конфликт. Система сначала описывает, что именно нужно найти, и только потом превращает это описание в конкретные поисковые формулировки.

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

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

Поиск источников и предварительная фильтрация

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

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

В описанном эксперименте система получила 30 источников, из которых 28 передала на содержательную проверку. Это наблюдение относится к конкретному запуску автора, а не к гарантированной эффективности любого новостного пайплайна.

Проверка события: дата, тема и доказательства

Проверка события должна отвечать на несколько разных вопросов. Источник действительно говорит об этом событии? Публикация относится к заданному периоду? Материал подтверждает факт или только пересказывает чужое сообщение? Достаточно ли независимых и качественных подтверждений для редакционного использования?

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

Вопрос «достаточно ли одной публикации?» не имеет универсального ответа. Для официального сообщения первоисточника одного материала иногда достаточно, но для спорного заявления, оценки рынка или сообщения со ссылкой на анонимный источник нужна дополнительная проверка. Пайплайн должен различать факт публикации и доказанность описываемого факта.

Статусы проверки и объединение дублей

Статус превращает редакционное решение в явное правило. В прототипе автора использовались четыре статуса:

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

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

Редакционный отбор после механической проверки

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

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

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

Интерфейс, повторный запуск и хранение данных

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

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

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

Где нужен человек

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

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

Что будет, если журнал обработки не заполнен? Команда не сможет отличить ошибку поиска от ошибки проверки и не поймёт, какой этап исправлять. Пошаговый журнал нужен для диагностики.

Ограничения прототипа и технический долг

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

Автор сообщает, что проект включал графический интерфейс, слой логики, базу данных, вызовы моделей и рекурсивную проверку через механизм критики. В проекте было более 20 000 строк кода. Эти сведения относятся к конкретному эксперименту и не позволяют оценить трудоёмкость любого аналогичного решения.

Указанные автором расходы также нельзя воспринимать как действующий тариф. В его тестовом сценарии использование облачной модели через API обошлось примерно в 25 долларов, а общие расходы он оценил примерно в 121 доллар, включая подписку и приобретённые кредиты. Без части покупок автор оценивал расходы примерно в 49 долларов. Стоимость зависит от провайдера, модели, лимитов, объёма текста и числа повторных запусков.

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

Чек-лист для самостоятельного тестирования

1. Зафиксируйте исходный запрос, аудиторию, период и географию.
2. Опишите критерии релевантности и стоп-темы до первого запуска.
3. Составьте тематическую карту с понятными границами разделов.
4. Разделите задачу на семейства событий, а не только на ключевые слова.
5. Сохраняйте каждый поисковый запрос и все найденные страницы.
6. Проверяйте точную дату, тему, качество источника и достаточность доказательств отдельно.
7. Используйте статусы, которые объясняют дальнейшее действие с событием.
8. Объединяйте дубли, сохраняя связанные источники.
9. Проводите редакционный отбор только после проверки фактов.
10. Добавьте ручную проверку спорных и общественно значимых материалов.
11. Считайте стоимость повторных вызовов моделей, а не только первого запуска.
12. Проверьте повторяемость на другой дате и на заранее подготовленном наборе новостей.

Итог

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

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