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, имеющей следующую структуру:

CHZjT9f8czkO	c5JD1g0oyitf	6CgAkoRcUkbj
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. Благодарности

• Karpov Courses

• Reliable ML

• AI Tallent Hub

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

• **Превратите свой пет-проект из хобби в карьеру