Источник — Александр Козлов: Корпоративный AI-агент в Норникеле

sources ai agent architecture local privacy security modified: 2026-09-26 06:09 · canonical

Александр Козлов — «Корпоративный AI-агент в Норникеле»

Иммутабельный raw-слой. Автоматические русские субтитры YouTube сохранены с минимальной очисткой повторов. Имена продуктов и термины могут быть искажены ASR; для выводов используйте подробный конспект. Связанный проектный контекст: агентская среда «Гелиос».

Описание автора

Спикер: Александр Козлов, Норникель. Доклад о пути от пилота на Open WebUI к масштабируемой внутренней платформе корпоративных AI-агентов.

Автоматическая расшифровка

00:00

Да. Всем привет. Меня зовут Козлов Александр. Я тех в компании Нурникель. Мы сейчас активно развиваем корпоративного агента. Вот платформу, можно сказать. И, собственно, хочу поделиться, как мы шли там от пилота и до более-менее сейчас работающей такой масштабируемой системы. А первое, с чего хочется начать, это в целом как бы ес если сейчас представить любую компанию, да, крупную корпорацию, одни и те же задачи, там в их проектном офисе документы, аналитика, транскрибация, sumary, там какие-то презентации и так далее. И всё это в целомто решается там текущими ассистентами, лэмками. Но когда мы говорим про большие корпорации, стоит учесть, что данные должны находиться в контуре. Чаще всего все сотрудники, они, э, скажем так, сидят под Бэмками, за которыми активно следят ибэшники и лишний раз там им не дают сделать какой-то шаг вправо, шаг влево. Поэтому

01:00

со всеми этими документами он сотрудниками отсюда не может пойти там в какой-нибудь чат GP или ещё куда-то, да, и выполнить свою рутинную работу. А это сильно замедляет, на самом деле. Вот. И как бы решение, соответственно, разворачивать что-то своё, ээ, ну или не своё, да, что-то искать на рынке, но, по крайней мере, в контуре компании. Вот мы сейчас Нурникели, в принципе, там столкнулись с такой же проблемы и решили, соответственно, разворачивать своё решение силами своей внутренней команды. А посмотрели на рынок вообще, что есть, поняли, что, да, понятное дело, провели исследование, там потестировали Open VBI, поняли, что, наверное, это сейчас самое лучшее решение, которое для нас подойдёт именно для пилотирования, по крайней мере. Вот. И развернули. Получилась примерно вот такая архитектура пилота нашего первого. Вот здесь, как видите, в принципе, Scell Lite Chrome DB в качестве inmemory э баз. То есть мы по максимуму использовали PWI, там сильно, [фыркает] скажем так, много вокруг него не

02:00

разворачивали какой-то инфраструктуры. Единственное, в Лэмку развернули, там наша доменная Metal GPT модель крутится. Quнry6, э, тоже Infрим отдельно. развернули свой отдельный сервисрапии, S3 подключили Dockling, ну и Viктория Step с графаной. Вот вот такую там простенькую архитектуру реализовали и там пошли пилотироваться. Э сразу как бы получили обратную связь. В целом стало понятно, что глобально пользователи довольны. То есть чат GPT подобный интерфейс, всё знакомо, всё понятно. Аа основные задачи выполняются прямо из коробки. Каких-то багов прям сильных в БКЕ или в UI мы не нашли. Были, конечно, разные, но достаточно легко решалось. И Рак, на самом деле, работает достаточно тоже хорошо. Он у них там простой, но для большинства задач пользователей справляется. То есть там они создавали новый BAS, грузили сотни документов, всё

03:00

в целом работало стабильно. А что не понравилось? Ну, во-первых, нет какой-то диалоговости агентности, потому что в целом там в Open OB залез, там вся агентность - это Wild Loop. Вот анализ данных тоже работает не очень хорошо именно для наших задач там, потому что пользователи хотят, например, выводить какие-то какую-то инфографику на в HTле, да, или у них эксельки там на 100 страниц, надо их замёрзть грамотно, какие-то там сводные таблицы построить. То есть вот это из коробки абсолютно не работает. При этом вот та архитектура, которую я показал, да, она там простая, но при этом сервер у нас достаточно мощный. У нас четыре А что было? У нас там достаточно много ВЦПУ памяти. И в целом система достаточно неповоротливая, медленная и даже там, э, 1.000 пользователей уже её сильно нагружают, перегружают. Если в моменте много параллельных запросов, то сильно тормозит.

