Полезные агенты на платформе MWS GPT

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

Здесь разберу несколько примеров LLM-агентов. Начнем с простого RAG на Faiss, посмотрим на мультимодальный RAG, рассмотрим мультиагентные схемы, речевую аналитику, а на закуску базово затронем MCP. Надеюсь, этот пост поможет коллегам подступиться к теме создания LLM-агентов, оценить варианты взаимодействия с ними и не упустить важные нюансы.

Примеры агентов

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

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

RAG для умных ассистентов в чате

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

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

Созданный простой RAG-агент выглядит так:

Процесс работы можно описать так.

1. Верхняя часть пайплайна:

   1. Разработчик агента загружает в компоненты File пару файлов в текстовом формате (PDF, Word, HTML, Markdown и другие офисные файлы) и запускает эту часть пайплайна.

   2. Документы разбиваются на куски-чанки, преобразуются в векторное представление (embeddings) и помещаются в векторную базу данных (в примере — простой вариант с Faiss).

   3. В векторной базе хранятся отдельно чанки в текстовом виде и те же чанки в векторном виде. 

   Внимательный читатель может заметить, что Faiss — это не полноценная БД, а библиотека для индексации и поиска векторов. Совершенно верно: мы здесь показываем простой вариант создания пайплайна RAG без лишней инфраструктуры на старте. Он подойдет только для прототипов, и ниже мы рекомендуем в проде использовать, например, настоящую базу вроде PostgreSQL в связке с векторным плагином pgvector.

2. Нижняя часть пайплайна:

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

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

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

   4. Агент берет полученные чанки и отправляет в LLM вместе с промптом.

   5. LLM на основе полученной информации формирует ответ на вопрос пользователя.

Когда такой агент собран, нужно его внедрить в тот интерфейс (frontend), с которым привыкли работать пользователи. Это можно сделать, используя функцию автоматической публикации агента через REST API, которая предоставляется в нашем инструменте Nocode, и интегрировав фронтенд с этим API:

В ответ от Nocode API приходит json, который можно парсить:

Интерфейсом, куда встраивается такой агент, и с которым работают непосредственно пользователи, может быть:

1. Веб-пор��ал, где достаточно нажать кнопку вызова чата, чтобы пообщаться с ботом:

   

2. Бот в мессенджере:

   

3. Агент в нашем агрегаторе чатов (подробнее о нем было в прошлом посте в разделе «Чат-UI» ).

4. Окно взаимодействия с ботом в Битриксе, 1С или другом интерфейсе, который поддерживает интеграцию с внешними системами через REST API для обеспечения работы бота.

5. Агент в плагине для IDE вроде vscode или Cursor (например, Cline, Continue), который может работать с MCP-сервером. В этом случае интеграция c Nocode производится не через REST API, а через MCP SSE:

Этот пример c RAG мы предоставляем для ознакомления с работой в Nocode, но, очевидно, перед использованием в продуктиве его нужно адаптировать:

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

2. Заменить Faiss на продакшен векторную БД — например, PostgreSQL с расширением Pgvector.

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

4. Заменить в нижнем пайплайне прямого вызова LLM на Агент+LLM (пример ниже).

5. Добавить историю сообщений, чтобы бот понимал историю взаимодействия с пользователем (пример ниже).

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

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

Мультимодальный RAG с получением документов из URL и добавлением метаданных

В этом агенте устранены ключевые ограничения «простого» RAG из предыдущего примера:

• Есть готовая к промышленному использованию векторная база данных — Pgvector-расширение для PostgreSQL. 

• Агент может обрабатывать мультимодальный контент (файлы с текстом + сканами или картинками, через Vision модель, в данном случае qwen2.5-vl). 

• Можно запускать пайплайн в параллель с разными файлами, полученными из S3 на вход.

• Есть история диалога и возможность добавлять к каждому чанку/куску инфо из метаданных документа.

• Использован агент для взаимодействия с БД.

Как и в прошлом примере, для извлечения информации из БД используется отдельный пайплайн в том же flow:

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

Варианты интеграции агентов с фронтендами для пользователей я описал чуть раньше, поэтому здесь покажу просто интерфейс Playground в том же IDE-инструменте Nocode, в котором работа агента тестируется разработчиком flow:

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

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

Мультиагент

