Анализатор рынка на публичных данных: как отделить сигнал от шума

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

Задача: слишком много данных, слишком мало смысла

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

«Анализировать» в таких задачах обычно означает «предсказать», а предсказание здесь невозможно и обещать его нечестно. Зато возможно другое: убрать из рассмотрения то, что заведомо не стоит внимания, по признакам, которые можно проверить.

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

Как устроен сбор

Три слоя, разделённых намеренно.

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

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

Оценка. Применение правил к нормализованным данным и формирование короткого списка.

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

Почему фильтры важнее любой модели

Соблазн в таких проектах — приделать предсказательную модель. Я этого не делаю, и вот почему.

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

Фильтры устроены иначе. Каждый проверяет формальный признак, который либо есть, либо нет: срок существования позиции, распределение между участниками, наличие ограничений, поведение объёма относительно заявленного. Ни один из них не говорит, что будет дальше. Все вместе они отвечают на вопрос «есть ли здесь вообще предмет для разговора».

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

Граница: аналитика, а не рекомендация

Здесь надо сказать прямо, потому что вопрос возникает у каждого заказчика подобного инструмента.

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

Формулировки в интерфейсе строились с этой границей в голове. «Не проходит по фильтру срока» — корректно. «Не рекомендуется к покупке» — нет, потому что инструмент такого не знает и знать не может.

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

Три вещи, которые ломают такие скрипты

Инструменты сбора данных редко умирают от сложных причин. Обычно от трёх простых.

Ограничения источника. Скрипт, написанный «в лоб», начинает обращаться к площадке так часто, что его ограничивают или блокируют. Лечится не хитростью, а вежливостью: пауза между обращениями, повтор с нарастающей задержкой при отказе, кэш, чтобы не спрашивать одно и то же дважды. Инструмент, который бережёт чужой сервер, живёт дольше того, который выжимает максимум.

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

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

Ни одна из трёх проблем не интересная, и все три решают, проживёт инструмент год или две недели.

Где ещё применима та же схема

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

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

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

Частые вопросы

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

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

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

Можно ли добавить уведомления? Да, и это обычно следующий шаг: инструмент из «зашёл посмотрел» превращается в «пришло, когда появилось».

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

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

Коротко о главном

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

Если у вас есть публичный источник данных, который вы просматриваете вручную, — соберём инструмент, который оставит от него короткий список.