API 호출 중 연결이 끊기는 상황을 고려해야 합니다. API를 반복적으로 호출하고 그 결과를 관리해야 할 경우, API 응답 내용을 데이터베이스에 순차적으로 업데이트하며 관리하는 방식을 추천합니다.

본 영상에서는 RDBMS와 벡터 DB의 차이점을 상세히 설명하겠습니다. RDBMS는 기존에 주로 사용하던 관계형 데이터베이스를 의미합니다. 반면, 벡터 DB는 RAG (Retrieval-Augmented Generation) 검색 시 많이 활용됩니다. 이 두 데이터베이스 간의 주요 차이점을 살펴보겠습니다.

이 자료에서는 RDBMS와 Vector DB의 활용 방식 및 차이점에 대해 상세히 알아보겠습니다. 특히 안드레이 카파시(Andrej Karpathy)의 LLM 및 AI 관련 강의 영상의 자막을 번역하며 해당 내용을 심도 있게 다룰 예정입니다.

안드레이 카파시는 전 세계적으로 인정받는 AI 분야의 권위자이며, 그의 유튜브 강의는 LLM과 AI 기술에 대한 깊이 있는 통찰을 제공합니다. 본 영상은 그의 강의 중 하나를 발췌하여 자막을 추출하고 번역하는 과정을 거쳐 RDBMS와 Vector DB의 개념을 명확히 이해하도록 돕겠습니다.

데이터베이스는 데이터를 효율적으로 저장, 관리, 검색하기 위한 체계적인 시스템입니다. 회원 가입, 상품 조회, 장바구니 담기 등 웹사이트 이용 시 발생하는 데이터가 데이터베이스에 저장됩니다. 목적과 특성에 따라 다양한 종류가 존재하며, 본 문서에서는 전통적인 RDBMS와 AI 분야에서 주로 활용되는 벡터 DB를 중심으로 설명합니다.

관계형 데이터베이스(RDBMS)는 데이터 관리의 오랜 표준으로, 벡터 DB가 이를 대체하는 것이 아니라 상호 보완적인 역할을 수행합니다. RDBMS는 'Relational Database Management System'의 약자로, 데이터를 정형화된 테이블 형태로 저장합니다. 테이블은 행과 열로 구성되며, 'Relational'은 테이블 간의 관계를 의미합니다. 쇼핑몰의 회원, 주문, 제품 테이블처럼 여러 테이블 간의 관계를 정의하여 데이터를 연결합니다.

RDBMS는 데이터의 무결성과 일관성 유지가 매우 중요합니다. 예를 들어, 쇼핑몰에서 판매된 금액을 정확히 계산하고 정산해야 하므로, 결제 및 배송 과정에서 트랜잭션 오류가 발생하면 계산 오류나 문제가 발생할 수 있습니다. RDBMS는 주로 엑셀과 같이 표 형태로 데이터를 다루며, 데이터 타입(숫자, 문자열, 날짜 등)을 미리 지정하는 엄격한 스키마를 사용합니다.

RDBMS의 주요 기능은 데이터의 생성, 조회, 수정, 삭제(CRUD)를 지원하고 기본적인 연산을 관리하는 것입니다. 또한, 트랜잭션 관리가 중요합니다. 주문, 결제, 배송 완료 등 일련의 과정에서 누락 없이 트랜잭션이 발생해야 하며, 이를 위해 ACID 원칙(원자성, 일관성, 고립성, 지속성)을 보장합니다.

RDBMS에서의 검색은 주로 SQL(Structured Query Language)을 사용합니다. SQL은 데이터 정의, 조작, 제어로 나뉘며, `SELECT` 문과 `WHERE` 절을 사용하여 정확한 조건으로 데이터를 필터링합니다. 예를 들어, 작성자 이름으로 검색하거나, 특정 가격 범위의 제품을 찾는 것이 가능합니다. 또한, 여러 테이블을 `JOIN` 연산을 통해 조합하여 데이터를 조회할 수 있습니다.

검색 성능 향상을 위해 RDBMS에서는 인덱싱 기술을 활용합니다. B-tree 인덱스나 해시 인덱스를 사용하면 특정 값에 대한 빠른 검색이 가능하여 데이터를 효율적으로 가져올 수 있습니다.

이렇게 확인하실 수 있습니다.

