TL;DR
Двухслойная архитектура знаний — принцип разделения контекста на долгосрочный (базовые инструкции, обновлять редко) и краткосрочный (свежие данные/примеры, обновлять часто). Исследование Google на рекомендательной системе показывает: комбинация медленных глубоких обновлений и быстрых точечных добавлений данных работает лучше, чем только один из подходов.
Ключевая находка: В динамичных областях (новости, тренды, соцсети) паттерны меняются радикально быстро — только 17% совпадений между топовыми паттернами через месяц. Это означает что любой статический контекст (базовые инструкции, примеры, данные) устаревает на 80%+ за 30 дней. Одна глубокая настройка раз в месяц не успевает за реальностью. Добавление свежих данных каждый день даёт прирост, но без базы быстро теряет точность. Instance-level контекст (1 точный пример под конкретную задачу) работает лучше, чем global-level (100 общих примеров). Frequency-based примеры (самые частые) работают лучше, чем trend-based (самые растущие).
Суть для практики: Если работаешь с динамичной областью — создай базовый чат с общими инструкциями (обновлять раз в месяц или реже), а в каждый запрос добавляй свежие данные за последние дни (обновлять часто или каждый раз). Не пытайся держать всё в одном месте — разделяй стабильное и меняющееся.
Схема принципа
СЛОЙ 1 (медленный, стабильный):
Базовый чат с кастомными инструкциями
→ Обновление: раз в месяц или реже
→ Содержит: общие правила, роль, формат, принципы
СЛОЙ 2 (быстрый, актуальный):
Свежий контекст в каждом промпте
→ Обновление: каждый день или каждый запрос
→ Содержит: данные за последние дни, релевантные примеры, тренды
ВЫБОР ПРИМЕРОВ:
Instance-level > Global-level (1 точный > 100 общих)
Frequency-based > Trend-based (самые частые > самые растущие)
Пример применения
Задача: Помогаешь SMM-специалисту генерировать идеи постов для бренда спортивной одежды в ВК.
Базовый чат (создать один раз, обновлять раз в месяц):
Ты SMM-эксперт для бренда спортивной одежды.
Целевая аудитория: 18-35 лет, интересуются фитнесом и ЗОЖ.
Принципы контента:
- Мотивация без токсичного позитива
- Полезность > продажи
- Разговорный стиль, никакого маркетингового языка
Форматы: карусели, видео до 60 сек, истории с опросами.
В каждый запрос (обновлять перед каждой сессией):
Актуальные данные за последние 7 дней в нише:
Топ-3 тренда в фитнес-сообществах ВК:
1. "12-3-30" (12% наклон, 3 км/ч, 30 минут на беговой дорожке)
2. Силовые тренировки для женщин (разбор мифов про "перекачаться")
3. Зимний бег: как не бросить в холода
Виральный пост конкурента (500+ репостов):
"5 упражнений которые я удалила из программы когда поняла что они не работают"
Твоя задача: предложи 3 идеи постов на следующую неделю.
Результат:
Модель выдаст 3 идеи постов, которые учитывают актуальные тренды (например, адаптация "12-3-30" для новичков или развенчание мифов про силовые для женщин), используют виральный формат ("5 упражнений которые..."), соответствуют принципам бренда. Контент будет релевантен сейчас, а не месяц назад.
Почему это работает
LLM не знает что происходит прямо сейчас. Даже самые свежие модели обучены на данных с задержкой в несколько месяцев. Если ты работаешь с динамичной областью — модель даёт советы основанные на том, что было актуально когда её обучали, не сегодня. В результате: рекомендации про тренды трёхмесячной давности, примеры с устаревшими форматами, советы про то что уже не работает.
Два типа знаний стареют с разной скоростью. Принципы работы (как писать цепляющие заголовки, структура вовлекающего поста) меняются медленно — раз в месяцы или годы. Тренды и паттерны (какие темы обсуждают, какие форматы виральны, что работает у конкурентов) меняются быстро — каждую неделю может появиться новый тренд. Держать всё в одном месте означает либо обновлять базу каждый день (дорого, сложно), либо использовать устаревший контекст (неточно).
Двухслойная архитектура использует сильные стороны обоих подходов. Базовый чат с кастомными инструкциями даёт стабильный фундамент — роль, правила, общий контекст. Модель понимает "кто она" и "как работать". Это не нужно повторять в каждом запросе. Свежие данные в промпте дают актуальность — что происходит прямо сейчас, что работает сегодня, релевантные примеры. Модель генерирует ответ учитывая и стабильные принципы, и текущую реальность.
Рычаги управления:
- Частота обновления слоя 1 → уменьши до "раз в квартал" если область стабильна, увеличь до "раз в неделю" если меняется фундаментально
- Объём контекста в слое 2 → добавь больше примеров если задача сложная, сократи до минимума если задача простая (экономия токенов)
- Тип примеров → frequency-based (самые частые паттерны) для стабильного качества, trend-based (самые растущие) если хочешь поймать волну раньше других
- Специфичность → instance-level (1 точный пример под задачу) для точности, global-level (несколько общих примеров) если задача размытая
Шаблон применения
ШАГ 1: Создай базовый чат (обновлять редко)
В настройках чата / Custom Instructions:
Ты {роль} для {контекст}.
Целевая аудитория: {описание}
Принципы работы:
- {принцип 1}
- {принцип 2}
- {принцип 3}
{Любые стабильные правила, форматы, ограничения}
ШАГ 2: В каждый запрос добавляй свежий контекст
Актуальные данные за последние {период}:
Топ-{число} трендов/паттернов:
1. {тренд 1}
2. {тренд 2}
...
Релевантный пример для моей задачи:
{1 конкретный пример, максимально близкий к текущей задаче}
Моя задача: {конкретная задача}
Пояснение к плейсхолдерам:
{роль}— кто модель (эксперт, аналитик, копирайтер){контекст}— область работы, бренд, проект{принципы}— стабильные правила которые не меняются часто{период}— 7 дней для быстрых трендов, 30 дней для медленных областей{число}— 3-5 для баланса, больше если нужна глубина{релевантный пример}— 1 максимально близкий к задаче (instance-level), не 10 общих
Почему работает двухслойная архитектура
Статистика из исследования: Google измерил стабильность топ-5 паттернов пользовательского поведения месяц-к-месяцу через Jaccard similarity (показывает совпадение между двумя наборами). Результат: 0.17 в среднем — то есть только 17% совпадений, а 83% — новые паттерны. Через месяц большинство того что было актуально — исчезло или сильно изменилось.
Это означает если ты обновил контекст месяц назад — 80%+ информации уже неточна для динамичной области. Если не обновляешь вообще — работаешь на основе устаревших паттернов.
Instance-level vs Global-level: Исследование показало что добавление 1 точного примера под конкретную пару (A,B) работает лучше, чем топ-100 общих примеров по всей базе. Причина: релевантность важнее объёма. Модель лучше понимает что делать когда видит похожий кейс, чем когда видит много разных.
Frequency-based vs Trend-based: Самые частые паттерны (что происходит чаще всего) дают лучшие результаты, чем самые растущие паттерны (где наибольший прирост). Причина: частота = стабильность, тренд может быть шумом. Если нужна точность — бери частое. Если хочешь рискнуть и поймать волну — бери растущее.
Hybrid > Only Fine-tuning OR Only RAG: Комбинация ежемесячного глубокого обновления базы + частого добавления свежих данных дала статистически значимый прирост пользовательской удовлетворённости на платформе с миллиардом пользователей (Satisfied User Outcomes +0.11%, Satisfaction Rate +0.25%). Только fine-tuning (раз в месяц) отстаёт от реальности. Только RAG (без базы) теряет точность. Вместе — работают.
Адаптации
🔧 Техника: Сделать слой 1 редактируемым → быстрее адаптация под новые задачи
Вместо Fixed Custom Instructions создай шаблон базовой настройки в отдельном документе. Когда область меняется фундаментально (новый проект, новая аудитория, изменились принципы) — скопируй шаблон, адаптируй, вставь в новый чат.
=== ШАБЛОН БАЗОВОЙ НАСТРОЙКИ ===
Ты {РОЛЬ} для {КОНТЕКСТ}.
Целевая аудитория: {АУДИТОРИЯ}
Принципы работы:
- {ПРИНЦИП_1}
- {ПРИНЦИП_2}
- {ПРИНЦИП_3}
=== КОНЕЦ ШАБЛОНА ===
Держи 2-3 варианта шаблона под разные типы задач. Вместо создания с нуля — адаптируешь за 2 минуты.
🔧 Техника: Автоматизировать слой 2 через saved prompts → экономия времени
Создай библиотеку форматов свежего контекста под разные задачи:
# Для контент-идей:
Топ-5 трендов за неделю в {НИША}:
[вставить из мониторинга]
Виральный формат конкурента:
[вставить пример]
# Для аналитики:
Данные за период {ДАТЫ}:
[вставить метрики]
Аномалии:
[вставить отклонения]
# Для рекомендаций:
Актуальный срез аудитории:
[вставить инсайты]
Релевантный кейс:
[вставить пример]
Вместо каждый раз писать структуру — копируешь шаблон, заполняешь данные, вставляешь в промпт.
🔧 Техника: Варьировать частоту обновления слоя 2 → под скорость изменений
| Скорость изменений | Частота обновления слоя 2 | Пример области |
|---|---|---|
| Очень быстрая | Каждый запрос | Новости, криптовалюты, соцсети |
| Быстрая | Каждый день | Маркетинг, e-commerce, тренды |
| Средняя | Раз в неделю | B2B контент, образование, здоровье |
| Медленная | Раз в месяц | Академические статьи, законодательство |
Если работаешь с новостным контентом — обновляй слой 2 каждый раз. Если пишешь про фундаментальные концепции — раз в месяц достаточно.
Ограничения
⚠️ Требует ручного сбора данных: Модель не обновляется сама — тебе нужно мониторить тренды, собирать примеры, искать статистику. Если нет источника свежих данных — двухслойная архитектура не работает лучше чем просто базовый чат.
⚠️ Не для статичных областей: Если работаешь с математикой, программированием, историей — контекст меняется медленно. Частое обновление слоя 2 не даст прироста, только увеличит сложность. Двухслойная архитектура ценна для динамичных областей (тренды, новости, поведение пользователей).
⚠️ Может конфликтовать: Если свежие данные противоречат базовым инструкциям — модель может запутаться или выбрать одно из двух непредсказуемо. Следи за согласованностью: если слой 2 показывает что принципы из слоя 1 устарели — обнови слой 1.
⚠️ Увеличивает токены: Каждый запрос включает и базовые инструкции (Custom Instructions), и свежий контекст в промпте. Если свежий контекст большой (много примеров, длинные данные) — стоимость растёт. Балансируй объём: минимум достаточный для точности.
Как исследовали
Google проверил гипотезу на реальной рекомендательной системе короткого видео (YouTube Shorts) с миллиардом пользователей. Система предсказывала какой кластер интересов пользователь захочет исследовать дальше — например, после "кулинария" и "путешествия" предложить "уличная еда в Азии".
Сначала измерили насколько быстро меняются паттерны. Взяли логи пользователей, построили последовательности из трёх кластеров (A → B → C), посчитали какие переходы самые частые. Через месяц повторили и сравнили топ-5 переходов через Jaccard similarity. Результат: 0.17 в среднем — только 17% совпадений, остальное изменилось. Это показало что статическая модель устаревает критически быстро.
Потом сравнили три стратегии обновления: 1. Только fine-tuning (глубокое переобучение раз в месяц на свежих данных) 2. Только RAG (добавление свежих примеров в промпт каждые 2 дня) 3. Hybrid (fine-tuning раз в месяц + RAG каждые 2 дня)
Измеряли hit rate (как часто предсказанный кластер появлялся в реальной истории пользователя). RAG обновляющийся каждые 2 дня показал выше hit rate, чем статичный RAG или fixed mapping. Но самое интересное: только 7.8% RAG-генераций совпали с non-RAG генерациями — то есть добавление свежих данных радикально меняет поведение модели, не просто слегка корректирует.
Финальная проверка — A/B эксперимент на живых пользователях. Hybrid подход (fine-tuning раз в месяц + RAG обновления в день 1 и день 4) показал статистически значимый прирост: - Satisfied User Outcomes +0.11% (95% CI: [0.00%, 0.21%]) - Satisfaction Rate +0.25% (95% CI: [0.01%, 0.48%]) - Dissatisfaction Rate -0.05% - Negative Interaction -0.04%
На масштабе в миллиард пользователей даже 0.1% — это миллионы более довольных людей. Самое важное: улучшения появлялись сразу после RAG-обновлений (день 1, день 4), подтверждая что свежесть данных критична.
Также проверили instance-level vs global-level подход для RAG. Instance-level (добавлять топ-1 самый частый пример для конкретной пары кластеров) работал лучше, чем global-level (топ-100 общих примеров). И frequency-based (самые частые паттерны) работал лучше, чем trend-based (паттерны с наибольшим ростом).
Вывод исследования: Динамичные области требуют частого обновления, но делать глубокое переобучение каждый день слишком дорого. Комбинация редкого глубокого обновления (фиксирует долгосрочные паттерны) и частого лёгкого обновления (ловит краткосрочные тренды) даёт лучший баланс эффективности и стоимости.
Ресурсы
Balancing Fine-tuning and RAG: A Hybrid Strategy for Dynamic LLM Recommendation Updates https://doi.org/10.1145/3705328.3748105
Changping Meng, Hongyi Ling, Jianling Wang, Yifan Liu, Shuzhou Zhang, Dapeng Hong, Mingyan Gao, Onkar Dalal, Ed Chi, Lichan Hong, Haokai Lu, Ningren Han Google, Google Deepmind RecSys '25, Prague, Czech Republic