В недавнем интервью The Register (https://www.theregister.com/databases/2026/09/18/the-ideal-database-for-ai-agents-doesnt-exist-yet-says-percona-ceo/5296906) генеральный директор Percona Питер Фаркас (Peter Farkas) заявил, что идеальная архитектура базы данных для ИИ-агентов еще не создана, и экосистеме агентов необходимо созреть, прежде чем можно будет разработать специализированную систему с нуля. Он прав в том, что ключевые аспекты развертывания агентов, такие как нормативные базы и операционные границы, все еще находятся в стадии формирования. Однако требования к уровню данных для ИИ-базы данных уже очевидны. Описанный им сценарий показывает, чего требуют подобные рабочие нагрузки.
Уровень данных для ИИ-агентов должен одновременно удовлетворять трем требованиям непосредственно на оперативных данных. Во-первых, компонуемость позволяет отвечать на нерегулярные запросы, которые никто не писал заранее. Во-вторых, параллелизм позволяет одновременно обслуживать запросы от множества пользователей и агентов. В-третьих, согласованность означает, что каждый запрос видит текущее операционное состояние, поэтому проверка и следующее за ней действие считывают одни и многие базы данных справляются с одной или двумя из этих задач. Агентам, совершающим бизнес-действия, нужны все три.
Задолго до появления ИИ-агентов с такими же требованиями столкнулись транзакционные системы, такие как оценка мошенничества в реальном времени и алгоритмический контроль рисков, в том числе на базе машинного обучения. Агенты же добавляют запросы, которые программное обеспечение формирует во время выполнения, причем их количество возрастает многократно.
Требования к базам данных для агентного ИИ и рабочих нагрузок с множеством попыток агента
Фаркас описал сценарий, в котором ИИ-агент генерирует 150 возможных решений для одной задачи, прежде чем человек или нисходящая система выберет лучшее из них. Ни один человек-оператор не стал бы рассматривать столько вариантов. Каждая попытка инициирует один или несколько запросов к корпоративным данным, что создает нагрузку, для обработки которой традиционные базы данных не проектировались.
Запросы меняются от одной попытки к другой. Один рабочий процесс может начаться со сверки активных заказов клиентов с доступными запасами, а затем объединить текущие сбои в доставке с многолетней историей возвратов, чтобы решить, можно ли безопасно предложить альтернативный продукт. Агент формирует эти запросы во время выполнения, поэтому предварительно вычисленные представления и слои кэширования не помогут, и базе данных приходится вычислять каждый ответ «на лету».
Кроме того, они поступают одновременно. Одна задача превращается в сотни запросов, и когда парк агентов в мультиагентной системе работает параллельно с существующими пользователями и приложениями, параллельная нагрузка быстро растет. Транзакционные системы уже давно справляются с высокой степенью параллелизма за счет обслуживания предсказуемых индексированных поисков по принципу «ключ-значение». Когда агенты массово отправляют непредсказуемые запросы, базе данных требуется индексация, которая ограничивает каждое сканирование только релевантными данными. Без этого трафик агентов замедляет все остальные процессы в системе.
Как только выбран подходящий вариант, агент производит оперативное изменение, например блокировку товара или установку удержания, которое должно немедленно вступить в силу для актуального состояния бизнеса. Если два агента считывают уровни запасов из отдельных несинхронизированных реплик, оба могут увидеть последний товар как доступный и попытаться заявить на него права. Каждое решение было правильным для считанного моментального снимка, но в результате один и тот же товар продается дважды.
Фаркас отметил аналогичную проблему в проектировании моделей: система, которая пытается решить каждую задачу, обходится дороже, чем создаваемая ею ценность. То же самое справедливо и для уровня данных. Когда 149 из 150 запусков запросов отбрасываются, организация платит за 150 циклов вычислений ради получения одного результата. При таком соотношении стоимость каждого запроса становится инженерным ограничением. Запуск попыток на избыточных копиях данных увеличивает расходы на инфраструктуру, а конвейеры, которые синхронизируют эти копии, работают постоянно, независимо от того, сохраняет ли кто-либо результаты попытки.
Что такое Active Data Intelligence?
Активные данные — это оперативные данные в реальном времени, на которых строится бизнес, такие как ожидающие обработки заказы и текущие остатки на счетах. Потоковые данные — это актуальная копия событий по мере их прохождения через конвейер. Активные данные обновляются на месте по мере изменения заказов и балансов, последовательно отражая текущее состояние бизнеса. Active Data Intelligence привносит компонующуюся аналитику в эти оперативные данные с тем уровнем параллелизма, который создают агенты, позволяя людям, автоматизированным системам и автономным агентам анализировать текущее состояние бизнеса и действовать на его основе в рамках одной системы. Без промежуточных копий путь идет напрямую от создания данных к анализу, принятию решения и действию.
Это зависит от трех требований из примера Фаркаса:
- Компонуемость: способность выполнять любой запрос по требованию, включая соединения, объединяющие живые транзакции с многолетней историей.
- Параллелизм: способность одновременно обслуживать большой объем запросов от пользователей, приложений и автономных агентов, используя индексы для поддержания низкой стоимости каждого запроса.
- Согласованность: гарантия того, что каждый запрос видит одно и то же текущее состояние системы, поэтому проверка и следующее за ней действие опираются на одни и те же данные.
Существующие системы обработки данных часто удовлетворяют лишь одному или двум из этих требований. Хранилища отвечают на любые вопросы небольшой команды аналитиков, а транзакционные базы данных справляются с высокой степенью параллелизма для заранее известных вопросов. Многим рабочим нагрузкам требуется компонуемость в сочетании с параллелизмом. ИТ-компания, внедряющая аналитику в свой продукт, имеет тысячи клиентов, задающих собственные вопросы одновременно, и несколько секунд задержки для них редко имеют значение. Агентам, совершающим действия в бизнесе, также необходима согласованность.
Работа непосредственно с оперативными данными важна потому, что каждая промежуточная копия создает задержку между анализом и текущим состоянием. Традиционные конвейеры принятия решений по-прежнему работают на реплицируемых данных, таких как ночные синхронизации хранилища или слои кэширования. Такая задержка приемлема для людей, принимающих решения в течение часов или дней. Но она терпит крах, когда программное обеспечение и агенты должны действовать за миллисекунды.
Может ли база данных для ИИ-агентов быть уже зрелой?
Фаркас утверждает, что нам следует подождать, пока базы данных созреют, отмечая, что устоявшимся, проверенным платформам баз данных потребовались десятилетия, чтобы доказать свою надежность, а у систем, созданных для ИИ-агентов, еще не было такого времени.
Я проработал четыре года в компании Mesosphere во время перехода на контейнеры, и моя команда перенесла наш набор продуктов в Kubernetes. Kubernetes опубликовала свой первый код на GitHub в июне 2014 года. Ее дизайн был основан на Borg — менеджере кластеров, который Google использовал внутри компании в промышленных масштабах почти десять лет, и многие ее инженеры работали над Borg. Код был новым, но его требования были проверены в масштабах Google в течение десятилетия. Требования и код созревают в разные сроки, и требования часто созревают первыми.
Требования к базам данных для агентов развивались по тому же пути. Задолго до появления ИИ-агентов программное обеспечение взяло на себя принятие важных решений, которые раньше принимали люди, таких как проверка транзакций по картам на предмет мошенничества и соблюдение лимитов риска на торговых площадках. Эти системы принимают тысячи решений в секунду с задержкой в миллисекунды, и устаревшие данные немедленно оборачиваются финансовыми потерями: мошенничество, выявленное после одобрения, — это уже убыток, а проверка риска на основе минутного снимка может пропустить одновременные сделки, нарушающие лимит. Базы данных, созданные для таких рабочих нагрузок, работают в продакшене уже более десяти лет. SingleStore, запущенная как MemSQL в 2011 году, — одна из них.
Крупный банк США, использующий SingleStore, перенес обнаружение мошенничества из ночных пакетных заданий в поток реальных транзакций. Теперь его система выполняет около 70 различных запросов за 50 миллисекунд, что укладывается в односекундный бюджет на одобрение транзакции. Таков профиль базы данных для ИИ-агента: множество целевых запросов об одном объекте, охватывающих живые и исторические данные, в условиях жесткого ограничения по задержке, где ответ определяет, пройдет ли платеж.
Разница заключается в предсказуемости. Инженеры банка написали и настроили каждый из этих 70 запросов заранее. Агент пишет свои запросы во время выполнения, поэтому никто не может предварительно вычислить или настроить их по отдельности. Независимо от того, какие модели ИИ лежат в их основе, агенты унаследовали требования к задержке и параллелизму, которые доказали свою эффективность в системах мошенничества и трейдинга, и должны удовлетворять им с помощью непредвиденных запросов.
Какие рабочие нагрузки агентов требуют сочетаемости, параллелизма и согласованности одновременно
Разным агентам от базы данных нужно разное. В корпоративных пилотных проектах с агентами часто встречаются четыре паттерна.
Паттерн агента
Пример
Что требуется от базы данных
Поиск (Retrieval)
Агент поддержки, ищущий правила и прошлые тикеты для ответа клиенту
Быстрый гибридный поиск по документам и записям. Он выполняет чтение и редко изменяет состояние
Анализ (Analysis)
Агент, проверяющий объяснения падения выручки с помощью десятков запросов
Сочетаемость и параллелизм. Свежая копия часто допустима, когда окончательное решение принимает человек
Мониторинг (Monitoring)
Агент, отслеживающий поток событий на предмет аномалий и поднимающий тревогу
Вопросы, в основном известные заранее, с которыми хорошо справляется потоковая обработка
Оперативное действие (Operational action)
Агент, который перенаправляет отправления или устанавливает удержания
Все три: он читает текущее состояние, составляет непредвиденные вопросы и изменяет данные, от которых зависят другие агенты и приложения
Агенты поиска и мониторинга отлично работают на стандартной инфраструктуре, такой как векторные индексы, векторные базы данных и процессоры потоков. Парку аналитических агентов требуются одновременно сочетаемость и параллелизм — те же два фактора, что и для аналитики, встроенной в продукт. Хранилища, созданные для небольшой команды аналитиков, справляются с первой частью и лишь частично со второй. Операционные действия требуют всех трех факторов одновременно, и неверные данные здесь напрямую оборачиваются финансовыми потерями.
Со временем агенты также склонны переходить к оперативным действиям. Помощник поддержки, отвечающий на вопросы сегодня, завтра может получить полномочия на обработку возвратов. Аналитический агент, объясняющий колебания выручки, позже может заняться перераспределением бюджета. Агент мониторинга, сигнализирующий об аномалиях, может начать устанавливать блокировки. Больше полномочий означает более строгие требования к данным. Агент, который изменяет данные, должен сохранять согласованность со всеми остальными системами, действующими одновременно, в то время как весь парк продолжает составлять собственные запросы.
Выбор архитектуры данных для агентного ИИ сегодня — это решение о том, что вашим агентам будет дозволено делать в будущем. Поиск работает на копиях. Как только агенты получают возможность действовать, организация либо переходит на актуальные данные под давлением сроков, либо уже работает на инфраструктуре, созданной для этого. Пока организации не определятся с тем, насколько сильно они доверяют агентам, более безопасным выбором является фундамент, который справляется с сегодняшними запросами и сможет взять на себя действия, которые появятся позже.
Что делает базу данных базой данных для ИИ?
В конце интервью Фаркаш подтвердил позицию Percona против простого ребрендинга Postgres или MongoDB в «базы данных для ИИ». Я согласен с этим по архитектурным соображениям.
Обычный способ адаптации существующей базы данных для ИИ заключается в добавлении возможностей вокруг движка: векторных расширений, поисковых индексов или конвейеров ETL для зеркалирования операционных записей в хранилища данных. Каждое из этих дополнений работает, но каждое добавляет еще одну копию данных по собственному расписанию синхронизации. Векторные индексы отстают от лежащих в их основе таблиц. Аналитические хранилища отстают от первичных транзакционных систем. Агент, который запрашивает их все перед совершением действия, видит три разные версии бизнеса.
Инженерия данных уже сталкивалась с этой проблемой. В 2011 году Натан Марц описал то, что стало известным как лямбда-архитектура, которая запускала пакетный путь и скоростной путь бок о бок для достижения как полноты, так и свежести. Это работало, но командам приходилось поддерживать два пути кода, которые могли расходиться. Архитектуры агентов, построенные на копиях, возвращают те же компромиссы. Риск сейчас выше, потому что агент может совершить действие до того, как человек успеет заметить несоответствие.
Запуск отдельных движков поверх общего хранилища решает эту проблему лишь частично. У каждого движка по-прежнему есть своя граница транзакций, поэтому проверка в одном движке и действие в другом могут видеть разные состояния. Эти пробелы позже проявляются в виде превышенных лимитов риска или перепроданных запасов.
SingleStore — это операционная база данных, созданная для активной интеллектуальной работы с данными (Active Data Intelligence). Она выполняет транзакции, аналитику, полнотекстовый поиск и векторный поиск в рамках одного движка на актуальных данных, поэтому приложения и агенты могут читать состояние и осуществлять запись в рамках одной ACID-транзакции, например проверять запасы и резервировать товар за один шаг. Новые записи поступают в память в виде строк, а затем перемещаются в сжатое индексированное колоночное хранилище, что обеспечивает высокую скорость нерегулярных (ad-hoc) запросов при высоком параллелизме. По мере старения данных они перемещаются с локальных SSD в объектное хранилище в открытых форматах, таких как Apache Iceberg, что снижает затраты на запросы без ущерба для аналитических результатов.
Традиционные системы записей (systems of record) и хранилища данных по-прежнему справляются с долгосрочным аудитом и обучением моделей на исторических данных. Рабочие нагрузки, которые принимают решения и действуют в реальном времени, включая ИИ-агентов, нуждаются в едином фундаменте актуальных данных.
Ключевые вопросы для оценки базы данных для ИИ-агентов
Отбросьте ярлыки и протестируйте платформы на соответствие требованиям цикла выполнения агента. Задайте эти вопросы любому вендору, включая нас:
- Адаптивность запросов и задержка: может ли база данных для ИИ выполнять нерегулярные запросы, которые объединяют актуальные операционные данные с многолетней историей достаточно быстро, чтобы уложиться в цикл агента?
- Параллелизм парка агентов: как удерживается время отклика, когда крупное развертывание с множеством агентов выполняет эти запросы параллельно с производственными приложениями?
- Транзакционная изоляция: когда агент проверяет условие перед совершением действия, гарантировано ли, что проверка и действие увидят один и тот же снимок, или другие агенты могут изменить состояние в промежутке?
- Репликация и задержка: сколько промежуточных копий данных существует между ИИ-приложением и первичной системой записей и какова задержка синхронизации для каждой из них?
- Унифицированное управление: достаточно ли одной политики контроля доступа для управления каждым путем, используемым агентным ИИ, включая точечные поисковые запросы, векторный и текстовый поиск, а также широкие аналитические запросы?
- Пост-аудит: может ли система восстановить и проверить точные данные, которые агент прочитал при совершении действия?
Аудит усложняется по мере увеличения числа попыток. Когда агент перебирает 150 возможных путей перед совершением одного действия, он оставляет 149 заброшенных ветвей. Вам необходима точная запись того, что прочитала успешная попытка, как для объяснения решения аудиторам, так и для того, чтобы дать инженерам материал для отладки.
Бизнес-эффект от данных в реальном времени
Работа напрямую с «живыми» данными снижает затраты, открывает новые источники дохода и предотвращает убытки.
Снижение затрат
Кэши и реплики, существующие исключительно ради производительности, увеличивают затраты на инфраструктуру и усложняют управление. Перенос рабочих нагрузок на оперативные данные в реальном времени устраняет необходимость в таких копиях. Каждое последующее приложение обходится дешевле, так как оно использует ту же основу из актуальных данных.
Новый доход
Принятие решений в реальном времени, пока клиент еще вовлечен в процесс, делает возможным следующее:
- Автоматизированное кредитование: кредиторы могут разрешить малому бизнесу подать заявку на кредит за пару минут и автоматически одобрять ее за одну секунду.
- Розничная торговля: ритейлеры могут предложить заменяющий товар до того, как покупатель бросит корзину.
- Динамическое ценообразование: торговые площадки могут менять цены по мере изменения спроса и предложения.
Работа, которая раньше ждала запланированного пакетного задания или статического отчета, может выполняться немедленно, что также делает ее отлично подходящей для ИИ-агентов.
Меньше убытков
Предотвращенные убытки — это показатель окупаемости, который проще всего измерить:
- Обнаружение и блокировка мошеннических транзакций до авторизации.
- Предотвращение перепродажи запасов и невыполнимых заказов.
- Соблюдение строгих лимитов рисков и экспозиции в реальном времени.
С чего начать
Фаркаш дал практический совет: выберите стек, способный справляться с такими нагрузками уже сегодня, и не рассчитывайте, что он вечно останется лучшим вариантом. Этот совет также указывает на то, с чего следует начать.
В большинстве организаций одна из рабочих нагрузок уже демонстрирует эту проблему: кэш, добавленный для обхода медленных запросов, или две системы, которые кто-то сверяет вручную, чтобы балансы счетов сходились. Найдите сценарий использования, где устаревшие или противоречивые данные обходятся дороже всего, и перенесите этот процесс на уровень актуальных данных.
Организации все еще решают, какой уровень автономности предоставить ИИ-агентам. Когда агент получает разрешение выдать возврат средств или пометить заказ, он работает с теми же данными и правами доступа, что и инструменты обнаружения мошенничества в реальном времени и резервирования запасов. Перенос этой рабочей нагрузки на активные данные повышает производительность еще до того, как в процесс вмешивается какой-либо агент, а агенты, которые появятся позже, начинают работу с актуальным состоянием бизнеса.
