Lakebase Search 출시: Lakebase Postgres에 내장된 에이전트 네이티브 검색

오늘 Lakebase에 내장된 하이브리드 벡터 및 전체 텍스트 검색 기능인 Lakebase Search를 소개합니다. 현재 AWS 및 Azure에서 베타 버전으로 제공됩니다. 두 개의 네이티브 Postgres 확장 프로그램인 lakebase_vector 및 lakebase_text를 기반으로 작동하므로, 전체 에이전트 루프가 단일 데이터 백엔드인 lakebase에 의존할 수 있습니다.

이를 통해 차원이 다른 확장성, 차원이 다른 경제성, 에이전트 우선의 사용 편의성을 제공합니다.

에이전트는 검색을 운영 워크플로우로 전환합니다. 즉, 컨텍스트를 검색하고, 추론하고, 행동하고, 기억합니다. 이는 읽기 경로(검색)와 쓰기 경로(메모리)를 긴밀하게 연결하여, 새로 생성된 인사이트에 실시간으로 액세스하는 데 즉각적인 검색이 필수적이도록 만듭니다.

지금까지는 대규모 검색에 필요한 확장성과 경제성을 충족하도록 설계된 Postgres 네이티브 환경이 이 루프에 존재하지 않았습니다.

에이전트에게 검색은 실제로 운영 워크로드입니다

이제 에이전트는 Lakebase에서 인간 사용자보다 4배 더 많은 데이터베이스를 운영하며, 이들의 주요 요구사항은 인간의 요구사항과 완전히 다릅니다. 기존의 검색 엔진은 오래된 데이터의 읽기 전용 스냅샷을 가정합니다. 하지만 에이전트는 검색을 실시간 운영 데이터베이스처럼 취급합니다.

일반적인 에이전트 스키마를 살펴보면, 청크된 문서와 임베딩이 활성 대화 메모리 로그 바로 옆에 함께 존재합니다. 이는 지속적인 읽기/쓰기 루프를 생성합니다. 에이전트는 한 차례에 새로운 학습 내용을 메모리에 기록하고, 다음 차례에 바로 그 데이터가 완전히 인덱싱되어 검색 가능해야 합니다. 에이전트에게는 빠른 검색뿐만 아니라, 가장 최근에 기록된 데이터에 대한 즉각적인 검색이 필요합니다.

검색은 독특한 워크로드입니다

검색은 두 가지 정의적인 특징을 가진 독특한 워크로드입니다.

첫째, 실제로 쿼리하는 것보다 훨씬 더 많은 데이터를 저장하므로 대부분의 데이터가 콜드(cold) 상태로 남게 됩니다.

둘째, 벡터 검색은 심각한 데이터 부풀림(bloat)을 유발합니다. 1 KB 크기의 텍스트 파일도 벡터화되면 크기가 커집니다. 이는 문서가 여러 청크로 분할되고, 인덱스 오버헤드를 고려하기 전에도 각 청크가 고유한 고차원 임베딩을 생성하기 때문입니다.

대부분 유휴 상태인 수천 개의 테넌트 전체로 이것이 확장되면 기존의 검색 아키텍처는 무너집니다. HNSW와 같은 업계 표준 벡터 인덱스는 근본적으로 메모리 제한적(memory-bound)입니다. 빠른 그래프 탐색은 인덱스가 RAM에 상주하는 것에 크게 의존하기 때문에, 콜드 멀티테넌트 데이터를 호스팅하는 것은 비용이 많이 듭니다.

검색에는 lakebase가 필요합니다

지난해 저희는 데이터가 저렴한 클라우드 오브젝트 스토리지에 저장되지만, 계층화된 캐시(RAM, 로컬 NVMe, pageserver)를 통해 핫(hot) 페이지를 로컬 디스크 수준의 대기 시간으로 읽을 수 있는 서버리스 Postgres OLTP 아키텍처인 Lakebase를 출시했습니다.

저희는 이것이 바로 현대적인 검색에 필요한 아키텍처라는 것을 깨달았습니다. 하지만 한 가지 걸림돌이 있었습니다. 쿼리 속도를 저하시키지 않으면서 이러한 경제성을 실제로 실현하려면, 계층화된 스토리지 계층 구조에 상주하도록 명시적으로 설계된 인덱스 레이아웃이 필요했습니다. Lakebase에는 이것이 없었습니다. 그래서 저희가 직접 구축했습니다.

계층형 아키텍처와 목적에 맞게 구축된 계층형 인덱스를 결합하여 다음과 같은 이점을 얻을 수 있습니다:

