Корпоративный ИИ становится очень хорош в освоении бюджетов еще до того, как начинает выдавать надежные ответы.
Проблема не в нехватке интеллекта. Проблема в том, что мы пытаемся внедрить ИИ в масштабах предприятия, используя архитектуры, которые слишком дороги, слишком централизованы и слишком терпимы к результатам типа «почти правильно». В промышленной эксплуатации «почти правильно» — это то, с чего начинаются неприятности. Ложноположительный результат может привести к движению средств, неверной оценке рисков, блокировке добросовестного клиента или направлению автоматизированного процесса по неверному пути еще до того, как кто-то это заметит.
На наш взгляд, решение заключается в том, чтобы перестать рассматривать корпоративный ИИ как одну огромную модель, ожидающую решения любой поставленной перед ней задачи. Корпоративный ИИ должен строиться как сеть специализированных моделей, а не как единая модель, от которой ожидают выполнения всего.
Корпоративному ИИ нужны специализированные модели, а не одна гигантская LLM
Вот почему я не думаю, что корпоративный ИИ в конечном итоге будет организован вокруг единственной всемогущей модели, расположенной поверх гигантской централизованной платформы данных. Он будет гораздо больше похож на сеть специализированных малых языковых моделей и агентов, каждый из которых предназначен для определенной области и работает совместно с общим, постоянно меняющимся массивом корпоративных данных.
Торговая модель должна разбираться в трейдинге. Модель управления капиталом должна понимать портфели, соответствие требованиям и историю клиентов. Модель цепочки поставок должна понимать запасы и логистику. Модель безопасности должна понимать телеметрию и риски. Им не нужны одна и та же модель, один и тот же контекст или одинаковый объем вычислительных мощностей.
Рациональный способ построения такой системы — декомпозиция задачи, а не попытка съесть слона целиком. Такая декомпозиция также имеет важные экономические последствия. Не каждый запрос требует колоссального расхода токенов: узкая задача может выполняться на меньшей модели с меньшим контекстом и гораздо более низкой стоимостью вывода, в то время как более сложная задача может быть перенаправлена на что-то более мощное. В противном случае интеллект общего назначения превращается в накладные расходы общего назначения.
Рои агентов превращают конкурентность баз данных в проблему ИИ
Однако, как только вы начинаете строить ИИ таким образом, архитектура базы данных становится еще важнее, поскольку рои агентов создают огромную конкурентность.
Один ИИ-агент считывает позицию клиента, в то время как другой обновляет ее. Третий ждет этого обновления, прежде чем принять следующее решение, а четвертый может рассчитывать риск по той же самой позиции. Ценность всей системы зависит от того, работают ли эти агенты с актуальным состоянием бизнеса, а не с набором слегка отличающихся исторических версий реальности.
В этот момент задержка перестает быть абстрактным показателем и становится прямой стоимостью завершения операции. Если агенту приходится ждать завершения записи, прежде чем другой агент сможет начать действовать, задержка накапливается в рабочем процессе. Одна медленная передача данных превращается в пять; пять агентов превращаются в пятьдесят. Аккуратная схема роя агентов начинает напоминать старую телефонную станцию в час пик: интеллект повсюду, провода переплетены, и все ждут, пока кто-то другой закончит разговор. В таком масштабе база данных становится частью плоскости управления.
База данных, лежащая в основе, должна поддерживать массовую конкурентность, сохраняя при этом синхронизацию операций чтения и записи на рабочей скорости. Это был один из фундаментальных принципов проектирования SingleStore: распределенная SQL-база данных, созданная для высококонкурентных транзакционных и аналитических рабочих нагрузок в рамках одного движка. Поскольку агентные системы создают все больше одновременных операций чтения, записи и принятия решений, эта архитектура становится все более важной.
Открытые данные и Apache Iceberg сохраняют свободу корпоративных данных
Я уже писал ранее о том, почему Iceberg нуждается в открытом каталоге, а не в очередном «огороженном саду». Архитектура агентного ИИ делает этот аргумент еще более весомым.
Мы не считаем, что каждый байт корпоративных данных должен быть физически перемещен на одну проприетарную платформу, прежде чем он станет полезным для ИИ. У предприятий уже есть огромные инвестиции в озера данных и открытые форматы, такие как Apache Iceberg. Архитектура должна работать с данными там, где они находятся, позволяя при этом высокоценным операционным данным находиться в движке, где агенты могут взаимодействовать с ними с очень низкой задержкой.
Это дает предприятиям то, что, на мой взгляд, будет становиться все более важным: свободу данных. Модель может меняться, агентная инфраструктура может меняться, специализированные SLM могут меняться, в то время как данные остаются в открытых форматах. Операционная база данных может обслуживать рабочие нагрузки, требующие согласованности и конкурентности в реальном времени, и каждый компонент может развиваться независимо.
Компонуемый ИИ победит корпоративный ИИ-монолит
Это сильно отличается от создания ИИ как одного вертикально интегрированного монолита, в котором платформа данных, уровень интеллекта и среда исполнения тесно связаны. Монолиты могут сделать первую схему архитектуры более простой. Они удобны в начале, но дороги всегда.
Преимущество будет у архитектуры, способной координировать тысячи специализированных моделей и агентов, работающих со свежими корпоративными данными, не заставляя каждую задачу проходить через одну и ту же модель, один и тот же профиль вычислений или один и тот же проприетарный стек. Именно здесь скорость, точность, контроль затрат и свобода данных начинают усиливать друг друга.
