Первая проверяемая версия платформы «Зеркало мира»
Версия 1.0
Приложение к книге проекта «Восприятие AI. Зеркало мира»
Статус документа
Документ является рабочей нормативной основой проекта. Он фиксирует текущее понимание системы и подлежит уточнению после исследований, юридической экспертизы, пользовательских испытаний и технического прототипирования. Изменения вносятся только с сохранением истории версий.
1. Цель MVP
MVP должен проверить не масштаб всей концепции, а жизнеспособность одного центрального цикла: человек создаёт профиль, приглашает знакомых, наблюдатель изучает материалы и оставляет анонимное Отражение, владелец получает понятную многомерную картину с указанием объёма и достоверности данных.
Главный вопрос MVP: готовы ли люди создавать и получать содержательную обратную связь в форме, отличной от лайка, рейтинга и публичного комментария?
2. Границы первой версии
2.1. Входит в MVP
• регистрация и подтверждение учётной записи;
• создание и редактирование профиля;
• загрузка базового набора фото, видео, аудио и текста;
• формирование персональной ссылки-приглашения;
• контроль минимального знакомства с материалами;
• создание анонимного Отражения;
• базовая агрегация и визуализация результата;
• показ числа Отражений, полноты материалов и уровня достоверности;
• жалобы, блокировки, удаление данных и администрирование;
• событийная аналитика и экспериментальные флаги.
2.2. Не входит в первый релиз
• автоматический окончательный прогноз личности по одному материалу;
• полноценный персональный ИИ-проводник;
• автономные решения о найме, образовании, кредитовании или правах;
• публичный глобальный рейтинг людей;
• биометрическая или «аурическая» диагностика;
• масштабный открытый API для третьих сторон;
• сложные блокчейн-механизмы для устойчивости системы.
3. Пользовательские роли
4. Основные пользовательские сценарии
5. Функциональные требования
5.1. Регистрация и идентичность
1. Поддержать регистрацию по электронной почте или номеру телефона с подтверждением.
2. Хранить согласия пользователя с версией текста и временем принятия.
3. Предусмотреть возрастные ограничения и отдельный режим для несовершеннолетних после юридической проработки.
4. Обеспечить восстановление доступа и защиту от массовой регистрации.
5. Не показывать владельцу профиля личность автора Отражения.
5.2. Профиль и материалы
6. Профиль содержит имя или выбранное отображаемое имя, описание, контексты и набор материалов.
7. Материалы имеют тип, источник, дату, язык, уровень видимости и статус подтверждения.
8. Пользователь может менять порядок материалов и задавать обязательный набор для знакомства.
9. Система вычисляет полноту профиля и предупреждает, если данных недостаточно.
10. Для каждого материала доступны удаление, скрытие и отзыв согласия на анализ.
5.3. Приглашения
11. Создавать уникальные ссылки с ограниченным сроком действия и возможностью отзыва.
12. Поддержать текст приглашения: «Зайди и расскажи, каким ты видишь меня. Мне это важно».
13. Не раскрывать владельцу, кто именно перешёл по ссылке и кто завершил Отражение, если это нарушает анонимность.
14. Показывать агрегированную статистику приглашений без деанонимизации.
5.4. Контроль знакомства
15. Фиксировать просмотр обязательных материалов и минимальное время взаимодействия.
16. Не считать фоново открытый экран достаточным доказательством знакомства.
17. Использовать мягкие контрольные вопросы или подтверждение ключевых фрагментов для части экспериментов.
18. Сохранять показатель полноты знакомства как часть контекста Отражения.
5.5. Форма Отражения
Форма должна занимать не более 5–8 минут в базовом режиме и позволять углубиться в расширенном режиме. Набор полей конфигурируется без выпуска новой версии приложения.
• контекст знакомства: лично, профессионально, по материалам, публичная фигура и другое;
• многомерные шкалы с нейтральной серединой и возможностью «не могу определить»;
• первое впечатление и степень уверенности;
• свободное описание и пример проявления;
• необязательная голосовая запись;
• подтверждение, что Отражение выражает личное восприятие и не содержит намеренной травли.
5.6. Результат
19. После первого сохранённого Отражения показать предварительный результат с явной отметкой низкой достоверности.
20. Показывать число независимых Отражений, полноту материалов, актуальность и устойчивость.
21. Разделять общую картину и отдельные группы только при достаточном размере группы для анонимности.
22. Не показывать точные ответы отдельных людей.
23. Предусмотреть временную шкалу и историю версий результата.
24. Позволить пользователю скрыть результат или удалить профиль.
6. Модель данных
7. Базовая логика агрегации MVP
Первая версия не должна изображать зрелый искусственный интеллект. Для шкал используется прозрачная статистическая агрегация с робастными оценками, минимальным размером выборки и явным показом неопределённости. Свободный текст может автоматически тематизироваться, но итоговые формулировки проходят контроль на недопустимые ярлыки и персональные данные.
• каждое Отражение имеет технический коэффициент качества: полнота знакомства, заполненность, внутренние противоречия, надёжность учётной записи;
• АРГО в MVP может использоваться только в исследовательском или скрытом режиме после калибровки;
• редкое мнение не удаляется из-за несогласия с большинством;
• для показа группы требуется порог анонимности;
• достоверность вычисляется отдельно от значения измерения.
8. Интерфейс
9. API первой версии
Фактическая схема API фиксируется в OpenAPI-спецификации. Все методы проходят авторизацию, проверку прав, ограничение частоты и журналирование критических действий.
10. Нефункциональные требования
11. Безопасность и противодействие злоупотреблениям
• антибот и ограничение частоты действий;
• выявление связанных аккаунтов и координированных кампаний без раскрытия лишних данных;
• запрет публикации прямых угроз, персональных данных и клеветнических утверждений в свободном тексте;
• механизм «карантина» подозрительных Отражений до проверки;
• разделение модераторских и административных полномочий;
• регулярные тесты на проникновение и сценарии реагирования на утечку;
• порог анонимности для групповых срезов и защита от вычисления автора по редкому контексту.
12. Аналитика продукта
13. Тестирование и критерии приёмки
• функциональные тесты всех пользовательских сценариев;
• нагрузочные тесты основных API;
• тесты восстановления и удаления данных;
• проверка анонимности на малых группах;
• юзабилити-тесты минимум с тремя различными аудиториями;
• проверка доступности;
• красная команда против накрутки, травли и деанонимизации;
• контроль воспроизводимости агрегированного результата по версии алгоритма.
MVP принимается не тогда, когда все экраны реализованы, а когда центральный цикл работает, пользователи правильно понимают результат, а система собирает данные достаточного качества.
14. Техническая архитектура MVP
15. Этапы реализации
Сроки являются ориентиром и уточняются после формирования команды и выбора стека. Параллельно ведутся юридическая и исследовательская работы.
16. Минимальная команда
• продуктовый руководитель/основатель;
• технический руководитель;
• 2–3 full-stack или backend/frontend инженера;
• мобильный инженер или кроссплатформенный разработчик;
• продуктовый дизайнер и исследователь;
• инженер данных/ML на экспериментальном контуре;
• специалист по безопасности и приватности на регулярной основе;
• психолог/социальный исследователь;
• юрист по данным и цифровым платформам;
• QA-инженер и модерационный операционный специалист.
17. Комплект поставки
• исходный код и инструкции развёртывания;
• OpenAPI-спецификация;
• схема данных и миграции;
• дизайн-система и интерактивный прототип;
• набор автоматических тестов;
• панель мониторинга и журнал аудита;
• политики приватности, согласий и модерации;
• отчёт пилота с метриками качества и вреда;
• реестр известных рисков и план следующей версии.
КОНЕЦ ДОКУМЕНТА №2
ДОКУМЕНТ №3