Технические дискуссии на Conversations — это про глубокое погружение в происходящее на рынке, про попытки нащупать настоящие болевые точки индустрии, задать неудобные вопросы и услышать честные ответы. В этот раз на сцене собрались эксперты из SberAI, Авито, Т-Банка и Raft, чтобы вместе с Just AI обсудить автономных агентов с суперпамятью, вызовы vibe coding и новую эру кибербезопасности. Вашему вниманию — расшифровка интереснейшей дискуссии!

О скорости изменений в индустрии и методах отслеживания важных технологических релизов, перспективах вычислительной революции, альтернативах NVIDIA и безопасности LLM, подходах к вайбкодингу в разработке и кейсах применения AI-ассистентов и многом другом расскажут:

• Илья Карев — Team Lead GenAI Solutions, Just AI

• Сергей Марков — популяризатор науки, директор по развитию технологий искусственного интеллекта SberAI

• Олег Королев — руководитель разработки AI Lab, Авито

• Евгений Кокуйкин — сооснователь Raft и SeoHive Trace

• Александр Поломодов — технический директор Т-Банка

О скорости изменений в индустрии и методах отслеживания важных технологических релизов

За последние годы, примерно с появления GPT-3.5 Turbo, генеративные модели стали использовать повсеместно: от исследований космоса до генерации видео. Стало появляться множество инструментов, моделей, архитектур, методов файнтюнинга и т.д. Для этого придумали термин «ИИ-турбулентность» — когда каждый день  происходит столько изменений, что за ними следить не представляется возможным.

Илья Карев ,Just AI (модератор): Коллеги, ощущаете ли вы эту турбулентность? И как ваши команды отслеживают происходящие изменения?

Александр Поломодов, Т-Банк:

Здесь хочется отметить преимущество больших компаний. Люди из разных отделов, ответственные за разные задачи, могут готовить какие-то выжимки о том, что происходит в мире. Например, я сам слежу за тем, как AWS DLC влияет на разработку. А, например, что-то про foundation модели и новые подходы я узнаю от коллег. Действует своего рода принцип разделения труда. Надо просто понять, в чем ты специалист и какая тема тебе близка. А другую часть отпустить и за ней следить, доверяя коллегам.

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

Евгений Кокуйкин, Raft и SeoHive Trace:

Сейчас самое волнительное — это рост автономности ИИ-систем. Всё чаще инструменты, тот же Deep Research, выдают ответ в том виде, в котором его можно сразу использовать.

Сергей Марков, SberAI:

В сфере ИИ турбулентность наблюдается ещё с момента появления технологий, а может быть еще и до зарождения ИИ. Когда в 1940-х Росс Эшби создал первую систему, которую с некоторой условностью можно назвать искусственной нейросетью, в газете появилась первая статья с названием: «Щелкающий мозг умнее человеческого».

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

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

Турбулентность однозначно ощущается, но и люди очень быстро привыкают к наличию технологий. Сколько комментариев мы слышали вроде, «Фу, у вас пальцев шесть получилось!» А когда генерили видосы, где Уилл Смит ел спагетти, ещё было непонятно, кто кого ест. Но ведь раньше подобное в принципе было невозможно…

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

Илья Карев, Just AI (модератор): А как у вас в Сбере устроено слежение за технологиями? Или вы не следите и сами до всего доходите?

Сергей Марков, SberAI:

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

Но даже с этим всем — это большой вызов, потому что каждую неделю выходит минимум пара десятков работ по ML, достойных внимания . Если пытаться всё это обозревать, то кроме обзоров больше ни на что времени не останется. Поэтому сейчас мы находимся в поиске эффективных решений этого вопроса.

О перспективах вычислительной революции, альтернативах NVIDIA и безопасности LLM

Илья Карев, Just AI (модератор): Видеокарты снова дорогие. На каком железе вы обучаете и запускаете модели? Знаю, что Евгений может рассказать про альтернативы NVIDIA.

Евгений Кокуйкин, Raft и SeoHive Trace:

У нас есть security-лаборатория Talent Hub в ИТМО, где мы исследуем, как атаки на LLM могут повлиять на безопасность решений. В основном мы используем доступное всем железо, поскольку ресурсы ограничены. Тем не менее существует трек, где мы тестируем китайское железо — например, сейчас ведется работа с моделями X500.

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

Сергей Марков, SberAI:

