В начале 2023 года миллион токенов GPT-4 стоил около 30 долларов. Сегодня тот же уровень возможностей обходится дешевле доллара, а отдельные провайдеры уже продвигаются ниже 10 центов. По данным Epoch AI, цены на инференс падают в диапазоне от 9 до 900 раз в год, медиана около 50x. Интеллекта, достаточного для большинства офисной работы, уже много, и он дешевеет каждый месяц.

Исследователи из Berkeley (BAIR, EPIC Data Lab) во главе с Адитьей Парамесвараном задали очевидный, но редко обсуждаемый вопрос: что эра почти бесплатного интеллекта означает для систем данных? Их ответ в эссе «Intelligence is Free, Now What?» сводится к трём направлениям, красиво обыгранным через геттисбергскую формулу Линкольна: системы данных для агентов, из агентов и созданные агентами (for, of, by agents).

Важно понимать масштаб сдвига. Медианное удешевление в 50 раз в год означает, что задача, которая в прошлом году стоила тысячу долларов на инференсе, сегодня стоит двадцать. Frontier-модели дешевеют с каждым поколением, а open-source следует за ними с отставанием в месяцы. Планка «гениального интеллекта уровня Нобелевской премии» пока не взята, но она и не нужна: для подавляющего большинства задач интеллектуальной работы, от аналитики до написания кода, текущего уровня уже достаточно. Именно это делает вопрос инфраструктуры острым: когда интеллект дешёв, узким местом становится всё остальное, и в первую очередь данные.

Почему базы данных не готовы к агентам

Классическая СУБД проектировалась под человека с BI-дашбордом: несколько запросов в минуту, предсказуемые паттерны, аккуратные транзакции. Агент ведёт себя иначе. Он занимается тем, что авторы называют агентской спекуляцией (agentic speculation): высокочастотный поток разнородных запросов, разведка схемы, пробные выборки, частичные формулировки, потом полные запросы. Один пользовательский вопрос вроде «почему упали продажи кофе в Беркли в этом году» разворачивается в тысячи SQL-запросов, потому что агент перебирает комбинаторное пространство джойнов, агрегаций и фильтров.

Забавная деталь из экспериментов на text-to-SQL бенчмарках: когда несколько агентов параллельно решают одну задачу, только 10–20% их под-планов уникальны. Остальные 80–90% запросов дублируют чужую работу. При этом избыточность полезна для успеха задачи, success rate растёт с числом попыток. Для агента это разумная стратегия, для движка базы данных это чистый мусор.

Data Systems For Agents: движок под спекуляцию

Первое направление: перестроить системы данных под агентскую нагрузку. Идеи здесь отчасти старые, их просто никто не применял в таком контексте. Multi-query optimization и shared scans из литературы 80-х и 2000-х позволяют переиспользовать результаты пересекающихся под-планов: если пять агентов считают почти одинаковую агрегацию, движок должен заметить это и посчитать один раз.

Вторая идея: приближённые ответы. Агенту не всегда нужен точный результат, ему нужно понять, куда копать дальше. Approximate Query Processing (AQP) и стриминг промежуточных результатов позволяют агенту прервать дорогой запрос на середине, если направление уже ясно. Третья идея касается самого интерфейса: вместо одиночных SQL-запросов агент мог бы слать пакеты запросов с индивидуальными требованиями к точности, или использовать высокоуровневые примитивы в духе Jinja-макросов из DBT, чтобы не перечислять вручную каждый запрос из экспоненциального пространства поиска.

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

Data Systems Of Agents: субстрат для роя

Второе направление шире: где живут тысячи агентов, как они помнят, координируются и переживают сбои друг друга. Сейчас эту роль играют харнессы вроде Claude Code и Codex плюс примитивные хранилища памяти. Рабочая мудрость индустрии звучит как «files are all you need»: агент пишет заметки в markdown-файлы, потом ищет их через grep или эмбеддинги.

По мнению авторов, это не масштабируется. Когда агенты берут на себя основную часть интеллектуальной работы, контекстное окно становится бутылочным горлышком: нельзя бесконечно запихивать фрагменты MD-файлов в промпт, и даже растущие окна не решают проблему латентности. Графы знаний тоже не спасают, потому что страдают от того же отсутствия структурированного поиска.

