ИИ в «Финаме»: от первого прототипа на Flutter до корпоративной платформы на 1000+ сотрудников

Цикл статей про внедрение ИИ в «Финаме».
👉 Часть 1: AI в Финаме - обзор ФинамAI
Часть 2: AI в Финаме - внедрение в людей
Часть 3: AI в Финаме - внедрение в разработку

Вступление

Меня зовут Дмитрий Журавлев и я хотел бы поделиться нашим практическим опытом внедрения ИИ-решений в компании «Финам».

Современный бизнес переживает эпоху стремительного роста влияния искусственного интеллекта. В 2023 год мы вошли на волне глобального ажиотажа, вызванного выпуском GPT-3.5 от OpenAI в конце 2022 года. Эта модель не только захватила умы разработчиков и бизнеса, но и стала катализатором для переосмысления того, как ИИ может трансформировать корпоративные процессы.

«Финам» — один из крупнейших розничных брокеров России, который предоставляет комплекс услуг в области трейдинга, инвестиционного консалтинга и инвестиционно-банковских продуктов. Поэтому мне было особенно интересно внедрять ИИ в процессы «Финама». В этом материале я рассказываю, какой опыт я получил, как с коллегами мы масштабировали этот эксперимент, какие инструменты разработали, с какими вызовами столкнулись и как используем ИИ сейчас.

Мой путь начался с личного эксперимента. В январе 2023 года я поставил себе задачу: разработать десктопное приложение командного трекера, используя Flutter — фреймворк, с которым я ранее не работал. Вооружившись GPT-3.5 и бесплатной версией GitHub Copilot, я, без глубоких знаний Flutter, но с богатым опытом разработки, создал рабочий прототип, собранный всего за 12 часов. Этот результат меня поразил - ИИ не просто ускорил процесс, но и открыл новые горизонты для применения технологий в работе.

Естественно, успех личного проекта нельзя было оставить без внимания. После демонстрации прототипа я провел презентацию и воркшоп для коллег, поделившись нашей первой success story. Успешным опытом использования AI поделились и другие коллеги-экспериментаторы. Это стало отправной точкой для более масштабного применения ИИ в «Финаме».

ФинамAI - масштабирование ИИ на 1000+ сотрудников

Какой вопрос следует за успешным применением ИИ силами экспериментаторов? Правильно – «Как распространить этот опыт на более чем тысячу сотрудников “Финама”?».

Ожидания и реальность

Сегодня ответ с точки зрения техники кажется очевидным – взять готовое решение вроде OpenWebUI, подключить его к OpenAI API или использовать универсальный шлюз вроде OpenRouter, добавить LiteLLM как промежуточное звено, приправить n8n – и дело сделано.

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

Поэтому мы решили привлечь внешних партнеров для разработки первой версии собственного аналога OpenWebUI под названием «ФинамAI». Параллельно мы активно наращивали внутренние компетенции и ресурсы, чтобы в дальнейшем подхватить разработку у партнеров и продолжить развитие системы своими силами.
Как только наши команды были готовы, мы взяли проект в свои руки, а партнеров переключили на следующие Proof of Concept (PoC), что позволило нам двигаться вперед сразу по нескольким направлениям.

Просто подключить к проекту API OpenAI было недостаточно, поэтому мы обогатили платформу дополнительными функциями, чтобы она стала полноценным, надежным и безопасным инструментом для работы.

Веб-поиск и загрузка документов

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

На тот момент мы еще не использовали RAG (Retrieval-Augmented Generation), поэтому весь текст документа отправлялся в ИИ напрямую. Это, конечно, имело свои ограничения. Как минимум – по возможному размеру документа, который был ограничен контекстным окном модели, но такое решение уже приносило ощутимую пользу.

Лимитирование запросов

Определяем лимиты

Промпт-тюнинг пришёл не сразу, коллег много, а интерес к этой «магии» у них бешеный — можно запросто посадить API-баланс «в ноль», что вообще не круто. Поэтому ввели лимитирование: 30 запросов в день на человека, но с оговоркой, что по просьбе коллег мы можем этот лимит увеличить.

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

Логирование

Логирование стало краеугольным камнем системы, решая сразу несколько задач.
А именно:

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

• Аналитика промптов
  Качественные запросы — залог качественных ответов. Логи помогали нам анализировать взаимодействия пользователей и готовить материалы для вебинаров по промпт-инжинирингу.

• Понимание потребностей
  Логи – хороший материал, чтобы узнать какие темы волнуют сотрудников чаще всего, что «болит» на этой неделе, какой продукт в топе обсуждений.