У нас, как всегда, всё сразу на всех фронтах. Флагманские модели обучаем на NVIDIA, но у нас есть опыт и с Atlas от Huawei. Мы начали их использовать еще до того, как это стало мейнстримом.

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

Вообще сам факт монополии в области фотолитографии — серьёзный звоночек. Разрушить ее в России невозможно, если не использовать гигантские государственные инвестиции. Китай пытается, но пока успехи ограничены. 

Это о чём говорит? Когда-то толковый инженер мог в гараже улучшить КПД двигателя внутреннего сгорания на несколько процентов. Сегодня нужны многомиллиардные инвестиции, чтобы продвинуть показатель на десятитысячные доли процента. И это может означать, что технология достигла своего определенного предела ,и в ближайшие десять лет нас ждёт слом существующей вычислительной парадигмы. 

Конвенциональную электронику становится всё сложнее совершенствовать поступательным путем, но потенциальных альтернатив очень много. Проблема не в их отсутствии, наоборот — в их изобилии. В Nature Science постоянно появляются новые публикации: мемристоры из никелатов, поляритонные конденсаты, 101-я нейроморфная архитектура...

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

Илья Карев, Just AI (модератор): Не менее интересная тема — это безопасность. Сергей уже начал говорить, что образовался монополист на рынке и, грубо говоря, нам могут обрезать железки. Одним прекрасным днем все Nvidia превратятся в тыкву, и нам придется на чем-то запускать наши модели.

Сергей Марков, SberAI:

Мне кажется, в России все NVIDIA, которые используют крупные корпорации, это так называемые зомби-NVIDIA. Их просто перепрошивают сразу после покупки.

Илья Карев, Just AI (модератор): Но безопасность не ограничивается только тем, что их могут отключить. Важно также фильтровать, что отправляется в LLM и насколько это безопасно. Утечке могут подвергнуться секретные документы, закрытые API-спецификации, токены авторизации. А учитывая ужесточение требований 152-ФЗ, персональные данные также рискуют попасть в зарубежные модели.

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

Евгений Кокуйкин, Raft и SeoHive Trace:

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

Рынок AI-security-решений для защиты систем на базе больших языковых моделей в России пока еще находится в зачаточном состоянии. За рубежом же уже было проведено несколько крупных сделок, когда крупные вендоры приобретали небольшие компании. Но в целом всё это пока что только формируется.

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

Вот коллеги в Сбере недавно представили свою модель угроз. Очень хорошая работа — если вы хотите погрузиться в тему кибербезопасности, связанной с LLM, эту работу стоит изучить.

Если говорить о том, куда смотрим мы, то у нас есть два направления. С одной стороны, это создание инструментов, позволяющих выявлять и тестировать сложные кейсы работы LLM. Например, в нашей лаборатории есть open-source инструмент Lamater, который позволяет тестировать GenAI-приложения. С другой стороны, мы активно работаем над решениями для защиты. У нас есть приложение HiveTraces, которое позволяет мониторить использование LLM и помогает снижать риски их эксплуатации в проде. 

Александр Поломодов, Т-Банк:

Мне кажется, история с LLM-уязвимостями — классная штука. Особенно это актуально для GenAI-приложений, выходящих наружу. Когда внутри компании делают прототипы, нередко встаёт вопрос выбора моделей. Часто используют «модели покруче» и закладывают в них побольше контекста. Вот только здесь возникает риск слива чувствительных данных.

Поэтому промпты проверяют через прокси и при необходимости перенаправляют запросы в on-premise модель. Она, конечно, дает не такие хорошие результаты, зато более безопасна. 

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

Илья Карев, Just AI (модератор): Олег, вы как раз файнтюните Qwen и разворачиваете его в проде, расскажи нам об этом.

Олег Королёв, Авито:

Да, у нас есть проекция для публичных LLM — там тоже реализовано логирование и мы стараемся отслеживать, что именно уходит в модель. Но всё равно остаётся проблема: человек должен сам научиться понимать, что можно отправлять, а что нет. Это непросто. Вот есть ли у сотрудников какие-то таблички, где написано, что относится к конфиденциальным данным, а что нет? Они нередко ошибаются.

У нас есть три основных сценария использования LLM: продакшн, внутренняя автоматизация и разработка кода. Для прода мы используем собственную модель, сейчас это pre-train — Qwen 2.5.7b. 

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

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

