Проблема, которая всех достала: 5 дашбордов вместо одного ответа
Представьте себе типичную сцену в поддержке крупного SaaS-продукта. Клиент спрашивает: "Почему моя подписка на премиум-функцию не обновилась?" Сейчас это выглядит так:
- Оператор открывает Salesforce - смотрит статус контракта
- Переключается на Redshift - проверяет историю платежей и failed транзакции
- Заходит в OpenSearch - ищет логи ошибок за последние 24 часа
- Прокликивает еще пару внутренних систем - и все это чтобы дать один ответ
Абсурд? Да. Реальность 2025 года в 80% компаний? Тоже да.
CAKE: не десерт, а лекарство от разрозненности данных
В AWS придумали архитектуру с запоминающимся названием CAKE (Contextual Augmented Knowledge Engine). Суть проста: вместо одного тупого ретривера, который пытается всё найти сразу, вы строите несколько специализированных.
Каждый ретривер знает только свою область:
| Ретривер | Что умеет | Где ищет |
|---|---|---|
| Customer Context | Понимает, кто клиент и что ему можно показывать | DynamoDB + Row Level Security |
| Transactional | Ищет факты: платежи, контракты, статусы | Salesforce, Redshift |
| Operational | Копается в логах и метриках | OpenSearch |
| Knowledge Graph | Связывает всё воедино | Amazon Neptune |
На февраль 2026 года Bedrock AgentCore поддерживает до 8 специализированных ретриверов одновременно. В прошлом году лимит был 3 - прогресс налицо.
Что меняется с февраля 2026: RLS стал умнее
Row Level Security в Bedrock AgentCore теперь понимает контекст запроса. Раньше это была просто фильтрация по ролям. Сейчас агент сам решает, какие данные можно показывать.
Пример: клиент спрашивает про платежную историю. Раньше агент либо показывал всё (опасно), либо ничего (бесполезно). Сейчас он:
- Смотрит в DynamoDB - кто этот клиент и какая у него подписка
- Применяет правила RLS из Salesforce - что можно показывать по контракту
- Фильтрует данные из Redshift - оставляет только релевантные транзакции
- Формирует ответ, который и информативен, и безопасен
Это не магия, а просто правильная настройка цепочек агентов. Кстати, про настройку агентных workflow есть отличный пример в статье про Suzano.
Neptune в 2026: графы, которые наконец-то работают быстро
Раньше Amazon Neptune был медленным для реального времени. В 2025 году вышла версия с поддержкой векторных индексов прямо в графах. Теперь можно искать не только по связям, но и по семантическому сходству.
В CAKE архитектуре Neptune делает то, что не могут реляционные базы: связывает клиента из Salesforce, его платежи из Redshift и ошибки из OpenSearch в единую картину.
Как это выглядит в коде (без кода, потому что это не гайд)
Конфигурация агента в Bedrock AgentCore теперь позволяет задавать не просто "где искать", а "как искать и что делать с результатами".
Вы указываете:
- Для Salesforce - какие объекты и поля релевантны
- Для Redshift - какие SQL-запросы запускать при разных типах вопросов
- Для OpenSearch - какие индексы сканировать и как фильтровать результаты
- Правила приоритета - что важнее: свежесть данных или их точность
И самое главное - все это работает в одном контексте. Агент не переключается между системами. Он спрашивает их одновременно и собирает ответы воедино.
Чем CAKE лучше обычного агента с одним ретривером
Обычный агент с RAG поверх OpenSearch умеет только искать по документам. CAKE-агент понимает разницу между:
- "Сколько я заплатил в прошлом месяце?" (транзакционные данные)
- "Почему мой платеж не прошел?" (операционные данные + транзакционные)
- "Что делать, если платеж не прошел?" (знаниевая база + транзакционные данные)
И для каждого типа вопроса он использует разные ретриверы в разной последовательности. Это как иметь команду специалистов вместо одного универсала.
Предупреждение: CAKE архитектура требует тщательной настройки. Если неправильно настроить приоритеты ретриверов, агент может начать искать логи там, где нужны только факты из Salesforce. Тестируйте на реальных запросах.
Кому подойдет (а кому нет)
Подойдет:
- Крупным SaaS-компаниям с разрозненными системами (у всех они есть)
- Финтех-проектам, где важны и транзакции, и логи, и compliance
- Корпорациям, которые устали от 15 разных дашбордов для ответа на один вопрос
- Тем, кто уже пробовал корпоративных ассистентов и хочет больше точности
Не подойдет:
- Стартапам с одной базой данных (им это overkill)
- Тем, у кого нет доступа ко всем системам через API (будет работать криво)
- Командам без DevOps-навыков для настройки Bedrock AgentCore
Что будет дальше: предсказания на 2026-2027
CAKE - это только начало. Уже сейчас видно, куда движется рынок:
- Автоматическое определение схем ретриверов - агент сам поймет, где у вас Salesforce, а где Redshift
- Динамическое перераспределение запросов - если OpenSearch лег, агент переключится на альтернативные источники
- Сквозное шифрование контекста - чтобы данные из разных систем не смешивались там, где не надо
И главное - скоро это перестанет быть экзотикой. Как когда-то RAG казался магией, а теперь это стандарт. То же самое произойдет с мульти-ретриверными архитектурами.
Начните с малого, но думайте о CAKE
Не пытайтесь сразу построить полную CAKE архитектуру. Начните с одного ретривера в Bedrock AgentCore. Подключите Salesforce. Посмотрите, как работает.
Потом добавьте Redshift. Потом OpenSearch. Каждый шаг будет давать ценность.
И помните: идеальный агент не тот, который знает всё, а тот, который знает, где искать нужное. CAKE - это как раз про это знание.
Если нужен готовый шаблон для начала, посмотрите FAST шаблон - там есть все компоненты для сборки.
Последний совет: не зацикливайтесь на архитектуре. Клиенту всё равно, как она называется. Ему важно получить ответ на вопрос без переключения между пятью системами. CAKE или не CAKE - это ваша внутренняя кухня. Главное - результат.
