Перезапустили инвест-платформу: ускорили загрузку в 50 раз, наладили 50+ интеграций и запустили ИИ-поиск (+18% к конверсии)

Главное о кейсе

Заказчик пришел к нам с задачей доработать реестр для B2B-платформы-агрегатора инвестиционных проектов. До нас над ним работали две команды, и после них продукт находился в плачевном состоянии. Страницы загружались по 20–60 секунд, данные при обмене с внешними системами терялись, документация отсутствовала.

Наша работа состояла из трех этапов. Первый — экстренная стабилизация за полтора месяца, чтобы продукт смог пройти ключевое отраслевое мероприятие. Второй — системная переработка архитектуры в течение года, в результате которой время загрузки сократилось до 200–500 миллисекунд. Третий — внедрение интеллектуального поиска на базе RAG, что дало снижение доли отказов на 24% и рост конверсии на 18%. Заказчик продолжает работать с нами на постоянной основе.

Как проект изменил жизнь пользователей

Основное изменение — устранение длительного ожидания при работе с реестром. Раньше открытие карточки компании занимало 20–60 секунд, потому что система запрашивала из базы данных все связанные сущности без фильтрации. После переписывания API загрузка страниц сократилась до 200–500 миллисекунд.

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

Третье изменение — появление поиска, который понимает профессиональные запросы. Мы собрали, очистили и векторизовали данные 100 000 профилей компаний, а затем внедрили RAG-поиск. Пользователи получили возможность формулировать сложные инвестиционные запросы и получать точные ответы без нерелевантных результатов. Это подтверждается метриками: отказы снизились на 24%, конверсия выросла на 18%.

Бизнес-задача и ее решение

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

Решение. Мы разделили работу на три последовательных этапа.

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

Системная переработка архитектуры. После мероприятия мы приступили к устранению корневых причин проблем. Мы не исправляли старый код, а написали новую версию API с архитектурой «сервис-репозиторий». Заменили Elasticsearch на полнотекстовый поиск PostgreSQL для пользовательской части. Внедрили шину данных на Kafka, которая замкнула на себя все внешние интеграции и сделала их контролируемыми. Настроили тестовый контур, автоматический деплой, мониторинг ошибок через Sentry и версионирование миграций базы данных через Alembic.

Развитие платформы. После стабилизации мы перешли к улучшению пользовательских функций. На основной платформе заказчика мы внедрили интеллектуальный поиск на базе RAG. Для этого мы сначала разработали скрапер, который собрал актуальные данные по 100 000 профилей. Затем очистили данные от дублей и технического мусора. Перевели очищенные данные в векторное представление через YandexGPT PRO и сохранили в ChromaDB. Только после этого подключили RAG-модель к поиску.

Крафт (мастерство), реализация, технические детали

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

Переписывание API. Старые роуты были построены по единому шаблону на самописном фреймворке предыдущих команд. Каждый запрос извлекал из базы все связанные данные, включая те, которые не требовались для отображения страницы. Мы не вносили точечные правки в эту логику, потому что связи были зашиты глубоко в структуру фреймворка. Вместо этого мы создали новую версию API с паттерном «сервис-репозиторий». Каждый новый эндпоинт запрашивает только те данные, которые нужны для конкретной страницы. Это сократило время загрузки с 20–60 секунд до 200–500 миллисекунд.

Шина данных. До нашей работы обмен данными с внешними системами был реализован фрагментарно. Не было обработчиков ошибок и таймаутов. Мы внедрили шину данных на Kafka, через которую проходят все обращения к внешним сервисам. Шина записывает все сообщения в базу данных, фиксирует статусы и ошибки. Мы переписали формирование файлов для SOAP и REST API, добавили предобработку данных: исключение запрещенных символов, валидацию по справочникам. Настроили полный цикл обмена с CRM-системой, включая обработку ситуации, когда сервер возвращает 500 ошибку, но данные при этом записывает. Там, где возможно, перевели получение данных с периодического опроса API на чтение очередей Kafka.

Подготовка данных для ИИ-поиска. Данные на платформе были низкого качества: анкеты заполнялись вручную, содержали дубли, пропуски и разную структуру. Прежде чем подключать нейросеть, мы разработали скрапер, который обошел сайты компаний и собрал актуальные данные. Затем провели многоуровневую очистку: удалили дубли через TF-IDF, отфильтровали технический мусор, унифицировали структуру анкет. Очищенные данные перевели в векторное представление и сохранили в ChromaDB. После этого внедрили RAG-поиск, при котором модель ищет ответ не в своей памяти, а в данных платформы. Это исключило некорректные ответы.

Инфраструктура и процессы. Мы подняли тестовый контур и связали его с тестовыми средами внешних систем. Внедрили Sentry для мониторинга ошибок и настроили логирование. Настроили автоматический деплой и внедрили Alembic для версионирования миграций базы данных. Разработали и утвердили у заказчика шаблоны отчетности, что исключило многократные переделки документов.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

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

Гипотеза о подготовке данных. Перед внедрением ИИ-поиска мы предположили, что качество ответов модели зависит в первую очередь от качества входных данных, а не от выбора модели. Мы вложили значительные ресурсы в сбор и очистку 100 000 профилей. Результат подтвердил гипотезу: поиск выдает точные ответы без некорректных результатов, доля отказов снизилась на 24%.

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

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

Скриншоты