IDBMS 테이블 예시로 직원 테이블을 살펴보겠습니다. 직원 ID, 이름, 부서, 급여 정보를 담고 있다고 가정하면, 각 컬럼명과 데이터 타입이 정의됩니다. 예를 들어 직원 ID는 숫자(integer)로, 직원 이름과 부서는 문자(character)로 지정될 수 있습니다. 또한, 문자열의 길이나 숫자 범위 등 데이터의 제약 조건도 함께 저장됩니다.

이러한 테이블 스키마 정보는 데이터베이스 내에 저장됩니다. 만약 게시판에서 제목의 최대 길이를 데이터베이스에 지정했는데, 이를 초과하는 내용을 입력하려고 한다면 SQL 오류가 발생합니다. 따라서 데이터베이스에 데이터를 입력하기 전에 스키마에 정의된 규칙에 따라 데이터의 유효성을 검증하는 과정이 필요합니다.

RDBMS 쿼리에서 `SELECT`, `FROM`, `WHERE` 절을 사용하는 방식은 특정 조건에 부합하는 데이터를 조회하는 데 활용됩니다.

저희가 임베딩하는 데이터는 테이블 형태라기보다 행렬 형태로 구성됩니다. 이 데이터는 여러 타입이 아닌 모두 숫자로 이루어져 있으며, 이를 통해 유사도 검색을 수행합니다.

이 RDBMS와는 차이가 있으며, 검색 시 정확히 일치하는 값보다는 유사한 값을 반환하는 특징을 가지고 있습니다.

RDBMS는 정확히 같은 값을 찾거나, 특정 조건을 만족하는 데이터를 추출할 때 유용합니다. 예를 들어, 'Sales' 부서에 속한 직원들만 조회하고자 한다면, RDBMS는 해당 조건에 맞는 데이터만을 정확하게 가져옵니다.

RDBMS는 데이터 무결성과 일관성을 보장하며, 표준 SQL로 접근이 용이하여 정형 데이터 관리에 효과적입니다. 오랜 기간 사용되어 온 성숙한 기술과 풍부한 생태계는 복잡한 관계 표현 및 다중 테이블 연결을 가능하게 합니다.

하지만 RDBMS는 생성형 모델에 비정형 데이터(텍스트, 이미지 등) 처리가 어렵고, 의미 기반 검색 및 대규모 데이터의 수평적 확장에 한계가 있습니다. 또한, 유연하지 못한 스키마 변경은 생성형 모델 활용 시 아쉬운 점으로 작용합니다.

RDBMS는 은행, 예약, 고객 관리, ERP, 전자상거래, 인사급여 등 다양한 비즈니스 분야에 폭넓게 활용됩니다. Oracle, MySQL, MariaDB, PostgreSQL, SQLite 등 다양한 제품군이 존재하며, MySQL에서 파생된 MariaDB는 창립자 딸의 이름에서 유래되었습니다.

정형 데이터에 특화된 RDBMS와 달리, 벡터 데이터베이스는 텍스트, 이미지, 비디오 등 비정형 데이터 처리에 강점을 보입니다. AI 모델의 텍스트 및 이미지 데이터를 벡터화하고, 이를 통해 데이터의 유사성을 기반으로 검색하는 새로운 필요성이 증대되고 있어, 벡터 DB의 중요성이 커지고 있습니다.

TensorFlow Embedding Projector에 대한 설명입니다. 여기서 Embedding은 단어를 선택하면 해당 단어와 가까운 거리에 있는 단어들을 다차원 공간에 표현하는 것을 의미합니다. 현재는 3차원 공간으로 차원 축소하여 어떤 단어가 멀고 가까운지를 시각적으로 보여주고 있습니다.

여기에 제공된 데이터는 밀집 벡터(dense vector)로 임베딩되어 있으며, 메타데이터와 함께 제공됩니다. 이렇게 임베딩된 데이터와 메타데이터를 활용하면

보유한 데이터로 인베딩 데이터를 시각화하여 확인할 수 있습니다.

임베디드 데이터는 예시에서 보시는 바와 같이 밀집 벡터, 즉 숫자로 구성됩니다. 따라서 기존 RDBMS보다는 벡터 DB로 관리하는 것이 검색 방식의 차이로 인해 저장 방식 또한 달라져야 함을 의미합니다.

