Attie и atproto в дипломе: ИИ-генератор кастомных фидов как тема ВКР
28 марта 2026 года TechCrunch сообщил: Bluesky выпустила Attie — приложение, которое с помощью ИИ помогает пользователю собирать собственные ленты в открытом протоколе atproto. Формально новость занимает два абзаца, но за ней стоит смена парадигмы: рекомендательная система перестаёт быть чёрным ящиком внутри платформы и становится пользовательским инструментом поверх открытого стандарта. Для выпускника ИТ-направления это готовый полигон для ВКР — здесь есть распределённая архитектура, ограничения протокола, генеративный ИИ и измеримые метрики качества. Тема защищаема, потому что её нельзя закрыть одним учебником: спецификация atproto живая, инструменты меняются каждые несколько месяцев, а сравнивать решения приходится самостоятельно.
Три темы ВКР, которые вырастают из этой новости
Тема 1. Проектирование ИИ-сервиса генерации кастомных фидов на atproto
Актуальность. Attie показывает рыночный запрос: пользователь хочет описывать ленту словами, а не разбираться в фильтрах и подписках. Платформа даёт для этого открытый протокол, но готовых архитектурных шаблонов в учебной литературе нет.
Цель: разработать сервис, который принимает текстовое описание интереса и разворачивает его в работающий feed generator.
- проанализировать модель данных atproto: DID, репозитории, lexicon-схемы;
- спроектировать конвейер «NL-запрос → правила фильтрации → выдача»;
- реализовать прототип feed generator и подключить его к клиенту;
- оценить задержку выдачи и точность подбора по ISO/IEC 25010.
Структура: глава 1 — протокол atproto, федеративные архитектуры, обзор рекомендательных подходов; глава 2 — архитектура сервиса, схемы взаимодействия AppView/PDS/feed generator, спецификация API; глава 3 — нагрузочное тестирование, расчёт затрат на инфраструктуру, оценка экономического эффекта от замены ручной настройки фильтров.
Тема 2. Сравнительный анализ методов построения пользовательских лент: от эвристик до LLM
Актуальность. Кейс Attie ставит вопрос ребром: где заканчивается логика правил и начинается генеративная модель. Ответ нужно обосновать экспериментально.
Цель: сравнить три подхода (правила на lexicon, классический ML-ранкер, LLM-интерпретация запроса) по качеству и стоимости.
- собрать корпус публичных постов через открытый поток событий;
- разметить выборку и определить метрики (precision@k, nDCG);
- провести замеры латентности и стоимости инференса;
- сформулировать рекомендации по гибридной схеме.
Структура: глава 1 — теоретические основы ранжирования и специфика открытых соцсетей; глава 2 — методика эксперимента, стенд, инструменты сбора метрик; глава 3 — результаты, статистическая значимость различий, экономика внедрения.
Тема 3. Безопасность и приватность пользовательских данных в ИИ-надстройках над федеративными соцсетями
Актуальность. Как только ИИ получает доступ к потоку постов и профилям, появляется класс рисков: утечка через промпт, деанонимизация, злоупотребление OAuth-сессиями. Новость об Attie легитимизирует постановку задачи — инструмент работает с публичными данными, но агрегирует их.
Цель: построить модель угроз и набор организационно-технических мер для ИИ-сервиса поверх atproto.
- классифицировать угрозы по STRIDE применительно к федеративной архитектуре;
- проверить сценарии утечки через контекст модели;
- предложить схему минимизации данных на стороне сервиса;
- оформить требования по ГОСТ 34.602-89.
Структура: глава 1 — нормативная база (152-ФЗ, GDPR, ISO/IEC 27001) и специфика децентрализованных сетей; глава 2 — модель угроз, проектирование защитных механизмов; глава 3 — тестирование на проникновение, оценка остаточного риска, ТЭО.
Аналитическая глава: чем её наполнить, кроме обзора литературы
Слабое место большинства работ по соцсетям — «обзор существующих решений» на пять страниц из маркетинговых страниц. Кейс Attie даёт материал для нормального сравнительного анализа. Стройте таблицу по критериям, которые потом вернутся в выводах.
| Критерий | Ручные фильтры (нативные) | ML-ранкер на сервере | ИИ-надстройка (кейс Attie) |
|---|---|---|---|
| Порог входа для пользователя | Высокий: нужно понимать синтаксис | Низкий, но настройки скрыты | Минимальный: описание словами |
| Прозрачность правил | Полная | Низкая | Средняя: правила можно показать |
| Зависимость от вендора | Платформенная | Платформенная | Снижена за счёт открытого протокола |
| Стоимость инференса | Нет | Средняя | Высокая на LLM |
| Воспроизводимость | Высокая | Средняя | Зависит от версии модели |
Обоснование стека удобно привязать к протоколу: клиентская часть — TypeScript и AT Protocol SDK, сервер генерации лент — Python или Node.js с подпиской на поток событий, хранилище правил — PostgreSQL, кэш выдачи — Redis, наблюдаемость — OpenTelemetry с выгрузкой в Prometheus и Grafana. Каждый выбор подкрепляйте не «популярностью», а требованием из ТЗ: почему не готовый Kubernetes-оператор, почему не serverless при холодных стартах на потоке событий.
Проектная часть: что рисовать и как описывать интеграцию
Ядро архитектуры — три участника: персональный сервер данных (PDS), индексатор/AppView и ваш генератор лент. Задача ВКР — показать, как ИИ-слой встраивается третьим компонентом, не ломая федеративную модель.
- Диаграмма последовательности: пользователь формулирует запрос → сервис обращается к модели → модель возвращает структурированный набор правил → правила компилируются в фильтр → генератор подписывается на поток и отдаёт карточки клиенту.
- Диаграмма компонентов: обязательное разделение «интерпретатор запроса» и «исполнитель ленты», иначе пересборка фида тянет за собой повторный вызов модели и растёт стоимость.
- Схема данных: правила храните декларативно, а не как исполняемый код — это упрощает аудит и повторное использование.
Интерпретацию запроса удобно фиксировать в формате, который затем проверяется валидатором. Пример описания правила для фильтра по языку и ключевым словам:
{
"feed_id": "custom-ai-1",
"rules": [
{ "type": "lang", "op": "in", "value": ["ru", "en"] },
{ "type": "text_match", "op": "any", "value": ["atproto", "federated"] },
{ "type": "exclude_reposts", "value": true }
],
"ranking": { "strategy": "chronological", "window_hours": 48 }
}
Такой артефакт легко защитить: он детерминирован, тестируем и не зависит от вендора модели. Если комиссия спросит «а где здесь ИИ» — ИИ на входе, а не в рантайме выдачи. Это осознанное архитектурное решение, и его нужно явно проговорить в тексте.
Тестирование и метрики: то, за что чаще всего снимают баллы
Кейс Attie полезен ещё и тем, что задаёт естественные ограничения: поток событий непрерывный, а выдача должна укладываться в доли секунды. Значит, метрики делятся на три группы.
| Характеристика (ISO/IEC 25010) | Метрика | Инструмент |
|---|---|---|
| Производительность | p95 задержки выдачи фида, пропускная способность событий/с | k6, wrk, OpenTelemetry |
| Надёжность | Доступность 99,5%, RTO ≤ 15 мин, RPO ≤ 5 мин | Prometheus, Grafana, chaos-тесты |
| Функциональная пригодность | precision@10, nDCG по размеченной выборке | собственный скрипт оценки |
| Удобство использования | Время до первой рабочей ленты, SUS-опрос | юзабилити-тест на 8–10 респондентах |
Отдельно опишите, как собираете тестовые данные: публичный поток событий протокола, собственный корпус сохранённых постов, синтетическая генерация для негативных сценариев. Это снимает типовой вопрос комиссии «откуда вы взяли датасет». Развёртывание прототипа удобно описать через CI/CD-пайплайн: сборка образа, прогон тестов, выкат в Kubernetes-кластер с ограничением ресурсов — так в тексте появляется ещё и инфраструктурная зрелость.
Чему вы научитесь на такой теме
- читать спецификацию открытого протокола и переводить её в проектные решения;
- разделять слои «ИИ-интерпретация» и «детерминированное исполнение» — навык, который ценят на собеседованиях;
- обосновывать стек через требования из ТЗ, а не через моду;
- собирать метрики наблюдаемости и защищать их перед комиссией;
- оформлять документацию по ГОСТ 34.602-89 и ГОСТ Р 7.32-2017 без переписывания шаблона в последнюю ночь.
Типичные ошибки и как их обойти
- Подмена понятий «федеративная сеть» и «обычная соцсеть с API». Нужно показать, что данные хранятся в репозиториях пользователей и сервис не владеет ими. Без этого вся аналитическая глава рассыпается.
- Отсутствие метрик эффективности ИИ-слоя. Фраза «модель работает хорошо» не защищается. Дайте хотя бы одну количественную метрику качества и одну — стоимости запроса к модели.
- Игнорирование требований ГОСТ при оформлении ТЗ. Проверьте разделы «Требования к системе», «Требования к видам обеспечения» и «Стадии разработки» — на рецензии это замечают чаще всего.
Частые вопросы
Обязательно ли писать работающий код, или хватит архитектурной схемы?
Зависит от требований кафедры, но по умолчанию для инженерной ВКР нужен прототип. Достаточно урезанной версии: интерпретатор запроса и генератор ленты без полноценного веб-клиента. Этот минимум уже даёт воспроизводимые метрики.
Как обосновать выбор LLM, если бюджет на инференс нулевой?
Сравнивайте локальную компактную модель с внешним API по трём осям: качество извлечения правил, задержка, стоимость 1000 запросов. Локальный вариант проиграет в качестве, но выиграет в воспроизводимости — это честный вывод для главы 3.
Где брать данные для эксперимента?
Публичный поток событий протокола и открытые репозитории постов. Обязательно опишите процедуру обезличивания и то, что вы работаете только с публичным контентом — это закрывает вопросы этики.
Чертить UML или хватит схем в draw.io?
Формально нотация важнее инструмента. Диаграммы последовательности и компонентов обычно требуются по заданию; остальное допустимо в свободной нотации, но с легендой и едиными обозначениями во всей работе.
Чек-лист перед сдачей
- Каждая задача из введения закрыта выводом в соответствующей главе.
- Ссылка на первоисточник и дата обращения указаны в списке литературы.
- В аналитической главе есть сравнительная таблица минимум по пяти критериям.
- Метрики описаны с методикой замера, а не только с результатом.
- ТЗ и структурные схемы соответствуют ГОСТ 34.602-89, оформление — ГОСТ Р 7.32-2017.
- Все рисунки пронумерованы, подписаны и упомянуты в тексте.
Если тема с ИИ-фидами уже выбрана, но непонятно, как перейти от идеи к главам — начните с бесплатной консультации: разберём ваш случай и подскажем, где взять исходные данные. Обычно цикл работы у наших студентов занимает около 120 часов; при необходимости подключаемся к реализации и оформлению.
Источник: Bluesky leans into AI with Attie, an app for building custom feeds (опубликовано 2026-03-28)
``` **Что здесь сработает на защите:** вы не пересказываете новость, а превращаете её в постановку задачи с проверяемыми метриками. Самая выигрышная связка — «ИИ на входе, детерминированный исполнитель на выходе»: она снимает половину вопросов комиссии о воспроизводимости результатов.