04:00

Ну и архитектурно в целом - это такой монолит. Всё напихано в один проект большой. И и я и часть, и и фронт, и БК, и в целом не хочется дорабатывать, ээ потому что тяжело провести грань, да, между своими доработками команды и то, что есть из коробки с одной стороны, а с другой стороны тяжело этот фортом поддерживать, потому что обновления постоянные. Ну и при этом всём пользователи постоянно приходили, просили новых агентов, каких-то, какой-то новый функционал с новыми идеями, да, мы их слушали внимательно и понимали, что хочется какую-то расширяемую архитектуру грамотную выстроить. Вот. Но при этом уже понимали, что с точки зрения Бека и UI Open Ubi нас устраивает. Ну и, собственно, пришли, наверное, вот к такой архитектуре примерно. А-э, то есть оставили Open VBUI, как опять же UIB, то, что устраивало. Реализовали оркестратор - это отдельный сервис, который, то есть, ну, фактически это агент, э, который по MCP вызыбает других агентов, там легко расширяется, а для

05:00

Open WBUI он является просто как моделью, то есть мы его подключаем через админскую панель, там как в подключениях, да, базово и всё. И дальше Open VI видит это как обычная модель. Мы её там переименовали и всё. Для пользователя это просто чат. Он туда заходит, задаёт вопрос и всё по HTTP летит в оркестра. А далее он по MCP вызывает агентов. Агенты здесь у нас там постоянно это сейчас расширяется. Первое - это дата аналитиalтик, который э- которого мы, собственно, создали под себя. Это там рак с веб-поиском подключили агент создания презентации и много других типа HR-агентов и так далее. Сейчас на подходе. Под ними ещё, соответственно, развернулись бокс. Далее используем Light LLM. Удобный EI Gitway. В принципе, много уже про него сказано, что в продето факто стандарт сейчас. То есть единый каталог моделей. У нас что-то на влэмке до сих пор крутится, что-то мы используем от Яндекса, да, через private

06:00

and point. И с этой точки зрения вот это единый каталог с Open A Compatable интерфейсом, да, он нам сильно помогает. Также настрой там всякие ретраи, бюджеты, фолбокчейны. Если у нас в лмка падает, мы идём на Яндекс и настроили тир сплитроутинг. То есть у нас есть быстрые модели, есть такие средние, сложные. И, соответственно, агенты э где-то напрямую используют модели сразу, где-то они сами себе выбирают модель. То есть, если пользователь написал: "Привет, как дела?" Да, очевидно, там какой-нибудь Qн 235B нет смысла использовать для ответа на вопрос. Вот. Э-э, ну и инфраструктура Постгрес, Милвус тоже переехали, Трефик настроили там, чтобы всеми нашими, в том числе балансировать всех наших, э, все наши реплики. Вот и настроил Fuse. А, то есть в целом теперь как бы когда приходят пользователи, мы не дорабатываем Open Open VBI. Мы создаём новый сервис агентский, в

07:00

регистреторы его прокидываем и всё работает. [тяжело вздыхает] А единственное, что мы там в первую очередь настроили с точки зрения юая - это добавили четыре кастомных SSE чанка. То есть для того, чтобы агент, когда он запускает какой-то анализ, что-то делает там, думает, чтобы пользователь просто так не сидел, не ждал и не понимал там, да, [тяжело вздыхает] может агент завис или сломался. Вот сделали вот эти чанки. Вы можете видеть на экране, как это выглядит на примере нашего агента анализа данных. [вздыхает] А проркистратор, собственно, да, это такой наш мозг Open BI по HTTP его дёргает. И дальше это по факту Нграфагент с реактортектурой. У него есть обработка запроса от Openяя. Он использует мемо, то есть стандартные работа с памятью Open UBI нас не устроила. Там они просто берут по факту топ n последних сообщений. как-то хочется более осмысленно к контекстнженирингу подходить, поэтому

