Конкретика семантической памяти: как реализовать «агент, который тебя знает». Что записывать, как обновлять, когда поднимать в контекст. И что такое self-evolving prompt — промпт, который растёт сам.
Персонализация — это не «приветствую по имени». Это профиль пользователя, который накапливается со временем и подмешивается в контекст каждого запроса. На входе: явные данные (что пользователь сказал) и неявные (как он реагировал). На выходе: набор устойчивых фактов о нём, который превращает универсального ассистента в персонального. Главный механизм — self-evolving prompt: промпт, в который встраивается профиль и который сам обновляется от каждого взаимодействия.
Семантическая память о пользователе обычно структурирована как профиль — набор пар «свойство → значение». Это не «всё, что мы знаем», а намеренно выбранный набор полей, которые ассистент использует для адаптации.
Хороший профиль обычно состоит из четырёх типов фактов:
Имя, роль/профессия, основной язык, часовой пояс. Самое стабильное — почти не меняется.
Как ответы должны быть оформлены: длина, тон, стиль, формат. Эти факты больше всего влияют на качество персонализации.
Чем человек занимается, что важно сейчас: проекты, текущие задачи, направление работы. Меняется чаще, но даёт нужную релевантность ответов.
Аллергии, противопоказания, чего избегать в темах, что нельзя советовать. Эти факты — самые важные, потому что их нарушение портит доверие сильнее всего.
Пример профиля, который часто встречается у персональных ассистентов:
Когда такой профиль подмешивается в system prompt — ассистент сразу ведёт себя по-другому с разными пользователями: один и тот же запрос «помоги структурировать встречу» получает разные ответы для Андрея-PM и для Марии-преподавателя.
Хорошая персонализация — это не «добавить эмодзи и обращаться по имени». Это «адаптировать содержание и форму ответа под устойчивые свойства пользователя».
Базовая идея self-evolving prompt: система не просто хранит профиль — она сама его обновляет по ходу взаимодействия. Это автоматическая дистилляция, о которой говорили в Дне 11, применённая к профилю пользователя.
Цикл обычно такой:
Это и есть «обучение» в полном смысле — не дообучение модели (что дорого и сложно), а обогащение её рабочего контекста на основе истории взаимодействий.
Ключевое отличие от наивного подхода «пиши всё, что узнаёшь»: тут не идёт хаотичное накопление, а есть дисциплинированная схема профиля, в которую факты вписываются. Если новый факт не вписывается ни в одно поле схемы — он не попадает в профиль (но может попасть в эпизодическую память).
Каждый факт в профиле проходит через стадии. Хорошая система не просто «есть факт / нет факта» — она знает, на какой стадии он находится.
Пользователь упомянул что-то один раз. Система извлекла кандидата на новое поле профиля. Например: «Я как раз готовлюсь к марафону» → кандидат на current_focus: "подготовка к марафону".
На этой стадии факт не используется в подмешивании в контекст. Он живёт как «потенциальный», ждёт подтверждения. Кандидат может быть случайным — пользователь сказал и забыл.
Зачем стадия: отделить «реальные предпочтения» от «случайной болтовни». Если ты сразу запишешь любое упоминание — профиль засорится мусором.
Факт упомянут хотя бы дважды или установлен явно («запомни, я не люблю формальный тон»). Переводится в активные.
Теперь он входит в подмешивание профиля в контекст. Ассистент начинает с ним считаться. Если пользователь не возражает следующие N взаимодействий — факт стабилизируется.
Активный статус не означает «истина навсегда». Если пользователь начнёт говорить иначе — система должна заметить и пересмотреть.
Факт пережил много сессий, неоднократно проверен. Это «опорный» факт профиля — например, «пользователь работает в IT».
На этой стадии факт трудно изменить случайным эпизодом. Если пользователь однажды напишет «я устал от IT» — это не повод сразу убирать поле role. Подтверждённые факты требуют повторного опровержения.
Зачем стадия: устойчивость к шуму. Без неё профиль каждый раз перетряхивается из-за каждой фразы пользователя в плохом настроении.
Пользователь явно сообщил, что что-то изменилось: «я ушёл из IT, теперь работаю в образовании». Старый факт role: "IT" уходит в устаревшие. Не удаляется навсегда — а помечается с датой.
Зачем не удалять: история позволяет понимать контекст («раньше работал в IT — это объясняет, почему пользователь любит технические аналогии»). Но в активное подмешивание в контекст устаревшие факты не идут.
Принцип: память — это не append-only, но и не destructive. Изменения помечаются, история сохраняется, но в рабочий профиль попадают только актуальные значения.
Профиль подмешивается в system prompt. Каждые лишние 100 токенов — это 100 × все запросы пользователя за время жизни сервиса. На большой аудитории это серьёзные деньги.
Хорошее правило: профиль в контексте не больше 200-400 токенов. Это около 10-15 ключевых фактов в компактной форме. Всё, что не помещается — должно жить за пределами активного контекста (в эпизодической памяти, на которую ассистент опирается «по запросу»).
Два подхода к заполнению профиля:
Лучшая практика — гибрид: минимальный onboarding (2-3 вопроса при первом запуске), дальше — неявное обучение через self-evolving prompt. Это даёт быстрый старт плюс постоянное улучшение.
«Пользователь сказал что-то — запишу». В итоге профиль через месяц превращается в свалку из мимолётных упоминаний: «говорил про путешествие в Тбилиси», «упомянул друга Сашу», «жаловался на погоду». Большинство — шум, не имеющий ценности для будущих ответов.
Лечится дисциплинированной схемой: «мы храним в профиле только эти 10 типов фактов, всё остальное — даже если интересно — идёт мимо».
«Система сама всё запомнит, юзеру не надо лезть в настройки». В итоге пользователь чувствует, что «ассистент решил за меня кто я» — и не может это исправить.
Хорошая практика: профиль должен быть видим и редактируем пользователем. Открыл — посмотрел, что система записала про него, может удалить лишнее, исправить неверное. Это и про доверие, и про качество (пользователь сам поможет очистить шум).
Ассистент в каждом ответе напоминает: «Поскольку вы любите краткость, я отвечу коротко...», «Я помню, что вы PM, поэтому...». Раздражает. Пользователь не хочет, чтобы ему постоянно показывали, что система «знает» его — он хочет получать качественные ответы.
Персонализация работает в фоне. Адаптируется содержание и форма — а не комментарии о том, как идёт адаптация.
Профиль — это PII. Имена, профессии, привычки. Хранится в твоей системе, передаётся в провайдера LLM каждый раз, накапливается со временем. Это серьёзная история про приватность.
Возвращайся к Дню 0: какие данные кладёшь, где хранишь, кто имеет доступ. Если речь о бизнес-сценариях — отдельно думай про GDPR / 152-ФЗ. Чем больше профиль — тем серьёзнее ответственность.
В ChatGPT: Settings → Personalization → Memory. Открой список того, что записано. Классифицируй каждую запись по типам профиля: identity / preferences / context / constraints. Какие записи кажутся точными? Какие — устаревшими? Какие — лишними (мусор)? Это даёт живой пример того, как одна из крупных систем реализует self-evolving profile.
Возьми идею «AI-помощник для подготовки к спортивным соревнованиям». Распиши схему профиля: какие поля будут? Под каждый тип (identity, preferences, context, constraints) дай 2-4 поля. Что точно надо узнать сразу (onboarding)? Что должно извлекаться из разговоров автоматически (self-evolving)? Что критически важно для безопасности (например, противопоказания)? Это упражнение прокачивает архитектурное мышление по памяти.
Возьми «полный» гипотетический профиль (10-15 фактов о вымышленном пользователе) и напиши, как он будет выглядеть в system prompt. Цель: уместить в 200-250 токенов, не теряя сути. Заметишь, что приходится выбирать слова: «профессионал в IT» — а можно ли короче? «предпочитает структурированные ответы» — а если просто «любит списки и заголовки»? Это и есть инжиниринг профиля.