Контекст для AI-агентов: почему цель важнее объема

«Контекст» стал главным словом в управлении данными с помощью агентов. По мере того как предприятия выводят AI-агентов из стадии пилотных проектов в реальные бизнес-процессы, обсуждение приходит к общему диагнозу: агенты терпят неудачу, потому что они недостаточно хорошо понимают бизнес, чтобы действовать на основе данных.

Предлагаемое лекарство обычно заключается в предоставлении большего контекста. Контекстные слои, контекстные графы и инженерия контекста стали стандартным лексиконом, и рабочее предположение сводится к тому, что чем большему контексту агент имеет доступ, тем лучше он будет работать. Тем не менее, по прогнозам Forrester, в 2027 году только одно из четырех усилий предприятий по созданию контекстного слоя будет поддерживать агентский ИИ в производственном масштабе.¹

Это предположение прошло проверку реальным миром в сентябре на конференции revAlation в Чикаго, где Alation провела хакатон с участием более чем 30 лидеров по работе с данными из числа корпоративных клиентов. Работая в десяти командах под руководством старшего топ-менеджера Alation, они потратили четыре часа на создание продуктов данных и агентов для реальных бизнес-кейсов. Мы проанализировали результаты этих сессий, и одна закономерность бросилась в глаза: наибольшего прогресса добились не те команды, у которых было больше всего контекста. Это были те команды, которые пришли с четким видением и точно знали, для чего им нужен этот контекст.

Основываясь на опыте работы с нашими более чем 600 клиентами, мы поняли, что контекст без цели — это болото: это объем без результатов, владельца или границ, из-за чего агенты остаются такими же ненадежными, как и раньше, и их труднее аудировать. Если вы решаете, сколько документации создавать, что сертифицировать или с чего начать работу с агентами, читайте дальше. Вы узнаете, что сделали команды иначе для достижения применимого в производстве контекста, познакомитесь с тремя принципами наделения контекста целью и семью вопросами, которые можно использовать для проверки собственной программы.

Одна метрика — множество ответов

Один лидер по работе с данными в финансовом секторе описал дашборд, перегруженный сотнями метрик, где одна и та же ключевая бизнес-мера («Продажи») встречалась в десятках отчетов с противоречивыми значениями. Независимо от того, работал ли сотрудник в маркетинге или финансах, получение показателя продаж за текущий финансовый год немедленно вызывало три базовых вопроса: Где он находится? Как он рассчитывается? И какая версия сертифицирована?

Люди справляются с таким уровнем неопределенности каждый день. Они спрашивают коллегу, проверяют ветку в Slack или выбирают отчет, которому доверяют. AI-агент не может сделать ничего из этого. Он выбирает одну из версий, отвечает бегло, и никто на последующих этапах не знает, что ответ был просто догадкой.

Именно с такой ситуацией сталкиваются многие команды по работе с данными, когда они направляют агентов на свои информационные активы. Это также порождает вопрос, на который текущие советы об ИИ и контексте не всегда дают ответ: что происходит, когда у нас полно контекста, но все еще нет ответа?

Преобладающий совет и то, в чем он прав

Основной посыл на рынке сейчас прост. Агентам нужен контекст для хорошей работы, поэтому давайте им его как можно больше. Каталогизируйте каждый актив, документируйте каждую таблицу и предоставляйте все это агентам во время выполнения.

За этим стоит реальный вес. Люди не могут написать каждое описание и определение, которые нужны ИИ. Документация всегда отставала от данных, и созданные ИИ метаданные могут восполнить часть этого пробела, выявляя знания, которые уже существуют в том, как люди используют данные. Команды, которые попробовали это, сообщают о реальных успехах.

Даже некоторые из наиболее обсуждаемых примеров создания метаданных с помощью ИИ в большом масштабе описывают нечто более осторожное, чем «используй все». Они описывают выбор ограниченного набора критических активов и проведение экспертной проверки всего перед запуском в работу. Самые веские версии аргумента «больше контекста» уже содержат ограничения. Разногласия касаются лишь того, насколько эти ограничения важны.

Где система дает сбой: контекстное болото

Мы стали называть этот сценарий сбоя контекстным болотом: это контекст, созданный ради самого себя, без привязки к результату, владельцу или границам.

У болота есть узнаваемые симптомы.

Существует много версий и ни одной сертифицированной. Одна и та же метрика существует в десятках мест с разными определениями, и никто не может сказать, какая из них является авторитетной. Больший объем контекста только усугубляет ситуацию, потому что каждый дополнительный источник — это еще один кандидат на роль ответа.

Владельцы и актуальность неизвестны. Никто не может сказать, кто стоит за активом, когда он в последний раз менялся или выполняются ли проверки качества до сих пор. На хакатоне, описанном ниже, команды сами, без каких-либо подсказок, затронули темы владельца, актуальности, качества и сертификации. Они обратились к этим критериям, потому что без них контексту нельзя доверять.

