Transcription
Начнём нашу встречу. И мы очень рады то, что вы сегодня к нам пришли и также рады ребятам, которые к нам подключились онлайн.
А сегодня для нас выступит Евгений Захарин, а тимлит команды МЛплатформы и расскажет, как LLM-платформа помогает внедрять искусственный интеллект, бизнес-процессы. И по традиции у нас в конце за лучший вопрос мы вручаем подарки от нашего сообщества. И также бы хотелось поблагодарить спонсоров. Это с Мортовия Headen Hands и также агентство инновационного развития республики Мортовия. И тогда передам Евгению слово, и в конце уже сможете задать вопросы. Спасибо.
Всем привет. А меня зовут Евгений. Спасибо за представление. Ещё немножечко расскажу о себе. А почему я вообще решил рассказать про это? А я занимаюсь ML и LL OpsМ уже последние, наверное, 5 лет. В компании Цан я этим занимаюсь и развиваю платформу 4 года. До этого у меня большой опыт в разработке бэкэнда. Я пишу, писал на Пайthнем на G, а немножко на джаваскрипте. Вот. А до этого ещё у меня порядка там 10 лет опыта в системном администрировании и в Divпсе. Вот. Эээ, поэтому мне очень интересны проекты и задачи на стыки трёх областей: DevOps, и разработка. И вот, в частности, AL-платформа, LM платформа, как её часть, мм, а часть отвечает моим потребностям и хочу этим поделиться.
А, собственно, давайте немножечко разомнёмся, познакомимся, кто уже для личной какой-то продуктивности использует generation AI, какие-то лмки, да, то есть какие-то сервисы, ну, типа там, не знаю, Perplexity, Chat GPT, да, уже в своей работе кто-то, может быть, кто использует, ээ, да, вот в работе, например, разработка, курсор, Pilot, да, Отлично. Так, а кто в принципе как-то связан с эмэйлем, пробовал обучать какие-то классические-модельки? Ага. Так, отлично. А кто в своей работе или практике, ну, я не знаю, использует а-тестирование и знаком вообще с этой концепцией? Так, хорошо. Значит, в принципе, можно немножечко попробовать зайти поглубже.
И если это, значит, с чем я в своей работе столкнулся, когда мы говорим про AI, да, то есть там генеation, про нейронки, сразу у людей сейчас складывается ощущение, что вот так выглядит типовой проект, да? То есть, что нам нужно? Так, придумаем какую-то задачу, например, нам нужно корпоративный поиск там по базе знаний. Что берём? самую крутую модельку, да, там сейчас это будет условно там GPT5 Pro, да, там или O3 Pro. Берём базу знаний, всё туда запихиваем. Желательно, чтобы она была векторная, всё без разбора туда запихали. Добавили промт, отвечай там, ты представь, что ты эксперт, да? То есть отвечай лаконично и кратко. И всё, собственно, профит, наше классное LLM, не знаю, AI приложение ассистент готов.
А, к сожалению, это всё отчасти и правил, да? То есть, чтобы сделать PC какое-то, да, то есть первую версию продукт, проверить вот вообще гипотезу, насколько она приносит пользу вообще, насколько она работает. В принципе, этого достаточно. Проблема в том, что после дальше вот вы при таком подходе никуда не двинетесь, да? То есть, как только вы это решение зарелизите, я не знаю, там на пользователей, на продакшн выкатите, а, и завтра Open меняет модельку, например, с GPT4O на GPT5, у вас может развалиться вообще всё. Ваше решение может перестать работать. Вы в промте решили поменять э не знаю, одно слово добавили, качество качество вашего решения упало там, я не знаю, на 30%. Вы не понимаете, что что произошло, да? Там вы срочно пытаетесь откатите решение и боитесь этот менять промт, тобы в дальнейшем желательно вообще его лучше не трогать и не дышать на нём. Вот. Аэ другой пример. А пользователи говорят: "Ваше решение работает не очень хорошо". Да? То есть и у вас нет потенциала для улучшения. То есть что хорошо? Как будет, например, ваш AI ассистент отвечать лучше бизнесу? У вас нет никаких критериев определения качества, насколько, э, например, там в примере с тем же самым рагом, да, то есть насколько релевантен ответ у ассистента. То есть вы в принципе подошли не совсем, а, так сказать, по науке к данному проекту, а вот все решения с внедрением проектов или AI всё-таки лучше начинать по классическому workкфлоу, да, где сначала ставятся, формулируется задача, определяются метрики, на основе которых мы будем дальше развивать э решение. То есть и с помощью мелких итераций, то есть гипотез, что А теперь давайте мы предполагаем, что вот, э, данные LLM-модель, например, не соответствует нам по качеству, да, то есть давайте возьмём более крупную, да, то есть и тогда она повысит качество. Мы умеем измерять качество, да, то есть у нас есть какие-то для этого метрики и подходы уже до того, как мы приступили к этому процессу.
То есть, и вот на текущий момент, что хотелось бы донести, что здоровый процесс выглядит примерно так, что сначала нужно подготовить данные как минимум. Что является подготовкой данных? Это собрать golden data set какой-то. То есть это желательный набор юзкейсов. Допустим, если это ассистент, то какие вопросы предположительно будут задаваться данному агенту или ассистенту? А и какие предположительно правильные ответы должны быть? А потом нам как-то нужно вот эти предположительно правильные ответы и фактически сверять, то есть считать какую-то метрику качества по ним. Хорошо, более-менее определись с этим. Вот, к слову сказать, в моей практике 90% запросов отваливается уже вот на этом этапе. То есть где говоришь, там команда приходит с классной идеей, давайте сделаем вот тут такой классный проект, а просишь их, приходите, пожалуйста, с Golden датасетом хотя бы из 200 каких-то примеров. Всё, ребята больше, скорее всего, не возвращаются. Отлично. Прошли первый этап. Пытаемся вообще понять его целесообразность и реализуемость. Не все кейсы, к сожалению, а на текущий момент хорошо решаются большими языковыми моделями, да, и наша задача как можно быстрее понять, оно вообще решается с помощью каких-то фронтир моделей самых топовых, самых дорогих. Мы их берём, о, примерно понимаем, что, да, то есть прогнали, посчитали метрику качества. О, хорошо. Но видим, что экономика проекта тогда не сходится. У меня в практике был пример, а давайте с помощью Generation AI какой-то там современной GPT5 будем, например, улучшать фотографии. Да, отлично. То есть современные LLM мультимодальные с этим прекрасно справляются. Но по экономике там, если посмотреть, что на одну картинку - это 20 коп. А в масштабах цан это, ну, это миллионы рублей в месяц фактически получается. То есть, да, классное решение, но с точки зрения затрат, да, то есть и стоимости, оно совершенно нереализуемо. То есть вы прошли стадию про Concept, лмка справляется с задачей, но она делает это настолько дорого, что, в принципе, вам надо искать какие-то другие способы её решения. Возможно, с помощью классического. Можно водички.
Значит, дальше происходит как раз этап оценки, её качество. Если звёзды сошлись, моделька отвечает с достаточным уром качества и решает хорошо вашу задачу. Ну, например, есть потенциал для улучшения по стоимости, да? И мы, например, ищем какие-то более дешёвые модели. Взяли 4 О, а давайте попробуем прогоним её на там на мини-версию. Она в несколько раз дешевле. А плюс тоже у более легковесных моделей меньше, то есть она отвечает просто банально быстрее. И с помощью вот таких вот мелких итераций, улучшений, то есть мы выдвигаем гипотезу, что будет, если там мы возьмём более легковесную модельку, да? Проверили, подтвердили, о, качество осталось, то есть стали меньше тратить. Э попробуем ещё сделать подход. А как мы ещё можем улучшить, да? То есть и вот с на этапе 2 и три мы можем проводить очень, ну, не знаю, десятки, сотни, а, и мелких итераций по улучшению нашего AI решения. Ну и в конце концов, когда всё, мы закончили вот этот этап, а, м, изучения ресерча и сравнения вариантов, да, выбираем уже какой-то функциональный вариант, который поедет в prodдакшн. То есть здесь мы уже выбираем, возможно, self host от это решение. мы выберем, да, там в связи там с какими-то вопросами безопасности. Если мы вм хотим обрабатывать, я не знаю, персональные данные и хотим избежать трансграничной какой-то передачи данных или там такая жёсткая коммерческая тайна, что я не знаю, то есть её за пределы компании в принципе нельзя вывозить. Ну, не знаю, там, допустим, это может быть, ну, не знаю, суммаризация, транскрибация записей там встреч, там си-левела, да, то есть, ну, там директоров, где они обсуждают какие-то стратегические вопросы и там вырабатывают какие-то решения. Ну, то есть, ну, явно не хочется эту информацию никуда вообще отдавать. Это просто как пример, да, почему иногда точно нужно selfhostд.
И вот мы чуть-чуть начали с проблематики и теперь перейдём к каким-то базовым вещам. Ну, LM - это большая языковая модель. Думаю, здесь уже термин всем знаком. А также появился новый термин относительно недавно. Это OBS, который, ну, сейчас считается разделом опса, который, ну, про управление жизненным циклом больших языковых моделей, а он достаточно, с одной стороны, классический для, с другой стороны, имеет много особенностей, потому что это требует большого количества вычислительных ресурсов для обучения, для инфренса моделей. Вот большое количество данных нужно собрать для как минимум для обучения её с нуля. и, ну, тоже значительные объёмы данных для дообучения. Ну, и типовые процессы LНM OPS - это развёртывание модели, управление данными до обучения, ключевый момент мониторинг качества, да, то есть и обезопечение безопасности. Вот, то есть в примере выше, где я обозначил, что как начинается типовой проект, давайте сделаем нашего ассистента, например, для корпоративный поиск по базе знаний, да, умный поиск, а фактически без того же самого мониторинга качества, да, и сбора каких-то мониторинг как технических метрик, там, не знаю, время ответа модели, то есть так и каких-то бизнесовых, насколько там ответа релевантен, насколько пользователь много задаёт вопросов и продолжает там уточнять какие-то моменты, насколько он возвращается в чат и пользуется им снова. Вот все вот эти вещи обязательно обязательно для сбора и анализа. Если вы этого не делаете, вы в принципе не можете развивать данные проекты в будущем. То есть действуйте вслепую. Ну то есть это не какой-то такой не современный подход.
И тут, чтобы всё это обеспечить, помогает, ну, какое-то платформенное решение. В данном случае это мплатформа, когда я подавал заявку на этот доклад, в принципе, этот термин имел смысл. Сейчас уже настолько всё изменилось, буквально за там 2 месяца, что правильно называть всё-таки та такой класс систем, не платформа, а AI платформа, потому что она включает в себя гораздо больше блоков. Я об этом чуть-чуть расскажу. Что сейчас в современном мире понимается вот под AI тире lm платформы, да? Как минимум это программно-аппаратный комплекс, да? То есть он может быть гибридный, то есть часть инфраструктуры может быть у вас, часть в облаке, то есть здесь нужно просто разумно балансировать из того, что у вас есть по железу, насколько у вас богатая компания. Вот и набор инструментов, которые ускоряют разработку там, я не знаю, до обучения моделей, внедрение этих моделей в бизнес-процесс, какие-то интеграции с бизнесом. Вот. Ну и помогает, основная цель LM платформ - это справиться с проблемой внедрения в бизнес. То есть самая частая проблема с внедрением проектов - это, во-первых, трудно посчитать рой, ну, то есть возврат инвестиций. И зачастую всей проекты, которые я видел за небольшим исключением, ну, это прыжок веры. То есть экономика у них плохо считается или плохо сходится. Просто люди верят, что в эту сторону нужно бежать, что, не знаю, нужно делать корпоративный EАСНТ там и так далее там или автоматизировать саппорт, э, я не знаю, какие-то автоответы в первой линии поддержки. Так вот, есть очень большой класс проектов, которые, в принципе, ну, очень плохо считаются с точки зрения затраты денег. Вот. И есть две самые главные области, где точно уже подтверждён эффект. Первый - это как раз автоматизация, саппорты, какие-то автоответы и где, не знаю, и понимает, что требуется помощь специалиста и где-то там он на каком-то этапе подключается к процессу, да, то есть в фоновом режиме, а там делает нужные действия и обратно передаёт управление там, не знаю, лмки. И вторая часть - это про, мм, это как раз про корпоративные базы знаний. Вот эти два кейса очень классно. Уже куча подтверждений, где есть экономический эффект там от 20 там до 30 там процен экономии. И, ну, рой там чётко считается.
Второй момент, почему появились платформы, и они зачастую как раз начинались с того, что люди учились у себя крутить, сёрвить вот эти большие языковые модели. Просто для них требуются достаточно дорогие ГПУ сервера, да? То есть вы можете, конечно, использовать у себя дома или, не знаю, в небольших компаниях консюмерские карточки, там Nvidia 4090, там 5090, но, к сожалению, долго на них не уедешь. Вот у них есть у них довольно малый ресурс наработки на отказ. Они просто у вас как минимум при интенсивной нагрузке будут очень быстро выходить из строя. Это примерно так же, как с майнингом процесс такой. Вот. А, то есть зачастую вы вообще не захотите, если вы грамотно подойдёте к подсчёту экономики проекта, вы не захотите покупать, ну, ГПУ в себя и держать, потому что м ну это аналогия такая, что мы хотим купить автобус, хотя для нашей задачи достаточно купить, я не знаю, там взять машину в каршеринг или проехаться на такси. То есть ещё неизвестно вообще, насколько это всё взлетит. А мы уже там купили ГПУ, потратили сотни тысяч или даже миллионов рублей, а проект показал, ну, какие-то такие средненькие результаты по вообще по качеству модели, там, не знаю, по вообще по рентабельности. Ну, естественно, там высокие затраты на разработку и поддержку. Мм, тяжело проекты, в принципе, идут тяжело. Да, то есть последняя статистика, где 95%, э, проектов там проваливается из-за того, что у внутренней команды не хватает компетенций в области вот как раз AI проектов, и они не привлекают консультантов и, соответственно, ну, и, в принципе, неправильную методологию используют для внедрения подобных проектов. Вот. Ещё очень часто проблема, как я уже сказал, это проблема с точностью результатов. Это так называемая галлюцинации. Это встроенны, то есть это генетическая проблема всех современных решений на базе. Вот. И недетерминированность ответов. Вот поэтому вам нужно вкладываться постоянно в мониторинг вашего решения на проде. То есть даже если вы выкатили решение и поначалу оно первую неделю работало, может внешний мир может чуть-чуть измениться, да? То есть, ну, например, на примере Цианы, я не знаю, пользователь ищет квартиры и в мире нерменился. Квартиры подорожали там в полтора-два раза, да? То есть и раньше ваш промт, я не знаю, ваша моделька хорошо работала, например, на квартирах до 10 млн. резко изменились изменилась тость квартиры, всё, у вас решение посыпалось, то есть вы ничего не меняли, решение работало, работало и в какой-то момент перестало работать. То есть метрики качества там вообще просели кардинально. Вот. То есть вот эта вот недетерминированность ответов, да, то есть и проблемы с галлюцинациями, ну вам придётся с ней бороться постоянно. Поэтому без мониторинга и без постоянной вот, в общем, в принципе, оценки качества уже решения на проводе, ну, лучше не заходить в такие проекты. LM-платформа отчасти как раз это и решает. Ну, отсутствие экспертизы у внутренних команд, да. Да, и вопросы безопасности и утечки данных. Это вопрос постоянный. Как только вы используете чат GPT и начинаете отправлять туда информацию типа, паспортные данные, да, даже номер телефона, email, ну есть, ну штрафы на юридические лица, там они это неско 1 тире3% на оборот компании. Это может быть очень плачевно для вашего бизнеса. Ну, точнее, вы-то переживёте, а вот бизнес не факт.
Ну и вот коротко, да, какие ещё проблемы есть и как, собственно, они решаются с помощью Млатформы. Ну, самое частое, да, то есть LLM требует вычислительных ресурсов, а платформа уже даёт готовую инфраструктуру. Инфраструктура - это не всегда только видеокарты и ГПУ сервера. Это правильно подобранная, не знаю, версия драйверов Nvidia, да? То есть какие-то СДК, типа там куда, это в действительности, вот пока вы с этим не столкнётесь, это сжирает куча вообще времени. Там, не знаю, собрать правильный докер образ с с нужными версиями библиотека, это, я не знаю, это дни, неделя может уйти у дивопса, у ЛОПС на такие задачи. То есть подогнать всё это, чтобы этим не занимался ML-инженер, да, то есть чтобы он только сконцентрировался на своей задаче. То есть готовая структура нужна обязательно, иначе все, ну, всё время будет уходить в какие-то непонятные решение каких-то непонятных сложных вопросов, а не непосредственно решение бизнес-задач. Вот дублирование усилий. То есть простой пример приведу, дублирование усилий. Если у вас, например, микросервисная архитектура или много команд и каждый пишут там какие-то свои сервисы, у вас в каждом и идёт обращение, ну, например, чат пти. У вас каждая команда будет реализовывать у себя обязательно тоже потребление ресурсов какое-то, да? То есть сколько запросов отправлено, сколько токенов потрачено, да? То есть какое-то широпросов будет, аудит этих запросов, маскирование, они как-то каждая команда начнёт их тоже совместно решать. Вот, ну, не знаю, в масштабах ЦАН, где там больше там больше тысячи уже, наверное, микросервисов и там десятки команд. Ну там дублирование кода. максимально, то есть каждый изобретёт велосипед. То есть если нет централизованного инструмента, все команды крутые и умные, обязательно сделают своё, но потом это приводит к серьёзным последствиям. В общем, здесь желательно сразу идти в какое-то централизованное решение. Недостаток экспертизы и разрозненности процессов - это как раз отчасти Н платформа. Ну вот в целом облегчает коллаборацию команд. То есть это разного профиля, там датсаентисты, линженеры, девопсы, аналитики, они вот работают на этой платформе и в принципе вот варятся во всём едином пространстве и начинают лучше понимать друг друга, язык друг друга, да? То есть и в принципе работа идёт быстрее. долгий цикл разработки моделей. Ну, в современном мире, ну, мало компании, в принципе, себе могут позволить с нуля разработать новую, да, обучить большую языковую модель. В основном это всё-таки до до обучения файнтюнинг под свои цели, да, то есть и через какие-то, то есть лорадаптеры. А задача платформы обеспечить какой-то простой, быстрый доступ. То есть, если тебе нужно, я не знаю, обратиться к модели, ты просто дёргаешь ручку API, да? То есть для быстрой интеграции, ускорения разработки, да, у тебя есть какой-то готовый SDК, где, в принципе, уже всё, что нужно, есть, тебе нужно сделать только импорт, там, я не знаю, Open AI клиента, бац-бацбац и погнали. Ну и автоматизация CCD процессов, да? То есть все ваши решения, в принципе, ну, необходимо как-то проверять на качество. Если, например, код для кода достаточно каких-то, например, функциональных или там, не знаю, юнит-тестов, то в области AI проектов у тебя на вход помимо кода ещё приходят и различные данные. Например, данные могут обновляться ежедневно. А плюс там, я не знаю, такая конфигурация модели, как промт. параметры модели, да? То есть, то есть на вход для тестирования подаётся гораздо больше изменяющихся в процессе каких-то артефактов. Вот это всё усложняет се, то есть и желательно, чтобы он у вас был, потому что это отжирает тоже кучу времени. Вот там по там основным ориентиркам ориентиром там тот же самый CCD процесс для деплоя как, не знаю, ваших собственных моделей, так и LLM приложений каких-то, AI приложений ассистентов. Но это может занять месяц просто на только CCD грамотный для всего этого с, да, то есть с тестированием, выкаткой на прот, я не знаю, выкаткой в тестовый какой-то контур, с откатом какой-то невалидной конфигурации.
И вот как резюме, условно, что делает платформа? Снижает порог вхождения команд в вообще в гi проекты. Время омбординга сокращается. То есть у вас, э, человек приходит в команду, видит, ага, он понимает так, в принципе, я до этого работал с подобным решением. Ага, здесь то, здесь это. почитал документацию и уже мм начинает это вместо того, чтобы он что-то начал делать сам, да, то есть у него уже есть готовые решения, которым он начинает использовать. Вот. Ну и, в принципе, снижение времени от прототипа до запусков prodдакш, снижение таймту маркета, как раз за счёт того, что команда ээ в таких проектах сконцентрирована исключительно на решение бизнес-задач, оно не возится с библиотеками, с версиями зависимости там каких-то там, не знаю, там со сборкой докеробразов, тестирование всего этого. То есть в целом время тратится только на решение задачи. Тем самым уменьшается тайм marкет. горизонтальное масштабирование. Вот это тоже важный момент. В области эмэля ия сложилась такая практика, что а вот быстрое прототипирование, то есть какой-то вот проект взлетает, он получает популярность, и его хочется очень очень быстро прямо сейчас отмасштабировать. А, то есть в практиках софтвера инжениринга зачастую мы говорим: "Ага, надо изначально делать правильно, потому что неправильная архитектура - это сразу же, я не знаю, это там порождает техдолг". То есть мы потом никак не выправим эту ситуацию, да? То есть в мире эмля там дата санса э пропагандируется обычно другой подход. Сначала мы выкатываем, мы можем выкатить очень низкого качества, какое-то базовое решение, оно хоть как-то решает нашу задачу. И наша задача мелкими итерациями его привести к классному какому-то суперрешению. Вот. Ну вот на вот этих начальных этапах, даже когда мы выпустили, выкатили, простите за выражение, какашку, нам тоже её очень важно быстро отмасштабировать. То есть, да, она работает не оптимально, но она, блин, работает. Если она уже приносит деньги, наша задача закидать проблему, а, не знаю, ГПУ дорогущими, да, то есть и и хоть как-то выдержать вот этот этап до тех пор, пока мы не приме не предпримем следующую итерацию там и не перепишем, не переделаем наши решение. То есть у нас должен быть какой-то вот в голове запас прочности, что вот наше решение, если что, если вдруг она выстрелит, мы сможем его отмасштабировать, у нас хватит ресурсов. Зачастую в небольших компаниях этих ресурсов нет, поэтому тут как раз большие перспективы у облака и вообще у гибридной инфраструктуры. Ну и, как я уже сказал, упрощение интеграции с бизнес-процессами, там всё, всё через API или готовые клиенты и СДК для встраивания в популярные бизнес-приложения. И, как я уже сказал ранее, без мониторинга качества и производительности и самих приложений лучше даже не заходить в эту область. Ну, вы очень быстро упрётесь в то, что вы ничего там не можете поменять и вы боитесь поменять решение, потому что обязательно что-то сломается. Вот. И если, то есть, оно работало, оно завтра может перестать работать, а вы вообще ничего не меняли, вот такие моменты превентивно нужно детектировать. Вот с помощью мониторинга, соответственно.
Рассмотрим более-менее. Это первая версия, как вообще из чего состоит современные там AI платформа, да? То есть у нас есть какое-то современное приложение AI, то есть что из чего она состоит? Какой-то usеer интерфейс - это какой-то чат, да? То есть какой-то чат-помощник или какой-то webй. С ним взаимодействует пользователь. под капотом у него есть какие-то промты, да, какие-то протестированные, да, то есть, а пользователь на вход даёт какой-то запрос. Этот запрос нужно очистить от персональных данных, где-то там маскирование произвести, а, не знаю, там проверить на товст, то есть нет ли там, не знаю, там, э, мата или ещё там каких-то вопросов. То есть провести вот некоторые на этапе input guard rail layer, то есть какую-то очистку данных, вот передать в слой прямо, где будет составлено там каких-то цепочка промтов. Всё это перейдёт ниже. И в зависимости от задачи там, мы выберем правильную модельку, и запрос в итоге уйдёт, возможно, в вашу развёрнутую hosted модель, может быть, уйдёт в там вот это вот такого типа запросы уходят, например, не знаю, в Open AI, а такие запросы там на, допустим, условно, э запросы, связанные там с написанием кода, уходят в анopic clк, да, то есть, а на при общении с чатом в там оме и вокруг всего этого пронизанны вот какие-то operation слои, да, то есть это сбор метрик, версионирование моделей, версионирование промтов. Как я уже сказал, вы можете там буквально одно слово в промте поменять, и у вас резко упадёт вообще качество ответа в модели. Вот. А алерты, инциденты, да? То есть это базовый вид. И здесь в этой схеме нет ключевого уже на данный момент компонента. Это, так сказать, решение для запуска иагентов. Вот об этом чуть позже. Вот пример lн платформы внутрибанка нашёл на просторах интернета. Что они здесь выделяют? как раз единую точку входа API gitway, то есть, чтобы соответственно все решения обращались к нему. В этом решении осуществляется какая-то фильтрация запросов, а Финопс, подсчёт стоимости, алертинг, там, не знаю, долго отвечает провайдер. В нём может быть реализован какой-то фолбек, например, не знаю, чат GPT сегодня лежит, быстро переключаемся на антроopic, да? То есть и это внутри API gitway такие фолбеки можно реализовать гипотетически. То есть они есть как самопис, ну, как уже open source, так и, не знаю, написать, в принципе, не сложно самостоятельно, как я уже сказал, здесь вот да слой аутентификации, то есть обязательно тоже, а, всевозможные сборы метрик, маскирование, упс, не ту кнопочку,
да, то есть все они это называют, да? То есть как раз детектирование каких-то секретов. То есть чтобы там, не знаю, в Лэмке не протекали ваши ключи шифрования, не знаю, какие-то сажключи, токены, да, то есть персональные данные.
Ну, у них интересный платформ подход с они называют вот выделяют такую сущность, как рак платформ. То есть это некоторая сущность, которая позволяет все ваши данные, да, то есть быстро создать какой-то пайплайн, который посчитает по нимбединги, уложит векторную базу знаний и будет доступно для ретрывела ваших там, не знаю, AI агентах, ассистентах. Вот.
Ну я бы не стал выделять, но вот условно они так вот тоже современный интересный подход как раз code low Code Automation. То есть мы общались с многими разными компаниями и пришли к выводу тоже на своём опыте, что в целом код, lло low cД - это полезная инициатива, которая должна быть частью современной LТ для быстрого прототипирования. Например, чтобы дать какой-то такой инструмент, где они с помощью уже готовых кубиков могут накидывать э решения и проверять свои идеи, да? То есть продукт вместо того, чтобы идти в разработку, уже сам может, не знаю, накидать какой-то элементарный флоу. То есть вот у меня есть, например, чат, а там, я не знаю, вот я сюда подгружаю какой-то файл, картинку, аудиофайл, вот здесь, я не знаю, происходит какая-то транскрибация или преобразование, то есть и он с помощью кубиков, в принципе, может накидать, а весь необходимый пайплайн и посмотреть, действительно ли валидна его гипотезы, что AI с этим справляется. Вот.
Ну и как раз, да, то есть платформа для запуска ассистентов. Это тоже современное вениние, которое там появилось буквально там полгода назад. То есть буквально полгода назад вот под AI LM платформой понимался вот только вот эти там блоки. И совсем недавно добавилось туда Lowcд какие-то решения и как раз платформа для запуска ассистентов. Все быстро поняли, что недостаточно просто кидать промты в модельку, то есть, ну, oneшот какие-то запросы. А зачастую для более качественного результата требуется модельку спрашивать ещё раз и ещё раз, да, то есть дозапрашивать, доуточнять. Вот. Ну, с этим, собственно говоря, очень хорошо и агент справляется.
Ну и я бы представил современную платформу вот в каком-то вот в таких слоях, где у нас сначала есть слой инфраструктуры, да? Почему здесь берс? Ну, как стандарт, некоторые сейчас для построения пасов и вообще платформ почти в любой компании. Вот и у нас есть возможность быстро масштабировать наши ресурсы, там ГПУ, CPU, Storage, Network. Вот есть слой хранения. Современные, ну, большинство современных решений с иагентами уже строятся, ну, на основе векторных баз данных, такие как пудрант. Вот. А, в принципе, векторные движки уже появились там и для постгреса, а, и есть в эasк. То есть некоторые решения уже предлагают так называемый гибридный поиск, где идёт поиск по, ну, векторный плюс полнотекстный. Ну и набирают популярность графовой базы данных, но пока это для специфического класса задач больше всё-таки. Основные - это векторный СБД и релиционный.
Вот дата пайплайны как раз это про подготовку данных. То есть, например, если нам нужно сделать иассистента по корпоративной базе знаний, у нас должен быть какой-то, а, движок для запуска, там, не знаю, наших ETL пайплайнов по расписанию, условно Airflow, да, то есть, которые будет брать данные, например, с конфлюенса, а, векторизовать их с помощью какой-то бединг модели и перекладывать, соответственно, результаты в векторным баздом. Это нужно делать регулярно, да, то есть, например, раз в час или раз в день.
Вот разметка данных. То есть это какие-то решения могут быть там по типу Label Studio, где, я не знаю, сидит эксперт в какой-то доменной области, и он может ээ с помощью своего экспертного мнения ответить, ну, правильно моделька отвечает на какой-то класс вопросов. То есть мы делаем выгрузку, актуальную выгрузку с прода, например, самплированных данных, и сидит человек и раз в день там, не знаю, тратит там час время на то, что он даёт размёт. Правильно ответила, неправильно, да? То есть пишут какой-то комментарий. Всё это потом э возвращается в пайплайны. Вот это вот фидбэк от эксперта может возвращаться в пайплайны до обучения, переобучения модели.
Ну и вообще в целом пайплайны, да, как раз по дообучению. self hosted модели. Ну, типовой набор LM платформы - это какие-то вот как раз большая языковая модель. Скорее всего, она будет уже сейчас мультимодальная, то есть умеет работать не только с текстом, но и с голосом, и с видео, и с картинками, да? То есть какие-то модели специализированные, которые умеют там превращать текст в голос, генерирует, да, то есть наоборот голос превращать в текст, то есть аля какие-то задачи суморизации, транскрибации звонков. И бейдинг модель как основной, ну, в общем, основное решение для построения каких-то рак пайплайнов и вообще там создание баз зна ассистентов с там с ответами по базе знаний.
Слой CCD для самих LLM, которые вы дообучаете или деплоите. Просто берёте open source CEN какой-нибудь или ламу. Ну, для этого тоже нужен CCD. Вам всё равно нужно их будет обновлять. вышла, я не знаю, была Н 2 с, вышла Н 3. Вам нужно её как-то выкатить, обновить. Скорее всего, это нужно сделать аккуратно, без даунтайма. Это, знаете, тоже задача не на 5 минут. У вас у вас всё это должно быть. А CCD для lm приложений каких-то AI ассистентов, да.
Ну и аб-тесты, как я уже сказал, из-за высокой недетерминированности ответов, вам зачастую сложно будет понять ваш какое-то AI решение или, не знаю, ваш новый промт или новая LLM-модель. Она ок или не ок. И зачастую современная практика, что вы выкатываете ваш, не знаю, изменённый промт или новую модельку в А эксперименте. Например, направляете на неё 10% трафика и ждёте, что AB эксперимент там, не знаю, неделю-две и собираете метрики. Насколько лучше она отвечает или хуже, чем э ваше предыдущее решение? Без ав-тестов, ну, вам очень сложно будет двигаться, то есть как-то осмысленно, да, то есть с использованием современных там data driven подходов. Вы будете двигаться вслепуй без экспериментов, без-тестов.
Ну и очень популярный компонент, с которого, в принципе, зачастую всё и начинается, какой-то условный LM gateway, который обеспечивает, ну, единую точку входа для всех команд, да, то есть и здесь под капотом происходят вызовы либо каких-то внешних, либо ваших внутренних, э, лэмок. Происходит с какой-то подчёт стоимости, э, слой секюрити, ну, то есть какой-то аудит, во-первых, запросов, во-вторых, тоже маскирование. не знаю, там распознание там каких-то секретов. Всё это должно логироваться, мониториться. То есть, я не знаю, метрики, там, не знаю, время ответа от модели, а количество там, не знаю, двухсоток, количество пятисоток и всё такое, да? То есть какой-то пром промт registry, а где вы, условно говоря, не в приложении, а хардкодите в константы, кладёте какой-то промт, а вы его получаете из какого-то проompт regджистри, условного говоря, где он обновляется каким-то специализированным человеком, например, промнженером. Вот. Ну, условно в LUS это реализовано так, что ты можешь получить определённый промт с нужной версией. И, например, я не знаю, в об эксперименте запустить вот старый промт, вот промт версии 2, вот промт версия 1. И давайте распределим их на 50% на этот кинем, 50 на плат и посмотрим результаты через месяц и решим, какой из них оставлять. Вот.
И здесь я условно назвал тоже MCP сервера, то есть где-то уже современный где-то MCP шлюз, условно говоря, который обеспечивает точку входа к другим MCP-серверам, а где-то интегрируют в LLM gitway, где-то условно появляется новые сущность здесь рядом, как MCPшлюз. Вот задача MCP шлюза по сути то же самое сделать единую точку входа ко всем MCP. А и также осуществлять там и мониторинг запросов, и маскирование данных, и логинг, и всё такое.
Ну и как бы самый верхний слой, да, то есть это какой-то плейграунд, где, соответственно, пользователи обычно могут позадавать вопросы, не знаю, покидать файлы и по то есть, ну, в принципе, в каком-то таком спокойном чат-режиме повзаимодействовать с лмкой. No cod, low код решение, где можно кубиками порисовать, я не знаю, посоединять стрелочками на такое UI программирование. Вот. Ну и какое-то решение для создания и ассистентов, то есть некоторая платформа для запуска.
Вот я вот эта карти на этой картинке я просто суммаризовал как бы более-менее то, что я сейчас вижу, как сейчас из чего состоят платформа. А, как видите, компонентов очень много. В действительности требуется большая экспертиза, чтобы всё это А, ну и надо сказать, что какие-то из из каждой из этих кубиков вы можете, например, разместить у себя и взять open source решения. Какие-то из этих кубиков вы можете взять в облаке, да, уже готовые воспользовать и в принципе строить гибридную инфраструктуру. Это всё необязательно может быть у вас. Вот. И не все компоненты здесь вам, скорее всего, нужны, да? То есть постепенно, то есть вы как минимум захотите начать там с условного там GPT LM шлюзы, вот и потом расширять и расширять это всё решение.
В общем, какие почему не стоит разрабатывать собственные платформы? Думаю, стало очевидно. очень много компонентов, а там где-то там порядка 2 лет на разработке может у вас уйти, чтобы как-то подсобрать действительно стоящее решение. А, то есть довольно большую команду всё это требует. Там от 10ти человек суммарно там разные квалификации, ну, разных компетенций: девопсы, датыинженеры, инженеры, программисты, вот аналитики. Ну, естественно, это отвлечение от основного бизнеса. Вы стро, если вы разрабатываете собственную платформу, вы не занимаетесь своим бизнесом.
Вот техническая сложность LM Ops. Ну она сложность в первую очередь, что большой объём данных, большое количество серверов и есть риск что-то сломать. Всегда неопределённость результатов и риск низкого качества. Ну это самое как раз вот про то, что текущая статистика по запуску проектов, ну довольно плачебная. Ну, в первую очередь из, как я уже сказал, там вытекает из предыдущих всех факторов.
Вот готовые решение. Я призываю использовать готовые решения, как Open Source, так и платные. Вот вы можете, как я уже сказал, их комбинировать. Есть, ну, и, на мой взгляд, хочется использовать какой-то разумный, экономичный подход, то есть и не покупать автобус, когда вам нужен там каршеринг. То есть нет, ну, не стоит кидаться покупать какие-то дорогущие ГПУ, как сервера, так, я не знаю, компьютеры с дорогущими ГПУ, если есть возможность провалидировать, проверить вашу гипотезу, запустить уже проект здесь и сейчас и посчитать его экономику и заплатить чисто за потребление. И как только вы увидите, что ваше решение приносит пользу бизнесу, что оно, в принципе адекватно, да, то есть уже можно рассмотреть покупку собственного оборудования, да, то есть и миграцию на него.
Вот, например, расчёты там от МТС, ссылка на их презентацию по их платформе прикреплена, то есть как они её строили. Как раз вот там больше они приводят статистику, что 2 года примерно они её делали. там штатом из там больше, ну, у них там только 10 devops инженеров. Вот. Ну, и в месяц вот они тратили на разработку, а сделали они, ну, как бы не так много, сделали infence lm моделей, какое-то код решение и какой-то чат. Ну, то есть плеграунд установ.
И вот здесь я в условном виде привёл сравнение популярных LM платформ. Аа, ну, то есть, как я уже сказал, по блокам примерно я выделил, что они сейчас включают и что сейчас есть. Ну, от себя могу сказать, что, ну, если вы живёте и работаете в России, то Яндекс Cloud, в принципе, это хороший выбор. Вот. А, да, у них нет каких-то супер качественных производительных моделей, но зато они расширяют э линейку. Ну, как минимум они развивают свою модельку Яндекс GPT плюс очень хорошо научились запускать infрить какие-то openс решения, тот же самую и ламу. И этого зачастую достаточно. Вот при условии там до обучения.
Вот ключевые выводы. Мплатформа, да и в принципе платформные решение становятся ключевым энейблером вообще в в проектах, связанных как с разработкой, так и с эмлем и AI. В AI проектах очень важно наименьшее время на создание прототипа. То есть это ключевой момент, вот который я хочу донести. Сначала минимальными усилиями и средствами научитесь валидировать ваши решения с помощью создания прототипа. Для этого есть как раз всякие low код решения,но код, вот эти вот плейграунды. Вот, чтобы оцените прямо на первых этапах решаются ли ваша задача с помощью современных моделей. Вот это нужно научиться делать быстро, чтобы не тратить деньги компании, не тратить своё время. Вот. И в AI проектах очень важна скорость проверки гипотез. Вот. И быстро, ну, какие-то вот мелкие итерации, да, то есть и здесь не обойтись без мониторинга, без подсчёта метрик, да, то есть и а-э экспериментов. Ну и вообще готовое решение экономит время. Спасибо за внимание. Угу. форма обратной связи. Готов ответить на ваши вопросы.
Да, микрофон подождите, сейчас будет, иначе на записи будет плохо слышно. Добрый день. Тут вот я накидал несколько вопросов. Если можно, вот первый вопрос по в области безопасности данных. Угу. Всё-таки вот как контролировать учечку данных, как я понимаю, это главная проблема, наверное, в области вот безопасности использования как раз вот этих систем, да? Если у вас уже готовое решение, вы используете не своё, как я понимаю, в основном те, кто разрабатывает свои решения, они разрабатывают именно исходя из проблем безопасности, утечки данных. Вот как вы видите, как бы условно здесь контроль какой-то. То есть это как это юридически должно быть как-то оформлено?
Ну, начнём с простых вещей. То есть желательно в современном мире пользоваться только российскими провайдерами, да? То есть, а, ну, условно, там тот же самый там Сбер, MTS Cloud, да, то есть, не знаю, ВК Cloud, Яндекс Cloud, то есть у них уже есть какая-то сертификация там по 152 ФЗ условно, да? То есть это, ну, такой первый шаг, скорее всего, с чего вы захотите начать. Второе, ну, я бы сказал, что лучше сделать какое-то централизованное решение аля вот это вот LLM gate VE, то есть и через него осуществлять все запросы, то есть и полностью, я не знаю, на уровне прямо, не знаю, сетевых там фильтров запретить прямой поход пользователей в чат GPT, условно говоря, только для вечных целей там, да? А там в этой точке, условно в GPT шлюзе, вы сможете более-менее проверять входящий трафик. А есть, в принципе, уже готовые решения, фреймворки для детекции, э, персональных данных, то есть и каких-то секретов, да, то есть на Пайthне. М, я сейчас вот быстро не вспомню. Вот мы используем, да, то есть там комбинация регекспов для базовый слой. Он ловит какое-то количество, детектирует какой-то процент, там порядка 60, да? То есть дальше это передаётся на на наши собственные какие-то дообученные модельки, которые более качественно отвечают на вопрос, нашли ли мы ПДМ, да, то есть, ну, и какие-то средства для маскирования. То есть в целом это очень трудозатратно. действительность вещь. Поэтому, в принципе, вот есть уже готовые решение, то есть на рынке для, например, от Just AI у них есть как раз LLMшлюз, который как раз они в принципе продают это как сервис, так и у себя его можно развернуть. И у них уже встроен как раз вот эта детекция и маскирование персухи. Вот. Ну и много других полезных. То есть уже есть как open source решение для как создания шлюзов, так и осуществление безопасности, так и коммерческие решения. Вот ответит вам на вопрос. Да, ну это, ну, но всё ухудшается с внедрением AI агентов. Вот там всё сложнее становится. Пока ответа здесь нет. Вот по возможности всё заворачивайте через шлюз, через единую точку входа. Вот рекомендация пока такая. А или используйте self-хоost модель, если для вас вопрос о безопасности критичны. Других, ну пока третьего не дано.
Вот второй вопрос такого рода. Вот, э, если можно, слайд третий покажите ещё. Вот какой вы видите всё-таки, наверное, этап внедрения лмок, да, наиболее, скажем так, дорогой для бизнеса, да, и наиболее, скажем так, трудоёмкий, скажем, по времени имеется в виду.
Наша практика показывает, что самый дорогой и трудоёмкий этап - это сбор подготовка данных. Это минимум 30% времени любого AI и проекта. Иначе, ну, потому что правило простое: мусор на входе, мусор на выходе. Чем больше вы усилий вкладываете в подготовку данных и вообще их количество и их качество, тем проще вам будет в ML и проектах двигаться. В принципе, вот это минимум 30%. Вот это вот занимает в действительности. Наверное, второй этап - это, наверное, как раз тоже второй по, скажем так, трудоёмкости. А как раз вот второй этап, да, вот этот какой-то resarch и экспериментирование, да, ну его оценить сложно, потому что он может быть вообще быстрый. А там, я не знаю, раз попробовали и идея взлетела, да? То есть прямо за за день. Так вы можете, ну, месяцами биться и вообще не прийти. То есть и я и проекта, они в принципе с очень высоким уровнем неопределённости и риском. что не получится ничего. Вот. И то есть вот этот этап он в принципе не определён не получится. Так что вот сравнение результатов онсурсных моделей и, скажем так, дорогих, это уже готовых решений коммерческих, да, не получится. Так что это будет, ну, скажем, по времени очень много занимать и сравнимо будет с первым этапом, да, может быть.
Но здесь такой нюанс. Ну, в принципе, open source-модели, они по качеству, ну, прямо сильно отстают, а, от, э, пропариентарных, да, то есть моделей, там, не знаю, антропика. Аа и если даже смотреть на бенчмарки, вот очень там популярны бенчмарки LМ Арена там, условно говоря, они никак не отражают реальную действительность, как та или иная модель справляется с реальными задачами в вашем бизнесе. И зачастую open source модели без файтюна, да, то есть до обучения на ваших данных под ваши задачи, ну, показывают, ну, кардинально худшее качество, то есть это в разы, условно говорять. Вот. А поэтому я бы здесь сплесал именно от пользы, которая то есть до тех пор, пока пользу от вашего решения, если вы можете оценить, превышает затраты на самые дорогие модели, пользуйтесь. Это не проблема. То есть это надо в динамике отслеживать профит, да? Да. Да. То есть вообще AI проекты то есть и LM-модели они есть тенденция чёткая, что они дешевеют со временем, да? То есть и это и по прайсу опы, да? То есть а они в принципе уменьшаются по размеру, то есть и если у вас уже на этом уровне экономика проекта не сходится, то есть в принципе не приносит столько прибыли и пользы ваш проект AI, подождите полгода. буквально ситуация может измениться, да? То есть через полгода выйдет Open source моделька, там, условно, так было с Квеном с 2,5 натри, у него кардинально выросли метрики, и мы очень многие вещи смогли там с помощью неё решить. А до этого это было, ну, вообще, ну, никак. А а то есть и или просто банально подешевеет, э, там цена за токен у ПНА или у Антропика, условно говоря. То есть, если пока не сходится юнит экономика проекта, подождите полгода и проверьте ещё раз. Вот. А так, если возможно, используйте платные решения какие-то, да, готовы?
Ну и третий вопрос, последний вот, ээ, всё-таки какую, может быть, вы порекомендуете для фронт разработчиков, для групп? для фронтенд разработки. А, ну, на наших задачах мы в компании используем преимущественно два решения, это курсор и капай. Вот. А, и, ну, на задачах разработки мы пишем очень много кода на Пайthне и, в принципе, на джаваскрипте. Ну, для нас антроopic clot 4 кд, ну, показывает, ну, на наш взгляд, пока самые интересное результаты показывает. Вот из open source это именно в режиме агента, если мы говорим, да, то есть вот здесь стоит различать вот разработку в режиме агента или в режиме автокомпшна. Если мы говорим про автошн, то, в принципе, икоoder там 2,5 очень неплохо себя показывает. Это если то, что можно развернуть у себя как минимум на компьютере, да, а или, я не знаю, в контуре организации. Вот, в принципе, кодер, ну, мне нравится, я его использую иногда и но именно как такой вот автокомплит умный, да? То есть смотря, что вам нужно, что вы понимаете под разработкой. Спасибо. Мы просто больше и больше вот сейчас пытаемся уйти в агентскую разработку. агентным. Вот. Спасибо за вопросы. Кто-то ещё.
Спасибо за доклад. А такой вопрос. А профессия LLM OBS, она уже подразумевает, что человек ML OBS или это совершенно кардинально разное?
Ну, в принципе, я бы сказал, что база - это MLPS специалист. То есть, э, ну, сейчас это считается как, ну, подраздел, скажем так, да, LM имеет свои особенности, но всё-таки это ML-модель, да, да, она большая, да, она толстая, требует много числительных ресурсов. Но все именно в базовом виде все знания, которые там человек, если он инженер, он, в принципе, может быстро там дообучиться, там создавать какие-то, да, пайплайны до обучения вот под лмки. В общем, я считаю, что дельта там небольшая, да, то есть требует там до обучения специалист, ну, не знаю, не больше полгода.
Ну, понятно. Спасибо. Ещ ещё один вопрос. А тогда как статьопсом? Как статьопсом?
А в первую очередь вот в современном мире Ops он больше начинает быть похож напс, ну то есть знание кубернетоса, да, то есть чтобы развёртывать какие-то готовые решения уже поверх каких-то существующих вот платформ типа Куберне. То есть вот это вот, ну, девопсовская история здесь должна быть обязательно. Какой-то минимальный опыт разработки должен быть, да, желательно на Пайthне. Вот. И, не знаю, то есть, ну, в моём понимании MLOPS инженер - это jниor data scienst или jor ML инженер, это какой-то midle python разработчик, ну, и ну и какой-то синьорный sре, условно говоря, ну, аля divвопс. Вот я бы так профиль написал. То есть чуть-чуть он знает L, понимает концепции, да? То есть он умеет программировать, вот, но он очень хорошо знает в в эксплуатацию систем, не знаю, в деплоди такое. Очень много на это времени всего ходит тоже.
Понятно. Спасибо. Ещё вопросы?
Да, Евгений, есть вопрос от Юрия Виноградова и стула. Он нас смотрит онлайн. А вопрос заключается в том, какой процент позитивных ответов можно считать за показатель успешности модели или каким образом вы считаете, что данная модель успешно решает бизнес-задачу?
Есть очень много способов для эвалюации качества модели. М есть простые, да, то есть, скажем так, а если ваша модель отвечает с качеством, условно говоря, там 70%, да, то есть это уже неплохой результат базовый, с чего можно начинать двигаться дальше. А зачастую к чему мы пришли? Вообще довольно сложная область эвалюации качества. То есть то, что ответила модель сравнить с каким-то образцом. Там есть какие-то энбишные методы, аля там, не знаю, расстояние Ливенштейна, это, не знаю, поиск вхожде там сравнение подстрок, да, то есть это сравнение эмбедингов, да, то есть какое-то векторное расстояние между ними. А мы стараемся искать простые варианты. И к чему мы пришли? То есть, э, модель отвечает, зачастую мы просим отвечать её в strctче output, ну, то есть в формате JSON, и уже сравнивать ответ именно, ну, сравнивать два Джейсона с, то есть, например, по наличию ключей, по определённых значений, то есть и выстраивать, условно говоря, и разбивать вот этот какой-то большой ответ на маленькие этапы, где на выходе модель отвечает каким-то структурированным джейсоном. Structure output в виде джейсона. Это легче валидировать, чем, я не знаю, искать разницы в формулировках там в тексте, условно говоря. Ответил на вопросы. Вот не знаю, насколько, я думаю, да.
И ещё от Юрия один вопрос. А каких специалистов в области Л сейчас не хватает на рынке?
Ну, сейчас дикий спрос на инженеров с опытом в NLP, в то в языковых моделях, да? То есть, ну, там спрос дикий, всем они нужны, их мало. То есть у кого есть реальный опыт, там у кого есть реальный опыт, кто обучал с нуля, э, создавал с нуля ML-модели, это Яндекс. Есть такой опыт у ТБАНКА, у Авито, ну и у Сбера. Вот, собственно, и всё, да? То есть эти специалисты, то есть имеющие опыт создания лмок с нуля и или до обучения на основе там условно каких-то foundation open source моделей типа или вот пользуются большим спросом сейчас. Вот второе - это как раз MLS. Растёт популярность. А популярность, потому что всё больше и больше задач связано с этим. Ну, ML и AI проникает в бизнес всё больше и чаще. Вот растёт популярностью этих профессий. Но я бы назвал это просто MLOs специалисто. Ну, в принципе, спрос на ML-инженеров, ну, стабильно высокий последние там лет пять и ток растёт. А всё отрасли здесь зависит. Это, ну, то есть именно в языковых моделях, где-то в CV, да, то есть в компьютер Vision, где как.
Спасибо большое за ответ. Так. Привет, спасибо за доклад. Так, ну, у меня интересный, наверное, вопрос, чуть не по теме, больше по процессам. Вот ты сказал,
Вы действуете наоборот. Вы сначала делаете плохо, тестируете гипотезу и потом делаете хорошо. Так, я, наверное, понимаю, как в крупной компании это плюс-минус происходит, потому что сам там работал. Нет, в крупной компании принято делать изначально хорошо, да? То есть, но в целом по и в нашей компании принято так делать, но я имел в виду в целом в индустрии AL, вот в этом, да, то есть принят вот как раз такой экспериментаторский подход, да.
Вот и я хочу спросить, как потом вы находите аргументы, чтобы сделать это всё хорошо и как на это как раз спросить денег у бизнеса. Ну, то есть я думаю вопрос понятен. Обычно они говорят: "Ну, деньги приносишь и всё хорошо. Зачем нам что-то делать?" Да.
Да. Ну, это, я скажу так, это постоянная борьба вообще сLинженерами, да, то есть, ну, я как представитель платформы заставляю инженеров делать хорошо, да, то есть, ну, то есть мы позволяем выкатить первые версии не совсем высокого качества, да, то есть, но в целом наша задача, чтобы они привели, то есть всеми правдами, неправдами, это к стандартам качества, а-э, э, на уровне всей компании, да, то есть у нас достаточно высокий качеству, ну, стандарты по качеству кода, по, я не знаю, по архитектуре, по выдерживанию там нагрузок и так далее. И зачастую, ну, моя как раз задача - это вот доталкивать, то есть проталкивать. Вот что, ребята, пожалуйста, доделайте, то есть иначе мы сейчас просто закроем ваше решение, то есть потому что оно начинает вредить. То есть в какой-то момент кто-то должен, да, помочь команде дотолкать это до продакшн состояния настоящего, да, то есть до вот красивого инженерного решения. Вот кто-то должен быть этим энейблером, скажем так. Вот. Ну это и в командах, и внутри компании зачастую это как раз представители платформы, да, условно говоря, они заставляют команды делать хорошо. Вот.
И, ну, где-то это просто пропагандируется, что делаем сразу хорошо, но в нашей области сделать хорошо сразу, это впустую потратить время и не получить результата. Я говорю, у очень, в принципе, большая неопределённость. Ты можешь делать, делать, делать и не получить результата вообще никакого. Вот так.
Ну и, наверное, сюда же сразу вопрос: а где вот та самая отправная точка, что принимается решение, что да, это работает хорошо и надо это развивать? Ну что только, то есть какие какие-то метрики, что на это влияет? Только на проде, да? То есть только вот как раз вот если ты на входе при начале проекта определил метрики, как ты будешь оценивать эффект, как ты можешь будешь оценивать качество твоего решения, и ты уже выкатил. Чем быстрее ты выкатишь это на пользователей и они начнут взаимодействовать, ты начнёшь собирать фидбэк, да, то есть и какие-то метрики качества, технические метрики. И то есть тебе, ну, не знаю, там месяц-два нужно подсобрать эту всю информацию и здраво принять решение. Вот посчитать и трезво сказать: "Мы двигаемся дальше, выпускаем вторую версию и или, не знаю, у нас не хватает данных, нужно ещё подсобрать, да, то есть фидбэк и выпустить, не знаю, добучить там что-то, да, то есть переделать и выпустить вторую версию существенно лучше. Вот.
Угу. Понял. Спасибо. Вопрос там по самой презентации я чуть-чуть не допонял. Там вроде есть оркеestration layer как раз модели. И вот у меня вопрос: а кто за оркестрацию отвечает? Тоже какая-то языковая модель отдельная. То есть кто принимает решение, э куда сходить? Вот этот нет до этого, по-моему, ещё Ага. Модель оркестраation layer, да? Здесь может быть вполне, ну, это какие-то могут быть декларативные правила. То есть типа для конкретного приложения разработчики могут предварительно выбрать две модели. То есть они, например, не знаю, э взяли чат GPT и антропик, условно говоря, сравнили примерно качество. То есть если чат GPT ложится, то есть у них декларативно, то есть, допустим, пять ответов неудачных, да, то есть мы переключаемся на другого провайдера. То есть какие-то декларативные правила, так и более умные с помощью каких-то легковесных LLM-моделей, которые условно на Литу могут роутить это всё.
Угу. Ну вот там было интересно вот, видимо, кавестные модели. В принципе, это возможно. А и примерно сейчас вот, ну, мы это не используем для примера текущий чат GPT, вот они убрали возможность выбирать модель по умолчанию, да? То есть, и они сами роутят на основании, они пытаются понять запрос пользователя и пытаются, а, предугадать в какую модельку, то есть GPT5, GPT5 mini или в N отправить запрос. То есть, а, вот это довольно сложный проект в целом, да, то есть, но направленный больше на оптимизацию. То есть, если запрос тупой, да, то есть ну, наверное, с ним справится и то есть более легковесная модель или наоборот, чем точнее и, не знаю, детализирование вопрос, тем лучше с ним справится легковестная модель, да, то есть умные модели заточены под большую неопределённость, там, да, то есть больше знания имеют. Вот, в принципе, ну, этот подход сейчас только развивается, да, то есть, ну, здесь исклю, ну, изначально он заложен, что, в принципе, это возможно, это уже делается с некоторыми компаниями для экономии времени, ну, и не времени, а денег на расходов на экин класса запросов просто взять и начать переключить их на дешёвую модель, какую-то более. Ну, нам, в принципе, тоже уже сейчас это ничего не решает, не мешает сделать. Ну, пока мы отдаём это на откуп разработчикам, да, то есть, чтобы они сами выбирали, но в какой-то момент, возможно, мы накопим знания и скажем: "Всё, вы больше не решаете, какие модели вы используете, мы сами решим, да, то есть и раз и какие-то часть запросов будем вообще на собственно на селхост отправлять, они будут думать, что, например, чар GPT отвечает, да, то есть, а в действительности это какой-то там развёрнутый selfthost. Вот такой переход возможен в целом в будущем.
Угу. Всё было. Спасибо большое. Может, ещё есть вопросы у кого-то? Спасибо за доклад. У меня вопрос такой, как сказать, более практический. Интересно вот стало, а, в плане применения всех этих i-систем и моделей у вас компании, потому что, мм, уже не первый год я слышу, что вот-вот программистов заменит какая-нибудь очередная там новая версия GPT. И понятно, что в продакшене наверняка у вас какая-нибудь рекомендательная система, там поисковая, всё это используют L модели. Но интересно, используется ли что-то для ускорения разработки, чтобы уменьшить количество рутины. Про автокомплит я слышал, но интересует именно более какой-то общий, не знаю, подход, который позволит, я не знаю, ну, допустим, заменить, э, ну, классического midл-разработчика, э чтобы какая-нибудь модель вместо него сидела, переносила из Фигмы в Реакт. И вот интересно, в какую-нибуд такую сторону вы двигаетесь и что для этого?
Ну, мы двигаемся, да? То есть, ну, нам, в принципе, история с автокомплитом не очень близка, потому что, ну, компания довольно зрелая у нас. И у нас, в принципе, очень много кодогенерации уже готовы. То есть, в принципе, разработчики там с каждым ээ годом там писали всё меньше и меньше кода, а больше его генерировали там, да, по определённым там правилам. Ну, очень много типовых вещей. В принципе, за 20 лет работа компании уже автоматизирована в этой области. И нас больше здесь интересовал как раз агентский подход, где, ну, человек только ревьют и опровет условно решение. И, в принципе, мы вот изучаем данный больше подход, чем какой-то автокомплит, потому что, ну, зрелые компании уже давным-давно вложились в кодогенерацию, скажем так, да, то есть и там кода пишется не так много, он просто копируется. Да, то есть вот аа поэтому агентский подход, ну, мы не считаем, я лично тоже не считаю, да, я буду вот сейчас только про я не считаю, что разработчики в ближайшее время заменятся, но мы уже пересматриваем грейды, и я наблюдаю это в других компаниях, что, э, условно то, что раньше там умел сеньор, да, вот скажем так, в принципе сейчас эти же требования для синьора, это для как для медла плюс AI, да? То есть вот то есть AI он, ну, повысил конкурентность специалистов и теперь, то есть требования к ним у увеличились. Вот. То есть, чтобы называть себя джуниром, ты уже, в принципе, по умолчанию должен владеть AI, да, в современном мире, то есть в современных IT-компаниях. Вот. Если ты этим не можешь владеть, то, ну, ты уже, наверное, не джуниор. Вот. Ну, естественно, ты должен уметь писать и читать код. Вот. Вот. Но у тебя в помощниках, то есть, короче, ну, я не верю пока в историю с заменой. Плюс написание кода - это, ну, по всем измерениям, вот по современной статистике, это не такой большой процент работы программиста. А где-то вот раньше существовала оценка, что программист пишет на самом деле в день 4 часа код непосредственно, да? А всё остальное время он, я не знаю, какие-то решает сложности, нестыковки находит, там думает над последствиями своего решения, ещё там что-то, обсуждает с бизнесом, какие-то технические требования там и так далее. Всё это утрясает. А по по более обновлённым данным только 2 часа времени программист пишет код. Вот что-то ещё он помимо этого делает, да? А зачастую что? Он следит за своим сервисом, как он работает в продакшене, он там, я не знаю, там изучает опыт пользователей, какую-то аналитику тоже смотрит. То есть я к тому, что сейчас растут требования к разработчику и фронт в том числе, то есть и больше всё уходит в Tшеape, так называемый. То есть ты должен знать не только про разработку, то есть и в данном случае тебе просто вот эти ассистенты помогают писать код. Вот. Но ты уже и так его не так много пишешь, в принципе, зачастую. Ну, в современном мире, да.
Спасибо за ответ. Ну, сумбурно ответил, да, но область сложная для себя нашёл. Ну, это опять-таки упарываться в, чтобы полностью заменить разработчика. Разработчик не так, мой поинт, не так много времени тратит на написание кода. Очень много других вопросов сейчас у разработчиков. Кто их на себя возьмёт, непонятно. Таких пока системы нет и не предполагается. Ребята, может ещё у кого-то есть, что спросить? Ну тогда, Евгения, спасибо вам большое. И время пришло выбрать лучшего участника и подарить подарок. Спасибо. По традиции, как это лучшими обычно называется либо последние, либо первые вопросы. Сейчас позвольте вспомнить. Значит, так. Был вопрос сначала про безопасность, про Так, первый про последний про, а, генерацию кода на Так, спрашиваю ещё из стула вопрос, да? Из стула, да? Угу. Ну, в общем, из ребят, которые тут. Хорошо. Ну, не будем внушать традиции. Последний вопрос. Ну, мне он больше всего тоже как разработчику отчасти тоже животрепещий. Да. Последний вопрос хотел бы отметить. Включайте, прошу, что тут. О, хороший подарок. Я обще Да, конечно. Да. А уже для вас в принципе. Да. А сейчас мы как это фото? Да, я сейчас. Держите. Это вам. Спасибо. Было приятно. Зави. Так. Фото. Ага. Вот куда-нибудь сюда. Вот ещё провее там немножко там. Ага. Спасибо. Да. Ещё раз спасибо, Евгений. Будем читать вас в дальнейшем у нас на докладах. Очень рады были, что вы пришли. И спасибо всем, кто присутствовал сегодня. Спасибо вам. Надеюсь, было не очень модно и скучно. Ah.