Мне удалось пообщаться с Константином Крестниковым @Rai220, управляющим директором и техлидом команды GigaChain, которая занимается агентными системами и разработкой SDK для GigaChat в Сбере. Константин глубоко погружен в развитие экосистемы вокруг GigaChat, поэтому разговор получился подробным, богатым на примеры и управленческие инсайты.

• Расскажите, пожалуйста, коротко о своей экспертизе и опыте в опенсорсе.

Я в ИТ с 2006 года. Прошел все стадии: от разработчика до управляющего директора. Были и стартапы, где я работал в роли СТО. На всех этапах взаимодействовал и продолжаю работать с опенсорсом. Также я всю жизнь занимаюсь программами, которые разговаривают с человеком, потому что мне это нравится. Кстати, еще в школе писал приложения, имитирующие общение с людьми, а затем часто ввязывался в подобного рода проекты.

Один из ярких стартапов подобного рода, к развитию которого я приложил руку, это — Cubic (хабрапосты о нем: тут, тут и здесь). Он представлял собой первую в мире умную колонку, с которой можно было взаимодействовать. Мы эту концепцию придумали еще до того, как у Яндекса появились Станции, а у Амазон — колонка Echo. В целом идея была простая — засунуть в колонку чат-бота, с которым человек общается голосом: узнает разную информацию, отдает команды, например, управляет умным домом.

Мы начали развивать этот проект в начале 2010-х и пошли на краудфандинг, где собрали приличную сумму на выпуск железа. Кстати, это была своя разработка, как с точки зрения железа, так и софта. Например, мы научились распознавать речь на большом расстоянии, что на тот момент было ноу-хау. Однако наш выход на рынок совпал с появлением Amazon Echo. Конкурировать было сложно, и мы решили вернуть деньги тем, кто вложился в нас на краудфандинге. При этом нашу компанию частично купили российские крупные игроки, а часть команды перешла в Яндекс.

В свою очередь, как только началась эпоха LLM, я сразу понял, что это очень интересно и нужно Сберу. На тот момент в Сбере предпринимались ранние попытки создать свою большую языковую модель, и они довольно быстро переросли в GigaChat. Для него потребовался инструмент, чтобы разработчики могли писать под него софт.

Тогда возникла идея — использовать для этого опенсорс, чтобы внутренние и внешние разработчики пользовались одним кодом. Так появилась наша команда GigaChain, где мы развиваем SDK для работы с GigaChat и создания на его основе ИИ-агентов.

Да, как и другие крупные компании, Сбер мог бы взять и написать все с нуля, но в таком случае, как мне кажется, был бы риск многое «переизобрести» и получить сложности с поиском специалистов, которым бы еще пришлось погружаться в неизвестное решение. У нас же речь шла о большой и перспективной теме, поэтому мы решили взять за основу уже существующее опенсорс-решение для создания ИИ-агентов. Таких решений было много, поэтому мы ориентировались на популярность, минимальные риски зависимости от вендора и решения, которые работали с большим количеством моделей. На тот момент наиболее популярным в мире был и сейчас остается LangChain. Мы взяли его за основу и стали в рамках него разрабатывать свой опенсорс для Сбера. Сейчас им пользуются сотрудники — для разработки агентов в Сбере, а также внешние пользователи GigaChat.

• GigaChain, насколько я понимаю, начинался как форк LangChain?

История тут следующая. Мы с этого начинали, но потом изменили подход. На старте форк был оправдан, потому что в самом разгаре была эпоха промпт-инжиниринга, и подобного рода агентные фреймворки содержали внутри себя огромное количество промптов, добавленных в hardcode-формате. LangChain не был исключением, и там промпты были добавлены на английском языке. На тот момент GigaChat был заметно лучше адаптирован к работе с русским языком, поэтому форк на старте был для нас практическим решением.

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

Однако в какой-то момент LangChain охватил водоворот новинок в силу роста внимания к самой теме LLM. Мы, как владельцы форка, были вынуждены затягивать к себе по 100-200 изменений, появлявшихся в основном проекте буквально каждую неделю. Почти все время команды стало уходить на эту синхронизацию, но происходили и другие важные изменения. Во-первых, промпт-инжиниринг потерял актуальность, и LangChain вынес большинство промптов в специальное хранилище. Во-вторых, LangChain становился модульным — крупные вендоры начали выходить из LangChain и создавать свои пакеты совместимости.

Тогда мы поняли, что от форка нужно отказываться. Мы создали свой пакет интеграции, сделали его качественно, чтобы весь функционал LangChain работал с GigaChat при установке этого пакета. Как оказалось, это было правильное решение. Теперь в Сбере мы рекомендуем всем для создания агентов и корректной работы с GigaChat использовать чистый LangChain и устанавливать пакет совместимости, который полностью написан нашей командой.

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