В этом примере демонстрируем реализацию паттерна LLM Supervisor, следуя которому можно сделать мультиагентную схему, где каждый агент занимается своей отдельной задачей. При этом с ростом количества агентов задержка с ответом пользователю почти не возрастает, так как оркестратор для ответа на конкретный вопрос вызывает только одного вспомогательного агента из доступных ему. Все вспомогательные агенты подключены к оркестратору как Tools/инструменты.

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

1. Flight Helper обращается к табло аэропорта для получения информации по рейсу исходя из предоставленной пользователем информации (номере рейса, городу назначения и так далее):

   

2. Web Crawler извлекает релевантную пользовательскому запросу информацию из поисковой системы аэропорта:

   

Для второго запроса также подойдет RAG — это снизит задержку в предоставлении ответа пользователю (по сравнению с обращением в реальном времени), а также уменьшит нагрузку на поисковик на веб-сайте (так как в этом случае мы только один раз извлечем все страницы из портала для помещения их в RAG БД).

Подобный оркестратор можно применить в любой системе, где нужно сделать что-то сложнее просто поиска по одной БД.

Насчет сценария применения для извлечения информации в реальном времени я писал в первой части.

Мультишаговый агент

Это агент, который после пользовательского запроса может выполнить последовательность действий:

1. Обратиться в векторную БД, извлечь из нее данные, а из них — релевантную запросу информацию.

2. Обратиться с полученной информацией в другую БД, в данном случае структурированную БД (в этом упрощенном примере — CSV-файл), извлечь оттуда релевантные данные.

3. Сформировать на базе полученных данных ответ для пользователя.

4. Если пользователь говорит, что информация ему не помогает, то отправить результат в сервисдеск через почту — для обработки оператором.

При необходимости могут быть и другие шаги, вызов других Tools- или MCP-серверов.

См. схему ниже, здесь у нас к основному агенту подключены: векторная БД (Faiss), структурированная БД (CSV) и модуль для отправки почты.

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

1. Запросить создание промпта у модели.

2. Предоставить пример данных из структурированной БД.

3. Предоставить пример ответа, который должна сгенерировать модель.

4. Проанализировать corner cases и описать для модели, что делать в каждом случае: если вернется пустой ответ из каждой БД, если запрос пользователя не по теме (например, классическое «напиши декоратор на Python»), в каких случаях переводить запрос на оператора и так далее.

Пример ответа от модели для этого агента (здесь в БД и в ответе синтетические данные):

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

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

Речевая аналитика контакт-центра

Здесь у нас агент, который на вход принимает аудиофайл и выполняет для него:

1. диаризацию: разделение по ролям участвующих в звонке, по голосу, для этого используется pyannote;

2. транскрибацию: перевод каждой реплики в текст (через whisper-large-v3-turbo), с пометкой, какой человек говорит. На выходе из этого пункта — текстовый диалог;

3. анализ диалога через qwen3-32b. В зависимости от промпта здесь можно делать аналитику: кто что говорил, какие решения приняты, какие проблемы обсуждались и так далее.

Файл может быть загружен пользователем в интерфейс или в Nocode через его API. Есть альтернативный вариант передачи файлов в Nocode — по ссылке, см. предыдущий пример с мультимодальным RAG.

Работа этого пайплайна выглядит так:

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

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

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

Агент MCP Streamable HTTP 

В данном примере демонстрируем работу Nocode с внешним сервером MCP Streamable HTTP.

Streamable HTTP — это самая актуальная на текущий момент версия протокола MCP для взаимодействия с удаленным сервером. Несколько забавно, что сейчас далеко не все поставщики ПО даже с предыдущей версией протокола MCP (HTTP SSE) сделали интеграцию, а уже нужно перестраиваться на новую версию протокола.

Этот протокол обеспечивает взаимодействие LLM с tools/инструментами в стандартизованном виде, без необходимости самостоятельного написания костылей уникального программного кода для каждой tool в каждой задаче.

В данном примере у нас очень простой агент, который реализует подключение с авторизацией к удаленному серверу Streamable HTTP. Также к агенту подключены несколько простых tools для демонстрации того, что они не конфликтуют с MCP.

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

Как выглядит взаимодействие с этим агентом в Playground:

В настоящий момент для большинства взаимодействий типа «агент на сервере стучится к tool» имеет смысл делать подключение через MCP Streamable HTTP, так как это:

• Снижает время разработки и сложность поддержки кода интеграции. MCP Streamable HTTP — это стандартизированный протокол, реализуется в агентах через SDK-библиотеку. 