텍스트나 이미지에서 추출한 벡터 임베딩은 유사한 의미나 특징을 가진 데이터를 벡터 공간에서 가깝게 위치시킵니다. 벡터화된 데이터는 행렬 형태로 볼 수 있으나, 기존 관계형 데이터베이스와는 다른 저장 및 검색 방법이 필요합니다.

벡터 DB는 이러한 인베딩 벡터를 효율적으로 저장하고 검색하기 위해 특화된 데이터베이스입니다. 핵심 기능은 쿼리 벡터와 유사한 벡터를 찾는 것으로, 고차원 공간에서의 빠른 유사도 검색 성능이 중요합니다. 이를 통해 비정형 데이터의 의미 검색에 활용됩니다.

여기 Embedding Projector에서 보시는 바와 같이

'밀크'와 같은 임의의 단어로 검색하면, 해당 단어와 의미적으로 유사한 단어들을 거리에 따라 순서대로 보여줍니다. 검색 결과의 거리 계산에는 코사인 방식 또는 유클리드 거리를 사용할 수 있습니다.

벡터 데이터와 인베딩된 데이터를 저장, 관리, 검색하는 데 특화된 데이터베이스가 벡터 데이터베이스입니다. 이는 주어진 쿼리 벡터와 유사한 벡터를 검색하는 데 활용됩니다. 고차원 공간에서의 유사도 검색 성능이 중요하며, 주로 비정형 데이터의 의미 검색에 사용됩니다. 벡터 데이터베이스는 벡터 임베딩, 즉 고차원 숫자 배열을 사용하며, 메타데이터를 부가 데이터로 포함합니다.

이러한 임베딩 프로젝터를 접했을 때도

이러한 임베딩 데이터는 벡터 데이터와 메타데이터로 구성되어 있습니다.

해당 데이터 구조는 벡터와 관련된 메타 데이터를 통합하여 관리합니다. 이러한 메타 데이터의 대부분은 유연한 구조를 지원하며, 주요 기능으로는 유사도 검색을 수행합니다.

TensorFlow Embedding Projector에서 단어를 클릭하면 해당 단어와 유사도가 높은 단어들이 제시되는 것과 같습니다.

쿼리 벡터와 디빈(divine) 벡터 간의 거리나 유사도를 계산하여, 가장 가까운 상위 K개의 벡터를 반환합니다.

여기서도 가까운 거리에 있는 상위 k-nearest neighbors, n-nearest neighbors를 보실 수 있습니다. 상위 몇 개의 데이터를 보여주고 있으며, 'nearest points'라고 표시되어 있습니다.

Approximated Nearest Neighbor(ANN)는 고차원 벡터 공간에서 정확한 최근접 이웃 검색이 매우 느리기 때문에, 100% 정확하지는 않더라도 매우 빠른 속도로 충분히 유사한 이웃을 찾는 검색 방식입니다. 유사도나 거리 측정에는 코사인 유사도, 유클리드 거리, 내적 등이 사용됩니다.

이에 앞서 인베딩 프로젝터를 통해 코사인 또는 유클리드 거리를 사용하고 있음을 확인하실 수 있습니다.

벡터 DBA 인덱싱은 유사도 검색 속도 향상을 위해 벡터 특화 인덱스를 사용합니다. 대표적인 알고리즘으로는 그래프 기반, 클러스터링 기반, 해싱 기반, 벡터 압축 기반 등이 있습니다.

벡터 DBA는 확장성과 일관성을 고려하여 설계됩니다. 수평적 확장이 용이하게 설계되었으며, 강한 일관성보다는 최종 일관성을 허용하는 경우가 많습니다.

이어서 벡터 데이터와 JSON 데이터 예시를 살펴보겠습니다. 벡터 데이터는 벡터 ID, 임베딩된 밀집 벡터의 숫자, 그리고 메타데이터 정보를 포함합니다. 이는 검색 및 필터링에 활용될 메타데이터를 함께 저장하는 구조로 구성됩니다.

벡터 데이터에 쿼리를 실행할 경우, 임베딩된 이미지나 텍스트에서 유사한 데이터를 찾거나 필터링을 수행하게 됩니다. 예를 들어 '탑 K(Top K)' 기능을 통해 가장 유사한 상위 5개 또는 10개의 데이터를 찾아올 수 있습니다.