08:00

используем мемо для работы с историей в рамках сессии, то есть чата, и в рамках э истории пользовательской, то есть долгосрочной памяти по каждому пользователю. Это всё оркестратор тоже вычленяет. Далее дёргает MCP Toolzo, которая запускает workflow агентский. Вот. Ну и дальше записывает результат, смотрит, собственно, верифицирует, всё ли хорошо. А далее дата аналитик. Э, собственно, это вот агент, который нам заменил то, что было из коробки. Мы там послушали пользовательские сценарии, ээ поняли, что нам надо что-то такое более сложное. Вот. И, э, сейчас расскажу более подробно погрузимся именно вот в этого агента. [фыркает] А базово верхний уровень это выглядит вот так, да. То есть у нас есть, э, нода профилирования для понимания того, что вообще в Эксельке лежит, э, роутинг и

09:00

выбор файла, э, нодапланировщика, м, написание кода. А дальше, если всё, дальше verifire, если всё хорошо, то, э, там самаризируем, формируем эти все артефакты, V3 подкладываем, вот, ну, и всё, отправляем пользователю. Если нет, то, соответственно, уходим наретрай. А теперь там по самым интересным архитектурным решениям, нодам этого агента. По поводу филирования здесь всё достаточно просто. То есть мы, когда просто отдавали лэмке задачу, э, типа у тебя есть вот экселька, да, лежит там в папке, э, она начинала писать код и совершала ошибки, там какие-то поля выдумывала, а, не знаю, там код неправильно писала, потом пыталась всё это как-то исправить, начи начинались ритра, и порой она там сама себя загоняла в угол. Было достаточно сложно выпутаться. То есть много, опять же, тратили токенов, циклов и так далее. А простое решение. Написали

10:00

детерминированную ноду, то есть детерминированный Python scriptрипt, который анализирует эксельку, анализирует хедеры, Merch Headers, анализирует колонки на предмет там типов, пертили, ну и так далее. И фактически ЛМКА получает на вход э JON структуру с там пониманием того, какие поля, что лежит, какие типы и так далее. Вот, казалось бы, такой простой шаг, но вот нам сразу повысилсрей на первые итерации на 20 там 20-25% где-то. Далее, по поводу CGR. Тоже интересный паттерн, на самом деле. Многие про него сейчас забывают, ээ, думают, что рининг модели как бы сами сейчас должны справляться со всем. Но в реальности мы очень часто, где используем этот паттерн, там при выборе каком-то, ну, то есть вообще при принятии решений, там, например, при роутинге, при выборе файлов датааналитике, вот когда нужна какая-то структура определённая. Э, фактически мы задаём модель, то есть identic с полями, м, где мы описываем

11:00

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

12:00

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

13:00

понятно, планировщик там задачу разбил, внутри одного шага вот этого планирования можно ещё разбить на подзадаче. А особенно, если опять же файл очень сложный, большой и лэмке требуется там дополнительная информация какая-то. Здесь у неё тоже внутри вот этого цикла ещё один внутренний цикл, который, а, как бы объясняет, ну, который говорит модели, что у тебя вот как бы есть профиль, но там общайся с инбоксом плотно, задавай вопросы, анализируй, исследуй и ээ ставь флаг continue, да, вот этот тег. Соответственно, модель, например, понимает, что ей чего-то не хватает, она делает какой-то маленький шаг, там, который объясняет ей какую-то структуру, там с другой стороны посмотреть на данные, может быть, она обращается к санбоксу, SНБО возвращает и результат, и, соответственно, эта вся история континируется в пронт, ещё одна итерация. И вот такими небольшими шагами мы приходим, собственно, к результату в рамках каждого, э, шага нашего плана.

14:00

