Экосистема решений для создания ИИ-среды: формирование корпоративной инфраструктуры искусственного интеллекта

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

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

Что представляет собой корпоративная ИИ-среда

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

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

Каждый этап предъявляет отдельные требования к безопасности и эксплуатации. Поэтому при росте количества ИИ-проектов возникает необходимость в общей технологической основе вместо множества независимых экспериментальных решений.

Почему одной языковой модели недостаточно

Большая языковая модель выполняет только часть корпоративной задачи. Она способна работать с естественным языком и создавать ответы, но сама по себе не знает текущего состояния внутренних систем, не определяет корпоративные полномочия пользователей и не получает автоматически актуальные сведения из документов организации.

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

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

Компоненты экосистемы Астра ИИ

В актуальной структуре "Астра ИИ" компоненты разделены по назначению. "Астра ИИ [Хаб]" связан с хранением ИИ-моделей, управлением ролями и распределением вычислительных ресурсов. "Астра ИИ [Платформа]" предназначена для создания ИИ-решений в режиме low-code и визуальной доработки агентных схем.

"Астра ИИ [Код]" ориентирован на применение ИИ при разработке программного обеспечения. "Астра ИИ [Цифровой офис]" является прикладным уровнем, через который сотрудники могут взаимодействовать с корпоративными ИИ-сервисами. "Астра ИИ [Агент Икс]" обозначается как профильный фреймворк для разработки ИИ-решений и среда исполнения пайплайнов.

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

Управление моделями и ресурсами

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

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

В "Астра ИИ" этот уровень связан с компонентом "Хаб". Централизация позволяет рассматривать модель как управляемый инфраструктурный ресурс. Это упрощает контроль версий и дает возможность проводить тестирование новой модели до ее подключения к промышленным приложениям.

Такой подход также важен с точки зрения рационального использования оборудования. Не каждая задача требует наиболее крупной модели. Классификацию короткого текста или извлечение простых признаков иногда рациональнее выполнять менее ресурсоемким инструментом.

Low-code-разработка ИИ-сервисов

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

Low-code позволяет представить эти операции в виде визуальной схемы. Специалист выбирает готовые блоки, связывает их и задает параметры. Это уменьшает количество типового интеграционного кода и делает логику приложения более наглядной.

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

Low-code при этом не является полным отказом от программирования. Нестандартная интеграция, особый алгоритм обработки или специализированная бизнес-логика могут потребовать разработки собственного компонента. Поэтому визуальная среда полезна прежде всего для стандартизации повторяемых частей ИИ-приложений.

Пайплайны и последовательность обработки данных

Пайплайн - последовательность этапов, через которые проходит пользовательский запрос. В простейшем случае он состоит из передачи текста модели и получения ответа. Корпоративная схема обычно сложнее.

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

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

В архитектуре "Астра ИИ" исполнительный уровень пайплайнов связан с "Агент Икс". Он рассматривается как профильный фреймворк для разработки ИИ-решений и выполнения соответствующих цепочек.

ИИ-агенты и их отличие от обычного чат-бота

Обычный чат-бот преимущественно отвечает на сообщение пользователя. ИИ-агент может самостоятельно выбрать несколько разрешенных действий для выполнения поставленной задачи.

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

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

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

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

RAG и корпоративные знания

Большая языковая модель не содержит автоматически актуального содержимого внутренних документов организации. Для использования таких сведений применяется подход RAG - Retrieval-Augmented Generation, то есть генерация с дополнением найденной информацией.

При получении вопроса поисковый компонент определяет связанные с ним фрагменты документов. Они передаются модели вместе с запросом, после чего ответ формируется с учетом корпоративного контекста.

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

Однако эффективность такой схемы зависит от качества исходной базы. Если в хранилище одновременно присутствуют несколько противоречащих друг другу версий инструкции, ИИ способен использовать устаревшую.

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