벡터 DB는 비정형 데이터의 의미 기반 검색과 대규모 데이터셋의 고속 유사성 검색에 탁월합니다. 또한 AI 모델과의 연동이 용이하며, 추천, 검색, RAG 등 다양한 응용 AI를 지원합니다.

기존에 유사도 검색은 주로 추천 시스템에 활용되었으나, 최근에는 검색 증강 생성(Retrieval-Augmented Generation, RAG) 기법과 함께 AI 모델의 할루시네이션을 줄이는 데 사용되고 있습니다. RAG는 최근 정보를 찾아오는 데 효과적입니다.

벡터 DB는 관계형 데이터베이스의 단점을 보완하지만, 정확한 값 매칭에는 비효율적입니다. 따라서 정확한 값 매칭이 필요할 때는 관계형 데이터베이스를 사용합니다. 벡터 DB는 관계형 커리나 트랜잭션 지원이 RDBMS보다 약하며, 아직 발전 중인 기술입니다.

임베딩 모델의 성능이 검색 품질에 큰 영향을 미치지만, 속도 및 유사도 검색 등은 꾸준히 연구되고 있습니다.

주요 활용 사례로는 추천 시스템(유사 상품, 뉴스, 비디오 등), 지식 검색, 이미지/비디오 검색, 챗봇, 가상 비서, 금융 분야의 사기 탐지 및 이상 거래 감지 등이 있습니다.

대표적인 벡터 DB로는 Pinecone, Milvus, Chroma 등이 있습니다. FICE도 많이 사용되지만, DB 자체라기보다는 Vector Store로, 인메모리 방식으로 동작합니다.

랭테인(Rangtain)에 게시된 보고서 중 하나입니다.

2024년 Vector Store 순위에 따르면 Chroma가 1위를 차지하였으며, 그 뒤를 이어 Pinecone, Weaviate, Milvus, Qdrant, Faiss, Pinecone, Pgvector 순으로 나타납니다.

벡터 DB와 벡터 검색 라이브러리인 FICE의 차이점은 다음과 같습니다. 벡터 DB는 영속성, 트랜잭션, 메타데이터 관리, API 제공, 사용자 관리 기능 등을 지원합니다. 반면 FICE는 고성능 유사도 검색에 특화된 오픈소스 라이브러리로, 주로 인메모리에서 작동하며 데이터 영속성이나 트랜잭션 기능이 제한적입니다.

FICE는 메타 AI에서 개발한 라이브러리로, C++로 구현되고 Python 바인딩을 제공합니다. GPU 가속, 메모리 효율성, 다양한 인덱싱 알고리즘을 지원하며, 대규모 데이터셋 처리에도 최적화되어 있습니다. 때로는 벡터 DB 내부에서 활용되기도 합니다.

FICE는 데이터베이스라기보다는 라이브러리이므로, 데이터의 저장 및 로드, 자동 저장/복원, 트랜잭션 기능 등이 부족합니다. 개발자가 직접 데이터 로딩, 인덱스 빌드, API 구축 등을 수행해야 하는 한계가 있습니다.

따라서 관리 및 검색 효율성을 고려하면, 벡터 DB에 데이터를 직접 저장하여 사용하는 것이 더 효율적일 수 있습니다. FICE는 고성능 유사도 검색, GPU 가속, 다양한 API 등을 제공하며, 이미지/비디오 검색, AI 모델의 임베딩 벡터 관리, 대규모 데이터셋 클러스터링 등에 활용됩니다.

FICE를 설치하고 사용하면 유사도 검색을 통해 상위 몇 개를 가져올 수 있습니다.

FICE는 벡터 검색 엔진의 핵심을 직접 구현하거나, 최고 수준의 검색 성능과 튜닝이 필요할 때, 그리고 빠른 프로토타이핑이 필요할 때 사용됩니다.

랭체인 리포트에서 1위를 차지한 Chroma DB에 대해 알아보겠습니다.

크로마 DB는 LLM 워크플로우에 최적화된 오픈소스 벡터 데이터베이스입니다. PIP 인스톨 크로마 DB로 간편하게 설치할 수 있으며, 랭체인(Langchain)이나 라마 인덱스(Llama Index)와 연동이 용이합니다.

크로마 DB를 랭체인의 벡터 스토어로 사용하면 문서 임베딩 저장, 유사도 검색, LLM 응답 생성에 활용됩니다. 이를 통해 빠르고 간결한 RAG(Retrieval-Augmented Generation) 파이프라인을 구현할 수 있습니다.