Преимущество в новом подходе еще и в том, что теперь Сбер и внешние игроки, использующие GigaChat, могут нанимать людей с релевантным опытом разработки агентов на LangChain, ставить все необходимые для работы компоненты из опенсорса и создавать агентов на современном стеке. Мы понимаем, что людям это действительно нужно, потому что одна наша библиотека, которая обеспечивает интеграцию с GigaChat API на Python, по данным ClickPy входит в топ 1,5% самых скачиваемых библиотек с PyPI по месячным скачиваниям.

Это хороший результат для Сбера и российской модели.

• Получается, открытый подход стал способом решения ряда важных задач в Сбере?

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

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

• Есть ли у вас кто-то, отвечающий за цели и координацию открытых инициатив?

Очень зависит от команды. Наш опенсорс родился как R&D-инициатива, фактически экспериментальный проект. Когда мы начинали его делать, в команде был только я, поэтому изначально проект был очень компактный. Поэтому здесь не было особых согласований и координации. Но как только наш проект начал органически расти, мы увидели, как благодаря столь скромной инициативе весь SDK для GigaChat удалось удержать в опенсорсе. Это логичное желание в контексте развития SDK, которое связано и с общей целью — сделать так, чтобы на основе наших базовых технологий появлялись продукты.

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

Думаю, здесь стоит добавить, что в целом же в мире создается огромное количество агентов. И поскольку разные модели имеют разные интерфейсы взаимодействия, возникает проблема переносимости. Например, я не могу взять агента, написанного под Claude, и перенести его на GigaChat. Да, можно сказать, что протокол OpenAI является чем-то вроде стандарта, но в силу наших внутренних особенностей в Сбере поддержать его полностью мы не могли.

Когда мы делали свой опенсорсный стек, нам очень хотелось, чтобы как можно большее число внешних агентов можно было запускать на GigaChat. Как раз на основе работы с LangChain, который является наиболее востребованным SDK в мире, мы решаем эту задачу. За счет совместимости с LangChain мы сильно снижаем барьер переноса существующих опенсорс-агентов на GigaChat. На практике это означает, что значимую часть таких решений можно адаптировать под GigaChat с минимальными изменениями. Этот подход уже показал свою прикладную ценность и в ряде внутренних сценариев оказался полезен для бизнеса.

• Как вы взаимодействуете с аудиторией ваших открытых проектов? Насколько в вашей ситуации важно коммуникативное и «контентное» сопровождение?

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

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

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

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

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

Отдельно отмечу GigaAgent — это наш открытый автономный агент. Мы не делали его как продукт в вакууме: на протяжении всего 2025 года показывали его на десятках конференций от Питера до Владивостока, общались с коллегами и итеративно совершенствовали GigaAgent на основании запросов разработчиков и бизнеса. Коллеги подсказывали, где действительно нужны REPL, инструменты, локальный запуск и модульная архитектура, а бизнес — какие сценарии дают прикладную ценность: анализ данных, подготовка презентаций, работа с корпоративными источниками. Поэтому GigaAgent для нас — это не просто R&D-эксперимент, а результат последовательной разработки на стыке инженерных потребностей и бизнес-задач.

• Как вы подходите к выбору правил игры и лицензий для открытых проектов?

У нас лицензионная политика исторически полагается на MIT-лицензии. Мы не хотим каким-либо образом ограничивать людей в использовании и тестировании открытых решений Сбера, в том числе, когда дело касается работы с GigaChat API. Все лицензии доступны на GitHub и на GitVerse, здесь у нас все прозрачно и без лишних сложностей.

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

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

• Что открытый подход даёт Сберу в целом? Какие цели вы могли бы отметить?

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

Когда мы остановили свой выбор на LangChain, сразу после него вторым по популярности фреймворком был LlamaIndex. Мы не стали его поддерживать с первых дней, потому что ресурсы в целом были ограничены. Однако в какой-то момент в этом фреймворке неизвестный нам специалист сделал пул-реквест с поддержкой GigaChat и использовал для этого нашу базовую библиотеку. Владелец LlamaIndex этот пул-реквест посмотрел и подтвердил от своего имени. Получается, что за счет опенсорс-сообщества мы добавили для GigaChat поддержку крайне популярного фреймворка для разработки агентов. Это прямая выгода от открытого подхода. Огромному количеству людей, которые делают агентов на LlamaIndex с очередным обновлением становится доступен GigaChat, и это достаточно выгодно для Сбера.

В-третьих, опенсорс — это то глобальное сообщество, которое даёт реальную пользу тем, кто принимает в нём активное участие.