Предлагаемая альтернатива: структурированная память. Каждая запись помечается атрибутами (таблица, колонка, тип операции, открытая текстовая инструкция), а при извлечении работает точный матчинг по фасетам, а не сходство эмбеддингов. Агент, дебажащий падающий тест, получает только воспоминания, помеченные нужным модулем, языком и типом сбоя. Причём извлекать нужно не сырые трейсы с ошибками (они провоцируют повторить ту же ошибку), а корректирующие инструкции вроде «при операциях с датами используй фискальный год» или «для имён продуктов бери колонку product_cleaned, а не product».

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

Отдельная боль: конкурентные правки. Когда тысячи агентов одновременно меняют общее состояние, классического multiversioning и copy-on-write может не хватить. Типичный паттерн: агенты пробуют десятки потенциальных транзакций, и откатить нужно все, кроме одной правильной. Авторы предупреждают о неприятном режиме отказа, своеобразном лайвлоке: агенты бесконечно компенсируют действия друг друга, и никакого прогресса не происходит. И это ещё не касаясь вопросов консенсуса: четыре агента-разработчика, согласующие общую схему данных с частично конфликтующими целями, это задача о механизмах переговоров, которых пока не существует ни в централизованном, ни в децентрализованном виде.

Ещё один недооценённый класс проблем: отказоустойчивость роёв. Что делать, когда отдельные агенты падают посреди длинной задачи? Как обнаруживать отстающих (stragglers), которые тянут вниз весь рой? Существующие решения для durable execution вроде Temporal пока проверялись на десятках агентов, а не на тысячах, и неясно, переживут ли они такой масштаб. Плюс вопрос коммуникации: агентам нужно договариваться друг с другом, напрямую или через общее состояние, когда они конкурируют за ограниченный ресурс. Человеческие команды решают это через итеративное обсуждение и компромиссы, для агентских роёв такие механизмы ещё предстоит формализовать.

Data Systems By Agents: базы данных на заказ за минуты

Третье направление самое радикальное. Если интеллект бесплатен, зачем вообще пользоваться универсальными СУБД, которые обязаны поддерживать любую схему и любое железо? Работы вроде Bespoke OLAP и GenDB показывают: агентский пайплайн может синтезировать полноценный аналитический движок под конкретную нагрузку за минуты или часы, за считанные доллары. Сама команда Berkeley проделала это с key-value хранилищами. Такие движки одноразовые: нагрузка изменилась, просто генерируешь новый.

Здесь проявляется сдвиг в самой роли спецификаций. Современные IDE для агентской разработки вроде Kiro уже поднимают спецификацию до статуса первоклассного артефакта: сначала формальное описание поведения, потом код. Для синтезируемых систем данных это критично, потому что спецификация становится единственным, что отделяет «быстрый движок» от «быстрого движка с тонкими багами в угловых случаях».

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

Есть и более прагматичные варианты. Вместо синтеза с нуля можно взять зрелую систему вроде Postgres и удалять лишнее. Или собирать системы композиционно из верифицированных компонентов: нагрузка не требует нового storage-слоя, но требует нового оптимизатора запросов. А ещё агенты могут ломать традиционную слоистую архитектуру (парсер, оптимизатор, storage manager), «смешивая» компоненты и находя оптимизации на стыках, которые были не видны, когда каждый слой принадлежал отдельной команде.

Куда это всё движется

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

Для практиков вывод простой. Если вы строите агентские системы поверх существующих баз, уже сегодня стоит думать о дедупликации под-запросов, приближённых ответах и структурированной памяти с фасетным поиском вместо «запихнём всё в контекст». Через пару лет эти вещи будут не оптимизациями, а обязательным минимумом. Исторически сообщество баз данных умело адаптироваться к смене доминирующей нагрузки: от OLTP к аналитике, от дисков к памяти, от одиночных машин к распределённым кластерам. Переход на агентские нагрузки выглядит следующим шагом той же эволюции, просто на этот раз клиентом базы становится не человек и не приложение, а другой софт, который думает, ошибается и учится.

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

Что такое агентская спекуляция?

Это паттерн работы ИИ-агента с базой данных: вместо одного точного запроса агент генерирует сотни или тысячи пробных запросов, исследуя схему, данные и гипотезы. На бенчмарках 80–90% таких под-запросов дублируют друг друга, что создаёт нагрузку, под которую классические СУБД не проектировались.

Чем структурированная память лучше markdown-файлов?

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

Правда, что агент может создать СУБД с нуля?

Да. Проекты Bespoke OLAP и GenDB показывают синтез аналитических движков под конкретную нагрузку за минуты или часы и несколько долларов. Ограничение: спецификации неполны, и агенты склонны к reward hacking, поэтому нужны отдельные верифицирующие агенты или формальные доказательства корректности.

Итог

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