Postgres로 RAG 파이프라인을 처리할 수 있을까요?

pgai의 데이터베이스 우선 접근 방식을 테스트해 RAG 운영을 간소화하는 부분과 복잡한 워크로드에 더 큰 유연성이 필요한 부분을 살펴봤습니다.

요약

  • LLM이 한 번에 ‘볼’ 수 있는 텍스트의 양은 제한적입니다. 이를 컨텍스트 윈도우라고 합니다. 소규모 작업에는 문제가 없지만, 지식 베이스가 수천 페이지에 이르면 제대로 작동하지 않습니다. 컨텍스트 윈도우가 충분하더라도 ‘건초 더미에서 바늘 찾기’ 문제로 인해 성능이 저하될 수 있습니다.

  • RAG(‘검색 증강 생성’)는 매우 보편적인 패턴으로 자리 잡았습니다. 문서, 위키, 정책, 녹취록 등으로 지식 베이스를 관리하고, 사용자 쿼리를 의미론적으로 검색해 임베딩으로 가장 관련성 높은 조각을 찾은 다음, 이를 질문과 함께 LLM에 입력하는 방식입니다. 이렇게 하면 모델의 컨텍스트 범위를 좁힐 수 있으며, 제대로 구현할 경우 답변 품질을 높이고 환각을 줄일 수 있습니다.

  • pgai는 신뢰받는 오픈 소스 데이터베이스 PostgreSQL을 기반으로 ‘AI 검색’ 워크플로를 구축하도록 지원하는 오픈 소스 Postgres 확장 프로그램 및 관련 도구입니다.

  • 핵심은 데이터베이스를 임베딩을 위한 ‘단순 저장소’로 취급하지 않고, 표준 RAG 파이프라인의 더 많은 과정(수집 → 청크 분할 → 임베딩 → 임베딩 동기화)을 데이터베이스 계층으로 옮기는 것입니다.

  • 첫인상은 유망하지만, RAG 파이프라인이 조금만 복잡해져도, 특히 청크 분할 방식이 복잡해지면 적합하지 않다는 것입니다. 그래도 이 프로젝트의 향후 행보를 면밀히 지켜볼 예정입니다.

RAG 패턴