벡터 데이터베이스는 데이터 저장, 인덱싱, 검색 기능을 제공하며, 데이터의 영속성 보장 및 트랜잭션 지원 여부는 DB마다 다릅니다. RESTful API나 SDK를 통한 데이터 접근, 사용자 친화적인 인터페이스 등도 제공됩니다.

RDBMS와 벡터 DB는 정형/비정형 데이터 저장, 정확한 키워드 검색 vs. 유사도 검색, 스키마 유연성, 관계 명시적 조인 vs. 거리 기반 유사성 검색 등에서 차이를 보입니다.

RDBMS는 조건 필터링을 통한 정확한 검색을 수행하는 반면, 벡터 DB는 유사성 기반 거리 계산으로 가장 가까운 데이터를 검색합니다. 또한 RDBMS는 수직 확장, 벡터 DB는 수평 확장에 용이합니다.

RAG 기술은 생성형 AI의 환각, 최신 정보 부족, 출처 불분명, 특정 도메인 지식 부족 등의 한계를 극복하는 핵심 기술입니다. LLM이 답변 생성 전 외부 지식 소스에서 관련 정보를 검색하고 참고하여 정확하고 신뢰성 있는 답변을 생성합니다.

RAG 활용 시 잘못된 답변, 최신 정보 미반영, 근거 없는 답변 등의 문제를 방지하여 답변의 신뢰도를 높일 수 있습니다.

LangChain Report의 첫 페이지에 나오는 Chroma DB 웹사이트입니다. Chroma DB를 통해 AI 애플리케이션에서 쿼리가 이루어지면, 검색 결과가 도출됩니다. 검색된 데이터는 임베딩(embedding) 과정을 거쳐 벡터화된 후 벡터 DB에 저장됩니다. 이후, 유사도가 높은 데이터를 프롬프트 쿼리와 함께 사용하여 더욱 신뢰성 있는 답변을 얻게 됩니다.

RAG(Retrieval-Augmented Generation)의 기본 흐름은 사용자의 질문 입력으로부터 시작됩니다. 이후 관련 정보를 Database에서 검색하고, 이 검색된 정보를 바탕으로 Prompt를 Augmentation(증강)하는 과정을 거칩니다. 최종적으로 증강된 Prompt를 활용하여 답변을 생성하게 됩니다.

RAG(Retrieval Augmented Generation)의 핵심 흐름은 사용자의 질문을 받아 관련 정보를 DB에서 검색하는 것입니다. 검색된 정보와 원본 질문을 결합하여 프롬프트를 강화(augment)하고, 이 증강된 프롬프트를 LLM(Large Language Model)에 입력하여 신뢰할 수 있는 최종 답변을 생성합니다.

RAG(Retrieval-Augmented Generation)에서 데이터베이스의 핵심 역할은 효율적인 정보 검색입니다. 대규모 지식 소스를 저장하고 가장 관련성 높은 정보를 빠르고 정확하게 찾아내는 능력은 RAG 성능에 직접적인 영향을 미칩니다. 특히 벡터 데이터베이스(VectorDB)는 RAG에서 핵심적인 의미 검색 엔진으로 기능합니다.

벡터 데이터베이스는 질문을 벡터로 변환(embedding)하고, 이와 유사한 벡터를 검색하여 원본 정보를 반환함으로써 RAG의 검색 품질을 결정하는 핵심 요소입니다. Q&A 챗봇 구현 시, FAQ나 내부 지식 문서를 벡터 DB에 미리 임베딩하여 저장하고, 사용자 질문과 가장 유사한 K개의 문서 조각을 검색하여 LLM이 답변을 생성하도록 합니다.

관계형 데이터베이스(RDBMS)도 RAG 시스템에서 신뢰도 강화 및 보완을 위해 함께 사용됩니다. RDBMS는 메타데이터 필터링, 구조화된 정보 조회, 사용자 세션 관리 등에 활용되어 벡터 검색만으로는 부족한 부분을 채웁니다.

RDBMS는 정확한 조건으로 필터링하여 일치하는 결과를 가져오는 데 사용되는 반면, 벡터 DB는 유사한 내용 검색에 강점을 보입니다. 예를 들어, RDBMS는 '1년 내 기술팀'과 같은 명확한 조건으로 필터링할 때 사용되며, 벡터 DB는 더 넓은 범위의 유사한 내용을 가져올 때 활용됩니다.

