Pinecone представляет Nexus: новую архитектуру для работы с агентным ИИ

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

Исследование VentureBeat «Q1 2026 Pulse» подтверждает эту тенденцию: каждая отдельная векторная база данных теряет долю использования, в то время как намерение использовать гибридный поиск утроилось, достигнув 33,3% — это самая быстрорастущая стратегическая позиция в анализируемых данных.

Пионер в области векторных баз данных, компания Pinecone, признаёт эту необходимость и переориентируется на удовлетворение специфических требований агентного ИИ.

Представление Nexus: новый подход к управлению знаниями

Компания Pinecone объявила о запуске Nexus, позиционируя его не как улучшение механизма поиска, а как полноценную систему управления знаниями. Nexus включает в себя два ключевых компонента:

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

Вместе с Nexus Pinecone выпускает KnowQL — декларативный язык запросов, который даёт агентам возможность точно определять формат вывода, требования к достоверности и допустимые задержки. Согласно внутренним тестам Pinecone, задача финансового анализа, которая ранее требовала обработки 2,8 миллиона токенов, с использованием Nexus была выполнена всего за 4 000 токенов. Это впечатляющее сокращение на 98%, хотя компания пока не подтвердила эти показатели в реальных производственных условиях у клиентов. Доступ к Nexus уже открыт для раннего использования.

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

Почему RAG не соответствует потребностям агентного ИИ

Механизм RAG подразумевает один запрос, один ответ и участие человека для интерпретации результата. Однако агенты работают иначе. Им поручаются задачи, а не вопросы, и для их выполнения требуется:

• Сбор контекста из множества источников.
• Разрешение конфликтов.
• Отслеживание уже полученных данных.
• Принятие решений о следующем запросе.

Это различие принципиально. Система RAG извлекает документы и передаёт их модели во время вывода. Каждая сессия агента начинается «с нуля», без скомпилированного понимания всего массива корпоративных данных — какие таблицы связаны между собой, какие источники являются авторитетными для конкретных вопросов, и какие форматы сможет использовать последующий агент. Каждая сессия заново открывает эту информацию.

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

Pinecone подсчитала, что 85% вычислительных усилий агентов тратится на этот цикл повторного обнаружения информации, а не на непосредственное выполнение задачи. Это приводит к цепной реакции негативных последствий: непредсказуемым задержкам, неконтролируемым расходам на токены и недетерминированным результатам. Если одну и ту же задачу запустить дважды с одними и теми же данными, агент может выдать разные ответы, при этом не будет записи о том, какие источники привели к тому или иному результату. Для предприятий, где аудируемость является требованием соответствия, это структурный недостаток, а не просто проблема настройки.

Что такое Nexus и как он работает

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

Архитектура, предлагаемая Pinecone, состоит из трёх отдельных компонентов, каждый из которых решает определённый аспект проблемы извлечения данных для агентов:

• Компилятор контекста: Получает исходные данные и спецификацию задачи, затем создаёт специализированные артефакты знаний — структурированные, оптимизированные под конкретную задачу представления, которые агенты потребляют напрямую без дополнительных затрат на интерпретацию. Один и тот же набор исходных данных может порождать разные артефакты для разных агентов: агент по продажам получает контекст сделок, синтезированный из CRM и записей звонков, а финансовый агент — контекст доходов, связывающий контракты с графиками платежей. Артефакты являются постоянными и многократно используются в разных сессиях агентов, а не генерируются заново каждый раз.
• Компонуемый поисковик: Предоставляет скомпилированные артефакты во время запроса, снабжённые типизированными полями, ссылками на источники с указанием уровня достоверности и детерминированным разрешением конфликтов. Вывод формируется в соответствии с указанным агентом форматом, а не возвращается в виде необработанного текста, который агенту пришлось бы повторно анализировать.
• KnowQL: Pinecone описывает его как первый декларативный язык запросов, разработанный для агентов, а не для людей. Шесть основных элементов — намерение, фильтр, происхождение, форма вывода, достоверность и бюджет — позволяют агентам задавать структурированные ответы, указывать источники и контролировать задержки через единый интерфейс. Ашутош сравнил структурный пробел, который заполняет KnowQL, с тем, что SQL сделал для реляционных баз данных: до появления стандарта каждый проект создавал свой собственный уровень доступа к данным с нуля.