RAG를 구축하는 방법은 다양합니다. 여러 RAG 접근 방식을 자세히 살펴보려면 맞춤형 RAG 솔루션의 실제 사례. 를 읽어보세요. 품질을 고려하기 시작하면 설계 선택지가 놀라울 만큼 복잡해지지만, 일반적인 ‘기본’ 접근 방식은 대체로 다음과 같습니다.

  1. 문서 묶음을 준비합니다.

  2. 문서를 청크로 나눕니다. 문단이나 의미 단위로 묶는 등 다양한 방법이 있습니다.

  3. 각 청크를 임베딩으로 변환합니다.

  4. 임베딩을 벡터 데이터베이스(Pinecone, Milvus 등)에 저장하거나 pgvector를 사용해 Postgres에 저장합니다.

  5. 쿼리 시점에 가장 가까운 청크를 검색해 `LLM에 전달합니다. 이 과정 역시 다양한 방식으로 구현할 수 있습니다.

많은 기술 스택에서 (1)~(3)단계는 데이터베이스 외부의 애플리케이션 코드나 데이터 파이프라인에서 처리되며, 데이터베이스는 주로 다음 용도로 사용됩니다.

  • 임베딩 저장

  • 임베딩 검색

pgai의 목적

pgai는 이러한 경계를 허물고자 하는 Postgres 확장 프로그램입니다. 오픈 소스이며 Timescale에서 개발했습니다.

pgai는 애플리케이션에서 임베딩을 직접 관리하는 대신, 임베딩을 데이터베이스 기능으로 제공합니다.

  • 임베딩할 테이블이나 문서를 지정합니다.

  • 임베딩 모델과 청크 분할 전략을 지정합니다.

  • 나머지는 pgai가 관리합니다. 원본 데이터가 변경될 때 임베딩을 최신 상태로 유지하는 작업도 포함됩니다.

기대 효과는 매력적입니다.

  • 유지 관리해야 할 맞춤형 연결 코드가 줄어듭니다.

  • 기반이 되는 원본 문서가 변경되어도 임베딩을 최신 상태로 유지하기가 쉬워집니다.

  • Postgres/pgai가 재시도, 속도 제한, 실패한 작업 등을 관리합니다.

독자 참고: pgai에는 널리 사용되는 또 다른 RAG용 Postgres 확장 프로그램인 pgvector가 포함되어 있습니다. pgvector는 Postgres에 벡터 저장 및 유사도 검색 기능을 추가합니다. pgai는 이를 기반으로 청크 분할, 임베딩, 임베딩 최신화와 같은 RAG 파이프라인 단계를 자동화합니다.

pgai에 대한 첫인상

마음에 들었던 점

1) 시작하기가 쉽습니다.

일반적인 설정 과정은 비교적 간단합니다.

  • Timescale Docker 이미지(데이터베이스 + 워커)를 가져옵니다.

  • 임베딩 제공업체의 API 키를 입력합니다.

  • 간단한 SQL을 실행해 벡터라이저를 정의합니다. 즉, 무엇을 임베딩하고 어떻게 청크로 나누며 어떤 모델을 사용할지 지정합니다.

이후 pgai는 벡터라이저 워커를 별도 프로세스로 실행하고, 원하는 주기(예: 5분마다)로 임베딩을 비동기 생성합니다.

2) 전체 파이프라인을 데이터베이스 ‘가까이에서’ 처리할 수 있어 편리합니다.

pgai는 테이블에서 콘텐츠를 수집할 수 있고 S3 같은 곳에서 문서를 불러온 뒤 파싱, 청크 분할, 임베딩까지 처리할 수 있습니다. PDF, Markdown 등 다양한 텍스트 문서 형식도 처리할 수 있습니다.

제약으로 느껴진 부분

1) 상당한 제어권을 잃게 됩니다. RAG에는 제어가 필요할 때가 있습니다.

답변 품질을 기준으로 성능이 뛰어난 RAG 시스템에는 다음과 같은 맞춤형 파이프라인이 필요한 경우가 많습니다.

  • 맞춤형 청크 분할 규칙(제목별, 페이지별, 화자 발언 순서별 등)

  • 메타데이터를 고려한 청크 분할(섹션 제목, 타임스탬프, 작성자, 문서 유형 유지)

  • 문서 유형별로 다른 임베딩 전략

pgai는 위 항목에 대한 유연성이 떨어집니다.

현재 주요 청크 분할 전략은 문자 텍스트 분할기와 재귀적 문자 텍스트 분할기 두 가지이며, 청크를 분할하지 않는 옵션도 있습니다. 일부 사용 사례에는 충분할 수 있지만, 많은 프로덕션 RAG 시스템에는 더 많은 맞춤 설정이 필요합니다.

Timescale이 Chonkie 같은 라이브러리의 정교한 청크 분할 전략을 통합하고, Anthropic의 컨텍스트 검색 같은 고급 설계도 지원한다면 매우 유용할 것입니다.

2) 멀티모달이 아닌 텍스트 중심입니다.

흥미로운 RAG 문제 중 상당수는 더 이상 텍스트에만 국한되지 않습니다.

  • 도표가 포함된 PDF

  • 스크린샷/이미지

  • 오디오 녹음

  • 동영상 클립

이러한 소스에서 ‘텍스트를 추출’할 수 있더라도 진정한 멀티모달 임베딩 파이프라인과는 다릅니다.

향후 pgai가 S3에 저장된 대용량 이미지, 오디오, 동영상을 안정적으로 동기화하면서 불러오기 → 청크 분할 → 임베딩까지 처리하는 멀티모달 모델을 엔드 투 엔드로 지원한다면 매력적일 것입니다. 하지만 현재는 텍스트 임베딩 워크플로에 그칩니다.

3) 임베딩만 필요하다면 pgai가 필요하지 않을 수 있습니다.

수집 파이프라인이 이미 맞춤형이거나 맞춤형이어야 한다면 ‘텍스트 청크 임베딩’은 RAG에서 가장 어려운 부분이 아닙니다. 그런 환경에서 pgai가 해결하는 것은 문제의 가장 쉬운 부분입니다.

또한 지식 베이스가 자주 업데이트되지 않는다면 자동 임베딩 동기화의 가치도 크지 않습니다.

Text-to-SQL 계층

pgai를 특히 효과적으로 활용하는 방법은 데이터베이스에 text-to-SQL 인터페이스를 배포하는 것입니다. pgai가 제공하는 semantic_catalog 모듈을 사용하면 비교적 쉽게 구현할 수 있습니다. 다음과 같이 간단히 설정합니다.

Bash

OPENAI_API_KEY="your-OpenAPI-key-goes-here"TARGET_DB="postgres://user:password@host:port/database"CATALOG_DB="postgres://user:password@host:port/database"

그런 다음 pgai semantic-catalog create를 사용해 시맨틱 카탈로그가 데이터 딕셔너리를 수집하도록 합니다. 그러면 데이터 저장소에서 다음과 같은 컨텍스트가 생성됩니다.

Plain Text

---schema: postgres_airname: aircrafttype: tabledescription: Lists aircraft models with performance characteristics and unique codes.columns:- name: model  description: Commercial name of the aircraft model.- name: range  description: Maximum flight range in kilometers.- name: class  description: Airframe class category or configuration indicator.- name: velocity  description: Cruising speed of the aircraft.- name: code  description: Three-character aircraft code serving as the primary key....

이제 pgai에서 이 컨텍스트를 여러 방식으로 활용할 수 있습니다.

의미론적 검색 사용:

이 쿼리는 자연어 쿼리와 관련성이 있을 수 있는 테이블, 함수 및 기타 객체를 반환합니다.

Bash

pgai semantic-catalog search -p "Your natural language question goes here!"

원시 컨텍스트 가져오기:

자연어 쿼리와 관련된 원시 YAML 컨텍스트를 표시합니다.

Bash

pgai semantic-catalog search -p "Your natural language question goes here!" --render

SQL 생성:

또는 쿼리에 답하는 데 필요한 원시 SQL을 직접 생성할 수 있습니다. 이전 단계의 컨텍스트가 LLM으로 전송되고 응답이 생성됩니다.

Bash

pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

지금 바로 pgai를 활용하는 방법

비교적 간단한 RAG 시스템을 구축하면서 다음이 필요하다면 pgai를 사용해 볼 만합니다.

  • 기준 데이터 시스템으로 사용하는 Postgres

  • 최소한의 연결 코드

  • 자동으로 동기화되는 임베딩

  • 데이터베이스에 text-to-SQL을 빠르게 적용하는 방법

  • 새로운 RAG 도구와 Postgres 확장 프로그램을 실험할 환경

신중하게 접근해야 할 경우

RAG 파이프라인에 다음 중 하나라도 필요하다면 pgai 도입을 미루는 편이 좋습니다.

  • 고도로 맞춤화된 수집 또는 청크 분할 로직

  • 서로 다른 파싱 요건을 가진 다양한 문서 형식

  • 멀티모달 임베딩

마지막으로 pgvector가 널리 도입된 것은 분명하지만, 출시된 지 약 18개월밖에 되지 않은 pgai가 같은 수준의 관심과 지원을 받을지는 아직 불확실합니다.

시간에 따른 Timescale pgai의 도입 추이를 보여주는 GitHub 스타 기록 차트.

요약

pgai는 데이터베이스가 일상적인 운영 작업을 더 많이 처리하게 하여 애플리케이션 코드를 단순화하는 흥미로운 RAG 접근 방식입니다.

현재 pgai는 다음과 같습니다.

  • 간단한 RAG 구성에는 실용적이며 실제로 사용하기도 편리함

  • 더 맞춤화된 파이프라인, 특히 멀티모달 파이프라인에는 유연성이 부족함

가능성이 엿보이는 만큼 향후 발전 과정을 지켜볼 가치가 충분합니다.

작성자

Andrew Liubinas