• Позволяет строить микросервисную архитектуру. Этот подход можно назвать «tool как микросервис», так как здесь tools (которые здесь рассматриваются как транслятор протокола MCP в API сервиса), выносятся на разные хосты и живут отдельно от агента, то есть их можно отдельно масштабировать, разрабатывать и поддерживать разными командами.

• Уменьшает зависимости и упрощает развертывание благодаря отсутствию необходимости добавлять библиотеку конкретного MCP-инструмента на сервер, на котором работает агент, так как на сервере в этом случае достаточно только стандартной MCP-библиотеки. 

• Уменьшает ИБ-риски благодаря стандартизированному подходу к имплементации безопасности.

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

Нужно уточнить, что здесь мы имеем в виду именно варианты MCP-over-HTTP (Streamable или SSE), но не Stdio. Stdio подойдет, если допустимо ставить софт MCP-клиента рядом с MCP-хостом, то есть когда они оба находятся на одном сервере или десктопе (подробности архитектуры MCP можно посмотреть здесь). Например, если есть десктопный клиент вроде VScode и агентский плагин MWS GPT (работающий как MCP host) или Cursor, и только в случае, если MCP-клиент (библиотека для подключения к MCP-серверу) реализует требуемый уровень безопасности.

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

Другие сценарии, о которых нас часто спрашивают

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

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

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

• Бот для работы с СЭД. Принимает на вход скан документа, извлекает из него ключевые реквизиты и добавляет их как метаданные в СЭД через API.

• Бот-помощник аналитика. Через интеграцию с BI-инструментом видит графики и дашборды и при получении запроса направляет пользователя на нужный дашборд — с фильтрацией по запрошенным пользователем параметрам, без необходимости искать нужный график и накликивать модификаторы/фильтры в BI самостоятельно. Если конкретный BI-вендор предоставляет MCP-сервер, то можно также строить в BI новые графики и дашборды, отправляя запрос в MCP-сервер на естественном языке.

• Бот-аналитик базы данных. Предоставляет информацию из структурированной БД: строит запросы, например к PostgreSQL, смотрит структуру базы и таблиц и извлекает из них информацию для ответа на вопрос пользователя.

При желании можно реализовать LLM-агентов для любых других требований, используя созданные нами или присутствующие в опенсорс-версии Langflow-компоненты. Если текущей библиотеки компонентов в Nocode недостаточно для интеграции с информационными системами компании, разработчик заказчика может создавать новые (каждый компонент — это класс на Python).

Далее опишем подход к реализации агента.

Разработка LLM-агента: от идеи до продакшена

Вне зависимости от способа размещения модели (в облаке или on-premises) и варианта создания ИИ-агента (графический или скриптовый фреймворк), нужно учитывать, что это программный продукт и при его разработке желательно следовать следующим шагам для соответствия лучшим практикам и имеющемуся в компании процессу SDLC для ПО. 

Ниже опишем пошаговый пример (для вашей компании, конечно, возможны отличия).

Примечание! Некоторые пункты пересекаются с разделом «Планирование нагрузки» из прошлого материала, но здесь фокус не на расчете нагрузки для конкретно on-premises, а на планировании и разработке агента, в том числе в облаке.

1. Аналитическая фаза

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

2. Анализ данных и правовое обеспечение

Определить типы обрабатываемых данных (пользовательские сообщения, документы, персональные данные и другие) и понять, как правильно с ними работать с юридической точки зрения (какие данные должны быть в агенте/LLM только внутри своего контура, какие допустимо передавать в облако в РФ, какие допустимо передавать в зарубежные модели). При необходимости подготовьте юридические соглашения с партнерами о передаче и обработке данных, обеспечьте соответствие требованиям защиты персональных данных.

3. Техническое планирование

Собрать технические требования: 

• как быстро должен отвечать агент (какая допустимая задержка до первого токена и до получения полного ответа); 

• из каких систем и по какому интерфейсу он доступен (API, MCP);

•  какие системы и базы данных он должен использовать в процессе работы; 

• на какое количество пользователей и одновременных запросов будет масштабироваться; 

• какие ожидаемые показатели отказоустойчивости; 

• другие функциональные и нефункциональные требования.

4. Выбор языковой модели

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

Если есть ограничения на передачу чувствительных данных и есть требование на получение достаточно качественного ответа от модели, но бюджет не позволяет разместить требуемые для этого GPU в своем контуре, то можно рассмотреть облачные LLM-сервисы и запланировать реализацию системы деперсонализации данных перед отправкой в них (например, через regexp в скриптах или на LLM, работающих на небольших видеокартах в своем контуре).

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

