Sakana Aquarium: зачем корпоративному ИИ-агенту общие определения данных

23 октября Sakana AI представила Aquarium — платформу для корпоративных ИИ-агентов. Её центральная идея не в новом чат-окне, а в общем описании того, что означают данные компании и по каким правилам принимаются решения. Такой слой называют онтологией. По заявлению разработчика, разные агенты могут опираться на одни определения, а действия и одобрения человека сохраняются в журнале. Публичное объявление пока не даёт оснований считать, что система уже подходит любой организации или доказала экономию времени в независимых испытаниях.

Зачем понадобился ещё один слой между данными и агентом

В обычной компании слово «клиент» редко означает одно и то же во всех системах. В CRM это организация с открытой сделкой, в бухгалтерии — контрагент с документами, в поддержке — человек, написавший обращение. Если агенту просто дать поиск по этим источникам, он может соединить записи по похожему имени и получить неверный вывод. Вопрос «какие клиенты ждут ответа больше двух дней?» станет ещё сложнее, если не определить рабочие дни, владельца обращения и момент, когда ответ считается отправленным.

Aquarium предлагает сначала описать сущности, связи и правила: какие записи относятся к одному заказу, какая версия договора действует, кому разрешено менять статус. Лишь затем агент получает задачу. Это отличается от надежды, что модель сама догадается о смысле колонок и внутренней процедуре по нескольким примерам. Для читателя, знакомого с поиском по корпоративным документам, важное различие такое: поиск помогает найти фрагмент, а онтология задаёт согласованное значение найденного и допустимое действие после ответа.

Что компания действительно показала

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

В опубликованном сообщении нет универсальной цены, открытой страницы самостоятельной регистрации и независимого сравнительного теста с привычной связкой «поиск плюс правила в коде». Sakana предлагает обращаться к команде за обсуждением внедрения. Следовательно, Aquarium сейчас разумнее рассматривать как вариант для пилота с заранее выбранным процессом, а не как готовую замену CRM или ERP. Неясно и то, сколько работы потребуется на поддержку определений при изменении бизнеса: онтология устаревает так же, как любая схема данных.

Как проверить пользу без большого проекта

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

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

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

Ограничения, о которых стоит спросить до подключения

Общие определения помогают только тогда, когда источники надёжны. Если два отдела по-разному ведут карточки, онтология не исправит историю автоматически. Нужно согласовать владельца каждого поля, порядок разрешения конфликтов и дату вступления правила в силу. Заодно проверьте, можно ли удалить доступ к источнику без оставшейся копии в журнале агента, и кто увидит промежуточные выводы с персональными сведениями.

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

Что остаётся после анонса

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

Частые вопросы

Aquarium — новая языковая модель? Нет. Sakana описывает платформу для построения и эксплуатации агентов поверх организованных данных; в анонсе она не представлена как отдельная базовая модель.

Можно ли заменить ею поиск по документам? Не обязательно. Поиск и общие определения решают разные задачи и могут работать вместе. Решение зависит от того, нужна ли агенту только цитата или ещё управляемое действие.

Доказана ли экономия на внедрении? Публичный анонс не содержит независимого расчёта для типовой компании. Измеряйте её в своём пилоте вместе с затратами на подготовку и поддержку данных.