• ИИ-ассистент аналитиков логов
  Более того, мы практически закончили работу над ИИ-ассистентом, который анализирует запросы пользователей, и может по запросу предоставлять всем статистику за любой промежуток времени по:

  • количеству обсуждений;

  • категориям обсуждений;

  • проценту обсуждений в позитивном тоне;

  • уровню удовлетворенности ответами (насколько успешно ИИ решает задачу сотрудника);

  • другим критериям.

Выбор моделей

С самого начала для нас было важно не «угадать одну идеальную модель», а выстроить систему, которая допускает изменения и эволюцию. Мы изначально исходили из того, что рынок ИИ будет меняться очень быстро — и, как показала практика, это было правильное предположение.

Исторически наша платформа начиналась с модели GPT-4, затем мы перешли на GPT-4o, а позже — на GPT-4.1.
И именно GPT-4.1 на сегодняшний день остается нашей основной рабочей лошадкой.

Причины довольно приземленные:

• модель достаточно быстрая

• универсальная — подходит для большинства рабочих задач

• достаточно умная, чтобы решать как технические, так и текстовые кейсы

• и при этом разумная по стоимости, что критично при масштабировании на сотни и тысячи пользователей.

К концу 2024 года мы увидели, что одной универсальной модели нам уже недостаточно. Запросы пользователей стали сильно различаться: где-то важна скорость и цена, где-то — глубина рассуждений, а где-то — креативность.

Именно тогда мы начали осознанно расширять пул моделей, а после – и пул провайдеров. Так у нас появился OpenRouter, который дает доступ к сотням моделей.

Эволюция платформы

В начале 2025 года, параллельно экспериментируя с моделями, мы пришли к важным выводам:

• рынок open-source и готовых решений развивается быстрее, чем мы можем развивать собственный продукт ограниченными ресурсами

• всё больше времени уходит не на ценность для бизнеса, а на поддержку базового функционала.

В этот момент мы приняли осознанное решение – не продолжать развивать собственный UI-слой ФинамAI как отдельный продукт, а взять готовое, зрелое решение — OpenWebUI, которое из коробки дает гораздо более богатый и удобный функционал.

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

Сегодня центр коммуникации сотрудников с ИИ — это ФинамAI на базе OpenWebUI с провайдерами OpenAI + OpenRouter + локальные модели.

Речь именно про чат-взаимодействие и историю диалогов — не про разработку. Для разработки у нас используются отдельные инструменты и терминальные агенты.

Работа с большими документами – наша эволюция RAG

В крупной компании вроде «Финама» работа с большими документами — неизбежная и не самая приятная рутина. ИИ способен значительно упростить этот процесс, но мы сталкиваемся с ограничением в виде размера контекстного окна модели. Например, у GPT-4o оно равно 128 тысячам токенов — примерно 250–500 тысяч символов в зависимости от языка и токенизатора. Для обработки объемных отчетов или баз знаний этого часто недостаточно.

RAG напрямую зависит от качества и актуальности данных

На помощь приходит Retrieval-Augmented Generation (RAG) — метод, который позволяет извлечь из большого массива данных только релевантные фрагменты и передать их в ИИ вместе с запросом пользователя. Для реализации RAG мы выбрали векторную базу данных Qdrant.

Почему Qdrant? Относительно простая, популярная, масштабируемая, self-hosted, opensource. Пока ее хватает под все наши задачи. Иногда используем и PgVector, но частота его применения сильно ниже, чем у Qdrant.

Отдельно отмечу, что с приходом OpenWebUI встроенный RAG в виде «Знаний» перестал быть инженерной фичей и стал повседневным рабочим инструментом, существенно упростившим работу с документами для рядовых сотрудников — без кастомных интерфейсов и сложных инструкций.

От простого к сложному

Изначально наш RAG был простым – пользователь вводил запрос, Qdrant искал подходящие фрагменты текста, и они отправлялись в ИИ для генерации ответа. Это хорошо работало для простых задач, но вскоре мы столкнулись с более сложными запросами, например: «Найди информацию о новых финансовых продуктах, сервисах и рыночных новостях, выведи в виде таблицы». Такой запрос выявил несколько проблем:

• Лишние слова.
  Вводная часть вроде «мне нужно, чтобы ты нашел» и финальная «выведи в виде таблицы» – мешали точному поиску.

• Семантическая неоднозначность.
  Фраза «новых финансовых продуктах» не гарантировала, что мы найдем актуальные события, такие как запуск финтех-стартапов или новых финансовых мобильных приложений.

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

Следующий этап

Мы перешли к многоэтапному процессу.

1. Предобработка запроса.
   ИИ анализирует запрос, разделяя его на три части: что хочет пользователь, что искать в документах, в каком виде представить результат.

2. Уточнение и расширение.
   На основе больших фрагментов документа ИИ определяет контекст и подбирает оптимальные сущности для поиска. Например, для «новых финансовых продуктах» он может предложить искать «финтех-стартапы» или «мобильные финансовые приложения» и так далее.