Ошибки остаются незамеченными. Когда программное обеспечение работает неверно, оно обычно выдает ошибку. Без семантического контекста агенты могут выбрать неправильный источник, неверную логику метрик или ошибочное соединение таблиц (join) без возможности объяснить почему.² Никто не получает предупреждений, и ошибка переносится дальше в отчет или принятое решение.

Существует более старая версия этой истории. Озера данных должны были сделать все данные доступными, и многие из них превратились в места, где данные были преданы забвению. Компания Gartner предупреждала в 2014 году, что без описательных метаданных и способа их поддержания озеро данных рискует превратиться в болото данных.³ Более темное озеро данных по-прежнему остается озером данных. Если ответом на появление ИИ является сброс всего подряд в контекстный слой без понимания назначения каждого элемента, команды рискуют воссоздать то же самое и назвать это новой архитектурой.

Цель превыше контекста

Закономерность, которая подтвердилась в ходе нашего наблюдения, заключается в том, чтобы определить назначение контекста до его создания. На практике это означает, что лидеры должны широко связывать данные, но проводить строгую и выборочную курацию.

Двигайтесь от результата к началу

Самой полезной привычкой, которую мы увидели, было фиксировать ожидаемый результат еще до начала разработки, во многом подобно составлению пресс-релиза продукта до его создания. Какое решение это поддержит и кто его примет? Что изменится в лучшую сторону после запуска? Наличие четкого пункта назначения позволяет легко отказывать всему, что к нему не ведет. Без этого команды склонны блуждать, и работа расширяется, чтобы занять все доступное время.

Сделайте продукт данных единицей масштаба

Продукт данных наделяет контекст границами и владельцем. Он упаковывает управляемые данные (governed data) для конкретной цели, а его описание отражает намерение и результат, а не просто перечень содержимого. Описание таблицы говорит вам, какие столбцы в ней существуют. Описание хорошего продукта данных говорит вам, на какой вопрос этот продукт отвечает и для кого.

Торговая площадка создает петлю обратной связи. Если команды не уверены, что именно стоит курировать дальше, они могут посмотреть, что люди действительно ищут и запрашивают. Спрос становится опережающим индикатором того, что нужно бизнесу, что является более надежным ориентиром, чем угадывание следующего домена для документирования.

Управляйте целенаправленно и в меньшем объеме

Это правило часто кажется нелогичным. Вместо того чтобы управлять всем одинаково, определите критически важные элементы данных, которые имеют наибольшее значение в вашем нормативно-правовом и операционном контексте, и в первую очередь курируйте и сертифицируйте именно их. Все остальное может оставаться связанным и доступным для поиска без прохождения того же уровня курации.

Мы не предлагаем игнорировать большую часть информационных активов. Разница заключается в широком подключении и узкой кураторской работе: соберите в поле зрения все активы, но подходите осознанно к тому, какие из них вы сертифицируете, подробно документируете и предоставляете агентам в качестве надежных. Команды, способные продемонстрировать ценность небольшого, хорошо управляемого объема данных, завоевывают право расширить его, и со временем под ваше управление попадет гораздо больше.

Место AIOS

Именно на решение этой задачи была ориентирована система Alation Intelligence Operating System. Цель заключается в том, чтобы поддерживать агентов, контекст и данные в актуальном, управляемом и постоянно улучшающемся состоянии, а не позволять им расходиться друг с другом после первого пилотного проекта. Такие возможности, как управление критически важными элементами данных (CDE), сертифицированные продукты данных и маркетплейс, созданы для того, чтобы у контекста появилась четкая цель и владелец. Сам принцип важнее продукта: какими бы инструментами вы ни пользовались, для надежности контексту необходимы границы.

Что показали десять команд за четыре часа

Хакатон проходил в рамках структурированного упражнения из трех этапов.

Во-первых, каждая команда создала стандартный продукт данных и агента, в основном для демонстрации того, как это делается. Во-вторых, каждая команда заполнила один слайд, на котором четко описывалась ценность конкретного продукта данных для их компании: бизнес-результат, целевая аудитория, план внедрения, итоговое техническое состояние, требования к доверию и управлению, а также главное препятствие. Каждая команда представила этот слайд коллегам. В-третьих, участники создали собственные продукты данных с работающим на их основе агентом.

Несколько наблюдений привлекли особое внимание.

Письменная фиксация заставила мыслить конкретно. Команды с туманным представлением о результате быстро обнаруживали пробелы, когда им приходилось заполнять каждое поле, а фасилитатор добивался ответа на каждый вопрос, заставляя команды отстаивать свою концепцию. Несколько команд пересмотрели свои планы после выступлений других участников.

