52 копии одной новости: как научить AI вовремя останавливаться
Сегодня AI умеет за считаные минуты просматривать десятки новостей, документов и экспертных мнений. Однако высокая скорость еще не означает качественный результат. Если не задать четкие критерии отбора, автоматизация начинает не решать проблему, а масштабировать информационный шум.
Поэтому в эксперименте с AI-радаром я поставила перед системой обратную задачу: не собрать как можно больше материалов, а найти один действительно значимый сигнал. Для этого радар должен был обнаружить потенциально важное событие, проверить первоисточник и дату, отделить факты от интерпретаций, удалить дубли и остановиться, если доказательств недостаточно.
На бумаге процесс выглядел безупречно:
поиск → проверка → решение о публикации → решение человека → сайт.
Но первый полноценный запуск показал, что основная проблема находится не в качестве AI-анализа.
Как в базе появились 52 одинаковые записи
В один из запусков система обнаружила 52 копии одной и той же новости. Сначала подозрение пало на AI: возможно, он не распознал повтор или неправильно сопоставил материалы.
Однако алгоритм анализа оказался ни при чем. Он последовательно обрабатывал те данные, которые ему передавали. Ошибка возникла на уровне логики процесса: новые сведения поступали корректно, но затем система снова и снова отправляла на обработку старую запись. При каждом цикле база создавала для нее новый технический идентификатор.
Для базы это были разные строки. С точки зрения содержания - один и тот же информационный повод.
Получается, система умела продолжать работу, но не имела правила, объясняющего, в какой момент продолжение запрещено. Именно это стало главным выводом эксперимента: автоматизации недостаточно знать, что запускает действие. Не менее важно определить условия, которые лишают ее права действовать.
После этого я перестала устранять отдельные симптомы и начала пересматривать переходы между этапами. Повтор, пустой результат или противоречивые данные больше не трактуются как повод "попробовать еще раз". Теперь это основания для остановки.
Когда отсутствие результата - хороший результат
Следующая проблема обнаружилась при пустой выборке. Система не нашла ни одной записи, готовой к публикации, но следующий модуль все равно попытался передать ему пустой заголовок.
Человек в такой ситуации мгновенно понимает: делать ничего не нужно. Для автоматизированной цепочки это очевидно только в том случае, если подобное поведение заранее прописано в правилах.
Я добавила принцип fail-closed - безопасное завершение при отсутствии достаточных данных. Если нет подтвержденного источника, корректной даты, заголовка или разрешающего статуса, следующий этап не запускается.
На контрольном прогоне ни одна запись не прошла фильтр, поэтому внешний запрос не состоялся. И именно это стало правильным результатом. Система не "сломалась" и не "ничего не сделала" - она корректно отказалась продолжать при недостатке оснований.
Такой подход особенно важен для новостных процессов. Ошибка публикации заметнее и опаснее, чем пропущенный материал: неверное утверждение может повлиять на репутацию, решения аудитории и доверие к площадке.
Почему AI пришлось убрать из части процесса
В ранней версии радара AI участвовал почти на каждом этапе: искал материалы, отбирал их, оценивал свежесть и анализировал содержание. Для прототипа это удобно, но для постоянной эксплуатации - слишком сложная и дорогая схема.
Поэтому все проверки, которые можно надежно выполнить обычным кодом, я перенесла до AI. Система сначала проверяет:
- наличие обязательных полей;
- корректность формата даты;
- допустимый возраст материала;
- наличие источника;
- уникальность записи;
- соответствие техническим ограничениям;
- отсутствие уже обработанного идентификатора.
Только после этого материал передается AI для смысловой работы: анализа содержания, сопоставления формулировок, поиска противоречий и оценки значимости.
Первый ежедневный запуск после перестройки не обнаружил ни одного свежего материала. Причина была не в AI и не в отсутствии новостей - сработало слишком строгое формальное условие. После его корректировки несколько материалов прошли первичный отбор, но до AI дошел только один.
Точный процент экономии я не рассчитывала, поэтому говорить о конкретном финансовом эффекте преждевременно. Но наблюдение было очевидным: отобранный материал больше не отправлялся на повторную AI-проверку.
Парадокс оказался полезным: путь к более надежной AI-системе начался с сокращения количества AI в ее архитектуре.
HOLD важнее красивого результата
Первый полноценный кандидат успешно прошел технические фильтры, AI-анализ и проверку источника. Но на финальном контрольном этапе обнаружилось расхождение: разные элементы официальной страницы указывали разные варианты даты публикации.
Система присвоила материалу статус HOLD - временную блокировку до выяснения обстоятельств.
Можно было выбрать наиболее удобную дату или ослабить правило, чтобы получить новый результат в радаре. Но я оставила материал на удержании. Официальный источник сам по себе не доказывает автоматически каждое утверждение, а несогласованная дата остается сигналом, требующим дополнительной проверки.
Этот случай показал важную вещь: отсутствие публикации не всегда означает неудачу системы. Иногда главная ценность автоматики заключается в том, что она не пропускает спорный материал дальше.
Где должен оставаться человек
Сейчас маршрут выглядит следующим образом:
обычный код проверяет формальные условия → AI исследует содержание и противоречия → независимый контроль оценивает доказательства → человек принимает решение → автоматизация исполняет его.
Технически последние этапы можно полностью поставить на расписание. Но окончательное решение я пока оставила ручным. Это не связано с невозможностью автоматизации. Причина в уровне риска: чем ближе действие к внешнему миру, тем меньше самостоятельности получает система.
AI может найти материал, сопоставить несколько источников, выделить расхождения и подготовить вывод. Но публикация - уже не просто техническая операция. Она создает публичное утверждение, за которое отвечает человек или организация.
Что стоит предусмотреть в похожем процессе
Опыт с 52 копиями показал, что надежность определяется не только моделью, но и всей окружающей инфраструктурой. Перед запуском автоматизации полезно заранее определить уникальный ключ записи. Им может быть не технический идентификатор базы, а комбинация источника, ссылки, даты и нормализованного заголовка.
Кроме того, важно разделять понятия "новая строка" и "новое событие". Запись может получить новый идентификатор, но описывать уже известный информационный повод. Поэтому проверять нужно не только структуру данных, но и смысловую повторяемость.
Полезно также вести журнал решений: почему материал был принят, отклонен или отправлен в HOLD. Такой журнал помогает разбирать сбои и понимать, на каком именно этапе возникла проблема.
Каждый этап должен иметь явные статусы. Например: `NEW`, `CHECKED`, `READY`, `HOLD`, `REJECTED`, `PUBLISHED`. Если система работает только по принципу "передать дальше", ошибки становятся почти неизбежными.
Отдельно стоит тестировать отрицательные сценарии: пустую выборку, повторный запуск, недоступный источник, изменившуюся страницу, несовпадающие даты, дублирующиеся записи и частично заполненные поля. Хорошая система проверяется не только на успешном примере, но и на способности безопасно остановиться.
Наконец, необходимо ограничивать количество повторных попыток. Бесконечный цикл перезапусков может выглядеть как активная работа, хотя на деле лишь создает новые дубли и увеличивает расходы.
Главный вывод эксперимента оказался простым: зрелая автоматизация - это не система, которая всегда продолжает работу. Это система, которая понимает границы допустимого действия. Иногда самый надежный результат - не найденная новость, пустая очередь или запись со статусом HOLD.
AI по-прежнему остается важным инструментом поиска и анализа. Но его сила проявляется только внутри хорошо спроектированного процесса, где обычный код отсеивает формальные ошибки, контрольные правила ограничивают риск, а человек сохраняет последнее слово там, где решение выходит за пределы внутреннего теста и становится публичным действием.
