RAG 시대가 에이전트 AI에서 끝나가고 있다 — 새로운 컴파일 단계 지식 레이어가 다음이다

Source: VentureBeat

Pinecone의 응답: Nexus

벡터‑데이터베이스 선구자 Pinecone이 에이전트형 AI의 특수한 요구를 충족하기 위해 방향을 전환합니다. 회사는 Nexus를 발표했으며, 이는 단순한 검색 개선이 아니라 지식 엔진으로 자리매김합니다.

주요 기능

“RAG는 인간 사용자를 위해 만들어졌습니다. Nexus는 에이전트형 사용자를 위해 만들어졌습니다, 왜냐하면 그들의 언어가 매우 다르기 때문입니다. 기대하는 응답도 크게 다릅니다. 에이전트에게 할당된 작업은 챗봇이 수행해야 하는 작업과 매우 다릅니다.” – Ash Ashutosh, CEO, Pinecone

Pinecone 내부 벤치마크에 따르면, 이전에 2.8 M 토큰을 소모하던 금융‑분석 작업을 Nexus는 4 K 토큰만으로 완료했으며 (98 % 감소). 이 주장은 아직 고객 실운영 환경에서 검증되지 않았습니다. Nexus는 오늘부터 조기 액세스 형태로 제공됩니다.

에이전트가 실제로 하는 일을 위해 RAG가 설계되지 않은 이유

1. RAG는 단일 질의 → 단일 응답 루프를 가정하고, 결과를 해석하기 위해 인간이 개입합니다.
2. 에이전트는 고립된 질문이 아니라 작업을 할당받습니다. 작업을 완료하려면:
   • 다수의 출처에서 컨텍스트를 조합하기.
   • 충돌 해결.
   • 이미 검색된 내용을 추적하기.
   • 다음에 어떤 질의를 할지 결정하기.

기존 RAG의 문제점

• RAG 파이프라인은 추론 시점에 문서를 검색하고 이를 모델에 전달합니다.
• 각 에이전트 세션은 초기 상태에서 시작되며, 기업 데이터 자산(예: 테이블 관계, 권위 있는 출처, 사용 가능한 형식)에 대한 종합적인 이해가 없습니다.
• 모든 세션이 이 정보를 처음부터 다시 발견합니다.

“이 모든 것의 핵심은 매우 단순한 문제였습니다,”라고 Ashutosh가 말했습니다. “당신은 에이전트—기계—에게 인간을 위해 설계된 시스템과 데이터에서 작업하도록 요구하고 있습니다.”

Pinecone은 **에이전트 연산 노력의 85 %**가 작업 완료가 아니라 재발견 사이클에 사용된다고 추정합니다. 그 결과:

• 예측할 수 없는 지연.
• 통제되지 않는 토큰 비용.
• 비결정적 결과(동일 데이터에 대해 다른 답변이 나오며, 출처 추적이 불가능).

감사 가능성 요구가 있는 기업에게 이는 조정 문제가 아니라 구조적 부적격 요인입니다.

Nexus가 무엇이며 어떻게 작동하는가

Reasoning을 업스트림으로 이동

• 전통적인 RAG: 추론(해석, 컨텍스트화, 구조화)이 쿼리 시점에 발생하여, 사전에 할 수 있었던 작업에 토큰을 소모한다.
• Nexus: 이 추론을 컴파일 단계에서 한 번 수행하고, 결과를 재사용 가능한 지식 아티팩트로 저장한다.

에이전트는 즉석에서 해석할 원시 문서 대신 구조화된, 작업 준비가 된 컨텍스트를 받는다.

아키텍처 구성 요소

1. Context Compiler

   • 원시 소스 데이터와 작업 사양을 입력받는다.
   • 전문화된 지식 아티팩트(구조화되고 작업에 최적화된 표현)를 만든다.
   • 예시:
     • 영업 에이전트 → CRM 및 통화 기록에서 합성된 거래 컨텍스트.
     • 재무 에이전트 → 계약과 청구 일정을 연결한 매출 컨텍스트.
   • 아티팩트는 영구적이며 세션 간에 재사용된다.

2. Composable Retriever

   • 쿼리 시점에 컴파일된 아티팩트를 제공한다.
   • 타입이 지정된 필드, 필드별 인용(신뢰도 수준 포함) 및 결정론적 충돌 해결을 제공한다.
   • 출력은 에이전트가 지정한 형식에 맞추어지며, 원시 텍스트가 아니다.

3. KnowQL

   • 에이전트를 위해 설계된 최초의 선언형 쿼리 언어.
   • 여섯 가지 프리미티브: intent, filter, provenance, output shape, confidence, budget.
   • 에이전트가 구조화된 응답, 출처 근거, 지연 시간 제한을 하나의 인터페이스에서 지정할 수 있게 한다.
   • Ashutosh는 그 영향을 SQL이 관계형 데이터베이스에 미친 영향에 비유한다: 표준 인터페이스가 없던 시절, 모든 애플리케이션이 자체 데이터 접근 레이어를 처음부터 구축해야 했던 것처럼.

Pinecone 벡터 데이터베이스와의 관계

• Context Compiler가 생성한 지식 아티팩트는 Pinecone 벡터 데이터베이스에 인덱싱 및 저장된다.
• Compilation layer는 지식을 형태화하고 제공한다.
• Vector layer는 스토리지, 검색 속도, 확장성을 담당한다.

“벡터는 여전히 Pinecone 벡터 데이터베이스에 저장·관리됩니다,” 라고 Ashutosh가 말했다.

Analyst Takeaways on the Architectural Claim

