Привет, Хабр! Меня зовут Олег Гуров, я Presales Solutions Architect на продукте MWS GPT — платформе для работы с LLM. Мы начали развивать ее в МТС Web Services два с половиной года назад: собрали песочницу на несколько видеокарт, где тестировали модели, проверяли гипотезы, искали применение в бизнесе. Мы быстро поняли, что в МТС интерес к LLM есть, и развернули внутренний сервис, где любой сотрудник или разработчик продукта мог попробовать их в деле.
За первый год у нас появилось более 15 тысяч пользователей и 150+ внутренних проектов, использующих платформу. Сейчас наш сервис выдает больше 0,5 трлн токенов в год. Что это за цифра и как ее оценить? Для токенайзера Llama 3, например, это около 0,5 млрд страниц текста, отправленного в модели и полученного от них.
В январе 2025-го мы вышли на новый уровень зрелости: технология показала эффективность, команда набрала темп, и мы решили запустить продукт для внешних заказчиков. Так и появилась коммерческая платформа MWS GPT.
О ней будет два поста:
Вы читаете первый — о возможностях платформы, сценариях ее использования, интерфейсах и инструментах, через которые с ней можно взаимодействовать.
Второй будет полностью посвящен агентам — разберем примеры агентов, посмотрим, как с ними интегрироваться и как их разрабатывать.
Надеюсь, посты будут полезны не только компаниям, выбирающим поставщика LLM, но и просто инженеру, заинтересованному в оптимальном применении моделей и ИИ-агентов.
Содержание
Как использовать MWS GPT
Сейчас основные задачи нашей платформы — в предоставлении больших языковых моделей (LLM) и инфраструктуры, а также в обеспечении работы агентов ИИ, которые выполняют задачи в бизнес-процессах.
Нашим заказчикам не нужно думать о развертывании LLM, масштабировании под всех своих потребителей, обслуживании и прочей рутине. Мы предоставляем LLM-инференс в облаке и в контуре у заказчиков. Наши клиенты просто берут готовые интерфейсы и начинают использовать их в своих проектах, в продакшене, на промышленных нагрузках и с соблюдения всех необходимых требований по ИБ. Остальное на нашей стороне: мы отслеживаем появление новых моделей и разворачиваем их, консультируем по внедрению, решаем инциденты.
В нашей компании модели MWS GPT применяются во многих продуктах, например в чат-боте поддержки в приложении Clatch, для работы голосового помощника в мобильном Cекретаре МТС. Про эти и другие кейсы писал мой коллега, Павел Бабин, в своем материале «Скучная правда о LLM» (рекомендую заглянуть, там на самом деле совсем не скучно, честное слово!).
Мы предоставляем много разных моделей, но какую именно использовать для конкретного сценария или задачи бизнеса?
Примеры сценариев работы с моделями
Конфиденциальная работа в чат-боте с персональными данными, вызова агентов для получения данных из личного кабинета клиента и, например, из БД своих продуктов. Для этого подойдет модель llama-3.3-70b-instruct, развернутая в аттестованном сегменте 152-ФЗ в одном из наших ЦОД в Москве.
Конфиденциальная работа с документами — например, с развернутой там же gpt-oss-120b.
Создание на RAG-архитектуре чат-ботов, которые отвечают пользователям на основе информации из ваших корпоративных документов. Здесь можно использовать bge-m3 — она выполнит перевод текста в векторную форму для помещения в векторную базу данных, а также упомянутую выше llama3 для подготовки ответа пользователю на основе извлеченного из БД контекста.
Обеспечение максимального качества для работы с кодом (например, генерации нового кода, объяснения, написания документации и тестов) — можете задействовать внешнюю модель по своему выбору, используя нас как прокси к ней.
Если вас интересуют AI-инструменты для улучшения эффективности разработчиков, то мои коллеги из соседней команды предоставляют плагины для IDE, работающие с нашими моделями MWS GPT, и с нашей коммерческой поддержкой.
Сбор статистики по качеству работы операторов кол-центра: подойдут связка whisper-turbo для транскрибации (перевода голоса в текст) с Pyannote.audio для диаризации (разделения одной голосовой дорожки на реплики отдельных людей по голосу) и использование qwen3-32b для аналитики диалога и получения информации о том, как вежливо общался оператор, решил ли он проблему клиента и так далее.
Под свои задачи можно сделать Finetuning небольшой быстрой модели, например llama-3.1-8b-instruct.
Считывание текста и семантических связей между объектами на изображении, в том числе печатей и подписей из документов, распознавания типа объектов: подойдут развернутые у нас в ЦОД qwen-2.5-vl-72b или gemma3-27b.
Аналитика и обработка данных, другие сложные запросы: можно использовать думающие модели, например qwen3-32b, qwen2.5-72b-instruct, QwQ-32B.
Использование tools/function calling с агентами: подойдет любая из упомянутых выше моделей, в том числе llama3, gpt-oss или qwen3.
Как видите, у нас уже развернуто большое количество опенсорс-моделей на наших видеокартах, в ЦОДе, который обеспечивает конфиденциальность обработки данных, плюс мы предоставляем доступ к внешним моделям и можем развернуть другую необходимую заказчику модель по запросу.
Кроме GPU-инфраструктуры и LLM мы также даем клиентам инструменты для создания агентов.
Мы рассматриваем «агента» в широком смысле — как программу, которая используют LLM в связке с другими модулями: подключением к базам данных, преобразованием файлов, взаимодействием с фронтендами, реализацией ролевой модели и прочим. Это гибкий подход, позволяющий строить конкретные сценарии, где LLM становится «мозгом» бизнес-логики.
Что можно сделать с помощью агентов
За фразой «мне нужен ИИ» чаще всего прячется не запрос конкретной LLM-модели, а «решения»: ассистента, бота, интерфейса, помощника. То есть чего-то, выполняющего определенную задачу и приносящего реальную пользу для бизнеса. Для этого и нужны агенты.
Как встраивается решение для агентов в экосистему заказчика:
Агенты выполняют сценарии, где LLM становится частью бизнес-логики, например:
Пользователь нажимает на кнопку подключения к боту в веб-портале (или мессенджере, или другом фронтенд-интерфейсе).
Из фронтенда, вроде нашего UI-портала — агрегатора чатов, веб-портала заказчика, 1C, Битрикса, Telegram-канала или других интерфейсов, направляется запрос в REST API агента (например, в наш инструмент Nocode).
Агент обрабатывает его в соответствии с бизнес-логикой — например, обращается к RAG, готовит и выдает ответ.
Ответ возвращается во фронтенд.
Фронтенд показывает ответ пользователю.
Nocode
В MWS GPT агенты можно собрать через встроенный интерфейс Nocode, созданный на базе Langflow с нашими дополнениями. Это графический IDE для разработки агентов, поддерживаемый как часть платформы:
Это главный интерфейс для создания продуктивных агентов. Он позволяет:
визуально собирать пайплайны, состоящие из блоков (обработка запроса, обращение к БД, вызов API, генерация текста, фильтрация, мультиагентная логика и др.);
переиспользовать предоставляемые нами примеры агентов в том числе как компоненты своего агента (RAG, скрипт поддержки, поиск по сайту, обогащение ответа);
делать мультиагентные схемы, когда один агент вызывает другого в зависимости от запроса или темы;
делать мультишаговые схемы, где агенты вызывают несколько tools или обращаются к нескольким MCP-серверам по очереди, передавая полученный после форматирования или изменения ответ в другой tools или MCP-сервер;
управлять поведением — fallback, циклы, логика отказа, таймауты;
выдавать ответ в нужном формате — текст, JSON, HTML, таблица;
модифицировать код любого компонента: они все написаны на Python, изменить их не составляет труда, особенно когда под рукой есть готовая на все модель (речь об LLM, конечно же).
Мы предоставляем не какое-то ограниченное по функциональности коробочное решение, а «конструктор», где компании любого размера могут:
собирать пайплайны для реализации своих специфичных задач;
интегрироваться с любыми своими системами (базы данных, веб-сайты, API, и так далее) по любым протоколам (API, Model Context Protocol — MCP, HTTPS, SQL и так далее);
использовать любые фронтенды (чатик на веб-портале, Тelegram и другие мессенджеры, наш агрегатор чатов и так далее).
Здесь у опытного читателя сразу может возникнуть вопрос: «А что, если я хочу не накликивать агента мышкой, а написать нормальный код для реализации всех функций?»
Без проблем! Подойдет любой скриптовый фреймворк, например LangChain, LangGraph или другой, который может работать с OpenAI-совместимым API нашей платформы.
Какой фреймворк выбрать — скриптовый или графический?
Преимущества скриптового — удобство для разработчика:
Быстрое написание кода в IDE (самостоятельно или с использованием LLM), без необходимости разбираться с тем, как соединять готовые блоки в UI.
Полный контроль выполнения: можно изменять или декорировать все функции, обеспечить любые интеграции с внешними инструментами для мониторинга, логирования, трассировки.
Вызов агента через любой протокол, включая кастомные вебхуки, регулярная отработка агента через планировщик.
Возможность интеграции с SDLC-процессом компании — для разработки ПО, его тестирования, доставки в продакшен и эксплуатацию.
Графический фреймворк подойдет аналитикам и citizen developers:
Можно быстро собрать пайплайн из готовых блоков мышкой, без написания кода.
Мы подготовили примеры агентов — с ними можно за пять минут собрать RAG, чат-бота для контакт-центра, сделать речевую аналитику, обработать документ и так далее.
Есть возможность быстро готовить прототипы агентов, удобно демонстрировать их руководству, не ожидая дни и недели, пока вам выделят разработчиков на простейшую задачку.
Нет необходимости выделять железо для размещения агента — из UI Nocode они сразу деплоятся в prod-среду и доступны через API.
Переиспользуемые модули
Важный момент: я выше писал «без написания кода», «no-code-интерфейс»... но вы, возможно, захотите сказать, что я немного слукавил. Чтобы аналитику при работе в UI не требовалось писать код для обеспечения работы нужных функций в агенте, кто-то другой должен заранее сделать переиспользуемый модуль.
Да, в составе нашего инструмента уже есть большой набор модулей, много примеров под разные задачи можно найти в интернете, плюс мы также дописываем новые модули для заказчиков, но в некоторых случаях (для специфичных вещей, например трансформации форматов данных или файлов, подключения к системам заказчика) нужно писать новые модули.
Это могут сделать разработчики на стороне заказчика или мы сами, например в формате привлечения по почасовой ставке. С дальнейшим развитием платформы мы ожидаем, что напишем модули под большинство популярных инструментов и заказчикам не надо будет писать новые под себя. Но, с другой стороны, заказчик никогда не ограничен в функциях и может сделать свой собственный модуль.
Мы часто слышим вопрос: «Окей, интерфейс удобный, а как для него дорабатывать компоненты, какие компетенции нужны?»
Раньше мы делали новые компоненты сами, но сейчас в дополнение планируем серию обучающих вебинаров по работе с интерфейсом, разработке агентов и переиспользуемых компонентов LangFlow. Вебинары облегчат для заказчиков вход в самостоятельный процесс написания компонентов и создания агентов. Пока мы не выложили записи — советуем посмотреть на внешние вебинары по LangFlow. Или немного подождать ?
API-интерфейс
Под капотом Nocode использует API-интерфейс для подключения к языковым моделям нашей платформы. Также API применяют, например:
при интеграции в свои продукты, где модуль предоставляет функцию обработки информации через ИИ;
в собственных агентах, использующих MWS GPT на бэкэнде.
Наш REST API совместим со стандартом OpenAI API — это принципиально важный выбор: любой разработчик, привыкший к SDK/библиотекам вроде openai-python, может использовать их напрямую без адаптаций. REST API дает возможность, например:
отправлять запросы на генерацию (chat/completions);
преобразовывать текст в векторную форму (embeddings) для целей RAG;
управлять выбором модели и параметрами генерации;
использовать любой язык, поддерживающий REST, — Python, JS, Java, Go и др.
За счет OpenAI-совместимости можно мигрировать из облачных решений с минимальными усилиями, просто сменив endpoint и API-ключ.
Наш API можно использовать как единую точку входа ко всем моделям, размещенным:
в нашем облаке;
в контуре заказчика (при выборе on-premises формата);
у зарубежных вендоров (все популярные поставщики моделей).
Также стоит сказать, что мы ориентируемся не только на разработчиков, но и на простых сотрудников предприятий, которые сейчас отправляют секретные документы в ChatGPT мечтают перейти на корпоративные инструменты для работы с языковыми моделями, поэтому мы предоставляем также удобный пользовательский интерфейс.
Чат UI
Аггрегатор чатов — это инструмент для пользователей, построенный на базе опенсорсного LibreСhat с нашими доработками. Он позволяет быстро начать работать с LLM в удобном интерфейсе: загружать, анализировать, сравнивать и модифицировать в них офисные файлы, генерировать, заполнять документы и создавать по ним шаблоны, делать переиспользуемые промпты и выполнять другие повседневные задачи.
В чате можно:
Выбирать модели и переключаться между любыми доступными LLM, в том числе в рамках одного диалога:
Загружать офисные документы:
Извлекать из загруженных картинки или скана текст или семантику по объектам и связям между ними:
В этом примере синтетические данные — договор сгенерирован моделью
Все настройки можно сохранять в пресеты — наборы параметров и промптов, которые удобно быстро переключать для разных сценариев:
Внутри МТС обычные сотрудники используют чат UI для решения ежедневных задач: работают с офисными документами — Word, Excel, PDF, PowerPoint, другими текстовыми файлами и изображениями, ищут ответы на общие вопросы и консультируются по различным темам.
Также отмечу, что чат UI можно интегрировать с Nocode, получив возможность доступа из единого интерфейса как к обычным моделям и своим документам, так и к общекорпоративным чат-ботам, работающим с чувствительными данными и в соответствии с внутренней политикой:
Итак, с интерфейсами разобрались, следующий этап — посмотреть на варианты интеграции LLM с окружением заказчика.
Как дообучить модель?
Нам очень часто задают этот вопрос, но, как оказывается в 99% случаев, заказчика интересует не собственно технический процесс дообучения, а просто «Как сделать так, чтобы мой чат-бот отвечал пользователям на основе контекста из моих корпоративных данных?»
Сейчас мы используем три подхода к этой задаче:
RAG — помещение данных компании в векторную БД и связь с ней через агента.
Fine-tuning — помещение данных компании в LoRA-адаптер, который подключается к модели (собственно, дообучение).
Realtime — доступ к данным в БД или хранилище, поисковой системе по файлам и статьям из базы знаний заказчика, URL или API в реальном времени, в момент получения запроса от пользователя.
RAG имеет смысл использовать, когда:
Приемлема задержка в несколько секунд до получения ответа пользователем — пока информация извлекается из векторной базы и генерируется сообщение пользователю.
Данные, с которыми должна работать модель, меняются часто, и нужно быстро добавить новый документ и обеспечить использование новой информации при ответах пользователю.
Есть возможность поддерживать выделенную инсталляцию сервера БД, например PostgreSQL+pgvector или ClickHouse — ее нужно будет позже масштабировать для обеспечения возможности работы с чат-ботом для всех ваших пользователей.
Конечно, мы рассматриваем и альтернативные варианты доступа к данным, например через графовую БД, но в общем случае это можно назвать альтернативой RAG.
Когда данные уже подходят для помещения в векторную БД или их несложно подготовить.
Finetuning имеет смысл использовать, когда:
Критична задержка на получение ответа от модели, и нужно обеспечить начало генерации меньше чем за секунду (например, при использовании с голосовыми роботами в телефонии).
Есть много свободного железа, которое занимается только дообучением (так как оно выполняется на отдельных GPU) или бюджет на него на стороне поставщика сервиса.
Технически возможно организовать сложную систему автоматизации, которая будет убирать GPU из пула инференса, добавлять в пул для дообучения, а после него возвращать эту GPU опять в пул для инференса. Для небольших предприятий это может быть оправданно, например, при выполнении такого процесса ночью, когда нагрузки на инференс нет. Но в общем случае такая оптимизация использования ресурсов оборудования создает большие риски, и на любом шаге автоматизация может сломаться, тогда возможно, что и дообучение не будет работать, и инференс на этих gpu тоже… Поэтому мы сейчас, например, для дообучения держим выделенные GPU.
Когда приемлемо производить дообучение не слишком часто. Так как дообучение может занимать много часов, в течение которых выделенные для этого видеокарты будут полностью загружены только им.
Realtime имеет смысл использовать, когда:
Нужны данные в реальном времени, например, когда чат-бот предоставляет информацию о рейсах из табло аэропорта или чат-бот магазина дает пользователю рекомендацию на основе данных из анкеты в его личном кабинете.
Данных ОЧЕНЬ много, и нет смысла их дублировать в дополнительной базе.
Также, по иронии, когда данных ОЧЕНЬ мало. Если у вас всего 1–2 документа или 1–2 URL и весь контент помещается в контекстное окно модели, то можно не заморачиваться с отдельной БД, а просто в процессе работы агента извлечь данные из этих доков/URLs и сразу передать их в модель.
Нет возможности или очень сложно получить полный доступ к хранилищу документов — например, если есть Sharepoint с файлами или специфическая поисковая система для СЭД и ее нужно использовать «как есть».
Для пользователя, задающего вопрос в чате, приемлема задержка на извлечение информации и ее обработку.
Здесь сразу возникает вопрос: «А что, если для моего чат-бота нужно получить все лучшее из этих методов (например гибкость и удобство), но избежать недостатков (задержка и лишняя инфраструктура)?»
Тогда мы бы порекомендовали проанализировать сценарий использования, понять, для каких запросов лучше всего подходит каждый из методов. В одном и том же чат-боте или агенте можно реализовать разную логику для разных запросов. Например, для упомянутого сценария с пользователем чат-бота аэропорта получать информацию можно разными путями:
о рейсах из табло через URL/API (Realtime);
о том, как что-то провезти в самолете из БД через RAG.
В следующей статье рассмотрим конкретно агентов, реализующих подобные подходы, stay tuned!
Форматы использования MWS GPT
Наша платформа предоставляется в нескольких вариантах, предпочтительный способ потребления зависит от требований по ИБ, имеющейся инфраструктуры и бюджета.
В облаке MWS
Вся инфраструктура уже развернута у нас, аттестована по ФЗ-152 и соответствует требованиям по хранению и обработке персональных данных. После активации учетной записи мы предоставляем заказчику доступ к UI-агрегатору чатов, OpenAI-совместимому API и визуальному конструктору LLM агентов (интерфейс Nocode).
Этот вариант подойдет, когда:
Нужно максимально быстро получить доступ к разным моделям или моделям разных типов и запустить проект или протестировать гипотезу с LLM.
Бюджет ограничен.
Команда разработки ИИ-агентов небольшая или ее нет совсем.
Полностью локально в контуре заказчика
В этом случае мы предоставляем инфраструктуру для больших промышленных нагрузок: серверы с Nvidia A100 на борту, объединенные в отказоустойчивый кластер и оптимизированные для работы с выбранными LLM-моделями, которые максимально тесно интегрируются в экосистему заказчика.
Количество серверов рассчитываем в зависимости от сценария использования, но обычно делаем расчет на сотни или тысячи одновременных пользователей в чат-ботах, ассистентах и других помощниках на базе LLM.
Этот вариант подойдет, когда:
Есть бюджет хотя бы на несколько серверов с Nvidia A100 на борту ?
Есть внутренние требования к ИБ, нужны интеграции с внутренними СЗИ (SSO, DLP, SIEM, МСЭ и так далее) и важно сделать так, чтобы данные не покидали сетевой периметр компании. Нужен полный контроль над системой и аналитику того, какие запросы пользователи отправляют в модели.
Гибридный формат
В этом случае инференс LLM (сами видеокарты и сервис, на котором запускаются модели) работает в облаке MWS, а вся управляющая обвязка и интерфейсы (UI, API, Nocode) развертываются локально в контуре у заказчика и подключаются к облаку при каждом запросе пользователя.
Этот вариант можно рассмотреть, когда:
Важно сохранять контроль над системой и запросами пользователей, но при этом не инвестировать сразу в дорогостоящую инфраструктуру (GPU).
Приемлемо отправлять в облако запросы пользователей и корпоративные данные.
Также стоит учитывать, что для разных сценариев могут быть предпочтительными разные варианты размещения — например, для одних задач облако, для других (самых конфиденциальных) только локальное размещение.
Планирование нагрузки и оборудования для размещения LLM локально в контуре заказчика
Если рассматривается on-premises, мы часто слышим вопрос: «А как понять, сколько железа нужно для чат-бота, который в нашем контуре работает?»
Рекомендации в этом разделе подходят для любых сценариев использования LLM, не только MWS GPT. Но они могут различаться для разных компаний в зависимости от их специфики и особенностей задач, поэтому мы обычно просим клиентов собрать некоторую информацию по сценарию использования и потом вместе рассчитываем нагрузку и объем нужного оборудования.
В общем, мы здесь даем не универсальную инструкцию, а описываем рекомендации и факторы, которые имеет смысл принимать в расчет.
Аналитика сценария использования и формата взаимодействия с LLM
-
Понять сценарии работы с LLM, например:
Пользователь обменивается с чат-ботом поддержки короткими вопросами-ответами.
Юрист проводит с помощью модели юридический анализ договора.
HR сравнивает резюме кандидата с имеющимися вакансиями.
Понять формат использования LLM: средний размер запроса к модели (объем токенов, который пользователь отправляет в модель), средний размер ответа от модели, частота и тип запросов (генерация текста, картинок, классификация и так далее).
Понять время, которое тратится на весь цикл для каждого вопроса-ответа, включая: набор и отправку текста в агента, обработку в софте агентом, передачу из агента в LLM, обработку в LLM, возврат результата, обработку его агентом, генерацию ответа пользователю, чтение и анализ ответа пользователем.
Понять общее количество пользователей и число одновременных пользователей системы.
Выбор модели, тестирование, оценка нагрузки:
Выбрать одну или несколько LLM определенного типа и размера и архитектуру агента, которые позволяют решить задачу, — например, llama-3.3-70b-instruct и RAG-агент.
Протестировать, какое качество для вашего сценария выдают дистиллированные модели и модели с квантизацией и оценить, допустимо ли использовать их для уменьшения количества GPU и объема VRAM при запуске моделей.
Сделать бенчмарк LLM и понять, сколько TPS (tokens per second) она выдает для ваших запросов на вашем GPU и с заданным количеством одновременных пользователей.
Оценить, сколько примерно пользователей ваш сервер (все GPU) сможет обслужить в «оптимистичном» сценарии. Например, если он выдает 400 output TPS, а пользователю в одном ответе выдается в среднем 200 токенов, то система сможет обслуживать двух пользователей в секунду. При цикле в один запрос в минуту (с учетом времени на набор, обработку в агенте и в LLM, получение и анализ результата, как выше описано), получается 120 пользователей в «идеальном» и очень усредненном сценарии.
Мы здесь намеренно упростили. Для вас этот расчет может не быть релевантным. Пожалуйста, не принимайте его как есть и проконсультируйтесь со своим провайдером LLM или с любимой моделью для более точного расчета для вашего сценария ?
Оценить, сколько пользователей выдержат все ваши серверы и видеокарты, занимающиеся инференсом LLM на данной модели, умножив данные по пользователям из предыдущего пункта на количество серверов.
Архитектурная проработка
Важно определить требования к задержке и требуемый uptime для агентов: это потребуется при планировании дополнительных GPU для обеспечения отказоустойчивой работы. Например, для прототипа может быть достаточно двух видеокарт, а для продакшена — минимум восемь; для аналитических запросов может быть приемлемо полминуты ожидания, а при работе в чате пользователь ожидает ответа через три секунды.
Спрогнозировать рост количества пользователей в следующие 6 и 12 месяцев.
Рассчитать вероятность скачков нагрузки в определенные часы и дни, сезонные и эпизодические всплески — например, после маркетинговых кампаний.
Оценить требования к масштабируемости: нужно ли обеспечить возможность автоматического масштабирования (в том числе в облако) или допустимо добавлять серверы с GPU по запросу. Понять, за какое время они должны добавляться с учетом требований бизнеса.
Оценить, какие еще другие модели могут понадобиться (для работы с картинками или голосом, например).
Определить бюджет на оборудование и понять, доступен ли он только через годовое планирование или возможны ежемесячные расходы.
-
По собранной информации рассчитать:
какое количество серверов и GPU минимально взять для пилота;
сколько оборудования нужно будет для обеспечения отказоустойчивой работы в проде;
как должен изменяться объем ресурсов в будущем с учетом органического роста;
как и когда будет обеспечиваться покупка серверов;
как они будут добавляться в пул инференса.
Также рекомендуем оценить требования к ИБ и конфиденциальности, хранению данных и другие функциональные и нефункциональные требования.
Выбрать вариант размещения: локально в контуре, в облаке (SaaS или аренда серверов с GPU для создания полностью изолированного окружения) или гибридный вариант.
Обычно планирование инфраструктуры — это довольно сложный процесс, в котором нужно учитывать и общие лучшие практики, и специфичные для компании требования и регламенты, поэтому мы рекомендуем рассматривать описанное здесь как пример, но адаптировать его под ваше окружение, в общем, YMMV).
Напоследок
C начала 2025 года мы уже провели сотни встреч с клиентами, выслушали описания тысяч задач и проблем в бизнесе, которые можно решить, используя LLM. А еще мы стояли на стендах МТС Web Services на конференциях True Tech Day и Saint HighLoad++, показывали готовых ИИ-агентов и применение их для бизнеса.
Вроде бы это немного: просто постояли на стенде, пообщались с посетителями конференции, показали демо своего продукта заказчику, послушали о его болях и потребностях, рассказали, как работают ИИ-агенты и как их применять для решения таких задач.
Но нам нравится думать, что таким образом мы помогаем коллегам и компаниям освоить ИИ-практики, получить представление о вариантах использования современных технологий для улучшения их процессов и развитию их бизнеса и массово способствуем росту ИИ-компетенций в нашем сообществе :)
Если хотите оценить применение платформы для решения задач вашего бизнеса, просто отправьте нам заявку на демо здесь.
Отвечу на ваши вопросы и комментарии! Пожалуйста, пишите.
P. S. Это был первый пост, посвященный MWS GPT. Что будет в следующем:
Покажу примеры агентов, которые создаются в Nocode, обсудим мультимодальный RAG, MCP, мультиагентные и мультишаговые схемы работы.
Опишу логику работы агентов и их интеграции с интерфейсами конечных пользователей через REST API и MCP.
Покажу пример процесса разработки LLM-агента от идеи до продакшена.