ИИ для разработки программного обеспечения

Отдельный класс задач связан с применением ИИ непосредственно в процессе разработки. "Астра ИИ [Код]" представляет собой агентную систему, рассчитанную на работу с программным проектом в контролируемом контуре.

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

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

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

Пользовательский уровень ИИ-среды

Большинству сотрудников не требуется доступ к инструментам настройки моделей или визуальному редактору агентных пайплайнов. Им нужен понятный способ решать прикладные задачи.

В структуре "Астра ИИ" за такой пользовательский уровень отвечает "Цифровой офис". Он предназначен для повседневного взаимодействия сотрудников с внутренней ИИ-средой и использования агентов, подготовленных на платформенном уровне.

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

С точки зрения эксплуатации такое разделение удобно тем, что внутреннюю модель или логику можно менять без существенного изменения привычного пользовательского сценария.

Работа в закрытом контуре

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

На странице "Астра ИИ" предусмотрена работа в закрытом контуре. В качестве вариантов размещения экосистемы указываются серверы заказчика, защищенная облачная инфраструктура Astra Cloud и поставка в формате программно-аппаратного комплекса.

On-premises-размещение позволяет организации контролировать серверы, сетевые соединения и хранение данных. При этом оно требует достаточных вычислительных ресурсов и компетенций для эксплуатации.

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

Сам факт нахождения системы в закрытом контуре не гарантирует безопасность. Необходимы аутентификация, разграничение прав, сетевые ограничения, управление учетными записями, журналирование и своевременное обновление компонентов.

Инфраструктура для работы моделей

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

В технологической схеме "Астра ИИ" упоминается платформа контейнеризации "Боцман", а в качестве системного слоя - Astra Linux.

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

Однако контейнерная среда также требует администрирования: необходимо управлять образами, сетевыми политиками, секретами, учетными записями сервисов и ресурсными лимитами.

Особенно важен контроль GPU и других ускорителей, поскольку одновременный запуск нескольких крупных моделей способен быстро исчерпать доступную вычислительную емкость.

Информационная безопасность ИИ-среды

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

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

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

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

Наблюдаемость и управление качеством

После запуска ИИ-сервиса недостаточно контролировать только доступность сервера. Необходимо наблюдать за поведением самого приложения.

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

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

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

Поэтапное внедрение ИИ-среды

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

Сначала определяется задача: например, поиск по технической документации, обработка входящих обращений или подготовка программного кода. Затем устанавливаются источники данных и измеримые критерии качества.

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

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

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

Ограничения экосистемного подхода

Единая ИИ-среда помогает стандартизировать разработку и эксплуатацию, но сама требует квалифицированного сопровождения. Необходимо администрировать модели, вычислительные ресурсы, данные и прикладные сервисы.

Централизация повышает значение общих компонентов. Ошибка конфигурации платформы или недоступность критичной модели способны затронуть сразу несколько ИИ-сервисов. Поэтому ключевые элементы необходимо мониторить и при необходимости резервировать.

Еще одно ограничение связано с данными. Даже технически корректная платформа не исправляет устаревшие, противоречивые или плохо структурированные документы.

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

Заключение

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

В экосистеме "Астра ИИ" эти роли распределены между специализированными компонентами. "Хаб" формирует инфраструктурный уровень моделей и ресурсов, "Платформа" используется для low-code-создания ИИ-сервисов, "Агент Икс" связан с разработкой и выполнением пайплайнов, "Код" предназначен для агентной работы с программным обеспечением, а "Цифровой офис" обеспечивает пользовательский уровень.

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

Наиболее устойчивый путь к созданию ИИ-среды - последовательное внедрение: выбор конкретных сценариев, пилотирование, проверка качества и безопасности, организация мониторинга и только затем масштабирование. В этом случае искусственный интеллект становится не отдельным экспериментальным сервисом, а управляемой частью корпоративной ИТ-инфраструктуры.