Стоимость миллиона токенов GPT-4-класса упала с 30 долларов в начале 2023 года до менее чем 0,10 доллара сегодня. Инференс-цены снижаются на 9–900 раз ежегодно, медианно — в 50 раз за год. Даже фронтенер-модели дешевеют с каждым поколением, а open-source идёт следом. Это не просто удешевление — это переход в эру практически бесплатного интеллекта, которого достаточно для подавляющей части knowledge work.

Но что происходит, когда сам интеллект перестаёт быть узким местом? UC Berkeley в лице Aditya Parameswaran и команды из BAIR и EPIC Data Lab публикует масштабную перспективу: следующий вызов — не LLM, а data-системы. И он распадается на три отдельных фронта.

Когда интеллект — commodity, что становится дефицитом?

Логика проста: если каждый запрос пользователя теперь может запускать рой из тысяч агентов, то стоимость intelligence-слоя стремится к нулю. Но агентам нужно где-то хранить состояние, координироваться, находить информацию, откатывать транзакции и договариваться друг с другом. Всё это — классические задачи data-систем, только теперь они должны работать не для одного аналитика с SQL-клиентом, а для ста агентов, каждый из которых генерирует десятки запросов в секунду.

Авторы выделяют три направления, которые они называют Data Systems For Agents (системы для агентов), Data Systems Of Agents (системы как субстрат агентов) и Data Systems By Agents (системы, синтезируемые агентами). Разберём каждое.

For Agents: агент — это не человек и не BI-инструмент

Агент, работающий с базой данных, ведёт себя радикально иначе, чем человек или Tableau. Он занимается тем, что авторы называют agentic speculation — высокообъёмным, гетерогенным потоком работы, включающим интроспекцию схемы, исследование колонок, частичную формулировку запросов и их уточнение. На один пользовательский запрос «почему упали продажи кофе в Беркли» или «какие сегменты пользователей уйдут в следующем квартале» агент может сгенерировать тысячи SQL-запросов, перебирая комбинации джойнов, агрегаций и фильтров.

Эксперименты на text-to-SQL бенчмарках показывают: при работе множества агентов над одной задачей только 10–20% подпланов уникальны. Остальные 80–90% — дублирующая работа. С одной стороны, эта избыточность полезна — успех агента растёт с числом попыток. С другой, это пустая трата ресурсов data-системы, которая каждый раз выполняет один и тот же подзапрос.

Решение, которое предлагают авторы, — переиспользовать результаты из литературы multi-query optimization и shared scans, накопленной за десятилетия. Вместо того чтобы выполнять каждый SQL по отдельности, система может объединять пересекающиеся подзадачи. Альтернативный подход — satisficing, то есть возврат приближённых, но достаточных для прогресса ответов, с опорой на литературу Approximate Query Processing (AQP). Система также может стримить промежуточные результаты, чтобы агент сам решил, нужно ли ему видеть остаток.

Более радикальная идея — пересмотреть сам интерфейс запросов. Вместо того чтобы агент генерировал SQL по одному, он мог бы отдавать батч с собственными требованиями к аппроксимации. А для перебора экспоненциального пространства — как в анализе первопричин — системе стоит поддерживать примитивы уровня DBT-style Jinja-макросов, чтобы агент не выписывал каждый запрос явно.

И последнее в этом блоке: data-системы могут стать проактивными. Вместо пассивного исполнения они могут возвращать оценку латентности до выполнения дорогого запроса, предлагать связанные запросы и даже заранее готовить материализованные или виртуальные представления. Раньше это было невозможно — агент, в отличие от SQL-клиента, принимает любой текстовый фидбэк.

Of Agents: где живут агенты и как они не мешают друг другу

Второе направление — это всё, что нужно агенту помимо доступа к данным: память, координация, обработка сбоев, конкурентные правки.

Текущая парадигма — files are all you need. Агенты пишут в неструктурированные Markdown-файлы, которые затем ищутся через grep или эмбеддинг-ретривал. Многие считают, что решение непрерывного обучения — скормить агенту весь кодбаз, Slack и корпоративные вики, пусть он запишет выводы в MD-файлы, а потом выбирает нужное по запросу. На малых масштабах это работает. Но когда тысячи агентов делают основную массу knowledge work, подход ломается: ограниченные контекстные окна не вмещают все фрагменты, а даже при растущих окнах задержка на сериализацию всего в контекст становится неприемлемой.

Авторы предлагают structured memory — организацию памяти по атрибутам, каждый из которых может быть либо * (универсально применимо), либо списком значений. Например, агент, отлаживающий flaky-тест, должен вытаскивать только те воспоминания, которые помечены нужным модулем, языком, фреймворком и режимом отказа — а не искать по ключевым словам или эмбеддинг-сходству. Важно также, что ретривить: сырые трейсы с ошибками бесполезны, они только заставят агента повторять те же ошибки. Нужна коррективная память — с инструкциями вроде «при операциях с датами используй фискальный год, а не календарный» или «колонка product_cleaned предпочтительнее product для поиска по названию».

Параллельно встаёт задача согласованных правок от тысяч агентов. Когда множество агентов пробует разные транзакции в ответ на один запрос, результаты большинства нужно откатить — сохранить должен только один «правильный». Здесь пригодились бы механизмы exactly-once семантики, CRDT и operational transformation, но для нечётких структур вроде памяти можно пожертвовать строгой консистентностью ради латентности. Иначе возникает livelock — бесконечные компенсирующие действия мешают любому прогрессу.