Команды, которые продвигались быстрее всего, сузили область применения. Они действовали итеративно и четко знали, для кого они все создают. У тех, кто столкнулся с трудностями, обычно не было ясности относительно аудитории или конечного результата.

Каждая команда завершила работу с рабочим прототипом. Все они создали продукт данных с работающим на нем агентом всего за четыре часа. Это были демонстрации на синтетических данных в тестовой среде, а не промышленные системы. Тем не менее они оказались достаточно конкретными для тестирования и обсуждения, с чего и начинается любое улучшение.

Кураторство стояло на первом месте. Некоторые команды планировали начать с чата на естественном языке еще до того, как написали описания или глоссарий. Полученные ими рекомендации были однозначны: сначала займитесь кураторством, так как качество чата зависит от стоящего за ним контекста. Команды, пропускающие этот шаг, как правило, остаются разочарованными.

Препятствия в основном касались внедрения, а не технологий. Чаще всего беспокойство вызывали интеграция с существующей инфраструктурой, поддержка со стороны бизнеса и технологических команд, поддержание актуальности прав владения и доступа, а также точность и скорость работы чата. Несколько руководителей также отметили, что само слово «управление» может восприниматься бизнесом как дополнительная нагрузка. Их подход заключался в том, чтобы на первое место ставить результат и использование ИИ, а описывать эту работу на языке бизнеса, а не в терминах критически важных элементов данных.

Стоит отметить еще одну деталь. Одна команда подсчитала, что ручная проверка описаний отнимает от одного до трех часов на каждый набор данных, и заявила, что это уже неприемлемо. Они создавали агента для проверки качества описаний. Один из руководителей этой команды отметил, что качество метаданных беспокоит их больше, чем качество самих данных — полезное напоминание о том, где чаще всего возникают сбои в эпоху искусственного интеллекта.

Почему это важно для бизнеса

Аргументы в пользу контекста, ориентированного на конкретную цель, сводятся к четырем аспектам, за которыми руководители уже следят.

Риск. Несертифицированный, бесхозяйный контекст — это путь к незаметным сбоям. Более узкая область применения с четкими владельцами позволяет точно определить, на что агенту было разрешено полагаться и кто за это отвечает.

Затраты. Ресурсы на кураторство и время на проверки небезграничны. Тратить их на активы, которые никто не использует, — это расход, который не проявляется до тех пор, пока не зайдет речь о бюджете, и его очень сложно защитить, когда руководство спрашивает об окупаемости инвестиций в ИИ.

Скорость. Сфокусированный проект реализуется за считанные недели, тогда как масштабный часто буксует. Первый рекомендуемый Gartner шаг к подготовке данных к работе с ИИ — это их сопоставление с конкретными сценариями использования ИИ.¹ Конкретный результат в одном домене также переносится на другие: четкий показатель из одного бизнес-подразделения становится аргументом для следующего.

Доверие. Команды по работе с данными и управлению ими, не умеющие четко сформулировать свою ценность, первыми сталкиваются с урезанием бюджетов. В отчетах Gartner указано, что программа управления данными, не обеспечивающая приоритетные бизнес-результаты, терпит неудачу, и рекомендуется пересмотреть цели управления в пользу осязаемых результатов.⁴ Управляемый продукт данных, привязанный к измеримому результату, дает им веские аргументы.

С чего начать

Если вы решаете, с чего начать, вам поможет короткий список вопросов:

• Можете ли вы сформулировать желаемый бизнес-результат одним предложением до начала разработки? Если нет, это ваша первоочередная задача.

Можете ли вы сформулировать желаемый бизнес-результат одним предложением до начала разработки? Если нет, это ваша первоочередная задача.

• Кто является потребителем? Назовите конкретную роль или команду, а не «бизнес».

Кто является потребителем? Назовите конкретную роль или команду, а не «бизнес».

• Говорит ли продукт данных о своем назначении, а не только о своем содержимом? Намерение и результат должны быть отражены в описании.

Говорит ли продукт данных о своем назначении, а не только о своем содержимом? Намерение и результат должны быть отражены в описании.

• Какие критически важные элементы данных имеют наибольшее значение для вашего нормативного и операционного контекста? Проведите их кураторскую обработку и сертификацию в первую очередь.

Какие критически важные элементы данных имеют наибольшее значение для вашего нормативного и операционного контекста? Проведите их кураторскую обработку и сертификацию в первую очередь.

• О чем люди спрашивают на вашем маркетплейсе? Пусть спрос определяет, что вы будете курировать дальше. Затем оцените ценность этих продуктов с течением времени на основе их использования.

О чем люди спрашивают на вашем маркетплейсе? Пусть спрос определяет, что вы будете курировать их в следующий раз. Затем оцените ценность этих продуктов с течением времени на основе их использования.

