Корпоративный мозг на одной видеокарте: что умеет локальная модель

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

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

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

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

В отрасли параллельно развиваются оба подхода: Сбер построил GigaChat, у Яндекса своя линейка, ряд банков создаёт внутренние платформы. Другие компании разрешают облачные модели под контролем DLP и фильтрации персональных данных. Оба пути рабочие, но первый требует бюджета на сотни человек, а второй упирается в политику безопасности. Эксперимент показывает, что есть третий путь — локальная модель на одной видеокарте, которая при правильной инженерии может закрыть большинство корпоративных задач.

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