Вот тоже такая сильное архитектурное решение, которое нам помогло решать действительно сложные задачи и разбираться со сложными там форматами, экселиками пользователей. По поводу Sunbox. Ну, здесь как бы кратко я пробегусь. мы выбирали между докером и файркрекером. А фактически основно основное отличие - это в том, что в докере он докер использует корнел хаста, а факт он свой там в каждой виртуальной машине. Вот здесь это ключевое отличие. И если то есть мы все понимаем, что вNEL периодически находит уязвимости, через него можно попасть на хост и там наделать дел. А поэтому выбрали просто более безопасное решение. Вот у Фаерккера здесь как бы двойной такой двойная защита. Они использует NNEL гостевой вот для каждой БМИ. Ещё мы использовали Sandbox сначала, то есть мы создавали его под каждый запрос,

15:00

потом поняли, что архитектурная, наверное, не очень правильная. И сейчас у нас работает это следующим образом. Пользователь, например, приходит запросом там анализа какого-то файла, да, Sandbox менеджер проверяет, а если по текущей сессии уже ВМКА, то есть по чат ID, если ВМКА есть, то, соответственно, она используется дальше. Таким образом, экономим ресурсы на э поднятии новой ВМки, да, и в том числе у нас артефакты сохраняются, очень удобно с ними работать. И ну да, то есть есть экшнлу ещё, который следит там через какое-то время эту ВМКУ убивает. Вот мы пока ещё время, кстати, не выбрали, а экспериментируем тут между где-то там, да, 10 и 20 минутами. [тяжело вздыхает] Вот. И ещё из интересного это то, что у нас не просто голый питон, да, который позволяет там выполнять вот эти задачи датааналитика. Мы поняли, что задач очень много у пользователей разных. Надо какую-то гибкость дать. И здесь подошли к задаче. Так, то есть

16:00

каждая ВМК - это не просто питон, это ещё и полноценный Linux. У него есть куча инструментов типа, типа, PON Dogs, там liberoice, графис для графики диаграмм, пандек и другие инструменты, которые установлены. Вот устанавливается вот эту ВМКУ. [фыркает] Аа что это нам даёт? Мм, собственно, реализовали скилы. skill registry, то есть в оркестраторе есть ээ skill registry, который смотрит, соответственно, там все наши MD-файлы, их описание, наименование, и в моменте выбирает. А MD-файлы, соответственно, они уже там описывают, а то, как там решать определённую задачу, например, там сгенерировать doc или там как-то его переформатировать или там с данными что-то сделать, да? При этом есть корпоративные шаблоны, сразу передаются там как бы в ВМКУ и всегда, соответственно, если нужно создать какой-то шаблон, да, именно, а, как, скажем так, в рамках компании, то у нас

17:00

лежит всегда брендбук Нурникеля. Вот здесь это очень удобно. А, да, и понятное дело, что помимо скилов реализовали рядом с Инбоксом новые МCшки, всякие тулзы, которые, э, там позволяют, например, работать с Линуксом напрямую. это выполнять всякие баш сскрипты, да, ээ там те же самые Liber Office дёргать, да, то есть работать с инструментами, в принципе, с Linux машиной. Вот мо есть тулзы, которые позволяют читать директории, создавать файлы, ну, в общем, вот какой-то набор тулзов плюс скилы. И получилось такое мощное решение, которое позволяет пользователю э работать по факту там с Linux машиной напрямую. А, ну есть ещё, да, один skill creator - это метал, который позволяет создать для пользователя скил, но это пока так больше как игрушка, потому что здесь надо подумать, как, [фыркает] э, разделить, скажем так, это всё по папкам, чтобы у нас не было тысячи скилов, а то пользователи сейчас нанерят. Вот мы тут ещё экспериментируем,

18:00

да. Ну, здесь я говорил про то, что у нас, собственно, skill creator есть, да, который это метаскил, который позволяет создать новый скилл для пользователя. Вот тут не надо ничего пересобирать. То есть просто создаётся скил, MD файл кладётся в папку, и пользователь его сразу может использовать. Вот. А про HR-агентов здесь это, наверное, про развитие я рассказывал, что а есть и ражирование, да, задача большая инженерная. С другой стороны, развиваем продукт, ээ, там сейчас на подходе HR-агент, ну, и куча-куча других блоков приходят, м, просят разработать под них решение. >> Угу. Спасибо. Там в чате есть вопросы. Вот Павел спрашивает, сколько ээ карточек 4 Сколько 4H выдают токенов в секунду? А, по-моему, там, ну, короче, порядка у нас, во-первых, да, у нас 4 А1 там не только были модели на них, да, то есть у нас, а, э, были всякие имбединги на одной

