В рекламной индустрии одновременно запускаются возможности, основанные на моделях. Лидеры отрасли инвестируют в такие функции, как оптимизация ставок в реальном времени и автономные агенты для управления бюджетами. За этими анонсами скрывается критическая, часто упускаемая из виду зависимость: решения, принимаемые этими ИИ-моделями, зависят от того, насколько свежие данные они получают.
Модели эффективны лишь настолько, насколько актуален их контекст, независимо от качества их обучения.
Будь то модель принятия рекламных решений, оценивающая аукцион на основе недавних поведенческих сигналов, или конвейер генерации с дополнением (RAG), извлекающий данные кампании для ответа на запрос рекламодателя, результат один и тот же. Если извлеченные данные устарели хотя бы на час, модель оптимизирует процесс для среды, которой больше не существует. Поскольку устаревшие входные данные по-прежнему генерируют уверенные выходные результаты, стандартный системный мониторинг часто не обнаруживает эти ошибки.
Невидимость разрыва в актуальности данных в офлайн-метриках
Причина, по которой многие команды не осознают эту проблему, носит структурный характер. Процессы обучения и оценки обычно используют одни и те же исторические снимки данных; следовательно, устаревание данных влияет на обе стороны офлайн-эксперимента, фактически нейтрализуя само себя. Хотя AUC остается стабильным, а кривые валидации выглядят оптимальными, вывод о том, что модель работает хорошо, верен только в вакууме. Количественная оценка этого разрыва требует производственного эксперимента — «отложенного теста актуальности». Он заключается в намеренной подаче устаревших признаков на один сегмент трафика и сравнении результатов с более актуальной контрольной группой. Большинство организаций избегают этого теста, потому что он выявляет неэффективность их собственных конвейеров, создавая данные, которые могут нарушить существующие планы развития.
Без специального графика для отображения разрыва между офлайн- и онлайн-производительностью команды часто принимают отсутствие измерений за доказательство работоспособности модели; уверенность в таком случае обычно является симптомом непроверенной актуальности, а не ее доказательством.
Скрытые финансовые потери из-за устаревания данных во время аукциона
В сценарии, описанном в первой статье, платформа на стороне спроса (DSP), обрабатывающая десятки миллиардов показов в день, сталкивается со значительными невидимыми издержками.
Когда конвейер признаков отстает на тридцать минут, каждая оценка модели оказывается устаревшей на этот же промежуток рыночной активности. Хотя возникающая неточность в цене любой отдельной ставки ничтожна (часто это лишь доля цента), совокупный эффект от миллиардов решений создает огромный, скрытый дефицит. Эта неэффективность редко приводит к инциденту, потому что рост числа проигранных аукционов легко принять за стандартную рыночную конкуренцию.
Эта ошибка возникает двумя путями.
Во-первых, устаревшие признаки приводят к ложноположительным результатам, что влечет за собой пустую трату бюджетов, которые рекламодатели в конечном итоге подвергнут проверке. Одновременно с этим такие признаки вызывают ложноотрицательные результаты, когда модель занижает цену или игнорирует показы, потому что данные о пользователе устарели на час. В то время как первое подрывает доверие рекламодателей во время аудитов, второе является упущенной возможностью, которая остается полностью невидимой на дашбордах.
Во-вторых, конкуренты с более свежими данными стабильно получают лучшие цены, оставляя платформе необходимость оправдывать снижение процента побед (win-rate) множеством правдоподобных, но неверных отговорок.
На рисунке выше изображен весь аргумент. Хотя логический вывод, извлечение признаков и запись решений происходят за миллисекунды, цикл тормозится одной медленной фазой — передачей событий в источник данных модели.
Эта задержка вызвана архитектурными ограничениями, обсуждавшимися ранее в этой серии, а не какими-либо недостатками команды машинного обучения.
Инвестиции в более совершенную модель лишь оптимизируют сегмент процесса, который никогда не был основным ограничением.
Проблемы производственных данных для ИИ-агентов
Агенты разрушают существующую инфраструктуру, меняя характер системной нагрузки. Автономные менеджеры бюджетов и помощники (копилоты) вводят шаблоны запросов, которые обходят традиционное планирование мощностей, масштабируясь вместе с уровнем активности, а не с количеством сотрудников.
Когда агент повторяет запрос, по которому истекло время ожидания, он фактически действует как генератор нагрузки, сфокусированный на пути обслуживания. Направление этого трафика в хранилище вызывает проблемы с затратами на параллелизм, обсуждавшиеся ранее, а перенаправление его на реплики для чтения вновь обнажает разрывы в актуальности данных, выявленные во второй статье.
Однако потеря доверия критичнее, чем сбой из-за нагрузки. Конвейер RAG, привязанный к снимку данных за прошлую ночь, может ответить на запрос о текущем скачке расходов беглой, конкретной дезинформацией.
Для клиентских помощников уверенный, но неверный ответ, сгенерированный ИИ, создает немедленный инцидент доверия, независимо от предыдущих оценок модели. Последующие разборы полетов обычно показывают, что слой извлечения работал как было спроектировано и выполнил отличный поиск на основе вчерашних данных.
Действительно ли нужна еще одна база данных, чтобы это исправить?
Типичная реакция — внедрение хранилища признаков (feature store) для моделей и векторной базы данных для извлечения, что фактически добавляет седьмую и восьмую системы в стек. Это следует шаблону, выявленному в первой статье серии: по мере появления новых высоконагруженных рабочих нагрузок добавляются специализированные хранилища, что вызывает дальнейшее расхождение данных.
Хотя концепция хранилища признаков фундаментально верна, настоящий вопрос заключается в том, должна ли это быть отдельная система или она может существовать как представление внутри движка, где уже находятся события.
Добавление отдельной векторной базы данных часто является избыточным. Хотя эти системы превосходны в поиске сходства и хранении эмбеддингов, им не хватает возможности фильтровать структурированные столбцы, объединять данные с событиями в реальном времени или поддерживать актуальность, необходимую для принятия решений в реальном времени. Это дополнение возвращает к созданию тех же конвейеров синхронизации, которых они должны были избежать.
Эрик Хэнсон подробно обсуждает это в статье «Почему ваша векторная база данных не должна быть векторной базой данных»: истинная ценность заключается в обслуживании векторов вместе с SQL-фильтрами по данным в реальном времени, а не в изоляции.
Консолидация предлагает более эффективную альтернативу: хранение признаков, векторов и текущего состояния в рамках одного движка.
Это позволяет выполнять поиск сходства одновременно с SQL-фильтрами по данным, поступившим всего несколько секунд назад. Хотя оригинальное исследование RAG (Lewis et al., 2020) предполагало извлечение как способ дополнения моделей внешними знаниями, в рекламном секторе эти знания полезны только в том случае, если они отражают последние несколько секунд. Рабочие нагрузки моделей требуют единого источника данных, который поддерживает комбинацию шаблонов доступа, таких как высокоскоростной поиск по ключу, агрегация свежих событий и поиск сходства.
Lakehouse остается инструментом хранения для пакетных задач, таких как наборы данных для обучения, генерация эмбеддингов и офлайн-оценка. Таким образом, один путь предназначен для обучения системы, а другой — для обслуживания решений в реальном времени.
Вопрос распределения бюджета
Организации часто отдают приоритет инвестициям в сложность моделей, рассматривая актуальность данных лишь как техническую утилиту. Однако в момент принятия решения ценность меняется на противоположную: более простая модель, работающая с текущими рыночными сигналами, неизменно превзойдет сложную модель, анализирующую исторические данные, поскольку последняя имеет дело с состоянием рынка, которое уже исчезло.
Внедрение AI-агентов повышает этот риск, поскольку программное обеспечение, принимающее автономные решения, превращает каждый архитектурный пробел в прямой сбой, влияющий на доверие клиентов или эффективность бюджета.
Это возвращает нас к исходной предпосылке серии статей. Фрагментированные хранилища, вращающиеся вокруг хранилища данных, никогда не были изолированными проблемами; они представляют собой единый отсутствующий архитектурный уровень, который был исправлен с помощью шести отдельных патчей. По мере появления продвинутых моделей они будут полагаться на стабильность этого уровня больше, чем любая предыдущая рабочая нагрузка.
Хотя обеспечение доступа моделей к контексту в реальном времени имеет важное значение, фундаментальная проблема идентификации остается. Даже самые свежие данные эффективны лишь настолько, насколько система способна точно сопоставить их с отдельными пользователями и устройствами. В нашей заключительной части мы переключаем внимание с извлечения на разрешение, рассматривая, как отойти от дорогостоящих периодических перестроек графов к более эффективному, инкрементальному разрешению идентификации.
