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

Вопрос в том, что окажется узким местом, когда сам интеллект перестанет им быть. Исследователи из UC Berkeley отвечают: данные. Лаборатория EPIC Data Lab под руководством Адитьи Парамешварана выпустила разбор «Intelligence is Free, Now What?», в соавторах у которого Матей Захария, Ион Стойка и Джо Хеллерстейн, авторы Spark, Databricks и классических работ по базам данных. Их главный тезис: когда интеллект почти бесплатен, всё упирается в системы данных, но проектировать их по-старому не получится.

Авторы формулируют три задачи: данные для агентов, данные об агентах и данные от агентов. Первая про то, как агенты нагружают хранилища. Вторая про субстрат, на котором живут их рои. Третья про мир, где агенты сами синтезируют системы данных с нуля.

Данные для агентов: тысячи запросов вместо одного

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

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

Что с этим делать? Многие направления опираются на давнюю литературу по базам данных. Переиспользовать результаты пересекающихся подпланов, как в multi-query optimization и shared scans. Возвращать приблизительные ответы, которых достаточно, чтобы агент двигался дальше (идея из области approximate query processing). Стримить промежуточные результаты, чтобы агент сам решал, нужно ли ему смотреть остальное. Перейти от одиночных запросов к пакетам, где у каждого запроса свои требования к точности. Поднять уровень абстракции: не заставлять агента перечислять каждый запрос в экспоненциальном пространстве поиска, а дать ему примитивы с циклами в духе Jinja-макросов из DBT.

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

Данные об агентах: память, координация, сбои

Вторая задача начинается там, где заканчивается работа с базой. Где агенты живут, как помнят, как договариваются друг с другом и что происходит, когда один из тысяч падает.

Сегодняшняя мудрость звучит так: files are all you need. Агент пишет заметки в markdown-файлы, а потом ищет по ним через grep или эмбеддинги. Считается, что и continual learning решается этим же: скормить агенту весь код, весь Slack, все вики компании, а выученное он сложит в MD-файлы и будет доставать по мере надобности. Авторы не спорят: файлы, bash и markdown останутся важными. Но в масштабе, когда агенты делают основную часть умственного труда, подход перестаёт работать.

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

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

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

Дальше начинается распределёнка. Тысячи агентов одновременно правят общее состояние. Спекулятивные транзакции почти все нужно откатывать, оставляя результат только одной, «правильной». Классических multiversioning и copy-on-write не хватит. Авторы указывают на exactly-once семантику, CRDT и operational transformation. И на отдельную опасность: livelock, когда бесконечные компенсирующие действия не дают системе продвинуться вообще.

Последний пласт: общение. Четыре агента-разработчика договариваются об общей схеме с пересекающимися целями. У людей это была бы серия обсуждений и компромиссов, а для роя агентов нужно определить механизм сходимости, централизованный или децентрализованный. Плюс сбои отдельных агентов, страгглеры и попытки вроде Temporal, которые пока не проверены на тысячах агентов.

Данные от агентов: когда систему пишет сам агент

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

Работы Bespoke OLAP и GenDB уже показали, что агентский пайплайн собирает аналитический движок под конкретную нагрузку за минуты или часы и за несколько долларов. Такие движки одноразовые: сменилась нагрузка, сгенерировали новый. Похожим образом авторы синтезировали кастомные key-value хранилища. А в IDE вроде Kiro спецификации для разработки систем стали полноценным артефактом первого класса.

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

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

Что дальше: границы размываются

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

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

Что это значит для команд, которые строят агентов

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

Первый: если вы строите text-to-SQL агента, избыточность запросов уже ваша проблема. Агент генерирует в разы больше запросов, чем нужно, и это заложено в саму природу перебора. Переиспользование результатов и приблизительные ответы дадут больше, чем очередной тюнинг промпта.

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

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

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

Что такое «почти бесплатный интеллект»?

Это ситуация, когда стоимость инференса падает до уровня, при котором рассуждающие модели можно применять массово и без экономии. Ориентиры из статьи: миллион токенов GPT-4-класса подешевел с $30 до меньше чем $1, а медианное снижение цен на инференс за год составило около 50 раз. Интеллект, достаточный для большинства задач умственного труда, уже доступен почти каждому.

Почему обычные базы данных плохо подходят ИИ-агентам?

Потому что агенты создают нагрузку другого типа. Вместо одного запроса они генерируют тысячи, из которых 80-90% дублируют друг друга, перебирая пространство гипотез. Плюс им нужна память между сессиями, координация в роях и понятная обработка сбоев. Классические СУБД проектировались под людей и BI-инструменты, а не под такое поведение.

Опасны ли агенты, которые сами пишут системы данных?

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

Итог

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

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

А вы как думаете: что раньше станет узким местом в вашей агентской системе, вычисления или данные?