Практическое занятие ПР-6

Архитектор памяти

Ролевая деловая игра с соревновательным элементом. Спроектируйте архитектуру памяти ИИ-агента «АкадемБот» для университетской среды.

60–80 мин 👥 12–24 студента 🏢 3–4 команды 📅 5 фаз
🎯

Подготовка к игре

Контекст, легенда и распределение ролей

Легенда: Год 2027. Крупная образовательная платформа запускает интеллектуального агента-ассистента «АкадемБот» для университетской среды. Агент должен помнить прогресс тысяч студентов, актуальные учебные программы, расписание, политики оценивания — и при этом работать в жёстких рамках бюджета токенов. Ваши команды — разработчики, конкурирующие за контракт.

Цель: Спроектировать архитектуру памяти для «АкадемБота», которая наберёт максимальный суммарный балл по критериям надёжности, масштабируемости, актуальности данных и стоимости.

Роли в команде

🏗️

Архитектор памяти

Отвечает за выбор типов памяти (слои L1–L4) и стратегий хранения. Определяет, какая информация хранится где и как долго.

🔍

Инженер по поиску

Проектирует конвейер извлечения: тип обогащения контекста, стратегию разбивки на фрагменты (chunking), ранжирование результатов.

🛡️

Инженер по надёжности

Анализирует риски галлюцинаций и устаревания данных. Предлагает механизмы отслеживания и обновления фактов.

📋

Владелец продукта

Формулирует требования от имени университета. Оценивает практическую реализуемость и экономичность решений.

📊

Аналитик (опционально)

Готовит финальную презентацию архитектуры, визуализирует решения, помогает команде структурировать аргументы.

📨

Фаза 1. Брифинг и анализ требований

Каждая команда получает карточку клиента с уникальными требованиями

10:00

Задание: Владелец продукта анализирует карточку клиента, команда обсуждает ограничения и задаёт уточняющие вопросы преподавателю (заказчику). Нажмите на карточку, чтобы увидеть подробные требования.

🧩

Фаза 2. Проектирование архитектуры

Заполните «Архитектурную карту АкадемБота»

20:00

Каждое решение должно быть аргументировано. «Нравится» не принимается — объясните, почему выбранная архитектура лучше альтернатив для вашего сценария.

Фаза 3. Испытание: «Инциденты»

Непредвиденные события, проверяющие устойчивость архитектуры

15:00

Правило: После вытягивания карточки инцидента у каждой команды есть 3 минуты, чтобы объяснить, как их архитектура справится с ситуацией.

🎲 Колода инцидентов

Нажмите кнопку, чтобы вытянуть карточку

3:00

Осталось карточек: 12 / 12

🎤

Фаза 4. Презентация и защита

Каждая команда за 3–4 минуты представляет ключевые решения

04:00

Формат: Команда за 3–4 минуты представляет ключевые решения. Другие команды и преподаватель задают вопросы, указывают слабые места, предлагают контрсценарии.

На что обратить внимание при защите:

• Какие типы памяти выбраны и почему?
• Как конвейер RAG обрабатывает разные типы запросов?
• Как система справляется с устареванием данных?
• Какие компромиссы были сделаны и почему?
• Как архитектура пережила инциденты?

Порядок выступлений

🏆

Фаза 5. Оценка и рефлексия

Подведение итогов, объявление победителя, обсуждение

10:00

📝 Оценка команд

🏆 Таблица лидеров

💭 Вопросы для рефлексии

Что оказалось самым сложным в проектировании?

нажмите для подсказки

Обычно — балансирование между полнотой контекста и бюджетом токенов. Чем больше информации мы пытаемся дать агенту, тем дороже каждый запрос. Это фундаментальный trade-off в архитектуре памяти ИИ-агентов.

Какие реальные системы используют похожие подходы?

нажмите для подсказки

ChatGPT использует многоуровневую память (системный промпт → memory → retrieval). Notion AI, Perplexity, Google NotebookLM используют RAG. GitHub Copilot использует контекстное окно как L1 и индексацию репозитория как L3. Mem0 — open-source решение для управления памятью агентов.

Как изменилось бы решение при бюджете в 10 раз больше?

нажмите для подсказки

Можно расширить L1 (контекстное окно), использовать более крупные модели эмбеддингов, добавить мультимодальный поиск, увеличить количество извлекаемых чанков и добавить re-ranking этап.

Какой слой памяти оказался самым критичным и почему?

нажмите для подсказки

Часто L2 (краткосрочная / рабочая память) — именно она определяет качество диалога. Но для образовательного контекста L3 (долгосрочная / извлекаемая) критична из-за объёма учебных материалов, которые не помещаются в контекстное окно.

Что бы вы изменили в архитектуре после фазы инцидентов?

нажмите для подсказки

Обратите внимание: инциденты выявляют слепые зоны начального проектирования. Большинство команд после инцидентов хотят добавить: механизм version control для фактов, систему приоритетов источников, и fallback-стратегию при недоступности хранилища.

📖 Справочник: Архитектуры памяти

Слои памяти (L1–L4)

СлойНазваниеОписаниеАналогия
L1 Сенсорная / контекстное окно Текущий промпт, системное сообщение, последние сообщения диалога. Ограничена размером контекстного окна модели. Оперативная память (RAM)
L2 Краткосрочная / рабочая История текущей сессии, промежуточные результаты рассуждений, сжатые саммари предыдущих ходов. Кэш процессора
L3 Долгосрочная / извлекаемая Векторные базы данных, графы знаний, индексированные документы. Доступ через RAG-конвейер. Жёсткий диск (SSD)
L4 Параметрическая / обученная Знания, «вшитые» в веса модели при обучении или дообучении (fine-tuning). Прошивка (firmware)

Типы обогащения контекста

Стратегии разбивки (Chunking)

Хранилища данных

Управление устареванием