RAG 시스템은 또한 RDBMS를 활용하여 구조화된 정보 조회를 수행합니다. '계정의 포인트 잔액'과 같은 구체적인 숫자나 '상품의 현재 재고 현황'과 같은 정보를 데이터베이스에서 직접 조회하여 가져옵니다. 더불어 사용자 세션 로그 관리에도 RDBMS가 활용됩니다.

이 레그(RAG) 시스템에서는 RDBMS와 벡터 데이터베이스를 함께 사용합니다. 정확한 필터링이 필요할 때는 RDBMS를 활용하고, 유사한 콘텐츠를 가져와야 할 때는 벡터 DB를 사용하여 검색합니다. 이렇게 검색된 정보를 프롬프트에 조합하여 모델에 입력하고, 최종 답변을 얻게 됩니다.

두 기술의 장점을 결합한 하이브리드 접근 방식은 더욱 신뢰성 높은 답변을 제공합니다. 정형 및 비정형 데이터가 혼재하는 실제 비즈니스 환경에서는 정확한 조건 검색과 의미 기반 유사성 검색이 모두 필요하기에 이러한 하이브리드 접근이 필수적입니다. PostgreSQL과 pgvector와 같은 RDBMS 확장 기능을 사용하면 단일 데이터베이스에서 SQL 쿼리와 벡터 유사도 검색을 동시에 수행할 수 있습니다.

이 방식의 장점은 익숙한 RDBMS 환경에서 단순하게 통합할 수 있다는 것입니다. 하지만 대규모 벡터 검색 시 확장성에 한계가 있다는 단점도 존재합니다. 별도의 데이터베이스로 접근하는 방식은 RDBMS와 벡터 DB를 각각 구축하고 애플리케이션 레벨에서 두 데이터베이스에 개별적으로 접근해야 합니다.

이 방식의 장점은 각 데이터베이스의 전문성을 활용할 수 있다는 것입니다. 그러나 시스템 구성 및 관리 복잡성이 증가한다는 단점이 있습니다. 따라서 하나의 시스템에서 데이터 처리와 벡터 검색 모두를 고성능으로 지원하는 하이브리드 DB 방식 솔루션이 등장하고 있습니다.

하이브리드 DB 방식은 통합이 용이하고 잠재적으로 고성능을 제공하지만, 기술 성숙도나 벡터 종속성에 대한 우려가 단점으로 작용할 수 있습니다. 벡터 검색 기능은 점차 데이터베이스의 기본 기능으로 통합될 가능성이 높으며, 데이터베이스들은 벡터 데이터베이스를 다룰 수 있는 기능들을 추가하고 있습니다.

이로 인해 RDBMS와 벡터 DB 간의 경계가 모호해질 수 있으며, 데이터 유형에 따른 최적의 저장 및 검색 전략의 중요성이 커지고 있습니다. 하이브리드 및 통합 솔루션은 계속 발전할 것으로 예상됩니다. RDBMS는 정형 데이터를 다루고 트랜잭션 처리가 필요하며 정확하고 일관된 관리가 필수적인 상황에서 여전히 강력합니다. 벡터 DB는 비정형 데이터의 의미를 이해하고 검색하는 데 필요합니다.

RDBMS와 벡터 DB의 차이점을 살펴보았지만, 이 두 데이터베이스는 경쟁 관계가 아닌 상호 보완적인 관계입니다. 서로의 강점을 활용하여 시너지를 창출할 수 있으며, 이를 통해 정확성과 의미적 활용을 모두 달성할 수 있습니다.

'Andrei Karpathy's "vibe coding"이 최근 화제입니다. 카파시의 영상은 2~3시간 분량으로 매우 긴 편입니다. 이러한 긴 영상을 기존 챗GPT 등 생성형 AI에 통째로 번역 요청하거나 자막 데이터를 넣어 번역하게 되면, 토큰 수 제한에 걸려 제대로 된 결과를 얻기 어렵습니다. 답변이 나오더라도 요약되거나 전문이 그대로 번역되는 등 아쉬운 부분이 있습니다.

