ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Спроектировать partial failure UI

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

Спроектировать пользовательский интерфейс для RAG-системы, корректно отображающий ситуацию, когда модуль retrieval не нашел релевантных документов в векторной базе знаний, но LLM сгенерировал ответ на основе своей внутренней памяти (общих знаний). Пользователь должен явно видеть, что ответ не подкреплён источниками из предоставленной базы знаний, и понимать лимиты системы.

Ключевой результат Прототип UI (макет или интерактивный прототип) с явной индикацией partial failure, понятной пользователю за 3 секунды.

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

Перед началом необходимо иметь:

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

1. Создать простой REST API на Python (Flask/FastAPI), который принимает запрос, имитирует retrieval (с вероятностью 30% возвращает "not_found") и возвращает JSON с полями retrieval_status: "found" | "not_found", answer: str, sources: list[str].
2. Развернуть локально статический HTML-файл с встроенным JS, который отправляет запросы на этот API и отображает ответ.
3. Использовать готовые библиотеки CSS (например, Tailwind) для стилизации индикаторов.

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

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

Этап 1: Анализ требований и исследование пользователей (30–45 минут)

Действия

1. Изучить существующие UX-паттерны для обозначения неопределённости или отсутствия источников:

   • ChatGPT: сноски "AI may produce inaccurate information"
   • Perplexity: явные ссылки на источники; если нет — "No sources found". Как они показывают?
   • Claude: может сказать "I don't have specific information on that"
   • Поискать best practices по отображению "partial failure" в документации.

2. Определить требования к индикации

   • Сигнал должен быть заметным, но не пугающим (например, жёлтый/оранжевый предупреждающий блок).
   • Должен быть текст: "Ответ основан на общей информации, так как релевантные документы не найдены. Проверьте данные в базе знаний."
   • Должен быть визуальный элемент: иконка, изменённый фон сообщения.
   • Не должен блокировать взаимодействие.

3. Определить метрики успеха UX

   • Пользователь в тесте замечает индикатор за < 3 секунд.
   • Пользователь верно интерпретирует (опрос: "Что означает этот индикатор?").
   • Время на понимание: < 5 секунд.

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

Этап 2: Проектирование макетов (1–2 часа)

Действия

1. Нарисовать 3 варианта UI для отображения partial failure:

   • Вариант A (полоска предупреждения сверху): Вместо обычного ответа — карточка с жёлтой полосой слева и текстом: "Информация без подтверждения из базы знаний. [Подробнее]".
   • Вариант B (иконка статуса): Рядом с ответом иконка (например, "глаз" с перечёркиванием) и тултип "Ответ не основан на документах".
   • Вариант C (разделение на две области): Верхняя часть — чёткое предупреждение с фоном warn, нижняя — сам ответ, но с пометкой "Источники: отсутствуют".

2. Создать mockup в Figma для всех вариантов, включая состояния:

   • Успешный retrieval (зелёный индикатор, источники видны).
   • Partial failure (жёлтый, текст "Ответ не основан на документах").
   • Полный failure (красный, "Не удалось найти информацию").

3. Добавить интерактивность в Figma (prototype mode): нажатие на "Подробнее" показывает всплывающее окно с объяснением.

Ожидаемый результат этапа 3 макета в Figma (или скетчи в другом инструменте) с различными подходами.

Этап 3: Реализация интерактивного прототипа (2–3 часа)

Действия

1. Создать простой HTML/CSS/JS прототип на основе одного выбранного варианта (лучшего по результатам этапа 2).

   • Использовать Tailwind или чистые стили.
   • Адаптивный дизайн (мобильный/десктоп).
   • JSON от бэкенда (API из этапа 2) или заглушка.

2. Реализовать backend-заглушку (FastAPI или Flask) с одним эндпоинтом /ask:

   • POST, принимает JSON {"question": "..."}.
   • Возвращает {"status": "partial_failure" | "success", "answer": "...", "sources": [], "message": "..."}.
   • Вероятность: 30% partial_failure.

3. Frontend

   • Отправляет запрос при вводе вопроса.
   • Показывает спиннер загрузки.
   • В зависимости от статуса отображает соответствующий UI.
   • Для partial_failure: обязательный жёлтый баннер с текстом, иконка предупреждения.
   • Для success: зелёный индикатор и список источников.

4. Добавить пояснительный текст при клике на "Почему так?" (модальное окно или спойлер).

Ожидаемый результат этапа Рабочий HTML-прототип с серверной частью, демонстрирующий partial failure UI.

Этап 4: Юзабилити-тестирование (30–60 минут)

Действия

1. Подготовить 3–5 тестовых сценариев

   • "Найди информацию по теме X (она есть в базе)".
   • "Задай вопрос по теме Y (её нет в базе)".
   • "Как система показывает, что ответ не из документов?"

2. Пригласить 2–3 коллег (или друзей) в роли тестировщиков.

   • Попросить их выполнить сценарии.
   • Записывать экран и действия.

3. Замерить

   • Время до первого замечания индикатора partial failure.
   • Понимание сообщения (спросить после теста: "Что означает жёлтый баннер?").
   • Общее впечатление.

4. Собрать фидбек что непонятно, что раздражает, что можно улучшить.

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

Этап 5: Итерация и финализация (1–2 часа)

Действия

1. На основе фидбека доработать прототип

   • Изменить цвет, расположение, текст.
   • Добавить/убрать элементы.
   • Улучшить анимацию (например, плавное появление баннера).

2. Подготовить финальный отчёт с описанием UI, скриншотами, результатами тестирования.

3. Создать документацию по компоненту (для разработчиков и дизайнеров): как использовать, когда показать, какие сообщения.

Ожидаемый результат этапа Финальный прототип, отчёт, документация.

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

• Прототип (HTML/Figma) содержит не менее двух состояний: success и partial_failure.
• Partial failure UI явно отличается от success: другой цвет, иконка, текст.
• Текст индикации поясняет пользователю, что ответ не основан на документах из базы знаний.
• Пользователь может кликнуть / навести, чтобы получить более детальное объяснение.
• В юзабилити-тестировании не менее 2 из 3 пользователей правильно интерпретировали индикатор.
• Среднее время замечания индикатора не превышает 5 секунд.
• Код прототипа (если реализован) опубликован в репозитории с README.
• Документация описывает, как компонент интегрируется в существующий чат-интерфейс.

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

Файлы/артефакты

• partial_failure_ui.fig или ссылка на Figma-прототип с 3 вариантами.
• index.html, app.js, backend.py — интерактивный прототип (если код).
• README.md с инструкцией по запуску и демонстрации.
• report.md — отчёт о юзабилити-тестировании (скриншоты, цитаты, метрики).
• component_docs.md — документация для разработчиков.

Содержание отчёта

• Описание выбранного варианта UI и обоснование.
• Результаты тестирования (таблица с метриками).
• Фидбек и изменения.

Опционально GIF-демонстрация поведения.

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

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

Примечание Для первого выполнения с изучением инструментов время может увеличиться до 10 часов. Рекомендуется работать в паре (дизайнер + разработчик).

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

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

• Я проверил, что в прототипе partial failure UI заметно отличается от успешного.
• Я проверил, что текст индикации понятен и не вызывает ложной тревоги.
• Я провёл хотя бы одно короткое юзабилити-тестирование и записал результаты.
• Я подготовил документацию, которая позволит разработчику воспроизвести поведение.
• Я сравнил свой дизайн с существующими практиками в ChatGPT/Perplexity и убедился, что он не хуже.
• Я убедился, что прототип работает на мобильном экране (адаптивный).
• Я загрузил код и макеты в репозиторий с README.