designdoc.md

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

• Этап 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. Допольнительные документы

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