19:00

модели, на на одной, точнее, видеокарте была Metal GPT развёрнута, на другой модели там Qu. А в целом мы прямо так сильно, если честно, не мерили, но, по-моему, один раз я вот смотрел, там что-то типа около 100 50 170, что-то такое было. Вот. >> То есть у нас, >> что это одна Гпуха там на вот эту одну модель была. >> О'кей, понятно. А возникают ли проблемы слен там утечки памяти, в частности, часто ли его приходится пребежать в расписании? >> Нет, мы как-то, ну, честно, вообще не было проблем. У нас есть проблемы там с доклингом, с другими сервисами. Сейчас Lightlm проблем не было. То есть, а, никаких утечек, то есть мы там специально следили, смотрели, у нас есть всякие утилизации, метрики по ЦПУ, по ГПУ, по Lightlm вообще не было проблем.

20:00

Угу. Ещё просит пояснить тезис перехода с классического рага на агентный. >> Ещё раз. А классического на агентный мы, ну вот мы пока не переходили, э потому что как раз-таки как бы всё устраивает, да. Здесь я, наверное, имею в виду, что это как бы как в перспективе возможно пользователям понадобится. То есть уже приходит просто с кейсами более сложными, где там тысячи документов. Возможно, нам понадобится и там какой-то агентский рак плюс, может, графовый рак, что-то такое, да? Это как прямо на перспективу. Пока что мы не переходили. То есть у нас, э, э, вот этот оркестратор, он использует rк Open UBI ходит. Вот. Ну, а в перспективе тезис там как бы, наверное, простой. Э, в целом, а, наивного рага не всегда бывает достаточно, да, бывают сложные данные, хочется, наверное, ну, какие-то дополнительные шаги, аэ, переписывания

21:00

запроса, да, может быть, выбора э какого-то кастомного там использовать поиск или нет. Ну, то есть там очень много как бы подходов, да, каких-то дополнительных нот, которые можно вставить и получить там хорошую прибавку по качеству. Вот. Ещё просят вернуть на слайд SLM. Там, наверное, какой-то вопрос будет. >> У меня отдельно пром нету. У меня вот есть это такой базовый про всё. >> Наверное, этот имелся в виду. Давайте можем подождать, будут ли вопросы по этому слайду. Ну вот ещё раз в чате спрашивают. Для безопасников уже получилось что-то реализовать? Я про экономическую и внутреннюю. >> А ещё раз вопрос. Не понял. >> А, ну я так полагаю, что какие-то кейсы для безопасников получилось сделать для

22:00

внутренней и для экономической безопасности? >> А, ну как бы здесь, э, я, наверное, в открытую про это не могу говорить, да, там про вопросы безопасности. Это всё же коммерческая тайна, но базово, да, то есть мы постоянно этим работаем. У нас есть команды ИБ, команда девопсов, которые постоянно там работают и, а, по безопасности, скажем так, всё реализует там в рамках наших правил и корпоративных. Вот. Ээ поэтому, если кратко, то да. >> Угу. Спасибо. Я тогда предлагаю Да, спасибо, Александр. Собственно, ты у нас сегодня был последним докладчиком. Так, сейчас последняя попытка в чате найти вопрос. А микров на винде работает? Спрашиваю? >> Честно не знаю. У нас везде линуксы эти [фыркает] убунты,

23:00

поэтому >> Угу. >> Не знаю, не не проверил. По-моему, я просто как-то пытался локально развернуть. Э, вроде на Маке точно вот не получилось. У меня там как разтаки, по-моему, была проблема, что я этот санбокс не мог развернуть. На винде не пробовал. Ну, >> наверное, можно просто в документации файкрекера посмотреть. У вас же, в общем-то, решение. Да, да, да, посмотрите, там документация хорошая. >> Ну всё, тогда предлагаю заканчивать. Спасибо всем, кто докладывал, всем, кто слушал, задавал вопросы. Всем пока. >> Всем пока. M.