ML System Design Doc - [RU]

Дизайн ML системы сервиса PostFinder

1. Цели и предпосылки

1.1. Зачем идем в разработку продукта?

  • Бизнес-цель:

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

  • Проблематика:

    • Накопление повторных вопросов от пользователей, перегружающих поддержку.

    • Недостаточная видимость старых, но релевантных постов для пользователей.

    • Долгий процесс поиска и отсутсвие хорошей системы поиска внутри телеграмма.

  • Преимущества использования ML:

    • Использование современных LLM для автоматизации семантического поиска в большом объеме текстовой информации.

    • Суммаризация и предоставление релевантных ответов без необходимости ручного поиска.

  • Критерии успеха:

    • Интеграция бота в активные телеграм-каналы и обеспечение пользователей ответами на вопросы с помощью бота.

    • Пользователи находят ответы на свои вопросы в нашем телеграм боте.

  • Пользовательские потребности (исходя из USM и CJM):

    • Разрешение пользовательской необходимости в быстром и точном поиске информации внутри телеграм-каналов.

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

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

    • USER STORY MAPPING:

    • CUSTOMER JOURNAY MAP

  • Ожидаемый пользовательский опыт:

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

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

1.2. Бизнес-требования и ограничения

  • Краткое описание бизнес требований

    • Разработка интуитивно понятного интерфейса для задавания вопросов в чате.

    • Создание системы для автоматического отвечания на вопросы на основе данных из социальных сетей.

    • Интеграция с основными социальными платформами с акцентом на экономию времени и повышение вовлеченности пользователей.

    • Соблюдение правил конфиденциальности и данных, включая GDPR.

  • Бизнес-ограничения

    • Разработка и тестирование в рамках бюджета и сроков проекта.

    • Обеспечение конфиденциальности и соответствие требованиям GDPR.

    • Управление зависимостями от сторонних API и поддержание модели в рамках финансовых ограничений.

  • Итерации проекта

    • Первая итерация:

      • Прототипирование основного функционала для демонстрации возможности системы.

    • Вторая итерация:

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

    • Третья итерация:

      • Оценка производительности на реальных данных и масштабирование. Добавление антифрода аккаунтов и запросов. Сообщения об ошибках, систему лайков и интента команд.

    • Четвертая итерация:

      • Доработка системы на основе пользовательской обратной связи и оптимизация производительности. Создание системы подписок и ограничение пользовательских функций и чарн рейт.

  • Описание бизнес-процесса пилота

    • Интеграция и тестирование системы на выбранных платформах.

    • Сбор и анализ обратной связи для последующих улучшений системы.

  • Критерии успеха и возможные пути развития проекта

    • Снижение числа повторных вопросов и повышение качества ответов.

    • Развитие: расширение функциональности, поддержка новых платформ, улучшение алгоритмов.

1.3. Что входит в скоуп проекта/итерации, что не входит

  • Какие БТ будут покрыты с технической точки зрения за первую итерацию:

    • Интеграция с API для анализа и классификации запросов пользователей на естественном языке.

    • Реализация базы данных для хранения и извлечения данных с использованием chroma db.

    • Разработка и тестирование алгоритма поиска для эффективного нахождения релевантных ответов.

  • Что не будет закрыто:

    • Ограниченная интеграция с социальными платформами, сосредоточенная только на основных платформах.

    • Итерационная оптимизация производительности: начальные версии могут не поддерживать полный объем запросов.

    • Неполная асинхронность обработки запросов и масштабирование системы.

  • Какие БТ будут покрыты с технической точки зрения за вторую итерацию:

    • Создание диалоговой системы, чат-бота с RAG и Memory

    • Ассинхронность запросов

    • Ручной фрод аккаунтов (Админка)

  • Какие БТ будут покрыты с технической точки зрения за третью итерацию:

    • Интент комманды

    • Поиск без указания канала или ресурса

    • Автоматический фрод аккаунтов или запросов

  • Описание результата с точки зрения качества кода и воспроизводимости

    • Код

      • Соответствие стандартам чистого кода и PEP8, использование Numpy Docstring для документирования.

      • Применение pre-commit-hooks для автоматической проверки кода RUFF.

    • Все тесты в GitHub actions должны быть пройдены.

      • RUFF ✅

      • Успешная установка зависимостей через Poetry и сборка виртуального окружения. ✅

      • Отсутствие конфликтов среды и пакетов, корректная сборка Dockerfile. ❌

      • Проведение нагрузочных тестов и асинхронная работа кода, проверка функциональности бота, подключения к API и работоспособности баз данных. ❌

      • Все изменения кода подвергаются code review перед слиянием в основную ветку. ✅

    • Последовательность проверки кода:

      • Выбора задачи в todoist

      • Cоздания ветки в Git для этой задачи и ее выполнения

      • Pull request в Main с коротким описанием изменений

      • Код проверяет более опытный товарищ и после мерджит в Main или пишет какие коррективы стоит еще внести

      • Задача закрывается как выполненая в todoist

  • Описание планируемого технического долга

    • Рассмотрение возможности интеграции с дополнительными API, включая OpenAI, для улучшения функциональности и качества ответов. ❌

    • Исследование альтернативных сервисов социальных сетей и способов интеграции. ✅

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

