Your Data Agents Need Context | Andreessen Horowitz
Статья Andreessen Horowitz рассматривает проблему контекста для data-агентов в корпоративной среде. Несмотря на развитие современного стека данных и рост возможностей LLM, большинство попыток внедрения ИИ-агентов для аналитики провалились из-за отсутствия бизнес-контекста — агенты не могли корректно интерпретировать определения метрик, находить нужные источники данных и работать с «племенными знаниями» команд. Авторы описывают эволюцию от text-to-SQL к полноценному контекстному слою (context layer), который объединяет семантические определения, маршрутизацию данных и неявные знания организации. Предлагается пятиэтапный процесс построения такого слоя: доступ к данным, автоматизированное формирование контекста, ручная доработка, подключение агентов и самообновляющиеся контекстные потоки. На рынке выделяются три категории решений: платформы с гравитацией данных (Databricks, Snowflake), существующие AI-аналитики и новые специализированные компании, строящие контекстные слои с нуля.
Вашим data-агентам нужен контекст
Контекст о контексте
В последнее время в мире данных и ИИ-агентов контекстные слои и графы стали интересной темой для обсуждения. Сегодня, по сути, невозможно поговорить с организацией, работающей с данными и ИИ, чтобы не затронуть тему контекста.
И на то есть веские причины. За последний год рынок осознал, что data- и аналитические агенты практически бесполезны без правильного контекста — они не способны разбирать расплывчатые вопросы, расшифровывать бизнес-определения и эффективно рассуждать на основе разрозненных данных.
И это не их вина, разумеется. Современный стек данных прошёл через десятилетнюю трансформацию от разрозненных источников к консолидированным данным и упорядоченным определениям (что хорошо), но даже в этом случае консолидация никогда не бывает идеальной и привносит немало беспорядка. Общая эволюция рынка выглядела следующим образом:
Расцвет современного стека данных — мы ранее рассматривали трансформационное становление современного стека данных вместе с Tristan Handy из dbt в наших прошлых публикациях и референсных архитектурах. Общая эволюция за последнее десятилетие преобразила архитектуры данных в области загрузки, трансформации, хранения и складирования, чтобы централизовать данные и сделать их быстро и легко доступными. Идея состояла в том, что при аккуратно организованных данных команды смогут просто писать SQL-запросы для извлечения данных из хранилищ, строить графики и дашборды и обеспечивать бизнес-аналитику по всей организации. Агентная лихорадка — в 2024–2025 годах, по мере роста возможностей LLM, буквально каждая организация хотела создавать и развёртывать агентов поверх существующих стеков данных. Мы ранее обсуждали, как определяем агентов, но с организационной точки зрения естественная привлекательность большего объёма работы при большей эффективности и меньших затратах времени привела к тяготению к агентным рабочим процессам. Компании пытались создавать чат-ботов типа «поговори со своими данными», агентов поддержки и т. д. Лихорадка шла одновременно снизу вверх и сверху вниз — разработчики хотели задействовать новейшие, блестящие возможности LLM, а руководство усиливало давление в пользу внедрения ИИ для автоматизации и сокращения расходов. Столкновение со стеной — несмотря на первоначальный оптимизм, быстро стало ясно, что большинство этих начинаний провалились. Организации пытались развернуть своих агентов, но упёрлись в стену. MIT опубликовал свой ставший знаменитым отчёт «State of AI in Business 2025», в котором говорилось, что при внедрении ИИ «большинство терпят неудачу из-за хрупких рабочих процессов, отсутствия контекстного обучения и несоответствия повседневным операциям».
Ключевой причиной, по которой агенты работали плохо, было отсутствие надлежащего контекста данных. Корпоративные данные по-прежнему невероятно разрозненны и беспорядочны — и поэтому data-агенты с трудом отвечали на базовые вопросы вроде «каким был рост выручки в прошлом квартале?» в различных архитектурах данных, объединяющих структурированные и неструктурированные данные.
Как и мечта о полностью самообслуживаемой аналитике прошлых лет, видение data-агентов тоже оказалось не оправдавшим ожиданий.
Проблема контекста — за рамками text-to-SQL
Так почему же первая волна внедрений агентов буксовала? Поначалу многие считали проблему фундаментальным пробелом в рассуждениях о данных и генерации SQL/Python на стороне модели. Общая идея заключалась в том, что модель должна принимать запрос на естественном языке, рассуждать поверх существующих систем данных и генерировать соответствующий SQL-код в традиционном стиле бизнес-аналитики (BI), чтобы извлечь нужные данные и ответить на исходный вопрос.
Если модель давала сбой или была неточной, проблему списывали на то, что модель плохо справляется с SQL, с расчётом на то, что производительность моделей со временем улучшится.
Это не совсем неверно. Хотя возможности моделей значительно улучшились для таких задач, как генерация кода и математические рассуждения, в области данных они по-прежнему отстают (о чём свидетельствуют бенчмарки SQL, такие как Spider 2.0 и Bird Bench). Безусловно, были большие скачки в способностях моделей, но мы быстро поняли, что проблема выходит за рамки text-to-SQL.
Чтобы прояснить ситуацию и подробнее разобрать пример с ростом выручки:
Допустим, внутри организации создан data-агент. Он построен на базе современных фундаментальных моделей, подключён ко всем нужным источникам данных и оснащён удобным интерфейсом для приёма вопросов от внутренних пользователей. Приходит наш запрос: «Каким был рост выручки в прошлом квартале?» Обманчиво простой вопрос, на который обычно можно ответить, бегло взглянув на дашборд в Looker или Tableau, — не должен же он быть проблемой для продвинутого интеллектуального агента! Задача №1 — откуда агенту знать, как на самом деле определены выручка или кварталы? Выручка — это бизнес-определение, которое не зашито жёстко в хранилище или пайплайн. Пользователь ищет run rate revenue или ARR? Отчётные фискальные кварталы могут не быть унифицированы для всех организаций и представлять совершенно разные трёхмесячные периоды в зависимости от компании. Какое временное окно правильное? К счастью, руководитель data-платформы вмешивается и говорит: «Мы создали семантические слои именно для решения этой проблемы. Мы фиксируем определение выручки там.» И — агент должен уметь загружать все семантические слои в качестве контекста. Многообещающее потенциальное решение, но команда смотрит на несколько YAML-файлов и понимает, что они были обновлены уволившимся в прошлом году сотрудником data-команды, больше не используются BI-инструментами, а также не включают две новые продуктовые линейки, запущенные с тех пор. Агент понятия не имеет, как выручка определяется сегодня на самом деле. Чтобы преодолеть этот барьер, член команды жёстко прописывает точные определения выручки и временных рамок. Data-агент продолжает работу, но быстро сталкивается с задачей №2 — где находятся нужные источники данных? Какие из них являются авторитетными? Сырые данные распределены по нескольким таблицам и хранилищам. Финансовая команда использует таблицу fct_revenue, которая может быть корректной, но data-команда создала материализованные представления вроде mv_revenue_monthly и mv_customer_mrr.
Очевидно, что data-агентам необходим доступ к актуальному репозиторию бизнес-определений и источников данных для преодоления этих проблем.
Появление контекстного слоя
Суть проблемы в том, что агенту не предоставлен надлежащий бизнес-контекст для ответа даже на самые простые вопросы. Это отражает более широкий пробел в построении автоматизированных ИИ-систем внутри организаций — необходим актуальный и поддерживаемый контекст, который не только понимает, как работает предприятие и как устроены системы данных, но и сохраняет «племенные знания», связывающие всё воедино.
Это привело к эволюции контекстного слоя. Сегодня в обсуждениях появилось множество названий — context OS, context engine, контекстный слой данных, онтология и другие — но базовая концепция остаётся неизменной. Связать воедино все беспорядочные данные предприятия, добавить контекстный слой поверх, чтобы помочь агентам понимать бизнес-логику, и упаковать его так, чтобы контекст можно было передавать агентам.
Дежавю управления контекстом
Но подождите. Разве то, что мы описываем, не звучит подозрительно похоже на семантический слой…? Действительно, есть определённые сходства, но в конечном счёте, если агентные рабочие процессы должны стать по-настоящему автономными, им нужно несколько больше, чем то, чем сейчас являются семантические слои.
Традиционный семантический слой в контексте BI отлично подходит для конкретных определений метрик (таких как выручка, отток, ARPU). Однако обычно они создаются вручную data-командами с использованием специфического синтаксиса через выделенный слой, такой как LookML, и подключены напрямую к BI-инструменту вроде Looker.
Современный контекстный слой данных по сути должен стать надмножеством того, что традиционно охватывает семантический слой. Конечно, конкретные определения метрик можно зашить жёстко, но современный контекстный слой должен включать больше для обеспечения автономии агентов — канонические сущности, разрешение идентичностей, специальные инструкции для расшифровки «племенных знаний», надлежащие правила управления данными и многое другое.
Эта статья в первую очередь посвящена контексту данных, связывающему традиционные системы записи. Не менее важная и пересекающаяся возможность — это также фиксация решений и логики рабочих процессов организации, чтобы можно было создавать действительно многоцелевых агентов, надёжно заземлённых во всех данных и контексте принятия решений организации.
Собираем всё вместе
На основе наших недавних бесед с клиентами и понимания их потребностей, вот как, по нашему мнению, может выглядеть современный контекстный слой в сочетании с агентной системой данных — поэтапно:
1) Доступ к правильным данным — первоочередная задача — убедиться, что все нужные данные доступны. Это базовое требование. В идеале организация внедряет какую-либо форму современного стека данных с определённой степенью унификации через архитектуру lakehouse. Но даже в этом случае мы хотим убедиться, что агент имеет доступ ко всем необходимым данным, которые могут выходить за рамки того, что доступно в хранилищах и операционных приложениях. Сюда относятся «племенные знания», зафиксированные во внутренних системах, GDrive/Slack и т. д.
2) Автоматизированное построение контекста — когда все нужные данные доступны, следующий шаг — начать построение контекстного слоя. Преимущество использования LLM в том, что значительную часть первоначального сбора контекста можно выполнить автоматически. Акцент следует делать на высокосигнальном контексте — например, анализ истории прошлых запросов может быть высокосигнальным для определения наиболее часто используемых таблиц и наиболее распространённых соединений, а решения для моделирования данных вроде dbt или LookML могут предоставить чёткие определения бизнес-метрик.
3) Доработка человеком — автоматизированное построение контекста может сформировать значительную часть контекстного корпуса, но не может создать полную картину. Заманчиво отпустить агентов на сбор всех внутренних знаний, но часть наиболее важного контекста является неявной, условной и исторически обусловленной и существует лишь как «племенные знания» внутри команд.
Человеческий вклад обеспечивает финальные критически важные связи, делающие возможной истинную автоматизацию агентов. Например: «для CRM-данных обращайтесь к Affinity для всех новых сделок USCAN с 2025 года, но к Salesforce — для всех глобальных лидов до этого периода».
Таким образом контекстный слой может стать многомерным корпусом, где код существует рядом с естественным языком, фиксируя любой контекст, который может понадобиться агенту. Подобно тому, как разработчики могут настраивать файлы .cursorrules для управления агентами и контроля поведения, специалисты по данным могут вести правила и рекомендации.
4) Подключение агентов — когда контекстный слой правильно построен, его нужно лишь открыть для агентов и сделать доступным в реальном времени. Обычно это реализуется через API или MCP.
5) Самообновляющиеся контекстные потоки — хотя начальная система настроена правильно, системы данных никогда не статичны, и контекстный слой тоже не должен быть таковым. Источники и форматы данных могут меняться на входе, а пользователи могут иметь собственные инструкции, которые захотят добавлять и изменять в соответствии с меняющимися бизнес-требованиями. Если data-агент предоставляет некорректные данные и требуется уточнение точности, это, разумеется, должно быть включено обратно в контекстный слой. Таким образом контекстный слой становится живым и постоянно эволюционирующим корпусом.
Один из выводов всего этого упражнения — построение полноценного data-агента является непростой задачей. Это сочетание технических вызовов, связанных с инфраструктурой и инженерией данных, с операционными человеческими задачами по сбору «племенных знаний».
Команда OpenAI недавно опубликовала отличный материал, описывающий создание собственного внутреннего data-агента. Это прозрачное описание очень детальной и элегантной реализации — но оно указывает на долгий путь, необходимый для достижения результата. Аналогично, Palantir имеет большой опыт построения онтологий для организаций, обеспечивающих чёткий контекст из беспорядочных данных, и построила на этом крупный бизнес.
Направление рынка
Естественно, это открывает окно для внешнего решения. В реальности не каждое предприятие может (или должно) строить это самостоятельно, и мы уже наблюдаем появление различных решений на рынке.
Хотя мы считаем, что ещё рано говорить о зрелых решениях, ниже представлена обзорная карта рынка разрабатываемых решений:
Разберём категории:
Платформы с гравитацией данных — платформы вроде Databricks и Snowflake уже прошли через процессы загрузки, трансформации и хранения данных, и гравитация данных — мощная сила. Они уже работают над продуктами ИИ-аналитики данных, такими как Databricks Genie и Snowflake Cortex Analyst, которые построены поверх хранилищ данных и используют фундаментальные модели для text-to-SQL, позволяя пользователям задавать вопросы о своих данных на естественном языке.
Хотя эти платформы не обладают суперсложной функциональностью контекстного слоя как таковой, они допускают лёгкое семантическое моделирование, и существует реалистичный путь — через приобретение компаний или внутреннюю разработку — для интеграции контекстных слоёв в платформу.
Существующие «компании ИИ-аналитики данных» — появилась волна компаний, использующих ИИ, чтобы позволить клиентам общаться со своими данными. Многие из них за время работы на рынке осознали, что ключ к эффективным data-агентам — это построение релевантного контекстного слоя. В результате некоторые эволюционировали и включили построение контекста данных как ключевую часть своих продуктов.
Новые специализированные компании контекстного слоя — появилась новая категория компаний, строящих контекстные слои с нуля. Им предстоит пройти весь описанный путь — загрузка данных, сбор «племенных знаний» и многое другое — и делать это для каждого отдельного клиента.
Взгляд в будущее
Мы находимся в интересном моменте развития рынка, когда проблема отсутствия контекста стала очевидной, но мы всё ещё на ранних стадиях построения решений.
Будущее вдохновляет — возможно, видение полностью самообслуживаемой аналитики наконец может быть реализовано, а BI, аналитика данных и data science могут быть трансформированы с помощью ИИ.
Естественно, остаётся множество открытых вопросов. Где будет жить этот контекстный слой? Может ли он существовать в нескольких местах? Будет ли он самостоятельным продуктом?
Нас воодушевляют возможности для инноваций в этой области. Если вы строите что-то в этом пространстве, мы будем рады пообщаться! Пишите на jcui@a16z.com или @jasonscui в X.
Jason Cui
партнёр в Andreessen Horowitz, где занимается инвестициями в инфраструктуру и ИИ.
Jennifer Li
генеральный партнёр в Andreessen Horowitz, где руководит инвестициями в инфраструктуру с фокусом на системы данных, инструменты разработчиков и ИИ.
Хотите больше об инфраструктуре?
Аналитика и новости о последних трендах, преобразующих ИИ и инфраструктуру.
Мнения, выраженные в «публикациях» (включая подкасты, видео и социальные сети), принадлежат конкретным сотрудникам a16z, цитируемым в них, и не являются мнениями a16z Capital Management, L.L.C. («a16z») или её аффилированных лиц. a16z Capital Management является инвестиционным консультантом, зарегистрированным в Комиссии по ценным бумагам и биржам. Регистрация в качестве инвестиционного консультанта не подразумевает какой-либо особой квалификации или подготовки. Публикации не адресованы каким-либо инвесторам или потенциальным инвесторам и не представляют собой предложение о продаже — или приглашение к покупке — каких-либо ценных бумаг и не могут использоваться или служить основой для оценки достоинств любой инвестиции.
Содержание настоящего материала — а также материалы, доступные на любых связанных платформах распространения и любых публичных аккаунтах a16z в социальных сетях, платформах и сайтах (совместно именуемых «каналы распространения контента») — не должно рассматриваться или использоваться в качестве инвестиционных, юридических, налоговых или иных рекомендаций. По вопросам, связанным с инвестициями, следует консультироваться с собственными советниками. Любые прогнозы, оценки, ориентиры, перспективы и/или мнения, выраженные в данных материалах, могут быть изменены без уведомления и могут отличаться от мнений, выраженных другими лицами, или противоречить им. Любые графики, представленные здесь или на каналах распространения контента a16z, предназначены исключительно для информационных целей и не должны служить основой при принятии инвестиционных решений. Определённая информация, содержащаяся здесь, получена из сторонних источников, в том числе от портфельных компаний фондов под управлением a16z. Несмотря на то что информация получена из источников, считающихся надёжными, a16z не проводила независимую проверку такой информации и не делает заявлений о её достоверности или пригодности для конкретной ситуации. Кроме того, публикации могут содержать рекламу третьих сторон; a16z не проверяла такую рекламу и не одобряет рекламный контент, содержащийся в ней. Всё содержание актуально только на указанную дату.
Ни при каких обстоятельствах какие-либо публикации или иная информация, представленная на данном сайте — или на связанных каналах распространения контента — не должна рассматриваться как предложение о покупке или продаже какой-либо ценной бумаги или доли в каком-либо объединённом инвестиционном инструменте, спонсируемом, обсуждаемом или упоминаемом сотрудниками a16z. Равно как она не должна рассматриваться как предложение об оказании услуг инвестиционного консультирования; предложение об инвестировании в объединённый инвестиционный инструмент под управлением a16z будет сделано отдельно и исключительно посредством конфиденциальных документов предложения конкретных объединённых инвестиционных инструментов — которые должны быть прочитаны в полном объёме и только теми лицами, которые, помимо прочих требований, отвечают определённым квалификационным критериям в соответствии с федеральным законодательством о ценных бумагах. Такие инвесторы, определяемые как аккредитованные инвесторы и квалифицированные покупатели, как правило, считаются способными самостоятельно оценивать достоинства и риски предполагаемых инвестиций и финансовых вопросов.
Не может быть никаких гарантий того, что инвестиционные цели a16z будут достигнуты или инвестиционные стратегии окажутся успешными. Любая инвестиция в инструмент под управлением a16z сопряжена с высокой степенью риска, включая риск полной потери вложенной суммы. Любые упомянутые, указанные или описанные инвестиции или портфельные компании не являются репрезентативными для всех инвестиций в инструменты под управлением a16z, и не может быть никаких гарантий того, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами под управлением a16z, доступен здесь: https://a16z.com/investments/. Прошлые результаты инвестиций a16z, объединённых инвестиционных инструментов или инвестиционных стратегий не обязательно являются индикатором будущих результатов. Из данного списка исключены инвестиции (а также определённые публично торгуемые криптовалюты/цифровые активы), по которым эмитент не дал разрешения a16z на публичное раскрытие информации. Что касается инвестиций в любой криптовалютный или токенный проект, a16z действует в собственных финансовых интересах, не обязательно в интересах других держателей токенов. a16z не выполняет особой роли ни в одном из этих проектов и не обладает полномочиями по их управлению. a16z не берёт на себя обязательство продолжать какое-либо участие в этих проектах, кроме как в качестве инвестора и держателя токенов, и другие держатели токенов не должны ожидать или рассчитывать на какое-либо особое участие.
В отношении фондов под управлением a16z, зарегистрированных в Японии, a16z предоставит любому представителю японской общественности копию документов, которые должны быть публично доступны в соответствии со статьёй 63 Закона о финансовых инструментах и биржах Японии. Для запроса таких документов обращайтесь по адресу compliance@a16z.com.
С прочими условиями использования сайта можно ознакомиться здесь. Дополнительная важная информация об a16z, включая нашу Брошюру Формы ADV Часть 2A, доступна на сайте SEC: http://www.adviserinfo.sec.gov.