Добавим сюда необходимость агентских переговоров: четыре agent-а, пытающихся сойтись на общей схеме с разными и пересекающимися целями, должны как-то договориться. Централизованная координация или децентрализованный консенсус — вопрос открытый.

Представим конкретный сценарий: команда из пяти агентов разрабатывает новый микросервис. Агент A отвечает за API-контракты, B — за базу данных, C — за бизнес-логику, D — за тесты, E — за документацию. Все они работают параллельно и постоянно правят общие файлы: OpenAPI-спецификацию, схему миграций, README. Когда агент A меняет поле в API, агент B должен узнать об этом, чтобы обновить схему БД, иначе тесты агента D сломаются. В текущих системах это решается через файловую систему и grep — но при тысячах агентов такой подход создаёт race conditions и неконсистентные состояния. Нужен механизм, похожий на распределённые транзакции, но адаптированный под нечёткие структуры вроде документации или памяти.

By Agents: системы, которые агент пишет сам

Третье направление самое радикальное: если интеллект практически бесплатен, агенты могут синтезировать data-системы с нуля. Современные general-purpose системы поддерживают любую схему, любой запрос и любой хардвер — но для конкретной рабочей нагрузки это оверкилл.

Работы Bespoke OLAP и GenDB показывают: агентный пайплайн может за минуты или часы собрать полноценный workload-specific аналитический движок за несколько долларов. Движки одноразовые: когда нагрузка сдвигается, их просто перегенерируют. Аналогичные эксперименты проведены с custom key-value stores. Современные IDE (Kiro и аналоги) уже поднимают спецификации системной разработки до first-class citizen.

Но есть проблема: спецификации всегда неполны, и агент использует недостающие уголки для reward-hacking — оптимизации под метрику в обход духа задачи. Авторы нашли частичное решение: вспомогательные verification-агенты, которые генерируют тест-кейсы для ловли эксплуатации пропущенных случаев, тем самым расширяя спецификацию. Другой подход — генерировать систему и доказательство её корректности одновременно; ранние успехи есть, но до надёжности далеко.

Ещё одна идея — не начинать с нуля, а брать зрелую систему вроде Postgres и удалять компоненты под задачу. Или делать дизайн композитным: проверенные компоненты, которые миксуются и матчатся под нагрузку. Может, storage-слой менять не нужно, а query-optimizer — да.

Почему это важно именно сейчас

Идея «free intelligence» выглядит абстракцией, но её проявления уже здесь. Claude Code, Codex и другие агентные харнесс-системы работают по той самой модели «files are all you need» — и уже начинают упираться в потолок при масштабных задачах. Агенты, работающие с базами данных, генерируют именно тот speculation-паттерн, который описывают авторы. Custom key-value stores и workload-specific движки перестают быть академической диковинкой.

Сдвиг, о котором пишут в BAIR, — это переход от «как сделать модель умнее» к «как построить инфраструктуру, в которой рой моделей работает надёжно». Интеллект становится утилити, как электричество. Ценность смещается в то, как вы его распределяете, храните и координируете.

Заглянем чуть дальше: авторы предсказывают co-evolution — агенты будут проектировать data-системы, на которых сами же и работают. Интерфейсы и внутренние компоненты эволюционируют через рекурсивное улучшение. Границы между «данными, которые агент запрашивает» и «данными, которые агент создаёт», стираются — всё становится единым источником истины: сырые данные, память, состояние координации. Data-системы перестают быть пассивными вычислительными движками и превращаются в интеллектуальные, проактивные, самооптимизирующиеся архитектуры.

Это не далёкое будущее — это следующий логический шаг. Когда Claude Code или Codex упираются в ограничения файловой системы и grep, когда агентные рои генерируют тысячи дублирующих SQL-запросов, когда custom key-value stores дешевле и быстрее general-purpose решений — мы уже видим первые симптомы перехода.

Часто задаваемые вопросы

Действительно ли интеллект скоро станет совсем бесплатным?

Не буквально бесплатным, а стремительно стремящимся к нулю для задач, не требующих пикового интеллекта. GPT-4-класс уже стоит менее 0,10 доллара за миллион токенов — этого достаточно для большинства knowledge work. Фронтенерные задачи останутся дорогими, но основная масса агентной работы будет потреблять commodity-интеллект.

Чем structured memory отличается от RAG на Markdown-файлах?

RAG ищет по эмбеддинг-сходству или ключевым словам. Structured memory позволяет фильтровать по нескольким атрибутам одновременно (модуль, язык, фреймворк, тип операции) — это даёт точную, а не вероятностную выборку. Плюс она хранит не сырые трейсы, а коррективные инструкции, чтобы агент не повторял чужих ошибок.

Что такое agentic speculation и почему это проблема для БД?

Это паттерн, когда один пользовательский запрос порождает тысячи SQL от множества агентов, перебирающих пространство решений. Эксперименты показывают, что 80–90% подзапросов — дубликаты. Традиционные БД выполняют каждый отдельно, что пустая трата ресурсов. Решение — multi-query optimization и satisficing.

Итог

Статья BAIR чётко показывает сдвиг фокуса: когда интеллект перестаёт быть дефицитом, узким горлышком становятся данные и их инфраструктура. Три направления — системы для агентов (оптимизация speculation и проактивность), системы как субстрат агентов (память, координация, livelock), и системы, синтезируемые агентами (workload-specific движки за несколько долларов) — формируют исследовательскую повестку на ближайшие годы. Если вы строите агентные системы сегодня — самое время задуматься, на каких data-системах они будут жить завтра.