Как ИИ помогает отслеживать сигналы в больших данных

Недавно мы запустили Trend Analysis — проект, который анализирует тренды через одно большое хранилище информации. Задача выглядела простой: понять, какие сигналы действительно важны, а какие — просто шум в потоке новостей. Но когда я начал обрабатывать данные из Claude Code, выяснилось, что задача намного сложнее.

Первая проблема: как выбрать сигнал из 30 статей в день? Я видел список заголовков — от “Спасибо HN: вы помогли спасти 33 тысячи жизней” до “Гороскоп на вторник”. Нужна была система, которая различала бы реальные события от фильтр-шума. Мы начали с простого подхода: отмечать технологии, проекты, действия. Но это не работало — слишком много ложных срабатываний.

Второе открытие: Claude API справляется лучше, чем я думал. Мы запустили асинхронный анализ сырых событий — сначала фильтруем мусор вроде пустых чатов и голых хешей, потом группируем по категориям. “Использование go fix для модернизации Go кода” — вот это сигнал для frontend-разработчиков. “Минимальное ядро x86 на Zig” — совсем другая аудитория. Система автоматически маркировала их по типам: feature_implementation, refactor, infrastructure.

Третий этап был критичен: дедупликация. Одна новость могла прийти разными путями — из Hacker News, из GitHub, из блога. Без дедупликации мы бы публиковали одно и то же трижды. Мы добавили матчинг по slug’ам и семантической близости.

Но главный вызов — масштаб LLM-вызовов. Каждая заметка могла потребовать до 6 запросов: генерация контента на русском и английском, создание заголовков, корректура. При 100 запросах в день к Claude CLI это означало, что мы быстро упирались в лимиты. Пришлось оптимизировать: извлекать заголовок из первой строки генерируемого контента вместо отдельного запроса, пропустить корректуру для модели haiku (качество достаточное для блога).

Из всего этого материала особенно интересными оказались истории про инновации: “Я преобразовал двумерную систему отслеживания полетов в трёхмерную” или “Я научил языковые модели играть в Magic: The Gathering друг против друга”. Именно такие сигналы привлекают читателей техблога.

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

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

😄 А знаете, чем это похоже? На поиск класса Spring’а — например, AbstractSingletonProxyFactoryBean. Огромное имя, которое в реальности существует в Java, и вот вы копаетесь в документации, пытаясь понять, что это вообще такое.