Еще есть решения для локальных документов. У нас есть развернутые Open Source модели. Там есть первая версия RAG, куда можно что-то свое загрузить. Сюда же можно отправить стратегии и конфиденциальные документы.

Подходы к вайбкодингу в разработке

Илья Карев, Just AI (модератор): Тема последнего года — это тема вайбкодинг. Что вы по этому поводу думаете и как вы к этому подходите в своих компаниях?

Александр Поломодов, Т-Банк:

Если говорить как раз про то, как мы пытаемся интегрировать ИИ в SDLC (software development lifecycle), то мы его рассматриваем как инструмент повышения продуктивности разработчиков. 

Сначала мы DevOps пытались сделать, потом научились писать пайплайны, развернули кучу инструментов. Затем пришли к Platform Engineering: появились PaaS-решения, пайплайны, рантаймы, сервисы из коробки. Всё это начало развиваться в продуктовой логике.

У многих продвинутых компаний была телеметрия по использованию этих инструментов, благодаря чему уже было понятно, какие джобы выполняют инженеры. Стало понятно, как их распределять — не намазывать на все инструменты, а применять точечно и более эффективно. Например, передать задачи на ассистентов, когда есть human-envelope, а потом, если все хорошо идет, делегировать эту часть работы полностью агенту. 

Примерно такой подход практикуется у нас внутри, его можно встретить и в зарубежных бигтех-компаниях. У Google есть статья про Measured Developer Goals, где достаточно неплохо рассказано про этот подход джобов в платформе. 

Есть некоторый гигиенический уровень. Условно, например, code completion — то, с чего все начиналось, что было еще до LLM.

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

И третья составляющая, когда у тебя уже хорошо работают ассистенты, ты пытаешься под ключ отдать работу агентам. Например, был питч стартапа от сотрудников JetBrains и Huawei — агента, который не только генерирует тесты, но и сам их компилирует, фиксит ошибки и запускает.

У нас есть ребята, которые делают наш ассистент с Code Completion — Nestor. Они используют предоставляемые им инструменты — LLM-платформу, сервис для сервинга моделей и прочие инструменты, чтобы не заниматься инфраструктурой с нуля. Благодаря этому им не приходится вручную поднимать базы данных и делать обвязки.

Есть куча аналитиков, которые пишут код в ноутбуках, и им прикольно рекомендовать код на Python или SQL. Еще у нас есть Observability-платформа с кастомным синтаксисом, похожим на Splunk. Называется она Mage, и в ней не так уж просто написать запрос — с полпинка это сделать не получится. Ты говоришь ей писать на человеческом, и тебе сгенерирует запрос на этом языке.

Рабочих групп много. Одна из них — по архитектуре, за которую я отвечаю. У меня есть определенное количество болей, которые хочется автоматизировать: сбор информации о системах, проверку RFC или Architecture Decision Records. 

Есть история с Reverse Engineering архитектуры. У тебя могут быть данные о деплойментах, исходный код, телеметрия. И здесь хочешь, чтобы у тебя не было отдельной касты людей, которые рисуют картинки и пишут обвязки. В идеале, чтобы Reverse Engineering был основан на production-данных. Текстовые описания извлекаются, обрабатываются, подключаются LLM, и процессы, ранее выполнявшиеся вручную, переходят в автоматический режим. Все, чтобы люди писали про будущее и что они хотят поменять, а текущее состояние системы получали из фактических данных. 

Вот примерно так у нас сейчас устроено применение AI в SDLC.

Илья Карев, Just AI (модератор): В мире действует гонка кодинг-ассистентов, потому что там есть курсоры, виндсёрфы, рукоды и так далее. У Сбербанка вот есть GigaCode.

Сергей Марков, SberAI:

Да, GigaCode, который раньше, к слову, назывался Джарвисом, появился удивительным образом раньше, чем GigaChat. Если смотреть исторически, мы начали автоматизировать задачи, связанные с разработкой кода, чуть раньше, чем сделали свой публичный чат-сервис.

И в те древние времена это всё называлось Programming Language Processing — PLP. Уже тогда было понятно, что это один из самых прикладных кейсов применения больших языковых моделей. У разработчиков уже был опыт работы в IDE с их умной подсказкой — пусть и на очень простых моделях. А тут прям низковисящий фрукт, который можно быстро сорвать.

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

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