1.4. Предпосылки решения

  • Для создания системы, которая отвечает на потребности бизнеса и пользователей, учитываем следующие предпосылки:

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

    • Горизонт прогноза: Система будет ориентирована на немедленный ответ без прогнозирования долгосрочных трендов.

    • Гранулярность модели: Ответы на вопросы будут генерироваться на уровне каждого запроса с использованием контекстно-зависимой обработки естественного языка.

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

2. Методология Data Scientist

2.1. Постановка задачи

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

2.2. Блок-схема решения

Блок-схема будет включать следующие ключевые этапы:

  • Подготовка данных: Препроцессинг запросов и исторических данных постов.

  • Разработка модели: Прототипирование и настройка LLM для интерпретации запросов и поиска ответов.

  • Оптимизация: Тонкая настройка и рефакторинг для улучшения точности и скорости ответов.

  • Тестирование: Валидация системы на реальных пользователях и сбор обратной связи.

  • Закрытие технического долга: Работа над известными проблемами и улучшение инфраструктуры.

  • Подготовка пилота: Интеграция системы с тестовыми каналами и начальные испытания.

2.3. Этапы решения задачи Data Scientist

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

user

user_id

telegram_id username first_name last_name registered_at

subscription_type

type_id

type_name montly_price

user_subscription

subscription_id

user_id type_id valid_from valid_to

user

user_id

telegram_id username first_name last_name registered_at

subscription_type

type_id

type_name montly_price

user_subscription

subscription_id

user_id type_id valid_from valid_to

  • Этап 1 – Подготовка данных: Загрузка, предобработка и векторизация постов целевого канала* для обучения модели, сохранение полученных эмбеддингов, например, в Chroma DB. На выходе — набор эмбеддингов постов целевого канала*. *Целевой канал: для автора – канал, к которому он подключает чат-бота, для пользователя – канал, который он выбирает для поиска информации.

  • Этап 2 – Обработка запроса пользователя: Получение, предобработка и векторизация запроса пользователя, передача его в систему семантического поиска. На выходе — эмбеддинг запроса пользователя.

  • Этап 3 – Семантический поиск: Определение схожести* запроса пользователя и информации в постах канала. На выходе — набор постов целевого канала, соответствующих запросу пользователя и отсортированных в порядке значимости согласно выбранному алгоритму. *Возможные варианты определения схожести: косинусное сходство, расстояние Жаккара, предварительно обученные языковые модели (BERT, GPT и др.) для измерения сходства эмбеддингов. Необходимо тестирование для определения оптимального варианта с учетом обрабатываемого объема информации, доступных вычислительных ресурсов и качества получаемого результата.

  • Этап 4 – Получение обратной связи: Оценка пользователем качества выданных чат-ботом ответов. Это необходимо для оценки работы алгоритма и выбора направлений для улучшения качества выдачи.

  • Этап 5 – Адаптация модели: Добавление системы отслеживания метрик эффективности, например, точности и полноты ответов. Здесь же может быть фиксация изменений качества при выборе на этапе 3 различных API.

  • Этап 6 – Формирование отчета: Описание используемых методов и параметров, достигнутых показателей эффективности, полученных данных для анализа и дальнейших доработок и улучшения чат

