Контекст имеет значение. Два ИИ-агента могут запросить одну и ту же таблицу Redshift и получить разные показатели выручки, и ни один из запросов не будет ошибочным. Это происходит потому, что каждый из них применил разные негласные допущения относительно финансовых календарей, исключений или того, какая таблица клиентов является авторитетной.
Amazon Redshift хорошо справляется со структурированной бизнес-аналитикой и отчетностью с низкой задержкой внутри AWS. Подключение к нему ИИ-агента — это другая проблема. Хранилище данных возвращает строки и столбцы. Оно не сообщает агенту, что означают эти цифры или какому источнику доверять.
Как только вы подключаете агента к Redshift, вы также принимаете ограничения платформы. Пределы параллелизма, область действия каталога в рамках одной базы данных и проприетарное хранилище уже были ограничениями для отчетности. С ними становится труднее мириться, когда агенты добавляют исследовательские запросы поверх нагрузки от отчетности.
Добавление управляемого уровня бизнес-определений, политик и продуктов данных поверх Redshift до выполнения первого запроса агента помогает решить проблему. В этой статье рассматривается, почему архитектура Redshift не была создана для обоснования агентов, обеспечиваемого контекстной инженерией. В ней рассказывается, что добавляет управляемый контекстный уровень и как можно начать его создание, не отказываясь от Redshift.
Основные выводы
- Ограничение Redshift на параллельное выполнение около 50 запросов и область действия в рамках одной базы данных на каталог затрудняют обслуживание ИИ-агентов, которым необходимо анализировать данные из нескольких источников.
- Контекстный уровень добавляет бизнес-определения, управление и продукты данных поверх Redshift, чтобы агенты получали обоснованные и соответствующие политикам ответы вместо уверенных догадок.
- Федерация Redshift с вашими озерами данных, другими хранилищами данных и источниками SaaS позволяет избежать копирования данных в еще один проприетарный изолированный склад.
- Предоставление управляемого контекста агентам через протокол Model Context Protocol (MCP) позволяет централизовать управление, предоставляя каждому инструменту доступ к одним и тем же проверенным определениям.
- Сравнивайте любые заявленные поставщиками показатели производительности или стоимости альтернатив Redshift с вашей собственной рабочей нагрузкой, прежде чем приступать к конкретному подходу.
Amazon Redshift хорошо справляется со структурированной бизнес-аналитикой и отчетностью с низкой задержкой внутри AWS. Однако при подключении к нему ИИ-агента вы сталкиваетесь с другим набором проблем. Одно лишь хранилище не говорит агенту, что означают ваши цифры или где еще искать информацию.
В этой статье рассматривается, почему ограничения Redshift по параллелизму, область действия в рамках одной базы данных и проприетарный формат хранения оставляют ИИ-агентов без бизнес-контекста, и что нужно добавить сверху, чтобы получать ответы, которым можно доверять.
Что контекстная инженерия означает для команд Redshift
Узкое место переместилось с моделей на контекст
Большие языковые модели стали достаточно хороши, чтобы поддерживать диалог о ваших данных. Чего у них нет, так это ваших данных. Ни одна передовая модель не знает ваш финансовый календарь, ваше определение оттока клиентов или какая из 5 таблиц клиентов является авторитетной, потому что этих знаний нет ни в одном общедоступном обучающем корпусе.
Этот разрыв объясняет отрезвляющую цифру. Только около 30 процентов проектов агентного ИИ доходят до промышленной эксплуатации. Большинство из них останавливаются не потому, что модель слабая, а потому, что никто не создал уровень, который снабжает ее обоснованной и управляемой информацией. Контекстная инженерия означает проектирование того, какая информация поступает в модель, чтобы она выдавала надежные, обоснованные ответы, и эта проектная работа теперь является более сложной половиной создания агента.
В чем Redshift сам по себе проигрывает для ИИ-агентов
Redshift — это единое закрытое хранилище данных. Агент, который запрашивает его напрямую, получает строки и столбцы, а не определения, происхождение или политику. Спросите его «что такое активная выручка», и вы получите то, что содержится в таблице, а не определение этого термина вашей финансовой командой.
Redshift также содержит лишь небольшую часть данных большинства компаний. Любой агент, ограниченный одним кластером Redshift, упускает все, что вы храните в других местах, включая озера данных, другие облачные хранилища данных и SaaS-приложения.
Почему контекстная инженерия важна сейчас для пользователей Redshift
Ограничения по параллелизму и стоимости подталкивают команды к федерации
Redshift обычно ограничивает вас примерно 50 параллельными запросами. Этот потолок был достаточно жестким для BI-дашбордов; он становится еще жестче, когда вы добавляете агентов, которые запускают исследовательские запросы поверх существующей нагрузки от отчетности.
Масштабирование Redshift для поглощения этой дополнительной параллельности обычно означает создание более крупных и дорогих кластеров. Прежде чем идти по этому пути, оцените истинную стоимость централизации данных в Amazon Redshift, где описано, как ограничения параллелизма и размер кластера накапливаются с течением времени.
Проприетарный формат хранения Redshift и привязка к поставщику
Redshift хранит данные в собственном проприетарном формате, поэтому каждый загружаемый вами набор данных должен оставаться там или быть скопирован. Это сочетание ограничений параллелизма, бремени обслуживания (например, вакуумирование) и привязки к проприетарному хранилищу делает Redshift дорогостоящей единой точкой истины для ИИ-агента, которому необходимо анализировать данные из нескольких источников.
Загрузка большего количества данных в Redshift для устранения пробела в охвате просто создает еще один изолированный склад данных. Кроме того, это еще больше привязывает вас к формату, от которого потом будет нелегко отказаться. Этот компромисс — недостающий элемент в большинстве стратегий работы с данными для ИИ. Вы получаете больше хранилища внутри одного хранилища, а не больше контекста по источникам, которые у вас уже есть.
Что контекстный уровень добавляет поверх Redshift
Бизнес-определения и метаданные
Контекстный уровень располагается над Redshift и содержит бизнес-определения, необходимые вашему агенту, включая то, что считается активной выручкой, какая таблица клиентов является авторитетной и как ваш финансовый год соотносится с календарными месяцами. Без этого уровня агент вынужден гадать, а уверенные догадки хуже, чем честное «я не знаю».
Управление и обеспечение соблюдения политик
Этот же уровень должен контролировать, кто и что может видеть. Создание корпоративного контекстного уровня означает объединение метаданных, управления и политики доступа в одном месте, чтобы каждый агент, запрашивающий Redshift, соблюдал те же правила на уровне строк и столбцов, которым следовал бы аналитик-человек.
Централизация управления здесь также означает, что вы устанавливаете политику один раз, вместо того чтобы повторять ее в каждом инструменте, который взаимодействует с вашими данными.
Продукты данных как механизм доставки
Вместо того чтобы предоставлять агенту доступ к необработанным таблицам, контекстный уровень упаковывает для него проверенные, хорошо задокументированные продукты данных. Именно поэтому контекстный уровень находится над уровнем хранилища, а не внутри него. Хранилище хранит данные, а контекстный уровень решает, что именно разрешено видеть конкретному агенту и как это описать. Продукты данных обеспечивают способ, с помощью которого это происходит, и являются важным компонентом создания контекстного уровня.
Как контекстная инженерия работает с Redshift
Федерация Redshift с другими системами без копирования данных
Вам не нужно мигрировать с Redshift, чтобы устранить его «слепые зоны». Благодаря подходу федерации вы можете запрашивать Redshift наряду с вашими озерами данных, другими хранилищами данных и источниками SaaS, ограничивая необходимость копирования данных между ними. Starburst в AWS подключается к Redshift и другим источникам, размещенным в AWS, таким образом, чтобы агент мог анализировать данные в разных системах через один интерфейс.
Этот подход также позволяет избежать распространенной ловушки. Контекст, а не возможности модели, сейчас является «узким местом» для большинства проектов в области агентного ИИ, а федерация — это способ расширить контекст агента без предварительного дублирования каждого набора данных в Redshift.
Предоставление управляемого контекста агентам через MCP
Как только ваш уровень контекста определяет и регулирует ваши данные, вам нужен согласованный способ передачи их агентам. Model Context Protocol (MCP) предоставляет нескольким агентам и инструментам общий интерфейс к одним и тем же проверенным определениям, поэтому вы обеспечиваете управление один раз и повторно используете его везде, вместо того чтобы подключать каждый инструмент к Redshift отдельно.
Эта согласованность важна, потому что доступ к бизнес-контексту, а не только доступ к данным, будет определять, кто сможет заменить BI на ИИ внутри вашей организации.
Рекомендации перед началом работы
Область действия: одна база данных на каталог
По умолчанию соединение с Redshift охватывает одну базу данных внутри кластера. Если ваш кластер Redshift содержит несколько баз данных, заранее спланируйте это ограничение области действия, так как оно влияет на то, как вы сопоставляете каталоги с вашим более широким уровнем контекста.
TLS и конфигурация сети
Современные драйверы JDBC для Redshift включают TLS по умолчанию, поэтому убедитесь, что настройки вашего соединения соответствуют требованиям сетевой безопасности, прежде чем приступать к федерации. Ошибки в этой конфигурации на раннем этапе потребуют больше времени на исправление, когда агенты уже будут зависеть от этого соединения.
Вакуумирование и накладные расходы на обслуживание
Redshift требует регулярного вакуумирования для освобождения места и поддержания эффективности планов запросов, и эти накладные расходы на обслуживание никуда не исчезают после добавления уровня контекста. Заложите бюджет на это так же, как вы делали бы это для любой другой рабочей нагрузки Redshift, поскольку затраты на централизацию, такие как вакуумирование и привязка к хранилищу, имеют тенденцию накапливаться, если никто не несет за них ответственность.
Шаги для начала контекстного проектирования ваших данных в Redshift
Следующие шаги могут стать полезным планом для контекстного проектирования ваших данных в Redshift.
- Начните с инвентаризации бизнес-определений, которые потребуются вашим агентам, включая выручку, отток и любые показатели, для которых существует более одной потенциальной исходной таблицы.
- Сопоставьте, какие другие системы, включая озера данных и SaaS-приложения, содержат данные, необходимые агенту наряду с Redshift.
- Настройте федеративный доступ, чтобы агенты могли запрашивать Redshift и другие источники без копирования данных в новый силос.
- Определите политику управления один раз, на уровне контекста, чтобы она последовательно применялась ко всем агентам и инструментам.
- Предоставляйте этот управляемый контекст агентам через MCP, чтобы несколько инструментов использовали одни и те же проверенные определения.
- Протестируйте любые заявленные поставщиком показатели производительности или стоимости на своей собственной рабочей нагрузке, прежде чем переходить к конкретному подходу.
Если вы взвешиваете, должен ли Redshift оставаться вашим единственным источником истины для рабочих нагрузок ИИ, компромиссы будут аналогичны тем, что рассматриваются в контекстном проектировании для Snowflake и Amazon Athena. Хранилище хорошо справляется с хранением и вычислениями, а уровень контекста — это то, что делает агента, построенного на его основе, надежным. Кроме того, ни одно из этих решений не означает, что вам нужно отказаться от Redshift, только перестать рассматривать его как единственное место, куда могут обращаться ваши агенты.
Дальнейшие шаги
Хотите узнать больше о контекстном проектировании для Redshift? Ознакомьтесь с отчетом Gartner об управлении данными с учетом контекста.
Часто задаваемые вопросы
Что такое контекстное проектирование и чем оно отличается от промпт-инжиниринга?
Контекстное проектирование означает проектирование того, какая информация доходит до модели, включая бизнес-определения, правила управления и доступ к нужным источникам данных, чтобы она выдавала обоснованные и надежные ответы. Промпт-инжиниринг фокусируется на том, как вы формулируете запрос к модели. Вам нужно и то, и другое, но без правильного контекста хорошо составленный промпт все равно вернет догадку вместо обоснованного ответа.
Почему данных Redshift недостаточно для правильного ответа ИИ-агента?
Redshift — это единое закрытое хранилище данных. Агент, который запрашивает его напрямую, получает строки и столбцы, а не определения, происхождение или политику, поэтому ему приходится угадывать, что означает такой показатель, как «активная выручка», вместо того чтобы применять определение вашего финансового отдела. Redshift также содержит лишь небольшую часть данных большинства компаний, поэтому агент, ограниченный одним кластером, упускает все, что вы храните в озерах данных, других хранилищах данных и SaaS-приложениях.
Нужно ли перемещать данные Redshift для создания уровня контекста?
Нет. С помощью подхода федерации вы можете запрашивать Redshift вместе с вашими озерами данных, другими хранилищами данных и SaaS-источниками, ограничивая необходимость копирования данных между ними. Загрузка большего количества данных в Redshift для устранения пробелов в охвате просто создает еще один информационный силос и еще больше привязывает вас к его проприетарному формату хранения.
Какое управление должен обеспечивать уровень контекста для данных Redshift?
Уровень контекста должен обеспечивать соблюдение тех же правил доступа на уровне строк и столбцов, которым следовал бы аналитик-человек, объединяя метаданные, управление и политику доступа в одном месте. Централизация управления здесь означает, что вы устанавливаете политику один раз, вместо того чтобы повторять ее в каждом инструменте, который обращается к вашим данным.
Как Model Context Protocol связан с контекстным проектированием в Redshift?
MCP предоставляет нескольким агентам и инструментам общий интерфейс к тем же проверенным определениям, которые поддерживает ваш уровень контекста. Как только ваш уровень контекста определяет и регулирует ваши данные, вы можете использовать MCP, чтобы обеспечить это управление один раз и повторно использовать его везде, вместо того чтобы подключать каждый инструмент к Redshift отдельно.
Может ли уровень контекста работать с ограничением Redshift «одна база данных на каталог»?
Да, но спланируйте это заранее. По умолчанию соединение с Redshift охватывает одну базу данных внутри кластера, поэтому, если ваш кластер содержит несколько баз данных, вам нужно сопоставить это ограничение области действия с тем, как ваш более широкий уровень контекста организует каталоги.
