Nexus от Pinecone переосмысляет агентный ИИ

Категория векторных баз данных переживает трансформацию под влиянием потребностей агентного ИИ.

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

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

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

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

«RAG создавался для пользователей-людей, — рассказал генеральный директор Pinecone Аш Ашутош (Ash Ashutosh) изданию VentureBeat. — Nexus создан для пользователей-агентов, потому что их язык сильно отличается. Ответы, которых они ждут, совершенно другие. Задача, которую ставят перед агентом, кардинально отличается от того, что должен делать чат-бот».

Почему RAG никогда не был предназначен для того, что на самом деле делают агенты

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

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

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

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

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

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

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

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

2. Композитный модуль поиска. Скомпилированные артефакты предоставляются по запросу с типизированными полями, полем для цитирования с указанием уровня достоверности и детерминированным разрешением конфликтов. Формат вывода настраивается в соответствии с требованиями агента, а не возвращается в виде неструктурированного текста для повторного синтаксического анализа.

3. KnowQL. Pinecone описывает его как первый декларативный язык запросов, разработанный для агентов, а не для людей. Шесть примитивов — намерение (intent), фильтр (filter), происхождение (provenance), форма вывода (output shape), достоверность (confidence) и бюджет (budget) — позволяют агентам задавать структурированные ответы, привязку к источникам и ограничения по задержке в рамках единого интерфейса. Ашутош сравнил структурный пробел, который заполняет KnowQL, с тем, что SQL сделал для реляционных баз данных: до появления стандартного интерфейса каждое приложение создавало собственный слой доступа к данным с нуля.

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

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

Что думают аналитики об архитектурном решении

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

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

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

Технический механизм, лежащий в основе этого утверждения, — это то, что вице-президент и аналитик Gartner Арун Чандрасекаран (Arun Chandrasekaran) назвал значимым архитектурным отличием.

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

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

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

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

Но аналитики сосредоточены не столько на сравнении функций, сколько на том, что на самом деле должны оценивать покупатели.

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

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

Планка возможностей выходит далеко за рамки скорости поиска.

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

Что это значит для бизнеса

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

Проблема стоимости поиска носит архитектурный характер

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

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

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

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

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

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

«Будущее агентного ИИ определит вовсе не тот, у кого длиннее окно контекста, — резюмировала Вальтер. — Его определит тот, кто сможет внедрить доверенные знания в масштабе, не раздувая при этом расходы и не теряя контроль над управлением».