• Upstream reasoning은 새로운 것이 아니다—온톨로지, 데이터 카탈로그, 그리고 시맨틱 레이어는 수년간 유사한 아이디어를 추구해 왔다.
• 변화된 점은 전용 엔지니어링 팀 없이도 이 접근 방식을 확장할 수 있게 된 것이다.
• Pinecone의 주장은 agent‑centric, deterministic, low‑token 검색을 대규모로 제공하는 데에 기반하며, 실제 배포에서 검증된다면 중요한 차별점이 될 수 있다.

Nexus와 RAG 아키텍처의 진화

Nexus는 큰 반향을 일으키고 있으며, 분석가들은 이를 진정한 진보로 보고 있습니다. HyperFRAME Research의 AI 스택 실무 책임자인 Stephanie Walter는 VentureBeat와의 인터뷰에서 Nexus가 지식 작업을 런타임 혼돈에서 사전 컴파일된 구조로 전환시키기 때문에 방향성상 중요하다고 말했습니다. 그러나 그녀는 이것이 RAG 아키텍처의 완전한 재창조가 아니라 진화라고 강조했습니다.

“진정한 혁신은 아이디어 자체가 아니라 지식 컴파일을 1급 인프라 계층으로 제품화한 것”이라고 Walter는 말했습니다. “Pinecone이 이를 신뢰성 있게 운영화한다면, 이는 또 다른 RAG 튜닝 트릭이 아니라 의미 있는 인프라가 됩니다.”

그 주장의 기술적 메커니즘을 Gartner‑지정 VP 분석가 Arun Chandrasekaran은 meaningful architectural distinction이라고 부릅니다.

“전통적인 RAG가 런타임에 순수한 의미 검색에 의존하는 것과 달리, 아키텍처 컴파일은 메타데이터 계층에 구조적 논리를 삽입하여 응답 시간을 단축하고 더 나은 추론을 제공할 수 있습니다.”라고 Chandrasekaran은 VentureBeat에 말했습니다. “이는 단순 검색에서 향상된 추론으로의 중요한 도약이며, 에이전트가 기업 스키마를 탐색하고 컨텍스트화에 필요한 더 나은 메모리를 확보하도록 합니다.”

경쟁 구도

다수의 벤더가 벡터 데이터베이스와 전통적인 RAG만으로는 에이전트형 AI에 충분하지 않다고 인정하고 있습니다.

“에이전트형 AI 스택은 수십 개의 기능으로 분산되고 있지만, 기업 구매자는 기능을 쫓아서는 안 됩니다,” 라고 Walter가 말했습니다. “그들은 제어를 쫓아야 합니다: 비용 제어, 거버넌스 제어, 그리고 보안 제어.”

그녀는 대부분의 기업이 에이전트형 AI에서 실패하는 이유는 기술적인 문제가 아니라 운영적인 문제—즉 비용 초과, 거버넌스 격차, 보안 규율 부족—에 기인할 것이라고 주장했습니다.

검색 속도 이상

“진정한 차별화 요소는 결정론적 그라운딩입니다,” 라고 Chandrasekaran이 말했습니다. 이는 에이전트가 기업 데이터 내 구조적 관계를 이해하도록 보장하는 지식 그래프와 같은 기술을 가리킵니다.

상호 운용성은 관련된 고려 사항으로, Model Context Protocol (MCP) 와 같은 표준은 새로운 의존성을 만들지 않고 에이전트를 레거시 데이터 소스에 연결하는 데 중요합니다.

기업에게 의미하는 바

RAG와 벡터 데이터베이스는 다른 시대를 위해 구축되었습니다

에이전트 워크로드가 두 기술의 한계를 드러내고 있습니다.

검색 비용 문제는 아키텍처적 문제입니다

기존 RAG 파이프라인에서 복잡한 에이전트 워크로드를 실행하는 팀은 추론 시점에 토큰을 소모하고 있습니다. 이는 사전에 수행될 수 있는 작업—지식을 해석하고, 맥락을 부여하며, 구조화하는 작업—을 매 세션마다 처음부터 수행하기 때문입니다. 이는 설계상의 문제이며, 검색 레이어를 튜닝한다고 해결되지 않습니다.

데이터 엔지니어링 팀을 위한 핵심 질문:
현재 스택이 특정 에이전트 작업을 위해 지식을 사전 컴파일할 수 있는 구조적 능력을 가지고 있는가, 아니면 그런 능력이 필요 없는 인간 사용자를 위해 설계된 것인가?

거버넌스가 파일럿과 프로덕션을 구분한다

에이전트 AI가 기업용으로 승인되는지를 결정하는 능력은 성능 지표가 아닙니다.

“실제 기업 가치 제안은 단순히 더 빠른 검색이 아니라 거버넌스가 적용된 지식 파이프라인입니다,”라고 Walter가 말했습니다. “이러한 능력이 에이전트 AI를 실험 단계에서 재무·리스크 팀이 실제로 승인할 수 있는 수준으로 전환시킵니다.”

예산이 이동했다

VentureBeat의 1분기 Pulse 데이터에 따르면 검색 최적화 투자 비중이 3월에 28.9 %로 상승했으며, 이는 분기 내 처음으로 평가 지출을 앞선 수치입니다. 기업들은 이제 검색 문제를 측정하는 것을 마치고, 이를 해결하기 위해 비용을 지출하고 있습니다.

“에이전트 AI의 미래는 누가 가장 긴 컨텍스트 윈도우를 갖고 있느냐에 따라 결정되지 않을 것입니다,”라고 Walter가 말했습니다. “그것은 비용이나 거버넌스를 폭발시키지 않으면서 신뢰할 수 있는 지식을 대규모로 운영화할 수 있는 사람에 의해 결정될 것입니다.”