С тех пор всё, конечно, сильно продвинулось вперед. Современный GigaCode встроен во все популярные IDE в виде плагина, плюс в нем есть RAG-механики: над проектом и по внешним источникам. 

Еще одной ключевой задачей было замкнуть среду разработки, позволить делать  многие вещи без покидания IDE, то есть встраивать туда сразу все генеративные модели. Нужна иконка — генеришь SVG прямо в среде. Музыка, 3D-объекты — всё там же. Весь зоопарк генеративных моделей собирается в одном месте. Мы хотим в целом снизить порог входа, чтобы не надо было никуда уходить из среды разработки, ведь там можно создать проект с нуля.

Вообще, сейчас происходит такой ползучий процесс переизобретения процесса разработки. Кто-то недавно пошутил про вайбкодинг: very inefficient, but entertaining. Да, пока местами так и есть. Но даже в таком виде инструменты работают и помогают стартовать быстрее.

Знаете, сколько «правильных» языков программирования уже придумали? А большинство веба до сих пор живёт на PHP. Всё потому, что дизайнер смог написать открывающую угловую скобочку, знак вопроса и уже стать программистом с этого момента. Не надо было учить, что такое импорт, модуль и класс. Вы попробуйте в Java написать программу hello world, сколько в этой программе вам нужно объяснить концепции начинающему программисту, чтобы он понял, как это на самом деле работает. Поэтому в целом это важная такая штука.

Посмотрим, куда всё это приведёт, но мы здесь активно экспериментируем. Если вам тоже интересно — пробуйте наши инструменты, присылайте свои ругательства. Мы открыты к совместному творчеству по совершенствованию этого инструмента.

Кейсы применения AI-ассистентов и фреймворки для их написания

Илья Карев, Just AI (модератор): Начали уже говорить про AI-ассистентов. Собственно, какие самые популярные кейсы использования AI-ассистентов в ваших компаниях?

Александр Поломодов, Т-Банк:

У нас ребята периодически проводят внутренние конференции, на которые зовут внешнюю аудиторию. И вот недавно был достаточно интересный рассказ про SRE-ассистента. У нас есть имплементация Space — это фреймворк, который используется для оценки продуктивности девелоперов. Там есть опросная часть, в которой было видно, что ребята, которые отвечают за надёжность, менее удовлетворены своей рабочей жизнью. Ну, в общем-то, неудивительно: эти люди часто просыпаются, например, ночью, если что-то пошло не так. Ты ночью не особо в хорошем состоянии, замедлена реакция, память похуже работает — тут как раз и может пригодиться ассистент. Он вытаскивает нужную инфу по связанным системам, подсказывает, что в ранбуке написано, показывает релевантные куски логов и метрик, чтобы ты по разным системам не искал. 

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

Илья Карев, Just AI (модератор): Какие фреймворки у вас используются для написания AI-ассистентов? 

Евгений Кокуйкин, Raft и SeoHive Trace:

Я могу ответить под таким углом. Вот в работе над отчетом OWASP нам надо было проанализировать наиболее популярные сейчас фреймворки, и мы делали опрос. Получается, QEI, AutoGen, Pedantic, выходит вперед LangChain, известная библиотека, которая адаптируется к фреймворкам. И на некоторых рынках, например, очень часто используется low-code, типа Copilot и Microsoft. По статистике именно эти выделяют, и вот именно вокруг них мы отчеты собирали.

Сергей Марков, SberAI:

У нас очень большой зоопарк. Я обращу внимание на два наших кейса. Первый — это уже помянутый GigaCode. Это действительно один из самых популярных ассистентов, это видно по метрикам его использования. А второй кейс — это весьма неочевидная история. 

Знаете, у нас люди очень любят LLM-ки в лоб в поддержку садить. Вот только без специальных «приседаний» это сделать трудно, либо нужно очень сильно постараться. Особенно опасно так делать в чувствительных областях, в которых цена ошибки велика. 

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

Хотя и системы на скриптах не идеальны. Когда мы в 2018 году запустили своего первого робота-оператора, получили довольно интересную жалобу. Наш голосовой робот неправильно поставил ударение в фамилии клиента, из-за чего получилось неловкое и даже оскорбительное звучание. Нам жалоба в ФССП прилетела сразу. Это к тому, что если у вас скриптовая система, не факт, что это вас спасет. 

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

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

Следующая Conversations, на которой вас ждут не менее захватывающие дискуссии, не за горами! Следите за обновлениями на сайте.