Your Data Agents Need Context | Andreessen Horowitz
Статья Andreessen Horowitz рассматривает проблему контекста для data-агентов в корпоративной среде. Несмотря на развитие современного стека данных и рост возможностей LLM, большинство попыток внедрения ИИ-агентов для аналитики провалились из-за отсутствия бизнес-контекста — агенты не могли корректно интерпретировать определения метрик, находить нужные источники данных и работать с «племенными знаниями» команд. Авторы описывают эволюцию от text-to-SQL к полноценному контекстному слою (context layer), который объединяет семантические определения, маршрутизацию данных и неявные знания организации. Предлагается пятиэтапный процесс построения такого слоя: доступ к данным, автоматизированное формирование контекста, ручная доработка, подключение агентов и самообновляющиеся контекстные потоки. На рынке выделяются три категории решений: платформы с гравитацией данных (Databricks, Snowflake), существующие AI-аналитики и новые специализированные компании, строящие контекстные слои с нуля.
Your Data Agents Need Context
Вашим data-агентам нужен контекст
The context on context
Контекст о контексте
Recently in the world of data and AI agents, context layers and graphs have emerged as an interesting topic of discussion. In fact, it’s difficult today to have a conversation with an organization working with data and AI and not have the topic of context come up.
В последнее время в мире данных и ИИ-агентов контекстные слои и графы стали интересной темой для обсуждения. Сегодня, по сути, невозможно поговорить с организацией, работающей с данными и ИИ, чтобы не затронуть тему контекста.
And for good reason. Over the past year, the market has realized that data and analytics agents are essentially useless without the right context – they aren’t able to tease apart vague questions, decipher business definitions, and reason across disparate data effectively.
И на то есть веские причины. За последний год рынок осознал, что data- и аналитические агенты практически бесполезны без правильного контекста — они не способны разбирать расплывчатые вопросы, расшифровывать бизнес-определения и эффективно рассуждать на основе разрозненных данных.
It’s not their fault, of course. The modern data stack has undergone a decade+ transition from disparate data sources to consolidated data and cleaned definitions (which is good), but even then the consolidation is never perfect and a lot of messiness is introduced. The general market evolution has been as follows:
И это не их вина, разумеется. Современный стек данных прошёл через десятилетнюю трансформацию от разрозненных источников к консолидированным данным и упорядоченным определениям (что хорошо), но даже в этом случае консолидация никогда не бывает идеальной и привносит немало беспорядка. Общая эволюция рынка выглядела следующим образом:
Расцвет современного стека данных — мы ранее рассматривали трансформационное становление современного стека данных вместе с Tristan Handy из dbt в наших прошлых публикациях и референсных архитектурах. Общая эволюция за последнее десятилетие преобразила архитектуры данных в области загрузки, трансформации, хранения и складирования, чтобы централизовать данные и сделать их быстро и легко доступными. Идея состояла в том, что при аккуратно организованных данных команды смогут просто писать SQL-запросы для извлечения данных из хранилищ, строить графики и дашборды и обеспечивать бизнес-аналитику по всей организации. Агентная лихорадка — в 2024–2025 годах, по мере роста возможностей LLM, буквально каждая организация хотела создавать и развёртывать агентов поверх существующих стеков данных. Мы ранее обсуждали, как определяем агентов, но с организационной точки зрения естественная привлекательность большего объёма работы при большей эффективности и меньших затратах времени привела к тяготению к агентным рабочим процессам. Компании пытались создавать чат-ботов типа «поговори со своими данными», агентов поддержки и т. д. Лихорадка шла одновременно снизу вверх и сверху вниз — разработчики хотели задействовать новейшие, блестящие возможности LLM, а руководство усиливало давление в пользу внедрения ИИ для автоматизации и сокращения расходов. Столкновение со стеной — несмотря на первоначальный оптимизм, быстро стало ясно, что большинство этих начинаний провалились. Организации пытались развернуть своих агентов, но упёрлись в стену. MIT опубликовал свой ставший знаменитым отчёт «State of AI in Business 2025», в котором говорилось, что при внедрении ИИ «большинство терпят неудачу из-за хрупких рабочих процессов, отсутствия контекстного обучения и несоответствия повседневным операциям».
A crucial reason agents didn’t work well was a lack of proper data context. Enterprise data today is still incredibly disparate and messy – and because of that, data agents struggled to answer basic questions like “what was revenue growth last quarter?” across various data architectures amassing structured and unstructured data.
Ключевой причиной, по которой агенты работали плохо, было отсутствие надлежащего контекста данных. Корпоративные данные по-прежнему невероятно разрозненны и беспорядочны — и поэтому data-агенты с трудом отвечали на базовые вопросы вроде «каким был рост выручки в прошлом квартале?» в различных архитектурах данных, объединяющих структурированные и неструктурированные данные.
Just like how the vision of fully self-serve analytics of years ago fell short, the vision for data agents seemed to fall short as well.
Как и мечта о полностью самообслуживаемой аналитике прошлых лет, видение data-агентов тоже оказалось не оправдавшим ожиданий.
The context problem – beyond just text to SQL
Проблема контекста — за рамками text-to-SQL
So why did that initial era of agent deployments struggle? At first, many believed the issue to be a fundamental data reasoning and SQL/Python codegen gap on the model side. The general idea was that a model should be able to take in a natural language query as an initial input, reason over existing data systems, and generate corresponding SQL code in traditional business intelligence (BI) fashion to pull the right data and answer the initial question accordingly.
Так почему же первая волна внедрений агентов буксовала? Поначалу многие считали проблему фундаментальным пробелом в рассуждениях о данных и генерации SQL/Python на стороне модели. Общая идея заключалась в том, что модель должна принимать запрос на естественном языке, рассуждать поверх существующих систем данных и генерировать соответствующий SQL-код в традиционном стиле бизнес-аналитики (BI), чтобы извлечь нужные данные и ответить на исходный вопрос.
If the model failed or wasn’t accurate, the gap was chalked up to the model not being good at SQL with the expectation that model performance would improve.
Если модель давала сбой или была неточной, проблему списывали на то, что модель плохо справляется с SQL, с расчётом на то, что производительность моделей со временем улучшится.
This is not entirely false. While model capabilities have improved dramatically for use cases like codegen and mathematical reasoning, they still lag behind on the data side (as evidenced through SQL benchmarks like Spider 2.0 and Bird Bench). There have undoubtedly been big leaps in models’ abilities, but we’ve quickly learned that the problem extends beyond just text to SQL.
Это не совсем неверно. Хотя возможности моделей значительно улучшились для таких задач, как генерация кода и математические рассуждения, в области данных они по-прежнему отстают (о чём свидетельствуют бенчмарки SQL, такие как Spider 2.0 и Bird Bench). Безусловно, были большие скачки в способностях моделей, но мы быстро поняли, что проблема выходит за рамки text-to-SQL.
To crystallize things and break down the revenue growth example a bit more:
Чтобы прояснить ситуацию и подробнее разобрать пример с ростом выручки:
Допустим, внутри организации создан data-агент. Он построен на базе современных фундаментальных моделей, подключён ко всем нужным источникам данных и оснащён удобным интерфейсом для приёма вопросов от внутренних пользователей. Приходит наш запрос: «Каким был рост выручки в прошлом квартале?» Обманчиво простой вопрос, на который обычно можно ответить, бегло взглянув на дашборд в Looker или Tableau, — не должен же он быть проблемой для продвинутого интеллектуального агента! Задача №1 — откуда агенту знать, как на самом деле определены выручка или кварталы? Выручка — это бизнес-определение, которое не зашито жёстко в хранилище или пайплайн. Пользователь ищет run rate revenue или ARR? Отчётные фискальные кварталы могут не быть унифицированы для всех организаций и представлять совершенно разные трёхмесячные периоды в зависимости от компании. Какое временное окно правильное? К счастью, руководитель data-платформы вмешивается и говорит: «Мы создали семантические слои именно для решения этой проблемы. Мы фиксируем определение выручки там.» И — агент должен уметь загружать все семантические слои в качестве контекста. Многообещающее потенциальное решение, но команда смотрит на несколько YAML-файлов и понимает, что они были обновлены уволившимся в прошлом году сотрудником data-команды, больше не используются BI-инструментами, а также не включают две новые продуктовые линейки, запущенные с тех пор. Агент понятия не имеет, как выручка определяется сегодня на самом деле. Чтобы преодолеть этот барьер, член команды жёстко прописывает точные определения выручки и временных рамок. Data-агент продолжает работу, но быстро сталкивается с задачей №2 — где находятся нужные источники данных? Какие из них являются авторитетными? Сырые данные распределены по нескольким таблицам и хранилищам. Финансовая команда использует таблицу fct_revenue, которая может быть корректной, но data-команда создала материализованные представления вроде mv_revenue_monthly и mv_customer_mrr.
It’s clear that data agents need access to a repository of up-to-date business definitions and data sources to overcome these problems.
Очевидно, что data-агентам необходим доступ к актуальному репозиторию бизнес-определений и источников данных для преодоления этих проблем.
Enter the context layer
Появление контекстного слоя
The crux of the problem at hand is that the agent isn’t given the proper business context to answer even the most basic questions. This is representative of a larger gap that’s present in building automated AI systems within organizations – there needs to be up-to-date and maintained context that not only understands how an enterprise works and how the data systems are structured, but also maintains the tribal knowledge to tie everything together.
Суть проблемы в том, что агенту не предоставлен надлежащий бизнес-контекст для ответа даже на самые простые вопросы. Это отражает более широкий пробел в построении автоматизированных ИИ-систем внутри организаций — необходим актуальный и поддерживаемый контекст, который не только понимает, как работает предприятие и как устроены системы данных, но и сохраняет «племенные знания», связывающие всё воедино.
This has led to the evolution of the context layer. Many names have emerged in discussion today – context OS, context engine, contextual data layer, ontology, and more – but the underlying concept remains the same. Tie together all of an enterprise’s messy data, add a contextual layer on top that helps agents understand business logic, and package it such that the context can be supplied to agents.
Это привело к эволюции контекстного слоя. Сегодня в обсуждениях появилось множество названий — context OS, context engine, контекстный слой данных, онтология и другие — но базовая концепция остаётся неизменной. Связать воедино все беспорядочные данные предприятия, добавить контекстный слой поверх, чтобы помочь агентам понимать бизнес-логику, и упаковать его так, чтобы контекст можно было передавать агентам.
Context management déjà vu
Дежавю управления контекстом
But wait. Doesn’t what we’re describing sound eerily similar to a semantic layer…? There are indeed some similarities, but at the end of the day if agent workflows are to become truly autonomous they need a bit more than how semantic layers currently manifest.
Но подождите. Разве то, что мы описываем, не звучит подозрительно похоже на семантический слой…? Действительно, есть определённые сходства, но в конечном счёте, если агентные рабочие процессы должны стать по-настоящему автономными, им нужно несколько больше, чем то, чем сейчас являются семантические слои.
A traditional semantic layer in the context of BI is great for specific metric definitions (like revenue, churn, ARPU). However, they are usually hand constructed by data teams using very specific syntax through a dedicated layer like LookML and are connected directly to a BI tool like Looker.
Традиционный семантический слой в контексте BI отлично подходит для конкретных определений метрик (таких как выручка, отток, ARPU). Однако обычно они создаются вручную data-командами с использованием специфического синтаксиса через выделенный слой, такой как LookML, и подключены напрямую к BI-инструменту вроде Looker.
A modern data context layer should essentially become a superset of what a semantic layer would traditionally cover. Sure, specific metric definitions can be hard-coded, but a modern context layer should include more to ensure agent autonomy – canonical entities, identity resolution, specific instructions to dissect tribal knowledge, proper governance guidance, and more.
Современный контекстный слой данных по сути должен стать надмножеством того, что традиционно охватывает семантический слой. Конечно, конкретные определения метрик можно зашить жёстко, но современный контекстный слой должен включать больше для обеспечения автономии агентов — канонические сущности, разрешение идентичностей, специальные инструкции для расшифровки «племенных знаний», надлежащие правила управления данными и многое другое.
This piece will primarily focus on data context that ties together traditional systems of record. An equally important and overlapping opportunity is also capturing an organization’s decisions and workflow logic so truly multipurpose agents can be built that are properly grounded in all of an organization’s data and decisioning context.
Эта статья в первую очередь посвящена контексту данных, связывающему традиционные системы записи. Не менее важная и пересекающаяся возможность — это также фиксация решений и логики рабочих процессов организации, чтобы можно было создавать действительно многоцелевых агентов, надёжно заземлённых во всех данных и контексте принятия решений организации.
Putting it all together
Собираем всё вместе
Based on our recent conversations with customers and understanding their needs, here’s what we believe a modern context layer paired with an agentic data system could look like, broken down step-by-step:
На основе наших недавних бесед с клиентами и понимания их потребностей, вот как, по нашему мнению, может выглядеть современный контекстный слой в сочетании с агентной системой данных — поэтапно:
1) Accessing the right data – the first order of business is ensuring all the right data is accessible. This is table stakes. Ideally an organization would be implementing some form of the modern data stack with some degree of unification through a lakehouse architecture. Even then, we’d want to ensure the agent has access to all the data it needs, which may extend beyond just what’s available in warehouses and operational apps. This includes tribal knowledge captured in internal systems, GDrive/Slack, etc.
1) Доступ к правильным данным — первоочередная задача — убедиться, что все нужные данные доступны. Это базовое требование. В идеале организация внедряет какую-либо форму современного стека данных с определённой степенью унификации через архитектуру lakehouse. Но даже в этом случае мы хотим убедиться, что агент имеет доступ ко всем необходимым данным, которые могут выходить за рамки того, что доступно в хранилищах и операционных приложениях. Сюда относятся «племенные знания», зафиксированные во внутренних системах, GDrive/Slack и т. д.
2) Automated context construction – once all the right data is accessible, the next step is starting the construction of the context layer. The benefit of using LLMs is that a lot of the initial context gathering can be done in an automated way. An emphasis of focus should be on high signal context – for example, looking through past query history can be high signal in determining the most referenced tables and most common joins, and data modeling solutions like dbt or LookML can provide clear definitions for business metrics.
2) Автоматизированное построение контекста — когда все нужные данные доступны, следующий шаг — начать построение контекстного слоя. Преимущество использования LLM в том, что значительную часть первоначального сбора контекста можно выполнить автоматически. Акцент следует делать на высокосигнальном контексте — например, анализ истории прошлых запросов может быть высокосигнальным для определения наиболее часто используемых таблиц и наиболее распространённых соединений, а решения для моделирования данных вроде dbt или LookML могут предоставить чёткие определения бизнес-метрик.
3) Human refinement – Automated context construction may be able to form a large portion of the context corpus, but it can’t create the full picture. It’s tempting to set agents loose and have them collect all internal knowledge, but some of the most important context is implicit, conditional, and historically contingent, and only exists as tribal knowledge inside teams.
3) Доработка человеком — автоматизированное построение контекста может сформировать значительную часть контекстного корпуса, но не может создать полную картину. Заманчиво отпустить агентов на сбор всех внутренних знаний, но часть наиболее важного контекста является неявной, условной и исторически обусловленной и существует лишь как «племенные знания» внутри команд.
Human input provides the final crucial links that enable true agent automation. For example – “for CRM data, look at Affinity for all new USCAN deals from 2025 onwards but Salesforce for all global leads before that.”
Человеческий вклад обеспечивает финальные критически важные связи, делающие возможной истинную автоматизацию агентов. Например: «для CRM-данных обращайтесь к Affinity для всех новых сделок USCAN с 2025 года, но к Salesforce — для всех глобальных лидов до этого периода».
In this way the context layer can become a multi-dimensional corpus where code lives alongside natural language, capturing any context an agent might need. Just like developers can set up .cursorrules files to guide agents and control output behavior, data practitioners can maintain rules and guidelines.
Таким образом контекстный слой может стать многомерным корпусом, где код существует рядом с естественным языком, фиксируя любой контекст, который может понадобиться агенту. Подобно тому, как разработчики могут настраивать файлы .cursorrules для управления агентами и контроля поведения, специалисты по данным могут вести правила и рекомендации.
4) Agent connection – once the context layer is properly constructed, it just needs to be exposed to agents and accessible real-time. This can typically be done through API or MCP.
4) Подключение агентов — когда контекстный слой правильно построен, его нужно лишь открыть для агентов и сделать доступным в реальном времени. Обычно это реализуется через API или MCP.
5) Self-updating context flows – While the initial system has been set up correctly, data systems are never static and as a result the context layer shouldn’t be either. Data sources and formats can change upstream and individuals may have custom instructions they’ll want to add and modify based on changing business requirements. In the case a data agent provides incorrect data and requires accuracy refinement, that should of course be incorporated back into the context layer. In this way the context layer becomes a living and constantly evolving corpus.
5) Самообновляющиеся контекстные потоки — хотя начальная система настроена правильно, системы данных никогда не статичны, и контекстный слой тоже не должен быть таковым. Источники и форматы данных могут меняться на входе, а пользователи могут иметь собственные инструкции, которые захотят добавлять и изменять в соответствии с меняющимися бизнес-требованиями. Если data-агент предоставляет некорректные данные и требуется уточнение точности, это, разумеется, должно быть включено обратно в контекстный слой. Таким образом контекстный слой становится живым и постоянно эволюционирующим корпусом.
One takeaway from this whole exercise is that building a proper data agent is no small feat. It’s a blend of technical challenges related to data infrastructure and engineering with human operational challenges related to tribal knowledge collection.
Один из выводов всего этого упражнения — построение полноценного data-агента является непростой задачей. Это сочетание технических вызовов, связанных с инфраструктурой и инженерией данных, с операционными человеческими задачами по сбору «племенных знаний».
The OpenAI team recently published a fantastic piece detailing the creation of their own internal data agent. It’s a transparent detail of a very detailed and elegant implementation – but points to the long journey required to get there. Similarly, Palantir has a long history of constructing ontologies for organizations that provide clear context from messy data, and have built a big business doing so.
Команда OpenAI недавно опубликовала отличный материал, описывающий создание собственного внутреннего data-агента. Это прозрачное описание очень детальной и элегантной реализации — но оно указывает на долгий путь, необходимый для достижения результата. Аналогично, Palantir имеет большой опыт построения онтологий для организаций, обеспечивающих чёткий контекст из беспорядочных данных, и построила на этом крупный бизнес.
Market direction
Направление рынка
Naturally, that opens up a window for an external solution. Realistically not every enterprise can (or should) build this in house, and we’re starting to see various solutions coming to market already.
Естественно, это открывает окно для внешнего решения. В реальности не каждое предприятие может (или должно) строить это самостоятельно, и мы уже наблюдаем появление различных решений на рынке.
While we believe we’re still early in seeing solutions come to fruition, the below is a high level market map of solutions being built:
Хотя мы считаем, что ещё рано говорить о зрелых решениях, ниже представлена обзорная карта рынка разрабатываемых решений:
To break the categories down:
Разберём категории:
Data gravity platforms – platforms like Databricks and Snowflake have already gone through the motions of data ingestion, transformation, and storage and data gravity is powerful. They are already working on AI data analyst products like Databricks Genie and Snowflake Cortex Analyst which are built on top of data warehouses and utilize foundational models for text to SQL to allow users to ask questions about their data in natural language.
Платформы с гравитацией данных — платформы вроде Databricks и Snowflake уже прошли через процессы загрузки, трансформации и хранения данных, и гравитация данных — мощная сила. Они уже работают над продуктами ИИ-аналитики данных, такими как Databricks Genie и Snowflake Cortex Analyst, которые построены поверх хранилищ данных и используют фундаментальные модели для text-to-SQL, позволяя пользователям задавать вопросы о своих данных на естественном языке.
While these platforms don’t have super sophisticated context layer functionalities per se, they do allow for lightweight semantic modeling and there’s a feasible path forward through either company acquisition or in-house development for context layers to be brought in on platform.
Хотя эти платформы не обладают суперсложной функциональностью контекстного слоя как таковой, они допускают лёгкое семантическое моделирование, и существует реалистичный путь — через приобретение компаний или внутреннюю разработку — для интеграции контекстных слоёв в платформу.
Existing “AI data analyst companies” – there’s a wave of companies that have already emerged utilizing AI to allow customers to chat with your data. Many have realized through time in market that the key to effective data agents is actually building the relevant context layer. As a result, some have evolved to encompass data context construction as a key part of their products.
Существующие «компании ИИ-аналитики данных» — появилась волна компаний, использующих ИИ, чтобы позволить клиентам общаться со своими данными. Многие из них за время работы на рынке осознали, что ключ к эффективным data-агентам — это построение релевантного контекстного слоя. В результате некоторые эволюционировали и включили построение контекста данных как ключевую часть своих продуктов.
New, dedicated context layer companies – a new category of company has emerged that is building context layers from the ground up. They will have to go through our journey above of ingesting data, collecting tribal knowledge, and more – and will have to do so for each individual customer they work with.
Новые специализированные компании контекстного слоя — появилась новая категория компаний, строящих контекстные слои с нуля. Им предстоит пройти весь описанный путь — загрузка данных, сбор «племенных знаний» и многое другое — и делать это для каждого отдельного клиента.
Looking forward
Взгляд в будущее
We are at an interesting point in time of market development, where the problem of a lack of context has become apparent, but we are still in the early innings of building solutions.
Мы находимся в интересном моменте развития рынка, когда проблема отсутствия контекста стала очевидной, но мы всё ещё на ранних стадиях построения решений.
The future is exciting – perhaps the vision of truly self-serve analytics can be fully realized, and BI, data analytics, and data science can be transformed through AI.
Будущее вдохновляет — возможно, видение полностью самообслуживаемой аналитики наконец может быть реализовано, а BI, аналитика данных и data science могут быть трансформированы с помощью ИИ.
Naturally, many open questions still remain. Where will this context layer live? Can it live in multiple places? Will it be its own standalone product?
Естественно, остаётся множество открытых вопросов. Где будет жить этот контекстный слой? Может ли он существовать в нескольких местах? Будет ли он самостоятельным продуктом?
We remain excited about the opportunities for innovation here. If you’re building in the space, we’d love to chat! Please reach out at jcui@a16z.com or @jasonscui on X.
Нас воодушевляют возможности для инноваций в этой области. Если вы строите что-то в этом пространстве, мы будем рады пообщаться! Пишите на jcui@a16z.com или @jasonscui в X.
Jason Cui
Jason Cui
is a partner at Andreessen Horowitz, where he invests in infrastructure and AI.
партнёр в Andreessen Horowitz, где занимается инвестициями в инфраструктуру и ИИ.
Jennifer Li
Jennifer Li
is a general partner at Andreessen Horowitz, where she leads infrastructure investments with an eye on data systems, developer tools and AI.
генеральный партнёр в Andreessen Horowitz, где руководит инвестициями в инфраструктуру с фокусом на системы данных, инструменты разработчиков и ИИ.
I Built TetrisBench, Where LLMs Compete at Playing Tetris. Here’s What I Found.
Я создал TetrisBench, где LLM соревнуются в тетрисе. Вот что я обнаружил.
Most People Can’t Vibe Code. Here’s How We Fix That.
Большинство людей не могут вайб-кодить. Вот как мы это исправим.
Want More Infra?
Хотите больше об инфраструктуре?
Analysis and news covering the latest trends reshaping AI and infrastructure.
Аналитика и новости о последних трендах, преобразующих ИИ и инфраструктуру.
Views expressed in “posts” (including podcasts, videos, and social media) are those of the individual a16z personnel quoted therein and are not the views of a16z Capital Management, L.L.C. (“a16z”) or its respective affiliates. a16z Capital Management is an investment adviser registered with the Securities and Exchange Commission. Registration as an investment adviser does not imply any special skill or training. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell — or a solicitation of an offer to buy — any securities, and may not be used or relied upon in evaluating the merits of any investment.
Мнения, выраженные в «публикациях» (включая подкасты, видео и социальные сети), принадлежат конкретным сотрудникам a16z, цитируемым в них, и не являются мнениями a16z Capital Management, L.L.C. («a16z») или её аффилированных лиц. a16z Capital Management является инвестиционным консультантом, зарегистрированным в Комиссии по ценным бумагам и биржам. Регистрация в качестве инвестиционного консультанта не подразумевает какой-либо особой квалификации или подготовки. Публикации не адресованы каким-либо инвесторам или потенциальным инвесторам и не представляют собой предложение о продаже — или приглашение к покупке — каких-либо ценных бумаг и не могут использоваться или служить основой для оценки достоинств любой инвестиции.
The contents in here — and available on any associated distribution platforms and any public a16z online social media accounts, platforms, and sites (collectively, “content distribution outlets”) — should not be construed as or relied upon in any manner as investment, legal, tax, or other advice. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Any projections, estimates, forecasts, targets, prospects and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Any charts provided here or on a16z content distribution outlets are for informational purposes only, and should not be relied upon when making any investment decision. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. In addition, posts may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein. All content speaks only as of the date indicated.
Содержание настоящего материала — а также материалы, доступные на любых связанных платформах распространения и любых публичных аккаунтах a16z в социальных сетях, платформах и сайтах (совместно именуемых «каналы распространения контента») — не должно рассматриваться или использоваться в качестве инвестиционных, юридических, налоговых или иных рекомендаций. По вопросам, связанным с инвестициями, следует консультироваться с собственными советниками. Любые прогнозы, оценки, ориентиры, перспективы и/или мнения, выраженные в данных материалах, могут быть изменены без уведомления и могут отличаться от мнений, выраженных другими лицами, или противоречить им. Любые графики, представленные здесь или на каналах распространения контента a16z, предназначены исключительно для информационных целей и не должны служить основой при принятии инвестиционных решений. Определённая информация, содержащаяся здесь, получена из сторонних источников, в том числе от портфельных компаний фондов под управлением a16z. Несмотря на то что информация получена из источников, считающихся надёжными, a16z не проводила независимую проверку такой информации и не делает заявлений о её достоверности или пригодности для конкретной ситуации. Кроме того, публикации могут содержать рекламу третьих сторон; a16z не проверяла такую рекламу и не одобряет рекламный контент, содержащийся в ней. Всё содержание актуально только на указанную дату.
Under no circumstances should any posts or other information provided on this website — or on associated content distribution outlets — be construed as an offer soliciting the purchase or sale of any security or interest in any pooled investment vehicle sponsored, discussed, or mentioned by a16z personnel. Nor should it be construed as an offer to provide investment advisory services; an offer to invest in an a16z-managed pooled investment vehicle will be made separately and only by means of the confidential offering documents of the specific pooled investment vehicles — which should be read in their entirety, and only to those who, among other requirements, meet certain qualifications under federal securities laws. Such investors, defined as accredited investors and qualified purchasers, are generally deemed capable of evaluating the merits and risks of prospective investments and financial matters.
Ни при каких обстоятельствах какие-либо публикации или иная информация, представленная на данном сайте — или на связанных каналах распространения контента — не должна рассматриваться как предложение о покупке или продаже какой-либо ценной бумаги или доли в каком-либо объединённом инвестиционном инструменте, спонсируемом, обсуждаемом или упоминаемом сотрудниками a16z. Равно как она не должна рассматриваться как предложение об оказании услуг инвестиционного консультирования; предложение об инвестировании в объединённый инвестиционный инструмент под управлением a16z будет сделано отдельно и исключительно посредством конфиденциальных документов предложения конкретных объединённых инвестиционных инструментов — которые должны быть прочитаны в полном объёме и только теми лицами, которые, помимо прочих требований, отвечают определённым квалификационным критериям в соответствии с федеральным законодательством о ценных бумагах. Такие инвесторы, определяемые как аккредитованные инвесторы и квалифицированные покупатели, как правило, считаются способными самостоятельно оценивать достоинства и риски предполагаемых инвестиций и финансовых вопросов.
There can be no assurances that a16z’s investment objectives will be achieved or investment strategies will be successful. Any investment in a vehicle managed by a16z involves a high degree of risk including the risk that the entire amount invested is lost. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by a16z is available here: https://a16z.com/investments/. Past results of a16z’s investments, pooled investment vehicles, or investment strategies are not necessarily indicative of future results. Excluded from this list are investments (and certain publicly traded cryptocurrencies/ digital assets) for which the issuer has not provided permission for a16z to disclose publicly. As for its investments in any cryptocurrency or token project, a16z is acting in its own financial interest, not necessarily in the interests of other token holders. a16z has no special role in any of these projects or power over their management. a16z does not undertake to continue to have any involvement in these projects other than as an investor and token holder, and other token holders should not expect that it will or rely on it to have any particular involvement.
Не может быть никаких гарантий того, что инвестиционные цели a16z будут достигнуты или инвестиционные стратегии окажутся успешными. Любая инвестиция в инструмент под управлением a16z сопряжена с высокой степенью риска, включая риск полной потери вложенной суммы. Любые упомянутые, указанные или описанные инвестиции или портфельные компании не являются репрезентативными для всех инвестиций в инструменты под управлением a16z, и не может быть никаких гарантий того, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами под управлением a16z, доступен здесь: https://a16z.com/investments/. Прошлые результаты инвестиций a16z, объединённых инвестиционных инструментов или инвестиционных стратегий не обязательно являются индикатором будущих результатов. Из данного списка исключены инвестиции (а также определённые публично торгуемые криптовалюты/цифровые активы), по которым эмитент не дал разрешения a16z на публичное раскрытие информации. Что касается инвестиций в любой криптовалютный или токенный проект, a16z действует в собственных финансовых интересах, не обязательно в интересах других держателей токенов. a16z не выполняет особой роли ни в одном из этих проектов и не обладает полномочиями по их управлению. a16z не берёт на себя обязательство продолжать какое-либо участие в этих проектах, кроме как в качестве инвестора и держателя токенов, и другие держатели токенов не должны ожидать или рассчитывать на какое-либо особое участие.
With respect to funds managed by a16z that are registered in Japan, a16z will provide to any member of the Japanese public a copy of such documents as are required to be made publicly available pursuant to Article 63 of the Financial Instruments and Exchange Act of Japan. Please contact compliance@a16z.com to request such documents.
В отношении фондов под управлением a16z, зарегистрированных в Японии, a16z предоставит любому представителю японской общественности копию документов, которые должны быть публично доступны в соответствии со статьёй 63 Закона о финансовых инструментах и биржах Японии. Для запроса таких документов обращайтесь по адресу compliance@a16z.com.
For other site terms of use, please go here. Additional important information about a16z, including our Form ADV Part 2A Brochure, is available at the SEC’s website: http://www.adviserinfo.sec.gov.
С прочими условиями использования сайта можно ознакомиться здесь. Дополнительная важная информация об a16z, включая нашу Брошюру Формы ADV Часть 2A, доступна на сайте SEC: http://www.adviserinfo.sec.gov.