3. Оптимизация поиска.
   ИИ подбирает параметры для векторного поиска (размер фрагментов, перекрытие), учитывая структуру документа — будь то монолитный отчет или разрозненные заметки.

4. Поиск в Qdrant.
   С подготовленным запросом и параметрами мы выполняем поиск релевантных фрагментов.

5. Генерация ответа
   Найденные данные вместе с уточненным запросом передаются в ИИ для создания точного и структурированного ответа.

Этот подход значительно повысил качество обработки сложных запросов.

Дайте мне холст: генерация изображений

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

В «Финаме» мы используем два подхода:

• DALL-E + gpt-image-1 от OpenAI
  Это универсальное решение для создания изображений общего назначения — от иллюстраций для вики-статей до слайдов для презентаций, интегрированное в нашу систему через существующий API OpenAI.

• LoRa-адаптеры на базе Stable Diffusion
  Сервис разработан для лаборатории клиентского опыта «Финама». Обучение и генерация происходят на платформе Replicate.com с использованием датасета, подготовленного нашими дизайнерами. Это позволяет создавать изображения в уникальном корпоративном стиле.

Этот проект стал для нас своего рода «лабораторией» проб и местом «набивания шишек».Поэтому делимся рекомендациями на базе своего опыта.

Управление ожиданиями заказчиков

Погружаясь в мир генеративных изображений, быстро понимаешь, что у каждой модели есть свои «слабые места» — будь то количество пальцев, рук, ног или других деталей. И когда вы говорите: «Мы обучим модель генерировать изображения в нашем стиле», на том конце провода могут услышать: «Подожди пару дней, и дизайнеры начнут получать идеальные картинки, готовые к публикации».

Поэтому важно сразу корректировать ожидания: в зависимости от датасета, качества промпта и сложности сцены, модель может выдавать результаты разного уровня. Редко это 100% готовый продукт, но это отличная заготовка для дизайнеров — достаточно немного доработать и финальный результат готов.

Подготовка датасета

Просто накидать разные папки с архивами разных изображений в кучу – нерабочий вариант для обучения модели. Потому нужно сразу описать правила формирования датасета.

• Определить диапазон разрешений изображений для единообразия – от минимального до максимального.

• Обеспечить преемственность стилистики изображений (например, избегать смешения реализма и мультяшной рисовки).

• Обеспечить разнообразие, ведь котики не помогут генерировать трейдеров или банковские карты.

Собрать достаточный объем данных — 10 изображений явно мало, мы рекомендуем минимум 50, а лучше от 100 изображений.

Анонимайзер – защита конфиденциальной информации

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

Основные возможности сервиса:

• поиск и удаление персональных данных в тексте;

• извлечение чувствительных данных из текста;

• анонимизация данных (замена на безопасные аналоги);

• деанонимизация данных (возврат исходных значений, если анонимизация была выполнена нашим сервисом).

Как работает сервис:

1. Получает запрос пользователя и текст для обработки.

2. Проводит анализ на наличие данных, передача которых запрещена (персональные данные коммерческая и иная конфиденциальная информация).

3. Анонимизирует данные, сохраняя информацию о том, что и где было изменено.

4. Передает анонимизированный текст в AI для дальнейшей обработки.

5. После получения ответа от AI выполняет деанонимизацию, возвращая реальные данные в сгенерированный текст.

Сервис доступен в двух форматах – в виде API для интеграции в AI-процессы и в виде удобного UI-интерфейса в нашем «ФинамAI-центре». Это позволяет как встраивать функционал в существующие системы, так и быстро обрабатывать тексты вручную — всего за пару кликов. Сервис способен распознавать широкий спектр данных: ФИО, города, адреса, паспортные данные, даты, номера телефонов, электронные почты, номера банковских карт, реквизиты организаций, счета, депозиты, аккаунты, договоры, ИНН, СНИЛС и многое другое.

Локальные модели – баланс между безопасностью, стоимостью и эффективностью

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

На рынке можно выделить три основных подхода к использованию локальных моделей, зависящих от размеров компании и объема данных внутри:

• крупные компании-гиганты могут позволить себе содержание мощных GPU-кластеров, разработку собственных AI-решений и даже создание своих LLM моделей. Таких компаний единицы, и кажется, что их можно пересчитать по пальцам одной руки.

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

• средний сегмент, к которому относится и «Финам». Это компании, где данных уже много, чувствительная информация требует защиты, но развертывание полноценных GPU-кластеров пока выглядит излишне затратным.

Мы начинали с нескольких NVIDIA RTX 3090, объединённых в связку. Этого хватало для первых экспериментов и рабочих сценариев. Полноразмерные модели мы не разворачивали — использовали квантованные версии разной размерности, чтобы разумно расходовать ресурсы.

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

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

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