• Есть ли один сертифицированный ответ для каждой важной метрики? Если их пятьдесят, начните с этого.

Есть ли один сертифицированный ответ для каждой важной метрики? Если их пятьдесят, начните с этого.

• Какой единственный домен вы можете взять для пилотного проекта и каков тот самый главный показатель, который вы будете отслеживать? Докажите успех там, прежде чем переходить к следующему.

Какой единственный домен вы можете взять для пилотного проекта и каков тот самый главный показатель, который вы будете отслеживать? Докажите успех там, прежде чем переходить к следующему.

Участники мероприятия описали желаемый темп работы как мультиварку, а не микроволновку: положите правильные ингредиенты, дайте блюду медленно приготовиться, и получится что-то стоящее. То же самое относится и к контексту. Целью никогда не был максимальный объем. Целью был контекст, которому люди и агенты могут доверять при ответе на конкретный вопрос.

Источники и примечания

Каждое внешнее утверждение на этой странице поддается независимой проверке. Публичные источники перечислены здесь.

• По прогнозам Forrester, в 2027 году лишь каждый четвертый проект по созданию корпоративного уровня контекста будет поддерживать агентный ИИ в промышленном масштабе. Это прогноз, а не замер. Forrester, «Predictions 2027: Artificial Intelligence», 14 октября 2026 г.

Forrester прогнозирует, что в 2027 году только каждое четвертое корпоративное решение для работы с контекстным слоем будет поддерживать агентный ИИ в продакшн-масштабе. Это прогноз, а не результат измерения. Forrester, “Predictions 2027: Artificial Intelligence,” 14 October 2026.

• DataHub описывает ситуацию, когда агенты без его контекста выбирают не тот источник, не ту логику метрик или ошибочное объединение (join) без возможности объяснить причину. Это собственный отчет вендора о сбоях, наблюдавшихся в продакшене. DataHub, "Inside the Context Platform: June 2026 Town Hall Highlights," 24 July 2026 (accessed 19 October 2026). https://datahub.com/blog/inside-the-context-platform-june-2026-town-hall-highlights/

DataHub описывает ситуацию, когда агенты без его контекста выбирают не тот источник, не ту логику метрик или ошибочное объединение (join) без возможности объяснить причину. Это собственный отчет вендора о сбоях, наблюдавшихся в продакшене. DataHub, "Inside the Context Platform: June 2026 Town Hall Highlights," 24 July 2026 (accessed 19 October 2026). https://datahub.com/blog/inside-the-context-platform-june-2026-town-hall-highlights/

• Gartner заявляет, что озеро данных без описательных метаданных и механизма их поддержки рискует превратиться в болото данных. Gartner, "Gartner Says Beware of the Data Lake Fallacy," 28 July 2014. https://www.gartner.com/en/newsroom/press-releases/2014-07-28-gartner-says-beware-of-the-data-lake-fallacy

Gartner заявляет, что озеро данных без описательных метаданных и механизма их поддержки рискует превратиться в болото данных. Gartner, "Gartner Says Beware of the Data Lake Fallacy," 28 July 2014. https://www.gartner.com/en/newsroom/press-releases/2014-07-28-gartner-says-beware-of-the-data-lake-fallacy

• Gartner утверждает, что программа управления данными и аналитикой, которая не обеспечивает приоритетные бизнес-результаты, терпит неудачу, и рекомендует пересмотреть масштабы управления с ориентацией на осязаемые бизнес-результаты. Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," 28 February 2024. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

Gartner утверждает, что программа управления данными и аналитикой, которая не обеспечивает приоритетные бизнес-результаты, терпит неудачу, и рекомендует пересмотреть масштабы управления с ориентацией на осязаемые бизнес-результаты. Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," 28 February 2024. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

Атрибуция аналитиков и отказ от ответственности

Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk" (Q&A with Roxane Edjlali), 26 February 2025. Gartner, "Gartner Says Beware of the Data Lake Fallacy," 28 July 2014. Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," 28 February 2024.

Gartner не поддерживает ни одного вендора, продукта или сервиса, упомянутого в своих исследовательских публикациях, и не рекомендует пользователям технологий выбирать только тех вендоров, которые имеют наивысшие оценки или другие обозначения. Исследовательские публикации Gartner отражают мнения исследовательской организации Gartner и не должны рассматриваться как констатация фактов. Gartner отказывается от всех гарантий, выраженных или подразумеваемых, в отношении данного исследования, включая любые гарантии товарной пригодности или пригодности для определенной цели. GARTNER и Magic Quadrant являются зарегистрированными товарными знаками и знаками обслуживания компании Gartner, Inc. и/или ее аффилированных лиц в США и других странах и используются здесь с разрешения. Все права защищены.