Привет, Хабр! В прошлом материале я рассказал о возможностях платформы MWS GPT, сценариях ее использования, интерфейсах и инструментах, через которые с ней можно взаимодействовать.
Здесь разберу несколько примеров LLM-агентов. Начнем с простого RAG на Faiss, посмотрим на мультимодальный RAG, рассмотрим мультиагентные схемы, речевую аналитику, а на закуску базово затронем MCP. Надеюсь, этот пост поможет коллегам подступиться к теме создания LLM-агентов, оценить варианты взаимодействия с ними и не упустить важные нюансы.
Содержание
Примеры агентов
Давайте посмотрим на типичные сценарии, о которых нас спрашивают чаще всего, и которые реализуются в нашем Nocode путем сбора в графическом модульном виде ИИ-агентов из визуальных «кирпичиков» вместо написания кода.
Примеры ниже могут отличаться для задач вашей компании и требовать адаптации или доработки в соответствии с вашими потребностями.
RAG для умных ассистентов в чате
RAG-агенты могут применяться в чат-ботах, они способны отвечать на запросы пользователей в контексте корпоративной информации. Сначала мы добавляем документы в специализированную векторную базу данных, а при получении запроса от пользователя извлекаем из нее релевантные фрагменты информации, и на их основе LLM генерирует максимально релевантный ответ.
Таким образом, сотрудник компании тратит на поиск нужной информации в большом объеме корпоративных документов не полчаса, а полминуты, включая чтение ответа от бота.
Созданный простой RAG-агент выглядит так:
Процесс работы можно описать так.
Верхняя часть пайплайна:
Разработчик агента загружает в компоненты File пару файлов в текстовом формате (PDF, Word, HTML, Markdown и другие офисные файлы) и запускает эту часть пайплайна.
Документы разбиваются на куски-чанки, преобразуются в векторное представление (embeddings) и помещаются в векторную базу данных (в примере — простой вариант с Faiss).
В векторной базе хранятся отдельно чанки в текстовом виде и те же чанки в векторном виде.
Внимательный читатель может заметить, что Faiss — это не полноценная БД, а библиотека для индексации и поиска векторов. Совершенно верно: мы здесь показываем простой вариант создания пайплайна RAG без лишней инфраструктуры на старте. Он подойдет только для прототипов, и ниже мы рекомендуем в проде использовать, например, настоящую базу вроде PostgreSQL в связке с векторным плагином pgvector.
Нижняя часть пайплайна:
Когда в агента попадает вопрос от пользователя, данный агент использует библиотеку из langchain, чтобы перевести запрос пользователя в векторную форму.
Далее запрос в векторной форме передается в векторную базу, и век��орная форма запроса сравнивается с векторной формой присутствующих в базе чанков. Поиск в базе здесь осуществляется не по ключевым словам, а по смыслу, семантическому соответствию, соответствию векторов в запросе пользователя векторам в БД.
Для релевантных чанков, найденных таким образом, извлекается их текстовое представление и возвращается в агента.
Агент берет полученные чанки и отправляет в LLM вместе с промптом.
LLM на основе полученной информации формирует ответ на вопрос пользователя.
Когда такой агент собран, нужно его внедрить в тот интерфейс (frontend), с которым привыкли работать пользователи. Это можно сделать, используя функцию автоматической публикации агента через REST API, которая предоставляется в нашем инструменте Nocode, и интегрировав фронтенд с этим API:
В ответ от Nocode API приходит json, который можно парсить:
Интерфейсом, куда встраивается такой агент, и с которым работают непосредственно пользователи, может быть:
Веб-пор��ал, где достаточно нажать кнопку вызова чата, чтобы пообщаться с ботом:
Бот в мессенджере:
Агент в нашем агрегаторе чатов (подробнее о нем было в прошлом посте в разделе «Чат-UI» ).
Окно взаимодействия с ботом в Битриксе, 1С или другом интерфейсе, который поддерживает интеграцию с внешними системами через REST API для обеспечения работы бота.
Агент в плагине для IDE вроде vscode или Cursor (например, Cline, Continue), который может работать с MCP-сервером. В этом случае интеграция c Nocode производится не через REST API, а через MCP SSE:
Этот пример c RAG мы предоставляем для ознакомления с работой в Nocode, но, очевидно, перед использованием в продуктиве его нужно адаптировать:
Заменить два компонента, которые используются для загрузки файла, на один новый компонент, считывающий все файлы из папки на сервере или из S3, в рекурсивном многопоточном режиме, обеспечивающем возможность обработки большого количества файлов.
Заменить Faiss на продакшен векторную БД — например, PostgreSQL с расширением Pgvector.
Применить ролевую модель к агенту, чтобы обеспечить его работу только для пользователей из выбранных групп AD и просмотр ими только определенных данных из векторной базы.
Заменить в нижнем пайплайне прямого вызова LLM на Агент+LLM (пример ниже).
Добавить историю сообщений, чтобы бот понимал историю взаимодействия с пользователем (пример ниже).
Для ускорения и улучшения качества работы с векторной БД можно также использовать другие специфичные для языковых моделей и общие техники оптимизации: индексацию, реранкинг, фильтрацию данных, оптимизацию промптов, расширение пользовательского запроса через LLM, настройку ролевой модели в БД, кластеризацию БД и другие подходы.
Наш заказчик может разрабатывать такие пайплайны или самостоятельно, или с нашей помощью, используя имеющиеся примеры, наработки, и опыт инженеров команды MWS GPT.
Мультимодальный RAG с получением документов из URL и добавлением метаданных
В этом агенте устранены ключевые ограничения «простого» RAG из предыдущего примера:
Есть готовая к промышленному использованию векторная база данных — Pgvector-расширение для PostgreSQL.
Агент может обрабатывать мультимодальный контент (файлы с текстом + сканами или картинками, через Vision модель, в данном случае qwen2.5-vl).
Можно запускать пайплайн в параллель с разными файлами, полученными из S3 на вход.
Есть история диалога и возможность добавлять к каждому чанку/куску инфо из метаданных документа.
Использован агент для взаимодействия с БД.
Как и в прошлом примере, для извлечения информации из БД используется отдельный пайплайн в том же flow:
Здесь видно, что по сравнению с предыдущим вариантом схема упрощена для визуального восприятия и несколько более универсальна за счет использования агента, который потенциально кроме обращения к векторной БД может выполнять и другие функции (об этом подробней расскажу ниже).
Варианты интеграции агентов с фронтендами для пользователей я описал чуть раньше, поэтому здесь покажу просто интерфейс Playground в том же IDE-инструменте Nocode, в котором работа агента тестируется разработчиком flow:
Сценарий применения — как и в прошлом примере: работа ассистентов в чат-ботах, но с возможностью поиска по информации, содержащейся не только в тексте, но и в картинках, а также предоставление ссылки на исходный документ, чтобы можно было из окна фронтенда по клику перейти в первоисточник и там увидеть все исходные формулировки.
Этот агент подойдет для сценариев, когда у заказчика есть множество документов, поиск по которым вручную отнимает слишком много времени, и нужно не просто быстро находить информацию, но и иметь возможность быстро найти первоисточник.
Мультиагент
В этом примере демонстрируем реализацию паттерна LLM Supervisor, следуя которому можно сделать мультиагентную схему, где каждый агент занимается своей отдельной задачей. При этом с ростом количества агентов задержка с ответом пользователю почти не возрастает, так как оркестратор для ответа на конкретный вопрос вызывает только одного вспомогательного агента из доступных ему. Все вспомогательные агенты подключены к оркестратору как Tools/инструменты.
Также здесь реализована возможность доступа к данным компании в реальном времени. Каждый вспомогательный агент выполняет свою функцию:
Flight Helper обращ��ется к табло аэропорта для получения информации по рейсу исходя из предоставленной пользователем информации (номере рейса, городу назначения и так далее):
Web Crawler извлекает релевантную пользовательскому запросу информацию из поисковой системы аэропорта:
Для второго запроса также подойдет RAG — это снизит задержку в предоставлении ответа пользователю (по сравнению с обращением в реальном времени), а также уменьшит нагрузку на поисковик на веб-сайте (так как в этом случае мы только один раз извлечем все страницы из портала для помещения их в RAG БД).
Подобный оркестратор можно применить в любой системе, где нужно сделать что-то сложнее просто поиска по одной БД.
Насчет сценария применения для извлечения информации в реальном времени я писал в первой части.
Мультишаговый агент
Это агент, который после пользовательского запроса может выполнить последовательность действий:
Обратиться в векторную БД, извлечь из нее данные, а из них — релевантную запросу информацию.
Обратиться с полученной информацией в другую БД, в данном случае структурированную БД (в этом упрощенном примере — CSV-файл), извлечь оттуда релевантные данные.
Сформировать на базе полученных данных ответ для пользователя.
Если ��ользователь говорит, что информация ему не помогает, то отправить результат в сервисдеск через почту — для обработки оператором.
При необходимости могут быть и другие шаги, вызов других Tools- или MCP-серверов.
См. схему ниже, здесь у нас к основному агенту подключены: векторная БД (Faiss), структурированная БД (CSV) и модуль для отправки почты.
Промт здесь для каждого сценария будет уникальным, поэтому рекомендуем при необходимости реализовать его самостоятельно:
Запросить создание промпта у модели.
Предоставить пример данных из структурированной БД.
Предоставить пример ответа, который должна сгенерировать модель.
Проанализировать corner cases и описать для модели, что делать в каждом случае: если вернется пустой ответ из каждой БД, если запрос пользователя не по теме (например, классическое «напиши декоратор на Python»), в каких случаях переводить запрос на оператора и так далее.
Пример ответа от модели для этого агента (здесь в БД и в ответе синтетические данные):
Такой агент может заменить бизнес-логику, реализованную в программном коде, на бизнес-логику, реализованную в промпте. Такая замена позволяет поддерживать пайплайн силами аналитика, который изменяет промпт, а не разработчика, который должен постоянно править код скрипта.
Очевидно, это может быть применимо в ряде случаев и НЕприменимо в других. Советуем пообщаться с вашим разработчиком агентов, чтобы проанализировать сложность внедрения и отдельно оценить преимущества от перехода на схему, где логика работы может быть изменена аналитиком без необходимости привлечения разработчиков.
Речевая аналитика контакт-центра
Здесь у нас агент, который на вход принимает аудиофайл и выполняет для него:
диаризацию: разделение по ролям участвующих в звонке, по голосу, для этого используется pyannote;
транскрибацию: перевод каждой реплики в текст (через whisper-large-v3-turbo), с пометкой, какой человек говорит. На выходе из этого пункта — текстовый диалог;
анализ диалога через 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 в агентах для обеспечения доступа использующих пайплайн пользователей только к ограниченному набору данных.
Следите за обновлениями!