Взаимосвязь между Nexus и базовой векторной базой данных Pinecone носит дополнительный характер. Компилятор контекста производит артефакты знаний, которые индексируются и хранятся в векторной базе данных; уровень компиляции формирует и предоставляет знания; векторный уровень отвечает за хранение, скорость извлечения и масштабирование.

«Векторы по-прежнему хранятся и управляются векторной базой данных Pinecone», — отметил Ашутош.

Мнения аналитиков об архитектурном решении

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

Стефани Уолтер, руководитель практики по стеку ИИ в HyperFRAME Research, считает, что Nexus имеет важное стратегическое значение, поскольку он переносит работу со знаниями из хаоса выполнения в заранее скомпилированную структуру. Тем не менее, она подчеркнула, что это скорее эволюция архитектуры RAG, а не её полная переработка.

«Настоящая инновация заключается не в самой идее, а в продуктовой реализации компиляции знаний как первоклассного инфраструктурного уровня», — заявила Уолтер. — «Если Pinecone сможет надёжно ввести это в эксплуатацию, это станет значимой инфраструктурой, а не просто ещё одним трюком для настройки RAG».

Технический механизм, лежащий в основе этого утверждения, был назван Аруном Чандрасекараном, вице-президентом и аналитиком Gartner, значительным архитектурным отличием. «В отличие от традиционного RAG, который полагается на чистый семантический поиск во время выполнения, архитектурная компиляция встраивает структурную логику в метаданные, что может значительно ускорить время ответа и обеспечить более точное осмысление», — пояснил Чандрасекаран. — «Это важный шаг от простого извлечения к расширенному осмыслению, позволяющий агентам ориентироваться в корпоративных схемах и улучшать свою “память” для контекстуализации».

Конкурентная среда

Многие поставщики решений признают, что векторной базы данных и традиционного RAG недостаточно для полноценного агентного ИИ.

• Компания Microsoft расширила свою технологию FabricIQ для обеспечения семантического контекста в агентном ИИ.
• Google* недавно анонсировала Agentic Data Cloud как подход к решению тех же проблем.
• Существуют также отдельные технологии контекстной памяти, например, Hindsight, которые предлагают ещё один вариант для пользователей.

Однако аналитики сосредоточены не столько на сравнении функций, сколько на том, что на самом деле должны оценивать покупатели. «Стек агентного ИИ фрагментируется на десятки функций, но корпоративным покупателям не следует гнаться за функциями», — считает Уолтер. — «Им следует стремиться к контролю: контролю затрат, контролю управления и контролю безопасности».

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

Планка возможностей выходит за рамки скорости извлечения данных. «Настоящим отличительным фактором является детерминированное обоснование», — подчеркнул Чандрасекаран, указывая на такие методы, как графы знаний, которые гарантируют понимание агентами структурных связей внутри корпоративных данных, а не просто поверхностные совпадения. Взаимосовместимость является связанным вопросом: такие стандарты, как протокол контекста модели (MCP), важны для подключения агентов к устаревшим источникам данных без создания новых зависимостей.

Что это означает для предприятий

RAG и автономные векторные базы данных были созданы для другой эпохи. Агентные рабочие нагрузки выявляют ограничения обоих подходов.

Проблема стоимости извлечения носит архитектурный характер

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

Управление — это то, что отличает пилотный проект от производственного внедрения

Возможности, определяющие одобрение агентного ИИ для использования в масштабах предприятия, не ограничиваются показателями производительности.

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

Бюджеты сместились

Данные VentureBeat «Q1 Pulse» показывают, что инвестиции в оптимизацию извлечения выросли до 28,9% в марте, впервые в этом квартале обогнав расходы на оценку. Предприятия завершили измерение своих проблем с извлечением. Теперь они тратят средства на их решение.

«Будущее агентного ИИ будет определяться не тем, у кого самое длинное контекстное окно», — заключила Уолтер. — «Оно будет определяться тем, кто сможет операционализировать надёжные знания в масштабе, не превышая затраты и не нарушая принципы управления».

* — деятельность компании запрещена на территории РФ

Твитнуть