3. Подготовка пилота

3.1. Способ оценки пилота

  • Для оценки пилота сервиса PostFinder будет использован подход A/B тестирования, где одна группа пользователей продолжит использовать телеграм-канал без интегрированной системы PostFinder, а другая группа получит доступ к сервису. Оценка эффективности будет проводиться на основе следующих параметров:

    • Время на поиск ответа: Измерение времени, которое потребуется пользователям на нахождение информации с помощью PostFinder по сравнению с традиционным способом.

    • Точность ответов: Анализ релевантности предоставляемых ответов, основанный на отзывах пользователей и их взаимодействии с ботом.

    • Удовлетворенность пользователей: Опросы пользователей для сбора данных о их удовлетворенности сервисом.

    • Количество повторных запросов: Сравнение количества повторных вопросов в чате с и без сервиса PostFinder.

    • LTV: Количество пользователей который остаются и уходят от нашего продукта

    • DAU: Количество уникальных пользователей которые ежедневно приходят к нам

3.2. Что считаем успешным пилотом

Пилот считается успешным, если наблюдается статистически значимое улучшение в следующих областях:

  • Снижение времени на поиск ответа: Значительное уменьшение времени, которое пользователи тратят на поиск ответов на свои вопросы.

  • Повышение точности ответов: Увеличение процента точных и релевантных ответов, полученных пользователями.

  • Улучшение удовлетворенности пользователей: Позитивная динамика в отзывах пользователей и оценках удовлетворенности сервисом.

  • Сокращение повторных запросов: Уменьшение количества повторных вопросов на одни и те же темы, что свидетельствует об улучшении доступности информации.

3.3. Подготовка пилота

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

  • Оценка ресурсов: Расчет необходимого объема вычислительных ресурсов для обработки пользовательских запросов.

  • Определение бюджета: Установление бюджета, доступного для проведения пилота, и соответствующего распределения ресурсов.

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

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

4. Внедрение для production систем, если требуется

4.1. Архитектура решения

4.1. Архитектура решения

  • Для внедрения в production система PostFinder будет развернута в соответствии с моделью, которая предусматривает масштабируемость, отказоустойчивость и быстрый отклик. Архитектура системы разделена на следующие компоненты:

    • Веб-интерфейс или API для пользовательских запросов: Будет обрабатывать входящие запросы от пользователей и возвращать ответы.

    • Сервис обработки естественного языка (NLP): Использует модели LLM для интерпретации запросов и поиска соответствующих ответов в базе данных.

    • База данных: Хранит информацию о постах и исторические данные запросов пользователей.

    • Система управления сессиями: Поддерживает состояние взаимодействия с пользователем.

    • Балансировщик нагрузки: Распределяет запросы по серверам для оптимизации производительности и предотвращения перегрузки.

Блок схема архитектуры доступна по ссылке

4.2. Описание инфраструктуры и масштабируемости

  • Описание инфраструктуры и масштабируемости

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

  • CI/CD

  • GitHub Actions

  • TimeWeb/Selectel/YandexCloud/MtsCloud

  • AirFlow/Dagster

  • Docker

4.3. Требования к работе системы

Система будет разработана с учетом следующих требований:

  • Отказоустойчивость: Реализация нескольких уровней резервирования и быстрого восстановления работы в случае сбоев.

  • Отклик: Система нацелена на предоставление ответов в рамках ~1ms, что обеспечивает почти мгновенный отклик на пользовательские запросы.

4.4. Безопасность данных

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

Разработка включает:

  • **Шифрование данных: Все данные, передаваемые и хранимые системой, будут зашифрованы.

  • **Управление доступом: Строгая политика управления доступом для предотвращения неавторизованного доступа к информации. [Антифрод запросов, аккаунтов, телеграм каналов]

4.5. Риски

В процессе внедрения системы учитываются следующие риски:

  • Отключение API сервисов: Разработка альтернативных механизмов взаимодействия с данными в случае изменения условий использования API сторонних сервисов.

  • Атаки на сервис: Реализация системы мониторинга и средств обнаружения вторжений для своевременного реагирования на угрозы безопасности. [Антифрод]

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

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

5. Контрибьюторы

6. Благодарности

7. Допольнительные документы

Previousdocs

Last updated