5. Выбор технологического стека

Определить фреймворк для разработки агента (LangFlow, LangGraph, LangChain и другие) с учетом компетенций команды разработки и технических требований проекта.

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

6. Архитектурное проектирование

Спроектировать внутреннюю архитектуру агента, определив для него необходимые компоненты, например:

• Выбрать способ подключения к моделям — просто вызов модели с промптом или применение умного «агентского» модуля для доступа к моделям с использованием tools.

• Запланировать иерархию агентов, например: единственный агент, или мультиагентные схемы с последовательным вызовов нескольких агентов, или использование одного агента как оркестратора с помощниками-сабагентами в виде tools.

• Запланировать, будет ли логика работы реализовываться в единственном агенте, или будет разбита на несколько агентов, исходя из сложности логики и требований к «детерминистичности» (повторяемости) ответов агентов.

• Использовать RAG схему с векторной БД для работы в контексте корпоративных документов, для создания чат-ботов и ассистентов.

• Интеграции с базами данных и API.

• Модули преобразования форматов файлов, протоколов (например, MCP -> API) и данных (например, для деперсонализации).

• Модуль для ограничения доступа к данным согласно ролевой модели (RBAC).

• Выбрать варианты оценки качества работы агента, например: получение от пользователей Like/Dislike в чате, автоматическое тестирование, избирательный контроль оператором.

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

7. Разработка

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

Если выбран скриптовый фреймворк типа LangGraph, то пишется код агента, желательно в соответствии с лучшими практиками, тестами, документацией и последующими Peers Review и ИБ проверками.

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

8. Юридическая проработка

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

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

9. Тестирование

Все варианты запросов пользователей нужно тестировать, желательно в автоматическом режиме (LLM evaluation), чтобы потом при необходимости изменения п��омпта просто перезапустить тест, без ручных действий вроде отправки всех вариантов сообщений, ожидания ответа и валидации. 

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

10. Системная интеграция

Сделать интеграции агента с существующими системами: пользовательскими интерфейсами, базами данных, внешними сервисами и API. Агент, который разрабатывается в нашем Nocode, сразу доступен для использования через REST API и MCP. Для скриптовых фреймворков типа LangGraph нужно дописать код для публикации его через FastAPI.

11. Безопасность и контроль доступа

Настроить RBAC (ролевую модель безопасности) для обеспечения доступа привилегированных пользователей к соответствующим функциям агента и данным, в том числе к векторной базе (например, через RBAC или фильтр по метаданным, если в базе есть поле вроде «список отделов, которым доступна информация», или через фильтрацию после выборки из базы).

Важно! RBAC нельзя реализовывать в промпте, так как всегда есть риск Prompt Injection! Ролевую модель нужно реализовывать в коде агента, вне контекста промпта — например, через проверку JWT-токена, с которым пользователь пришел в агента.

Также рекомендую обеспечить возможность аудита сотрудниками ИБ через интеграцию с SIEM или DLP (при наличии).

12. LLMOps

Настроить автоматизацию развертывания агента с использованием практик LLMOps: CI/CD-пайплайны или Kubernetes operator, мониторинг доступности и производительности агента, версионирование, автоматическое или ручное масштабирование.

13. Развертывание в продуктивной среде

Сделать финальные шаги:

• Финализировать документацию.

• Развернуть агента в продуктивной среде.

• Провести приемочное тестирование с реальными пользователями и данными.

• Получить разрешение от ИБ.

• Официально вывести агента в промышленную эксплуатацию в соответствии с внутренними политиками компании.

• С чувством выполненного долга уйти в отпуск :)

Заключение

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

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

Если вас интересует создание ИИ-агентов в Nocode формате — можете связаться с нами здесь или написать комментарий. 

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

P. S. Это вторая часть моего цикла про MWS GPT. В прошлом материале «Как работает наша LLM-платформа MWS GPT» можно почитать о ее возможностях, способах использования, о выборе способа подключения корпоративных данных к LLM, планировании размещения моделей в локальном контуре.

P. P. S. В следующем материале планируем описать более продвинутые агенты, которые запрашивали крупные заказчики: 

• деперсонализация с обратимым избирательным шифрованием запроса пользователя на стороне заказчика перед передачей запроса в LLM в облаке; 

• использование S3 для загрузки большого количества документов в пайплайн;

• использование S3 для выгрузки сгенерированных в пайплайне файлов для удобного доступа пользователя через браузер; 

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

Следите за обновлениями!