• 속도 저하 없는 차원이 다른 확장성: 오브젝트 스토리지에서 필요한 페이지 만을 로컬 캐시로 지능적으로 가져옴으로써, 더 작은 Postgres 인스턴스에서도 대규모 컴퓨팅 리소스 없이 동일한 재현율(recall)과 대기 시간을 달성할 수 있습니다.
• 차원이 다른 경제성: 사용 빈도가 낮은 콜드 벡터는 거의 비용이 들지 않는 오브젝트 스토리지에 저장되는 반면, 활성 상태인 핫 워킹 세트(working set)는 NVMe에 유지됩니다. 저장하는 데이터가 아니라 쿼리하는 데이터에 대해서만 비용을 지불하면 됩니다.

경제성은 표로 보면 가장 쉽게 이해할 수 있습니다. 클라우드 정가 기준, 월별 테라바이트(TB)당 비용은 다음과 같습니다:

저희의 인덱싱 방식을 사용하면 Lakebase가 활성 워킹 세트만 RAM에 유지할 수 있습니다. 대부분의 콜드 데이터는 오브젝트 스토리지에 보관되므로 시스템 비용이 100배 더 저렴해지는 동시에, 애플리케이션에 실제로 필요한 고성능 검색을 제공합니다.

Postgres에 레이크 네이티브 검색 인덱스 도입

Lakebase Search를 구축할 때 저희는 타협할 수 없는 두 가지 특성에 집중했습니다.

Lakebase Search를 구축할 때 저희에게는 두 가지 엄격한 요구사항이 있었습니다. 바로 100% Postgres 네이티브여야 하고(표준 pgvector/tsvector 유형 및 생태계 도구 재사용), 인덱싱이 계층화된 클라우드 오브젝트 스토리지를 위해 처음부터 새로 구축되어야 한다는 점이었습니다.

이를 달성하기 위해 오늘 두 가지 새로운 Postgres 확장 프로그램의 베타 버전을 출시합니다. 두 프로그램 모두 RAM을 과도하게 프로비저닝하도록 강제하지 않으면서 최첨단 검색 관련성을 제공한다는 동일한 목표를 공유합니다.

1. lakebase_vector: 32배 압축 및 10억 개 이상의 규모.

표준 pgvector 데이터 유형과 연산자는 유지하되 기본 인덱스 유형을 변경했습니다. 데이터가 네이티브 pgvector 형식으로 유지되므로 호환성이 보장되고 다른 시스템으로 내보낼 수 있습니다. RaBitQ(Randomized Binary Quantization)를 사용하여 벡터를 클러스터링하고 압축함으로써, 높은 재현율을 유지하면서 인덱스 공간을 32배 줄였습니다. 이전에는 300GB의 RAM이 필요했던 1억 개의 벡터 인덱스가 10GB 미만에 들어갑니다. 이렇게 줄어든 메모리 공간 덕분에 단일 인덱스를 10억 개 이상의 벡터로 확장할 수 있습니다. 활성 워킹 세트는 로컬 NVMe에 캐싱되고, 콜드 테일은 오브젝트 스토리지에 저장됩니다.

2. lakebase_text: GIN 메모리 부풀림이 없는 진정한 BM25.

Postgres는 GIN 인덱스를 통해 정확한 키워드 매칭을 처리하는데, 성능을 유지하려면 이 인덱스가 RAM에 상주해야 합니다. 이 아키텍처로 인해 메모리 비용이 데이터 세트 크기에 따라 선형적으로 증가합니다.

lakebase_text는 GIN을 클라우드 오브젝트 스토리지의 순차 읽기에 최적화된 인덱스로 대체합니다. 이를 통해 관련 RAM 공간을 차지하지 않고도 Postgres에 네이티브 BM25 관련성 순위 지정을 도입합니다.

두 확장 프로그램 모두 동일한 엔진 내에서 실행되므로 하이브리드 검색이 단일 SQL 쿼리로 실행됩니다. 벡터 유사도와 키워드 관련성이 RRF(reciprocal rank fusion)를 통해 결합되어 결과를 운영 테이블과 조인하고 필터링할 수 있습니다.

Postgres는 대규모의 본격적인 검색 워크로드를 처리할 준비가 되었습니다

단일 인스턴스에서 1억 개의 768차원 벡터, top-10 검색을 수행하는 LAION-100M 데이터 세트로 Lakebase Search의 벤치마크를 수행했습니다. 웜 캐시 및 단일 연결 환경에서의 쿼리 성능은 데이터 부풀림 없이 정확한 최근접 이웃 재현율을 제공합니다:

