Контекст имеет значение. Два ИИ-агента могут выполнить запрос к одной и той же таблице Redshift и вернуть разные показатели выручки, и ни один из запросов не будет ошибочным. Это происходит потому, что каждый из них применил разные негласные предположения о финансовых календарях, исключениях или о том, какая таблица клиентов является авторитетной.
Amazon Redshift хорошо справляется со структурированной бизнес-аналитикой и отчетностью с низкой задержкой внутри AWS. Подключение к нему ИИ-агента — задача иного рода. Хранилище данных возвращает строки и столбцы. Оно не сообщает агенту, что означают эти цифры или какому источнику следует доверять.
Как только вы подключаете агента к Redshift, вы также принимаете на себя ограничения платформы. Лимиты параллелизма, область действия каталога в рамках одной базы данных и проприетарное хранилище уже были ограничениями для отчетности. С ними становится еще труднее мириться, когда агенты добавляют исследовательские запросы поверх нагрузки по формированию отчетов.
Помогает добавление управляемого слоя бизнес-определений, политик и продуктов данных поверх Redshift до запуска первого запроса агента. В этой статье рассматривается, почему архитектура Redshift не была создана для заземления (grounding) агентов, обеспечиваемого контекстной инженерией. В ней рассказывается, что дает управляемый контекстный слой и как можно начать его создание, не отказываясь от Redshift.
Основные выводы
- Лимит параллелизма Redshift, составляющий около 50 одновременных запросов, и область действия каталога в рамках одной базы данных затрудняют обслуживание ИИ-агентов, которым необходимо сопоставлять данные из нескольких источников.
- Контекстный слой добавляет бизнес-определения, управление и продукты данных поверх Redshift, чтобы агенты получали обоснованные ответы с соблюдением политик вместо уверенных догадок.
- Федерация Redshift с вашими озерами данных, другими хранилищами данных и SaaS-источниками позволяет избежать копирования данных в очередное изолированное проприетарное хранилище.
- Предоставление управляемого контекста агентам через Model Context Protocol (MCP) сохраняет централизацию управления, обеспечивая каждому инструменту доступ к одним и тем же проверенным определениям.
- Прежде чем выбрать конкретный подход, протестируйте любые заявления вендоров о производительности или стоимости альтернатив Redshift на вашей собственной рабочей нагрузке.
Amazon Redshift хорошо справляется со структурированной бизнес-аналитикой и отчетностью с низкой задержкой внутри AWS. Однако при подключении к нему ИИ-агента вы сталкиваетесь с другим набором проблем. Само по себе хранилище не сообщает агенту, что значат ваши цифры или где еще искать информацию.
В этом материале рассматривается, почему ограничения параллелизма Redshift, область действия в рамках одной базы данных и проприетарный формат хранения лишают ИИ-агентов бизнес-контекста, и что необходимо добавить сверху, чтобы получать ответы, которым можно доверять.
Что контекстная инженерия означает для команд, работающих с Redshift
Узкое место сместилось от моделей к контексту
Большие языковые модели стали достаточно хороши, чтобы поддерживать диалог о ваших данных. Чего у них нет, так это самих ваших данных. Ни одна передовая модель не знает вашего финансового календаря, вашего определения оттока клиентов или того, какая из 5 таблиц клиентов является основной, потому что этих знаний нет ни в одном публичном обучающем корпусе.
Этот разрыв объясняет отрезвляющую статистику. Только около 30 процентов проектов агентного ИИ доходят до стадии эксплуатации. Большинство из них застревают не из-за слабости модели, а потому, что никто не создал слой, который снабжает ее обоснованной и управляемой информацией. Контекстная инженерия означает проектирование того, какая информация поступает в модель, чтобы она выдавала надежные, обоснованные ответы, и эта работа по проектированию сейчас является более сложной половиной создания агента.
В чем Redshift сам по себе не справляется с задачами ИИ-агентов
Redshift — это единое закрытое хранилище данных. Агент, который обращается к нему напрямую, получает строки и столбцы, а не определения, происхождение данных (lineage) или политики. Спросите его «что такое активная выручка», и вы получите то, что случайно оказалось в таблице, а не определение этого термина от вашего финансового отдела.
Кроме того, в Redshift хранится лишь малая часть данных большинства компаний. Любой агент, ограниченный одним кластером Redshift, упускает все, что вы храните в других местах, включая озера данных, другие облачные хранилища данных и SaaS-приложения.
Почему контекстная инженерия важна для пользователей Redshift именно сейчас
Ограничения параллелизма и стоимости подталкивают команды к федерации
Redshift обычно ограничивает вас примерно 50 параллельными запросами. Этот потолок был достаточно низким для BI-дашбордов; он становится еще ниже, когда вы добавляете агентов, запускающих исследовательские запросы поверх существующей нагрузки по отчетности.
Масштабирование Redshift для обеспечения дополнительного параллелизма обычно означает использование более крупных и дорогих кластеров. Прежде чем идти по этому пути, оцените реальную стоимость централизации данных в Amazon Redshift, которая показывает, как ограничения параллелизма и размер кластера накапливаются со временем.
Проприетарный формат хранения Redshift и привязка к вендору
Redshift хранит данные в собственном проприетарном формате, поэтому каждый загруженный набор данных должен либо оставаться там, либо копироваться. Сочетание ограничений параллелизма, нагрузки на обслуживание (например, выполнение vacuum) и привязки к проприетарному хранилищу делает Redshift дорогостоящей единой точкой истины для ИИ-агента, которому необходимо анализировать данные из нескольких источников.
Загрузка большего количества данных в Redshift для устранения пробелов в охвате лишь создает еще один изолированный массив данных. Кроме того, это еще больше привязывает вас к формату, от которого вы не сможете легко отказаться в будущем. Этот компромисс — недостающий элемент в большинстве стратегий данных для ИИ. Вы получаете больше места в одном хранилище, но не больше контекста по всем имеющимся у вас источникам.
Что контекстный слой добавляет поверх Redshift
Бизнес-определения и метаданные
Контекстный слой находится над Redshift и содержит бизнес-определения, необходимые вашему агенту, включая то, что считается активной выручкой, какая таблица клиентов является авторитетной и как ваш финансовый год соотносится с календарными месяцами. Без этого слоя агенту приходится гадать, а уверенные догадки хуже честного «я не знаю».
Управление и обеспечение соблюдения политик
Этот же слой должен контролировать, кто и что может видеть. Создание корпоративного контекстного слоя означает объединение метаданных, управления и политик доступа в одном месте, чтобы каждый агент, запрашивающий данные из Redshift, соблюдал те же правила на уровне строк и столбцов, которым следовал бы аналитик-человек.
Централизация управления здесь также означает, что вы устанавливаете политику один раз, а не повторяете ее в каждом инструменте, работающем с вашими данными.
Продукты данных как механизм доставки
Вместо того чтобы предоставлять агенту прямой доступ к необработанным таблицам, контекстный слой упаковывает проверенные и хорошо документированные продукты данных для выполнения запросов. Отчасти поэтому контекстный слой располагается над уровнем хранилища, а не внутри него. Хранилище хранит данные, а контекстный слой решает, что разрешено видеть конкретному агенту и как это описывать. Продукты данных обеспечивают способ реализации этого процесса и являются важным ингредиентом при создании контекстного слоя.
Как контекстная инженерия работает с Redshift
Федерация Redshift с другими системами без копирования данных
Вам не нужно мигрировать с Redshift, чтобы устранить его «слепые зоны». С помощью подхода федерации вы можете запрашивать Redshift наряду с вашими озерами данных, другими хранилищами данных и SaaS-источниками, ограничивая при этом необходимость копирования данных между ними. Starburst на AWS подключается к Redshift и другим источникам, размещенным в AWS, именно таким образом, позволяя агенту анализировать данные в разных системах через один интерфейс.
Этот подход также позволяет избежать распространённой ошибки. Теперь главным ограничением для большинства проектов на основе агентного ИИ является контекст, а не возможности модели, и федерация — это способ расширить контекст агента без предварительного дублирования каждой базы данных в Redshift.
Предоставление управляемого контекста агентам через MCP
Как только ваш слой контекста определяет и управляет вашими данными, вам нужен последовательный способ передать их агентам. Протокол контекста модели (MCP) предоставляет нескольким агентам и инструментам общий интерфейс к одним и тем же проверенным определениям, что позволяет вам обеспечить управление один раз и повторно использовать его везде, вместо того чтобы подключать каждый инструмент к Redshift отдельно.
Эта последовательность важна, потому что доступ к бизнес-контексту, а не только к данным, определит, кто сможет заменить BI на AI внутри вашей организации.
Соображения перед началом работы
Охват одной базы данных на каталог
По умолчанию соединение с 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?
Слой контекста должен обеспечивать те же правила доступа к строкам и столбцам, которые соблюдает человеческий аналитик, объединяя метаданные, управление и политику доступа в одном месте. Централизация управления здесь означает, что вы устанавливаете политику один раз, вместо того чтобы повторять ее в каждом инструменте, который взаимодействует с вашими данными.
Как Протокол контекста модели (MCP) относится к контекстному инжинирингу в Redshift?
MCP предоставляет нескольким агентам и инструментам общий интерфейс к одним и тем же проверенным определениям, которые поддерживает ваш слой контекста. Как только ваш слой контекста определяет и управляет вашими данными, вы можете использовать MCP, чтобы обеспечить это управление один раз и повторно использовать его везде, вместо того чтобы подключать каждый инструмент к Redshift отдельно.
Может ли слой контекста работать с ограничением Redshift на одну базу данных на каталог?
Да, но планируйте это заранее. По умолчанию соединение с Redshift осуществляется с одной базой данных внутри кластера, поэтому, если ваш кластер содержит несколько баз данных, вам нужно сопоставить это ограничение охвата с тем, как ваш более широкий слой контекста организует каталоги.
