Omer Primor про CaaS: где заканчивается аренда контекста (Рубрика #AI)

У контекста для агента есть неприятная бухгалтерия. Пока вопрос разовый, AI-поиск выглядит как обычный API: спросили, получили ответ, пошли дальше. Но если каждый день проверять одни и те же компании, вакансии и цены, счётчик запускается заново — даже когда ничего не изменилось. В какой-то момент мы арендуем уже не ответ. Мы арендуем способность системы помнить.

Именно эту границу разбирает Omer Primor из Bright Data в докладе «The Rise of CaaS: Context-as-a-Service for Agentic AI» с AI Engineer World’s Fair 2026. Название похоже на ещё один "-aaS", но вопрос внутри вполне взрослый: когда агенту достаточно покупать контекст, а когда его пора собирать, обновлять и хранить самому? Тема уже появлялась в разборе Hands-On RAG for Production, где retrieval из одного паттерна постепенно вырастал в платформенный слой. Primor добавляет к архитектуре экономику: кто платит за обновление знаний и у кого остаётся накопленный актив.

Его отправная точка — веб не снимок. По показанному в докладе анализу Bright Data, данные социальных сетей могут терять актуальность меньше чем за сутки, а новости, финансовая и retail-информация — в основном за 30 дней. Это внутренний анализ компании, а не универсальный закон. Но сама проблема понятна: один раз найти страницу недостаточно, если агенту важно знать, как менялись цена, вакансии или состав компании.

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

А дальше частота запросов приводит к огромному счету.

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

Чтобы показать механику, команда Bright Data провела небольшой тест. Карточку из 25 полей проверили на 100 компаниях-спонсорах конференции и сравнили AI-поиск, несколько CaaS и прямой сбор из известных источников. Primor сразу называет это тестом, а не benchmark. Покрытие оказалось близким, но некоторые CaaS уступили поиску на выбранных полях: сервис знает только то, что решил собирать. При этом сам докладчик оговаривает, что у этих платформ могут быть другие данные и преимущества, которые тест просто не измерял. Для собственного варианта команда использовала готовые источники Bright Data и два специально собранных скрейпера. По словам Primor, демонстрационный конвейер занял около дня. Затем он условно оценил полноценную настройку в неделю и $5 000 — при таких допущениях пересечение получилось чуть выше 15 000 сущностей или запросов.

Красивое число, но переносить его в закупочную таблицу я бы не стал. Primor тут же допускает и 10 000, и 30 000, и 100 000: всё зависит от сценария. К тому же он представляет Bright Data, а «самостоятельный» путь собран на инструментах той же компании. За рамкой расчёта остаются поддержка скрейперов, полноценное сопоставление сущностей (entity resolution), контроль качества, юридические ограничения, наблюдаемость и дежурства. Собственный конвейер особенно дёшев на слайде. В жизни первый редизайн сайта-источника быстро добавляет в формулу людей и кофе :)

Поэтому я бы выбирал не по магической отметке 15 000, а по пяти вопросам:
— Как часто повторяется запрос?
— Как быстро устаревают данные?
— Насколько стабильны сущности и схема?
— Сколько стоит неверный или несвежий контекст?
— Во что обходится владение всем конвейером?

Мой базовый вариант здесь — гибрид. Разовые вопросы и неизвестные заранее источники остаются у AI-поиска или CaaS. Частые запросы к понятным сущностям и полям уходят в собственный сбор, нормализованное хранилище и инкрементальные обновления. Внешний поиск остаётся резервом для пробелов, а не обязательным шагом каждого запуска агента. Это та же граница «арендовать — адаптировать — оставить своим», о которой я писал в лонгриде про AI-стек. Только считать здесь полезнее не цену одного запроса, а стоимость принятого результата с нужной свежестью.

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

#AI #Agents #Architecture #Data #PlatformEngineering #FinOps