이러한 문제를 해결하기 위해 벡터 데이터베이스를 활용하는 방안을 소개하고자 합니다. 벡터 데이터베이스는 긴 텍스트를 의미 기반으로 분할하고 검색하는 데 강점을 가지므로, 긴 영상의 내용을 효율적으로 처리하고 원하는 정보를 추출하는 데 유용합니다.'

유튜브에서 수집한 안드레이 카파시 영상의 자막을 활용합니다. 긴 자막은 생성형 AI의 토큰 수 제한으로 인해 전부 번역되지 않거나 잘릴 수 있습니다. 노트북 LM과 같은 최신 기술은 긴 영상 요약 및 번역을 지원하지만, 직접 번역하며 VectorDB와 RDBMS 활용 방안을 모색합니다.

OpenAI API를 사용하여 자막을 번역하되, 토큰 수 제한을 고려하여 텍스트를 적절히 분할합니다. 이때, 번역 과정에서 발생하는 API 호출 결과 및 상태를 효율적으로 관리하기 위해 데이터베이스 활용을 권장합니다.

데이터베이스에는 원본 텍스트와 함께 API 응답 결과를 순차적으로 업데이트합니다. 이 방식을 통해 API 호출 중단 시에도 번역되지 않은 부분부터 재시도하여 API 비용 절감 및 시간 효율성을 높일 수 있습니다.

자막 텍스트를 데이터베이스 형태로 관리하는 것이 좋습니다. 파이썬에 내장된 SQLite를 사용하면 별도 설치 없이 원본 텍스트를 저장하고, API 응답 결과를 순차적으로 채워나가며 API 호출 상태를 명확하게 파악할 수 있습니다.

번역된 내용은 Chroma DB와 같은 Vector DB에 저장하여 검색, 요약, 질의응답 등에 활용할 수 있습니다. 데이터베이스 내에 데이터가 저장된 것을 확인하고, 이를 바탕으로 웹페이지를 구축하여 번역 결과를 시각적으로 확인할 수 있습니다.

HTML 형태로 번역 결과를 확인했을 때, 글자 수 기준으로만 청크(chunk) 처리하여 텍스트가 잘리는 현상이 발생했습니다. 'you go to the google call app'과 같이 이어져야 할 구문이 분리되어 자연스럽게 번역되지 않았습니다. 텍스트 데이터를 인베딩할 때는 일반적으로 다양한 청킹 방식을 사용하며, 겹쳐서 청크하는 윈도우 방식도 활용됩니다.

이러한 겹침 방식은 텍스트가 중간에 잘려나가고 맥락이 어색하게 번역되는 문제를 야기합니다. 예를 들어, 'You go to the Google Core 앱, Google Core 앱으로 가서 뭘 해라'라는 의도가 'Google Core 앱으로 가서 비디오를 봐라'와 같이 의미가 왜곡될 수 있습니다.

번역 후 원문을 통합하여 비교할 때, 토크나이징(tokenizing)이 너무 작게 이루어지면 원문과 번역문 사이에 끊김이 발생하여 어색함이 느껴집니다. 원문 데이터를 정제하고 문단 또는 의미 단위로 청크하여 번역하면 훨씬 더 맥락에 맞는 자연스러운 결과물을 얻을 수 있습니다.

번역된 내용을 데이터베이스에 저장하여 "토크나란 무엇인가?"와 같은 질문을 할 수 있습니다. 스터디 내용에 기반한 질문에 대한 답변은 다음과 같습니다. "토크나란 언어모델에서 사용되는 단어들을 작은 단위로 분리하는 과정입니다. 이 과정은 복잡하고 주의해야 할 숨겨진 문제들이 많아 중요하며, 많은 이상한 문제들이 토크나에서 기인하므로 이해하고 적용하는 것이 중요합니다."

이 정보는 문서에서 검색하여 벡터 DB를 통해 찾아왔습니다. 벡터 DB와 관계형 데이터베이스(RDBMS)는 분리하여 사용하는 것이 아니라 함께 사용합니다. 정확한 내용 검색 시에는 RDBMS를, 유사도 검색 시에는 ChromaDB와 같은 벡터 DB를 활용합니다.

데이터 유형과 처리 목적에 맞춰 데이터베이스를 선택하고, 정확도, 유사도 또는 두 가지 모두 필요한지에 따라 하이브리드 방식을 활용하여 다양한 비즈니스 문제를 해결해 보시길 바랍니다.