전통적으로 이 정도 규모를 달성하려면 메모리 제한적 아키텍처가 필요합니다. 표준 pgvector HNSW 인덱스는 성능이 뛰어난 탐색을 위해 이웃 그래프와 대상 힙 페이지가 RAM에 상주해야 합니다. 1억 개의 벡터 기준:

1. pgvector: 512 GB(64 CPU) 인스턴스가 필요합니다. 인덱스 빌드에는 약 40시간이 소요됩니다. 그래프 탐색이 국소화되지 않은 무작위 액세스에 의존하기 때문에, 콜드 재시작 시 심각한 디스크 읽기 대기 시간이 발생하여 첫 번째 쿼리가 완료되는 데 몇 분이 걸립니다.
2. lakebase_vector: 192 GB(96 CU / 24 CPU) 인스턴스에서 실행됩니다. 인덱스 빌드에는 1.5시간이 소요됩니다. 탐색이 여전히 무작위 액세스 방식이기는 하지만, 인덱스 레이아웃이 데이터를 클러스터링하므로 무작위 조회가 NVMe 캐시의 핫 워킹 세트 내로 국소화되고 콜드 테일은 오브젝트 스토리지에 남게 됩니다. 유휴 상태일 때는 인스턴스가 0으로 축소되며, 첫 번째 콜드 캐시 쿼리는 1.13초가 걸립니다.

이 아키텍처는 총 소유 비용(TCO)에 접근하는 방식을 바꿉니다. 레거시 검색은 쿼리 볼륨에 관계없이 고정된 기본 비용이 필요한 반면, Lakebase는 실제 사용량을 추적합니다.

Lakebase Search는 에이전트 우선의 사용 편의성을 제공합니다

메모리와 컨텍스트를 위한 단일 백엔드:

에이전트가 컨텍스트용 벡터 데이터베이스와 메모리용 트랜잭션 데이터베이스를 번거롭게 결합할 필요가 없습니다. 검색 로직을 데이터베이스에 직접 푸시함으로써 전체 에이전트 루프가 단일 백엔드에서 실행됩니다. Lakebase Search는 Postgres이므로 표준 pgvector 및 tsvector 유형을 완전히 재사용하여 기존 MCP, 표준 드라이버 및 커넥터에 기본적으로 연결됩니다. 더 중요한 것은 검색이 운영 데이터 바로 옆에 위치하므로, 단 하나의 SQL 쿼리만으로 하이브리드 검색을 실행하고, 애플리케이션 테이블과 조인하며, 테넌트별로 안전하게 필터링할 수 있다는 점입니다.

지속적인 검색 실험

청킹 전략이나 하이브리드 가중치를 최적화하려면 시행착오가 필요합니다. 재처리를 위해 데이터를 외부 배치 시스템으로 내보내는 대신, Lakebase Search는 Lakehouse와 연결되어 긴밀한 피드백 루프를 생성합니다. 비용 없이 즉시 멀티 테라바이트 데이터 세트를 분기하고, 병렬 컴퓨팅을 사용하여 대역 외(out-of-band)로 인덱스를 빌드하며, 오프라인 평가를 위해 에이전트 피드백을 Lakehouse로 다시 보낼 수 있습니다.

에이전트당 전용 검색 엔진

기존 아키텍처에서는 모든 에이전트가 단일 검색 클러스터를 공유해야 합니다. Lakebase의 유휴 인덱스는 스토리지 비용이 거의 들지 않으므로 특정 에이전트, 사용자 또는 세션 전용의 격리된 코퍼스를 수천 개 프로비저닝할 수 있습니다. 이를 통해 검색이 오래된 스냅샷에서 운영 읽기/쓰기 루프로 전환됩니다. 에이전트가 한 차례 작성한 데이터는 완전한 트랜잭션 보장과 함께 다음 차례에 커밋되어 검색할 수 있습니다.

에이전트 루프를 위한 단일 기반

Lakebase를 사용하면 별도의 벡터 저장소, 검색 클러스터 및 트랜잭션 데이터베이스를 연결할 필요가 없습니다. 전체 라이프사이클을 단일 Postgres 시스템 내에 통합함으로써, 에이전트 워크플로에 필요한 실시간 읽기/쓰기 편의성과 함께 계층화된 클라우드 오브젝트 스토리지의 확장성 및 저렴한 비용을 제공합니다.

Lakebase Search는 현재 AWS 및 Azure에서 베타 버전으로 제공됩니다. 여러분의 에이전트는 무엇을 만들어낼까요?

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)