ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Реализовать user trust метрику

1. Цель задачи

Научиться проектировать и вычислять метрику пользовательского доверия (trust score) на основе поведенческих сигналов в AI-ассистенте или RAG-системе. Trust score позволяет оценить, насколько пользователь склонен доверять ответам системы, исходя из таких действий, как копирование, клики на источники, время чтения, лайки/дизлайки. Результатом будет рабочий пайплайн сбора событий, расчёта trust score и визуализации его динамики.

Ключевой результат Реализованный сервис (или ноутбук), который агрегирует поведенческие события пользователя и вычисляет числовой trust score (0–1) с интерпретацией, а также дашборд для мониторинга.

2. Исходные данные

Если нет реального инструмента — симулируем:

1. Написать Python-скрипт generate_events.py, который создаёт таблицу событий (CSV/JSON) со следующими колонками:
   • user_id (str)
   • timestamp (datetime)
   • event_type (copy / click_source / like / dislike / dwell_time_sec / request_rephrase / open_detail)
   • session_id (str)
   • value (число или None — для dwell_time в секундах)
2. Сгенерировать не менее 100 записей для 10 разных пользователей.
3. Добавить «шум» и пропуски, чтобы данные были реалистичными (например, 5% пользователей не совершают никаких действий).

3. Технологический стек

4. Этапы выполнения

Этап 1: Проектирование метрики и весов (30 минут)

Действия

1. Определить, какие события будут влиять на trust score. Рекомендуемый минимальный набор:

   • copy — пользователь копирует ответ (положительный сигнал)
   • click_source — клик по ссылке на источник (положительный, сильнее copy)
   • dwell_time_sec — время, проведённое на странице с ответом (>15 сек — положительно, <3 сек — отрицательно)
   • dislike — дизлайк (сильный отрицательный сигнал)
   • rephrase_request — пользователь просит переформулировать (лёгкий отрицательный)

2. Установить веса для каждого типа события (нормировать так, чтобы итоговый score был от 0 до 1). Пример:

3. Написать формулу:
   $$trust_score = \max(0,\ \min(1,\ 0.5 + \sum (w_i \cdot count_norm_i)))$$
   где $count_norm_i$ — количество событий данного типа за период, нормированное на количество диалогов пользователя.
   Можно использовать экспоненциальное сглаживание для учёта давности событий.

4. Документировать метрику в TRUST_METRIC_DESIGN.md.

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

Этап 2: Генерация / сбор событий (1 час)

Действия

1. Разработать класс EventCollector (или скрипт), который:

   • Принимает события через REST API (POST /event) или читает из CSV.
   • Валидирует схему (обязательные поля, типы).
   • Сохраняет в SQLite (таблица events).

2. Написать генератор синтетических событий (если нет реальных данных):

   • Создать 10 пользователей с разными профилями: «доверчивый» (много copy/click), «скептик» (много dislike/rephrase), «нейтральный».
   • Распределить события по времени (например, за последние 7 дней).
   • Сохранить в data/events.db.

3. Протестировать сбор: отправить несколько тестовых событий через curl или requests, проверить запись.

Ожидаемый результат этапа Работающий сборщик событий + база данных с ~100+ записей.

Этап 3: Расчёт trust score (1 час)

Действия

1. Реализовать функцию compute_trust_score(user_id, as_of_date, lookback_days=7):

   • Загружает события из БД за указанный период.
   • Группирует по типу, считает count, нормирует на количество диалогов (или sessions) за тот же период.
   • Применяет веса и формулу из этапа 1.

2. Добавить поддержку экспоненциального сглаживания (опционально):
   $$score = [alpha](/wiki/alpha) \cdot score_{today} + (1-[alpha](/wiki/alpha)) \cdot score_{yesterday}$$
   с $[alpha](/wiki/alpha) = 0.3$.

3. Написать unit-тесты с использованием pytest:

   • Проверить, что пользователь с только положительными событиями получает score > 0.7.
   • Проверить, что пользователь с только дизлайками получает score < 0.3.
   • Проверить граничные случаи (нет событий → score = 0.5).

4. Создать скрипт calculate_all_scores.py, который вычисляет score для всех пользователей и выводит таблицу.

Ожидаемый результат этапа Модуль trust_score.py с функцией расчёта и покрытием тестами.

Этап 4: Визуализация и интерпретация (1 час)

Действия

1. Построить дашборд с помощью Plotly (или Streamlit) в dashboard.py:

   • График «Trust score по дням» для выбранного пользователя.
   • Гистограмма распределения trust score среди всех пользователей.
   • Топ-5 событий, повлиявших на score.
   • Таблица пользователей с текущим score и цветовой индикацией (зелёный >0.7, жёлтый 0.4–0.7, красный <0.4).

2. Добавить интерпретатор: функция interpret_score(score) возвращает текстовый комментарий (например, «Пользователь доверяет системе», «Требуется внимание», «Низкое доверие»).

3. Опционально: экспортировать графики в PNG/PDF для отчёта.

Ожидаемый результат этапа Интерактивный дашборд + текстовые отчёты.

Этап 5: Валидация и A/B-тест (имитация) (30 минут)

Действия

1. Создать симуляцию A/B-теста:

   • Группа A — старая версия ассистента (без изменений).
   • Группа B — улучшенная версия (более точные ответы, больше источников).
   • Сгенерировать события для обеих групп (группа B должна показать более высокий trust score).

2. Сравнить средний trust score между группами с помощью t-теста.

3. Задокументировать результат: подтвердить, что метрика чувствительна к качеству системы.

Ожидаемый результат этапа Отчёт о валидации метрики (раздел в README).

5. Критерии приемки (Definition of Done)

• Разработан и задокументирован дизайн trust score (формула, веса, нормализация).
• Реализован сбор событий (REST endpoint или импорт из CSV).
• Написана функция расчёта trust score, покрытая unit-тестами (минимум 4 теста).
• Сгенерированы синтетические данные для 10+ пользователей.
• Создан дашборд (статический или интерактивный) с динамикой score.
• Проведена имитация A/B-теста, метрика показала значимое различие.
• Код залит в Git-репозиторий с README, инструкцией по запуску.
• В README описаны ограничения метрики и возможные улучшения.

6. Ожидаемый результат

Основной артефакт Git-репозиторий со следующей структурой:

├── README.md                    # описание, запуск
├── TRUST_METRIC_DESIGN.md       # дизайн метрики
├── src/
│   ├── event_collector.py       # сбор событий (API или парсер)
│   ├── trust_score.py           # расчёт scores
│   ├── dashboard.py             # визуализация
│   └── generate_events.py       # синтетический генератор
├── data/
│   └── events.db                # база событий (или CSV)
├── tests/
│   └── test_trust_score.py      # unit-тесты
├── reports/
│   └── validation_report.md     # результаты A/B-теста
└── requirements.txt

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

Дополнительно

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

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

При первом выполнении рекомендуется заложить +1 час на изучение инструментов и отладку.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я проверил, что trust score корректно реагирует на положительные и отрицательные события (тесты проходят).
• В дашборде отображается динамика для каждого пользователя.
• События собираются через REST API (если выбран такой путь) и сохраняются в БД.
• В README написана команда для запуска и пример curl-запроса.
• Я провёл имитацию A/B-теста и убедился, что метрика чувствительна к изменениям.