벡터 데이터베이스는 잘못된 추상화임

• AI 애플리케이션을 구축하려는 엔지니어링 팀을 괴롭히는 메시지 : "임베딩이 다시 동기화되지 않았습니다"
• 간단한 벡터 검색 구현은 모니터링, 동기화 및 문제 해결의 복잡한 오케스트라로 발전함
• 벡터 데이터베이스로 AI 시스템을 구축하는 엔지니어링 팀과 이야기를 나눈 결과, 벡터 데이터베이스의 잘못된 추상화와 오늘날 사용 방식의 결함을 발견함

"RAG 시스템을 구축하는 공통적인 사례"

• Pinecone을 벡터 데이터베이스로 사용하여 임베딩을 저장하고 검색함
• 텍스트 데이터가 Pinecone의 메타데이터에 잘 맞지 않아 DynamoDB로 블롭과 애플리케이션 데이터를 처리함
• 어휘 검색을 위해 OpenSearch가 필요했음 이제 3개의 시스템을 연결하고 동기화하는 것이 악몽임

소스 문서를 삭제할 때 다음을 수행해야 함:

1. boto3를 실행하여 DynamoDB에서 레코드 제거
2. Pinecone을 업데이트하여 임베딩이 삭제되었는지 확인
3. 어휘 검색 인덱스를 업데이트하기 위해 POST 요청 필요

 

• 모든 소스 문서 업데이트, 추가 또는 삭제에 대해 이를 수행해야 함
• 구성 관리는 지저분할 뿐만 아니라 위험함 4개월 전에 삭제했어야 할 인덱스에 대해 한 달에 $2,000를 지불한 팀도 있음
• 잘못되거나 오래된 데이터를 사용자에게 반환할 위험이 있음

 

RAG 시스템에 필요한 벡터 DB가 정말로 "올바르게" 나아가고 있는가? 아니면 hype인가?

 

TimescaleDB의 대안

• Vectorizer 추상화를 제안
• 임베딩 모델과의 통신 및 임베딩 벡터 갱신 등의 책임을 데이터베이스에게 넘기기

SELECT ai.create_vectorizer(  
    'public.blogs'::regclass,  
    embedding => ai.embedding_openai('text-embedding-3-small', 1536),  
    chunking => ai.chunking_recursive_character_text_splitter('content')  
);


-- blogs 테이블의 데이터를 자동으로 임베드하는 벡터라이저 생성  
SELECT ai.create_vectorizer(  
   'public.blogs'::regclass  
   -- OpenAI text-embedding-3-small 모델 사용  
 , embedding=>ai.embedding_openai('text-embedding-3-small', 1536, api_key_name=>'OPENAI_API_KEY')  
   -- 테이블에 100k 행이 있을 때 StreamingDiskANN 인덱스 자동 생성  
 , indexing => ai.indexing_diskann(min_rows => 100000, storage_layout => 'memory_optimized'),  
   -- content 열에 재귀적 청킹 적용  
 , chunking=>ai.chunking_recursive_character_text_splitter('content')  
   -- 더 나은 검색을 위해 다른 열의 메타데이터를 임베딩에 추가  
 , formatting=>ai.formatting_python_template('Blog title: $title url: $url blog chunk: $chunk')  
);  
-- 벡터라이저는 소스 테이블이 변경될 때 임베딩을 업데이트함   
-- 다른 사용자 작업은 필요하지 않음

 

예를 들어 다음은 HTML 소스 파일을 재귀적으로 분할하고 소스 데이터에서 OpenAI 임베딩을 만들도록 구성된 벡터라이저임. 코드, 문서, 마크다운 등 애플리케이션 데이터에 맞게 청킹과 포맷팅을 구성할 수 있음

-- 고급 벡터라이저 구성   
SELECT ai.create_vectorizer(  
   'public.blogs'::regclass,  
   destination => 'blogs_embedding_recursive',  
   embedding => ai.embedding_openai('text-embedding-3-small', 1536),  
   -- HTML 콘텐츠에 대해 지정된 설정으로 재귀 청킹 적용  
   chunking => ai.chunking_recursive_character_text_splitter(  
       'content',  
       chunk_size => 800,  
       chunk_overlap => 400,  
       -- HTML 인식 구분 기호, 우선 순위가 가장 높은 것부터 가장 낮은 순서로 정렬  
       separator => array[  
           E'</article>', -- 주요 문서 섹션에서 분할   
           E'</div>',    -- div 경계에서 분할  
           E'</section>',  
           E'</p>',      -- 단락에서 분할  
           E'<br>',      -- 줄 바꿈에서 분할  
           E'</li>',     -- 목록 항목에서 분할  
           E'. ',        -- 문장 경계로 대체   
           ' '          -- 최후의 수단: 공백에서 분할  
       ]  
   ),  
   formatting => ai.formatting_python_template('title: $title url: $url $chunk')  
);

 

• pgai Vectorizer는 임베딩 관리를 크게 단순화할 수 있는 강력하고 혁신적인 도구로 보임.
• 벡터라이저 추상화는 개발자가 임베딩을 수동으로 관리해야 하는 부담을 덜어주고 임베딩이 소스 데이터와 동기화되도록 보장.
• 특히 임베딩 모델 업그레이드 또는 청킹 전략 변경과 같은 변경 사항을 적용할 때 매우 유용할 것 같음.
• 기존의 벡터 데이터베이스에서는 이러한 변경으로 인해 여러 시스템에서 사용자 정의 코드를 작성하고 조정해야 하는 복잡한 프로세스가 발생할 수 있지만, pgai Vectorizer를 사용하면 벡터라이저 구성만 업데이트하면 됨.
• 또한 PostgreSQL과 같은 범용 데이터베이스에서 임베딩을 관리하면 여러 전문 시스템을 오케스트레이션해야 하는 문제를 피할 수 있음. 이는 애플리케이션 개발을 크게 단순화할 수 있음.
• 한 가지 고려해야 할 점은 외부 Python 프로세스에서 실제 임베딩이 생성된다는 것. 이는 데이터베이스 성능에 영향을 미치지 않도록 하는 좋은 설계 선택이지만, 임베딩 생성 프로세스를 별도로 모니터링하고 관리해야 함을 의미함.
• 궁극적으로 pgai Vectorizer는 AI 애플리케이션을 위한 임베딩 관리 방식에 상당한 발전을 나타냄.
• 더 많은 팀이 이를 도입하고 피드백을 제공함에 따라 이 강력한 도구가 더욱 발전할 것으로 기대됨.
• Postgres와 같은 친숙한 도구에 임베딩 관리를 통합하면 더 많은 개발자가 첨단 AI 기능을 활용할 수 있게 될 것임.

 

References:

Vector Databases Are the Wrong Abstraction