api를 호출을 하다가 중간에 api가 끊길 수가 있잖아요. 이런 식으로 번역을 하는데 우리가 이 api를 계속 호출을 하는데 이 api를 한두 번 호출을 하는 것도 아니고 api를 호출을 하고 나서 그 호출된 결과도 관리를 해야 되는데 그럴 때는 차라리 데이터베이스에다가 그 답변을 받은 api로 답변을 받은 내용을 하나씩 하나씩 업데이트 하면서 관리하는 것을 추천을 합니다. 안녕하세요 이번 영상에서는 rdbms 와 벡터 db의 차이점에 대해서 알아보도록 할 텐데요 rdbms 같은 경우에는 기존에 우리가 이제 주로 이제 사용을 하던 관계형 데이터베이스를 의미를 하고요 그 다음에 이제 벡터 데이터베이스 같은 경우에는 RAG 검색 증강 생성 작업을 할 때 이 벡터 db 를 많이 사용을 하게 됩니다 그래서 이 rdbms와 벡터 db와 무슨 차이가 있는지를 한번 알아보도록 하겠습니다.

저희는 여기에서 긴 텍스트를 번역을 해 가면서 rdbms와 벡터 db가 어떻게 활용이 되는지 rdbms와 벡터 db의 차이점에 대해서 알아보도록 할 예정이에요. 지금 여기 안드레이 카파씨의 영상 중에 하나를 제가 썸네일을 하나 가져왔는데요. 이 안드레이 카파시 전세계 1타 강사라고 해도 과언이 아닐 정도로 이런 LLM이라든지 AI 관련 강의를 유튜브에서 진행을 하고 있는데 강의 영상이 꽤 길죠. 그 다음에 요즘에 바이브 코딩의 창시자이기도 하죠. 그래서 이 안드레이 카파시의 유튜브 영상을 가져다가 자막을 추출을 해서 한번 번역하는 작업을 해보면서 RDBMS와 벡터 DB의 차이점에 대해서 알아보도록 하겠습니다.

일단 데이터베이스란 무엇인지에 대해서 소개를 하고요. 그 다음에 관계형 데이터베이스 보통 RDBMS라고 부릅니다. 그리고 이제 벡터 데이터베이스 그리고 RDBMS와 벡터 DB에 대해서 비교를 해보고 그 다음에 검색 증강 생성을 하는 RAG에서 데이터베이스의 역할이 무엇인지 알아보고 그 다음에 RDBMS와 벡터 DB를 함께 사용하는 하이브리드 접근 방법에 대해서도 한번 알아보도록 하겠습니다. 데이터베이스란 무엇인가에 대한 정의를 한번 살펴볼 텐데요. 데이터베이스는 데이터를 효율적으로 저장 관리 검색하기 위한 체계적인 시스템이라고 볼 수가 있는데 저희가 웹사이트에 회원 가입하거나 그 다음에 쇼핑몰에 가서 물건을 보거나 장바구니에 담거나 했을 때 그런 데이터들이 데이터베이스에 담기게 되죠. 목적과 유행에 따라서 다양한 종류가 존재하고 오늘은 전통적인 DBMS와 AI에 주로 활용이 되는 벡터 DB를 한번 주로 다뤄보도록 하겠습니다. 관계형 데이터베이스는 오랜 시간 데이터 관리에 표준이 되어온 기술이고 벡터 DB가 있다고 해서 관계형 데이터베이스를 대체하는 게 아니라 서로 보완해가는 역할로 이 두 가지 데이터베이스를 사용하게 될 거예요. 그래서 RDBMS 같은 경우에는 Relational Database Management System의 약자로 이 RDBMS는 데이터를 정형화된 테이블 형태로 저장을 하게 되는데요. 테이블은 행과 열로 구성을 하게 되는데 여기 R이라는 게 Relational, 뭔가 관계를 의미를 하죠. 그래서 테이블에 보면 우리가 쇼핑몰이다 라고 하게 되면 회원 테이블, 주문 테이블, 제품 테이블 이런 식으로 여러 테이블들이 있는데 그 테이블들 간의 관계를 정의하며 데이터를 연결을 해줍니다. 데이터의 무결성이나 일관성 유지가 굉장히 중요한데 왜냐하면 우리가 쇼핑몰에서 물건을 판매를 했다 라고 하게 되면 판매된 금액이 얼마냐 그래서 그걸 계산을 해서 정산을 해야 된다라고 했을 때 그런 금액적인 부분, 그 다음에 결제가 일어나고 배송이 되고 그 과정에서 뭔가 트랜잭션에 오류가 나게 되면 그런 계산이 맞지 않거나 문제가 생길 수가 있겠죠. 그래서 데이터 무결성과 일관성 유지가 굉장히 중요하다고 볼 수가 있어요. DBMS, RDBMS 같은 경우에는 주로 정형 데이터, 표 형태의 데이터, 우리가 엑셀처럼 생긴 데이터를 다룬다. 그리고 이 RDBMS의 스키마를 정해줄 때는 이게 숫자냐, 문자열이냐, 날짜냐, 시간이냐 이런 것들을 정해주게 됩니다. 노에스큐일 같은 경우에는 이런 데이터 타입을 스키마를 미리 정해주고 데이터를 넣어야 되는데 노에스큐일 같은 경우에는 이런 스키마에 약간 더 자유롭다 이렇게 볼 수가 있겠죠. 데이터 구조는 테이블 형태, 엑셀하고 유사한 형태로 되어 있다고 볼 수 있고 앞에서 얘기했었던 것처럼 스키마가 굉장히 엄격하기 때문에 데이터 구조를 사전에 정의해주고 만약에 컬럼이 하나 추가가 된다고 하게 되면 스키마에 추가를 한 다음에 데이터를 넣어주어야 되는 형태입니다. RDBMS의 주요 기능은 우리가 무언가 웹사이트를 개발을 할 때 CRUD 할 줄 안다. 그러면 다 할 줄 아네. 이렇게 얘기를 하기도 하는데 데이터 생성 조회 수정 삭제가 있고요. 데이터 관리에 기본적인 연산을 지원을 한다고 볼 수가 있습니다. RDBMS의 주요 기능으로는 트랜잭션. 아까 앞에서 얘기했었던 것처럼 우리가 뭔가 주문이 일어난다. 결제가 일어난다고 하게 되면 결제에서 배송에서 배송 완료 이런 과정들을 거치게 되는데 배송 완료까지 가면 정산을 해야 된다. 그 다음에 정산 금액이 얼마가 된다. 그 다음에 취소가 들어왔다 라고 하게 되면 그 중간 과정에서 누락된 과정 없이 이런 트랜잭션이 일어나야겠죠. 그래서 ACID 원칙 보장 이런 게 있는데 원자성 전부 실행되거나 전부 실패해야 된다. 만약에 카드 결제는 일어났는데 실제로 쇼핑몰에서 주문 완료가 되지 않았다 라고 하게 되면 문제가 되기 때문에 전부 실행되거나 전부 실패해야 된다. 그 다음에 일관성 트랜잭션 후에도 DB 상태가 일관적이고 고립성 트랜잭션 간의 영향을 최소화하고 그 다음에 지속성은 성공한 트랜잭션은 영구적으로 저장을 하게 됩니다. 그래서 DBMS, RDBMS의 검색에서는 보통 SQL, Structured Query Language, 보통 SQL이라고 부르기도 하죠. SQL 랭기지를 사용을 하게 되는데 데이터 정의 조작 제어로 나뉘고 그 다음에 셀렉트문 사용하게 되면 데이터 검색, 웨어 조건을 사용하게 되면 정확한 조건 필터링 그래서 우리가 게시판에서 뭔가 검색어를 입력한다고 하게 되면 이런 식으로 작성자 이름은 뭐가 들어간다. 이렇게 검색을 하면 like 연산을 웨어 구문에 쓸 수도 있고요. 그 다음에 30살인 사람을 찾는다. 그 다음에 가격이 100원에서 200원짜리의 제품을 찾는다. 이런 식으로 웨어절에다가 정확한 키워드를 넣거나 조건을 넣어서 필터링을 하게 됩니다. RDBMS에서 여러 테이블이 있다고 하게 되면 이런 키값을 사용을 해서 조인 연산을 해서 다양한 테이블들을 조합해서 조회를 하는데 고객 주문 혹은 주문 제품 이런 식으로 조인을 해서 사용을 하게 됩니다. 그 다음에 RDBMS에서 인덱싱을 사용하게 되면 우리가 검색을 할 때 훨씬 빠르게 가져올 수 있어요. 그래서 검색 성능 향상을 위한 기술로 이런 비트리 인덱스를 사용을 한다. 그 다음에 해시 인덱스를 사용하게 되면 특정 값에 대한 빠른 검색이 가능하다.

이렇게 보실 수가 있고요.

IDBMS 테이블 예시를 보게 되면 예를 들어서 직원 테이블이다. 제가 대학교 때 데이터베이스 수업에서 들었던 예시도 딱 이거였었는데요. 직원 아이디, 직원 이름, 그 다음에 부서, 그 다음에 셀러리, 급여가 있다고 하게 되면 이렇게 컬럼 명과 그 다음에 데이터 타입, 아이디 값은 숫자, 그 다음에 employee name이나 department 같은 경우에는 캐릭터로 되어 있다. 그 다음에 숫자나 문자 같은 경우에도 길이가 어느 정도가 된다. 이런 것들을 스키마에다가 저장을 해두고 그래서 우리가 만약에 게시판에서 제목의 크기를 지정을 데이터베이스 지정을 해줬는데 그것보다 더 크게 입력을 한다라고 하게 되면 SQL 오류가 발생을 하게 되죠. 그래서 그런 것들 이제 데이터 유효성 검증을 하고 데이터베이스에 입력을 해주게 됩니다.

RDBMS 쿼리 예시로 이런 식으로 Select From Where를 사용하게 되면 특정 조건에 맞는 데이터를 갖고 오게 되는데

우리가 인베딩하는 데이터는 이런 식으로 테이블 형태의 데이터라기보다는 그 데이터도 행렬 형태로 되어 있기는 해요. 하지만 데이터의 타입이 이렇게 여러 가지가 아니라 인베딩된 데이터는 다 숫자로 되어 있고 그 다음에 우리가 유사도 검색을 하게 되기 때문에

이 RDBMS하고는 좀 다르다라고 볼 수가 있고 그 다음에 검색을 할 때도 이렇게 정확하게 같은 값을 가져오기보다는 유사한 값을 가져오게 됩니다.

RDBMS는 정확히 같은 값을 찾거나 하게 되면 여기에서 그 디파트먼트가 세일즈인 부서만 갖고 오겠다라고 하게 되면 세일즈 부서인 사람들만 이렇게 갖고 오게 된다.

RDBMS 같은 경우에는 데이터 무결성이나 일관성을 보장해주고 표준화된 SQL 사용으로 접근이 용이하고 정형 데이터, 표로된 데이터 관리에 매우 효과적입니다. 그 다음에 성숙한 기술, 풍부한 생태계 굉장히 오랫동안 사용을 해왔기 때문에 복잡한 관계의 표현이라든지 여러 테이블을 연결해서 쓸 수가 있습니다. 근데 RDBMS를 생성형 모델에 사용을 하게 되면 비정형 데이터 텍스트나 이미지 등을 처리가 어렵고 그 다음에 데이터의 의미 기반 검색을 할 때 이런 것들이 조금 어렵고요. 그 다음에 대규모 데이터에서 수평적인 확장이 어렵고 그 다음에 유연하지 못한 스키마 변경 이런 것들이 생성형 모델에 사용했을 때 아쉬운 점이다 라고 볼 수가 있어요. RDBMS 같은 경우에는 정말 다양한 비즈니스에 쓰이죠. 우리가 알고 있는 온라인 서비스, 비즈니스 대부분은 쓰인다. 은행 시스템, 예약 시스템, 고객 관리, ERP, 그 다음에 전자상거래, 인사급여관리 등 정말 다양한 곳에 쓰이고 RDBMS 같은 경우에도 제품군이 굉장히 많다. 오라클, MySQL, MariaDB, PostgresQL, MySQL, MySQL 서버, MariaDB, SQLite. 그래서 MySQL에서 파생된 오픈소스인데 이게 만든 사람의 딸 이름이라고 하죠. 그래서 My라는 이름과 Maria라는 거는 그 사람의 딸의 이름을 따서 데이터베이스 이름을 지었다고 합니다. RDBMS가 정형 데이터를 위한 데이터베이스라면 벡터 데이터베이스는 비정형 데이터를 위한 데이터베이스라고 볼 수가 있는데요. 텍스트, 이미지, 비디오 등 비전형 데이터가 급증하고 있고 그 다음에 인베딩을 통해서 AI 모델에 있는 텍스트라든지 이미지 데이터들을 벡터화를 하게 되죠 기존의 RDBMS로는 이런 의미 기반의 검색에 한계가 있기 때문에 데이터의 유사성을 기준으로 검색을 해야 되는 필요성이 증대가 되고 있습니다 그래서 새로운 벡터 DB들도 많이 나오고 있다고 볼 수 있을 것 같아요

네 텐서플로우 인베딩 프로젝터인데요. 여기에서 인베딩이라는 거는 우리가 단어 하나를 이제 골라요. 그러면은 이 단어하고 가까운 거리에 있는 단어가 무엇이냐 이런 것들을 다차원 공간에다가 이렇게 이제 표현을 할 수가 있는데 지금 3차원 공간에다가 차원 축소를 해가지고 보여줬을 때 어떤 단어가 멀고 가깝다 이런 것들을 이제 표현을 하게 되는데

여기 넣어준 데이터들을 보게 되면은 이런 식으로 숫자로 밀집 벡터로 인베딩을 해서 넣어주고 그 다음에 메타데이터 같이 넣어준 것을 보실 수가 있어요. 우리가 이렇게 인베딩된 데이터하고 메타데이터를 넣어주게 되면

우리가 가지고 있는 데이터로도 이런 식으로 인베딩 데이터를 시각화해서 볼 수가 있죠.

인베딩된 데이터는 여기 예시에서 보는 것처럼 이런 밀집 벡터, 숫자들로 구성이 되어 있다. 그래서 기존에 있었던 RDBMS 보다는 벡터 DB로 관리를 하는 게 검색하는 방식도 다르기 때문에 저장하는 방식도 달라져야 된다라고 볼 수가 있겠죠.

그래서 벡터 임베딩 같은 경우에는 앞에서 봤었던 것처럼 텍스트나 이미지에서 그 벡터를 추출을 해서 유사한 의미나 특징을 가진 데이터는 벡터 공간에서 가까운 거리에 위치하고 있다. 그리고 벡터화된 방식도 표 형태로 우리가 행렬 형태로 볼 수 있기는 하지만 검색 방법이나 저장 방법이 기존의 광경 데이터베이스와는 달라져야 된다고 볼 수가 있습니다. 그래서 벡터 DB는 이 인베딩 벡터를 효율적으로 저장하고 검색하는 데이터베이스다 라고 볼 수가 있어요. 벡터 DB는 벡터 인베딩 데이터를 저장 관리에 검색하는 특화 DB고 핵심 기능 같은 경우에는 쿼리 벡터와 유사한 벡터 검색을 하게 됩니다. 고차원 공간에서의 빠른 유사도 검색에 대한 성능이 중요하게 되는데 비정형 데이터의 의미 검색에 활용이 된다.

그래서 여기 인베딩 프로젝터에서 보시는 것처럼

우리가 밀크를 검색을 했다라든지 여기 아무 단어나 아무거나 검색을 해보도록 할게요. 아무 단어나 이렇게 검색을 해보면 그 단어와 가까운 단어가 무엇인지를 이렇게 순서로 찾아주게 돼요. 그래서 거리를 구할 때 코사인 방식을 사용할 수도 있고 아니면 유클리드 거리를 구해서 사용을 할 수도 있습니다.

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

그래서 이런 임베딩 프로젝터를 봤을 때도

이런 임베딩 데이터와 메타데이터로 구성이 되어 있다. 벡터 데이터, 메타 데이터로 구성이 되어 있죠.

그래서 이 데이터 구조를 벡터와 관련된 메타 데이터를 함께 관리를 하게 되고 메타 데이터 대부분은 유연한 구조로 지원을 하게 됩니다. 주요 기능으로는 유사도를 검색을 하게 된다.

여기 텐서플로우 인베딩 프로젝터에서도 우리가 단어 하나 이렇게 클릭하게 되면 그거와 유사도가 높은 것을 보여주는 것처럼

쿼리 벡터와 디빈의 벡터 간의 거리나 유사도를 계산을 하고 거리가 가장 가까운 상위 k계의 벡터를 반환을 해주게 된다.

지금 여기에서도 거리가 가까운 상위 k계, n계 이렇게 보실 수가 있죠. 상위 몇 개의 데이터를 보여주고 있다. 이렇게 보실 수가 있는데 여기에서도 보면 네어리스트 포인트라고 적혀져 있어요.

여기 Approximated Nearest Neighbor를 보시게 되면 가까운 이웃을 근사하고 추정하는 이런 검색 방식이라고 볼 수가 있는데 고차원 벡터 공간에서 정확한 최근적 이웃에 대한 검색은 매우 느리기 때문에 100% 정확하지 않지만 매우 빠른 속도로 충분히 유사한 이웃을 찾는 이런 알고리즘을 사용을 하게 되고요. 그 다음에 유사도나 거리 측정을 할 때 코사인 유사도, 그 다음에 유클리드 거리 내적 등을 사용을 하게 됩니다.

그래서 앞에서 이 인베딩 프로젝터에서 봤을 때도 코사인이나 유클리드 거리를 사용하고 있다는 것을 보실 수가 있어요.

그리고 이제 벡터 DBA 인덱싱 같은 경우에는 이런 유사도 검색 속도 향상을 위한 벡터 특화 인덱스를 사용을 하게 되는데 대표적인 알고리즘으로는 그래프 기반, 클러스터링 기반, 해싱 기반, 그 다음에 벡터 압축 기반으로 이렇게 볼 수가 있습니다. 그리고 이제 벡터 DBA 확장성하고 일관성을 보면 수평적 확장이 용이하게 설계를 하고요. 그 다음에 일관성 모델 같은 경우에는 강한 일관성보다는 최종 일관성을 허용하는 경우가 많다라고 볼 수가 있습니다.

그 다음에 벡터 데이터, JSON 데이터 예시를 보게 되면 벡터 아이디, 그 다음에 인베딩된 밀집 벡터에 대한 숫자과 그 다음에 메타 데이터에 대한 정보를 함께 가지고 있다. 그래서 검색과 필터링에 사용할 메타 데이터를 함께 저장하는 형태로 구성이 되어 있습니다. 그래서 벡터 데이터에서 이제 쿼리를 한다고 하게 되면은 우리가 뭐 인베딩, 이미지에서 찾거나 텍스트에서 찾을 때 유사한 데이터를 찾거나 아니면 필터링을 하게 되는데 탑 K 해가지고 가장 유사한 거 상위 5개, 10개 이런 식으로 찾아오게 된다라고 볼 수가 있어요.

벡터 DB 같은 경우에는 비정형 데이터의 의미 기반 검색에 탁월하고 그 다음에 대규모 데이터 어셋의 고속 유사성 검색, 그 다음에 이런 인공지능 모델과의 연동이 용이하고 수평적인 확장이나 추천, 검색, RAG 등 다양한 응용 AI를 지원을 하고 있습니다. 그래서 이 유사도라는 것을 조금 다르게 응용하게 되면 원래 유사도라는 것은 추천 시스템에 더 많이 사용을 했죠. 검색에서도 활용을 하고 그리고 Rage 같은 경우에는 최근에 검색 증강 생성을 AI 모델에 함께 사용을 하면서 할루시네이션을 줄일 때 주로 사용하는 최근의 정보를 찾아올 때 사용하는 게 검색 증강 생성 기법이죠. 벡터 DB는 이런 관계형 데이터베이스의 단점을 보완을 하지만 정확한 값 매칭에는 비효율적이다. 그래서 관계형 데이터베이스, 정확한 값을 매칭하고자 할 때는 관계형 데이터베이스를 사용하게 되고요. 복잡한 관계형 커리 등을 지원하거나 트랜잭션 기능이 RDBMS보다 약하고 상대적으로 새로운 기술이고 생태계가 계속 발전하고 있다. 그 다음에 인비딩 모델의 의존성이 커서 모델 성능이 검색의 품질에 큰 영향을 차지하게는 되지만 그래서 벡터 DB도 속도라든지 유사도 검색이라든지 이런 것들이 꾸준히 지금 연구가 되고 있다. 이렇게 볼 수가 있겠죠. 벡터 DB 주요 활용 사례를 보면 추천 시스템에 주로 사용이 될 수가 있고요. 유사한 상품, 연관 상품, 뉴스, 비디오, 음악 이런 추천 시스템이라든지 지식 검색, 이미지 비디오 검색이나 챗봇, 가상 비서, 금융, 사기탐지, 이상거래감지 등 여러가지 활용을 해볼 수가 있을 거예요. 대표적인 벡터 DB로는 파인콘이나 밀버스, 크로마 여러가지가 있는데 FICE도 많이 사용을 하기는 하지만 FICE 같은 경우에는 DB 자체라기보다는 Vector Store라고 볼 수가 있고요. 그래서 인메모리 상태로 메모리에 저장을 해서 사용을 하게 됩니다.

이거는 랭테인에 올라온 리포트 문서 중에 하나인데요.

2024년 Vector Store 순위인데 크로마가 1위이고 그 다음에 이제 파이스, 파인콘, 피지 벡터 이런 순위라고 보실 수가 있어요.

그래서 이제 벡터 DB는 벡터 검색 라이브러리하고 이제 차이점, 파이스와의 차이점을 보게 되면 벡터 DB는 이제 인메모리로 관리하는 벡터 검색 라이브러리도 있는데요. 벡터 DB 같은 경우에는 이런 이제 영속성이나 트랜젝션, 메타데이터 관리를 지원을 하고 그 다음에 API를 제공한다든지 관리용 서비스, 사용자 관리 기능 등을 제공하고 있는 차이점들이 있습니다. 물론 제품에 따라서 조금씩 차이가 있고요. 벡터 검색 라이브러리인 FICE, 페이스북 AI 시뮬러리티 서치 이름에도 유사도 검색이 들어가게 된다. 그래서 메타 AI에서 개발한 오픈소스 라이브러리이고 dense vector, 밀집한 빼곡한 그 벡터의 효율적인 유사성 검색이나 클러스터링에 사용이 되고 대규모 데이터셋 처리에도 최적화할 수가 있다. FICE 같은 경우에는 벡터 DB의 내부에서 사용이 되는 경우도 있습니다. FICE는 고성능 C++로 구현이 되어 있고 Python의 바인딩을 제공하고 있고 다양한 인덱싱, 알고리즘, 그 다음에 GPU를 지원한다든지 메모리를 효율적으로 사용하거나 인덱스를 조합을 해서 사용할 수도 있습니다. 이 FICE는 데이터베이스라기보다는 라이브러리라고 볼 수가 있는데요. 주로 인메모리로 처리를 하고 데이터 영속성이나 트랜잭션 기능이 없고 메타데이터를 저장하고 필터링하는 기능이 제한적이다. 그 다음에 관리형 API나 사용자 관리 기능이 없고 개발자가 직접 데이터를 로딩하고 인덱스를 빌드하고 API를 구축할 필요가 있다. FICE가 라이브러리로서의 한계는 인메모리 기반이라서 파일 저장이나 로드 등은 수동으로 해야 되고 자동 저장이나 복원 기능이라든지 트랜잭션 기능이라든지 인덱싱, 저장, 로딩, API 구축 등에 대한 한계점이 있다고 볼 수 있습니다. 그래서 FICE하고 벡터 데이터베이스 같은 경우에는 이런 관리나 검색, 효율적인 측면에서 봤을 때 벡터 데이터베이스를 직접 저장을 해놓고 사용하는 게 좀 더 효율적일 수도 있습니다. 그래서 파이스 같은 경우에는 고성능 유사도 검색, 그 다음에 다양한 인덱싱 알고리즘, 그 다음에 GPU 가속이라든지 메모리 효율성, 그 다음에 파이썬 C++의 API를 제공하고 있다. 이렇게 보실 수가 있고요. 그 다음에 대규모 이미지나 비디오 검색이라든지 유사도 검색, 그 다음에 AI 모델에서의 인베딩 벡터 관리라든지 대규모 데이터셋의 클러스터링 분류 등에 활용이 되고 있다고 볼 수 있습니다.

FICE를 설치를 하고 사용을 하게 되면 우리가 유사도 검색해가지고 상위 몇 개 이런 식으로 검색을 해서 가져올 수가 있다.

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

랭체인 리포트를 보게 되면 1위에 있는 게 크로마 DB인데요. 크로마 DB에 대해서도 같이 알아보도록 하겠습니다.

크로마 DB란 오픈소스 벡터 데이터베이스로 LLM 워크플로우에 최적화된 데이터베이스라고 볼 수가 있는데요. PIP 인스톨 크로마 DB로 간단하게 설치가 가능합니다. 그 다음에 이제 랭체인이라든지 라마 인덱스와 연동이 용이하다라는 장점이 있고요. 그래서 랭체인과도 이제 연동이 가능하고 이제 라마 인덱스하고도 이제 연동이 가능한데 이 크로마 DB는 랭체인의 벡터 스토어로 이제 사용이 되게 되면은 문서 인베딩 저장 유사동 검색 LLM 응답에 활용이 되게 됩니다. 빠르고 간결한 레그 파이프라인을 구현을 할 때 사용이 되고요. 이 벡터 데이터베이스의 데이터는 저장 인덱싱 검색 등의 기능을 제공을 해주고 데이터의 용속성을 보장을 한다든지 트랜잭션 지원 여부 같은 경우에는 DB에 따라서 좀 차이가 있다고 볼 수가 있습니다. 그 다음에 데이터베이스에 따라서 RESTful API나 SDK를 통한 데이터 접근이 가능하고 그 다음에 사용자 친화적인 인터페이스 등을 제공하고 있다고 볼 수가 있어요. 그래서 RDBMS하고 벡터 DB하고 비교를 해보게 되면은 정형 데이터냐 비정형 데이터냐 그 다음에 완전히 정확한 키워드 검색을 할 거냐 아니면 유사도 검색을 할 거냐에 따라서도 차이가 있고요. 그 다음에 데이터 처리 방식에서도 정형 데이터를 저장할 건지 임베딩된 고차원 데이터를 저장을 할 건지 스키마가 엄격하냐 유연하냐 그 다음에 데이터 관계가 명시적으로 조인을 하냐 아니면 안목적인 유사성 거리 기반으로 하냐 이런 차이점이 있습니다. 그 다음에 검색 메커니즘을 보게 되면 RDBMS 같은 경우에는 조건 필터링으로 완전히 정확하고 범위를 지정해 준다든지 하지만 벡터 DB는 유사성 기반으로 거리 기반으로 가장 가까운 것을 가져온다고 볼 수 있습니다. 그 다음에 시스템 특성으로는 RDBMS 같은 경우에 수직 확장 중심이라면 벡터 DB는 수평 확장이 용이하고요. 검색 증강 생성 레그 기술하고 DB의 역할은 생성형 AI의 한계를 할루시네이션을 극복해주는 핵심 기술이라고 볼 수가 있는데요. 생성형 AI의 한계점이라고 보게 되면 환각형상이라든지 최신 정보가 부족하고 정보의 출처가 불분명하다든지 특정 도메인 지식이 부족하다라는 이런 한계점이 있습니다 그래서 그 레그는 LLM이 답변을 생성하기 전에 관련 정보를 외부 지식 소스에서 검색하고 참고해서 정확하고 신뢰성 있는 답변을 생성을 해주게 되죠 레그를 사용하게 되면 기존에는 잘못된 답변이라든지 최신 정보를 제대로 답변하지 못한다든지 근거 없는 답변을 한다든지 이런 것들을 방지해서 답변의 신뢰도를 더 높일 수 있다고 볼 수 있습니다.

랭체인 리포트의 첫 번째에 나오는 크로마 DB의 웹사이트인데요. 이 크로마 DB에서 보게 되면 우리가 AI 어플리케이션에서 쿼리를 하게 되면요. 이렇게 뭔가 검색을 해서 가져오게 되고 검색된 데이터를 이런 식으로 인베딩해서 벡터화해서 벡터 DB에다가 저장을 해주고 그 다음에 데이터를 가져오는데 유사도가 높은 것을 가지고 와서 프롬프트 쿼리와 함께 넣어주게 되면 아웃풋 조금 더 신뢰 있는 답변을 얻게 됩니다.

RAG 기본 흐름을 보게 되면 사용자가 질문 입력하고 정보 검색 관련 정보를 DB에서 찾고 프롬프트 증강, 그 어그멘테이션을 해주고 그 다음에 답변을 생성을 해주게 된다.

RAG의 기본 흐름은 사용자가 질문을 하고 검색해서 관련 정보를 DB에다가 요청을 해서 검색된 정보와 원래 질문을 같이 넣어서 프롬프트를 증강시켜주고 증강된 프롬프트를 LLM에 넣어서 신뢰에 있는 최종 답변을 생성을 해주게 됩니다.

그래서 RAG에서의 데이터베이스의 역할은 핵심은 검색이다. 대규모 지식 소스를 효율적으로 저장하고 가장 관련성 높은 정보를 빠르고 정확하게 찾아내는 역할을 하고 어떤 데이터베이스를 사용하느냐가 이런 RAG 성능에도 영향을 줄 수가 있겠죠. 그래서 이 벡터디비를 RAG에서 쓸 때 핵심 의미 검색 엔진이다라고 볼 수가 있는데 질문을 벡터로 변환, 인베딩을 해주고 유사 벡터를 검색을 하고 유사 벡터에서 원하는 원본 정보를 반환을 해서 RAG의 검색 품질을 결정하는 핵심 요소가 되게 된다. 그래서 만약에 Q&A 챗봇을 구현한다고 하게 되면 수많은 FAQ 문서나 내부 지식 문서를 미리 벡터 DB에 인베딩해서 저장하고 사용자가 질문을 했을 때 질문과 가장 유사한 K계의 문서 조각을 VectorDB에서 검색을 해서 검색된 텍스트를 기반으로 LLM이 답변을 생성을 해주게 됩니다. 그러면 RDBMS는 사용을 안 하는 거냐 라고 보게 되면 RDBMS 같은 경우에도 보존한 신뢰도 강화로 함께 사용을 한다. 그래서 Vector 검색만으로는 부족한 부분을 보완을 해주고 VectorDB와 함께 사용해서 RAG 시스템의 완성도를 높이게 됩니다. 메타데이터를 필터링하거나 구조화된 정보 조회하거나 사용자 세션 관리 등에 활용을 하고요. RDBMS에서 메타데이터를 필터링 할 때는 정확한 조건으로 결과를 필터링해서 완전히 유사한 것만 갖고 오는 게 아니라 완전히 정확한 것들을 가지고 오고자 할 때를 RDBMS 사용하고 유사한 내용 검색하고자 할 때는 벡터 DB를 가져온다. 그래서 RDBMS는 1년 내 기술팀 이런 조건을 필터링하고 벡터 DB는 유사한 조건을 가져옵니다. 그래서 RDBMS 같은 경우에는 구조화된 정보를 조회하는 데 주로 사용하고 이 레그 시스템이 RDBMS SQL 쿼리를 실행을 해서 내 계정에 포인트 잔액은 얼마냐 이런 구체적인 숫자를 물어볼 때 실제로 데이터베이스에 가서 포인트를 조회해오고 그 다음에 상품의 현재 재고 현황을 알려달라. 그 다음 그러면은 프로덕트 테이블에서 재고 현황을 조회를 해서 가져오게 되죠. 그리고 이제 사용자 세션 로그 관리 할 때도 RDBMS를 사용을 하고

그래서 이 레그 시스템 내에서 RDBMS도 사용하고 이제 벡터 데이터베이스도 사용을 해서 정확한 필터링이 필요한 건 RDBMS 그 다음 유사한 컨텐츠를 갖고 와야 될 때는 벡터 DB를 사용해서 검색을 해와서 그 다음에 프롬프트에 조합을 해서 모델에 놓고 최종 답변을 얻게 됩니다.

이렇게 두 기술의 장점을 합쳐서 하이브리드 접근으로 답변을 얻게 되면 좀 더 신뢰 있는 답변을 얻을 수가 있고요. 이런 하이브리드 접근이 필요한 것은 정형 데이터와 비정형 데이터가 실제 비즈니스에 혼재하기 때문에 정확한 조건 검색과 의미 기반의 유사성 검색이 모두 필요하다고 볼 수가 있습니다. 그래서 rdbms의 확장으로 PostgreSQL하고 pg벡터의 확장 기능을 사용한다든지 하게 되면 하나의 DB에서 SQL 쿼리와 벡터 유사도 검색을 동시에 수행을 할 수가 있습니다. 그 다음에 장점은 익숙한 rdbms 환경에서 단순한 통합을 할 수 있다는 거 하지만 단점으로는 대규모 벡터 검색이라든지 확장성에 한계가 있다고 볼 수가 있습니다. 접근 방식은 별도 데이터베이스로 접근을 한다고 봤을 때 rdbms와 벡터디비를 각각 구축을 하고 어플리케이션 레벨에서 두 데이터베이스에 각각 접근을 해서 사용을 해야겠죠. 장점으로는 각 데이터베이스의 전문성을 활용할 수 있다면 단점은 시스템 구성이나 관리 복잡성이 증가한다는 단점이 있겠죠. 그래서 하이브리드 DB 방식으로 하나의 시스템에서 네이티브하게 데이터 처리와 벡터 검색 모두 고성능으로 지원할 수 있는 이런 솔루션들이 등장하고 있다고 볼 수 있을 것 같아요. 그 다음에 이런 하이브리드 DB 같은 경우에는 통합이 용이하고 잠재적으로 고성능이고 기술 성숙도나 벡터 종속성 같은 것들이 우려될 수도 있다는 게 단점이라면 단점입니다. 그래서 벡터 검색 기능은 점차 데이터베이스의 기본 기능으로 통합될 가능성이 있고 데이터베이스에서 이런 벡터 데이터베이스를 다룰 수 있는 기능들을 추가하고 있다. 그래서 RDBMS와 벡터 DB 간의 경계가 모호해질 수도 있고 데이터 유형에 따른 최적의 저장이나 검색 전략에 대한 중요성이 증대되고 있고 하이브리드 및 통합 솔루션이 계속 발전이 될 것으로 보여집니다. RDBMS 같은 경우에는 여전히 강력하다라고 볼 수가 있고요. 정형 데이터를 다룰 때 트랜잭션이 필요할 때 정확하고 일관된 관리에 필수적으로 사용이 되고요. 벡터 DB 같은 경우에는 비경영 데이터의 의미를 이해하고 검색할 때 필요하다고 볼 수가 있을 것 같아요. RDBMS와 벡터 DB의 차이점에 대해서 알아봤는데요. 이 두 데이터베이스는 경쟁 관계가 아닌 상호 보완적인 관계로 서로의 강점을 활용해서 시너지를 창출할 수 있다고 볼 수가 있습니다. 최진 시스템은 두 기술을 함께 사용해서 정확성과 의미적 활용을 모두 달성을 하고요.

여기 안드레이 카파시 바이브 코딩이라는 단어가 요즘 화제가 되고 있는데요 안드레이 카파시의 영상들이 대부분 길어요 2시간 3시간씩 되는 영상들이 많이 있습니다 이런 영상들을 기존에 채찌비티라든지 다른 생성형 AI에게 이 영상 전문을 번역해줘 혹은 전문에 대한 이런 자막 데이터를 넣어주고 번역을 해달라고 하게 되면 보통 이제 토큰 수 제한에 걸려서 제대로 안 나온다든지 답변을 주더라도 요약을 해서 나온다든지 전문을 그대로 번역을 해준다든지 하는 것들이 약간 좀 아쉬운 부분이 있습니다. 그러면 만약에 여기서 벡터 데이터베이스를 활용을 한다라고 하면 어떻게 활용을 할지에 대해서 잠깐 소개를 해보도록 하겠습니다.

유튜브에서 자막을 수집을 해왔어요. 지금 아까 봤었던 안드레이 카파씨의 영상에 대한 자막을 이렇게 수집을 해왔다. 그래서 여기 보시면 이제 시간 타임 코드가 있는 것도 있고 없는 것도 있는데 지금 보시면 자막이 굉장히 깁니다. 근데 이 긴 자막을 그대로 이제 생성형 AI에다가 넣어주게 되면은 토큰 수 제한으로 내용이 전부 다 번역이 되지 않거나 잘려서 나오는 경우가 많아요. 최근 노트북 LM 같은 경우에는 이런 긴 영상 같은 경우에도 잘 요약을 해주고 그 다음에 번역도 어느 정도 해주기는 하는데요. 내가 직접 이거를 한번 번역을 해보면서 VectorDB와 RDBMS를 어떻게 활용을 해야 될지를 찾아본다면 일단 이렇게 자막을 수집을 해왔다라고 보게 되면요. 그 다음으로 이런 OpenAI API를 활용을 해서 우리가 번역을 할 수가 있겠죠. 이제 번역을 할 때 토큰 수를 계산을 해서 일부 토큰들 수를 계산해서 토큰 수가 넘치지 않게 안전한 토큰 수를 계산을 해서 잘라서 텍스트를 번역을 합니다. 그래서 이렇게 셋집이 API를 OpenAI API를 사용을 해서 보내는데 이때 이 번역을 할 때 저는 데이터베이스를 활용을 하는 것을 꼭 권장을 하는데요. 왜냐하면 우리가 번역을 한다고 하게 되면 일단 얘를 토큰화를 해야겠죠. 토큰 수가 제한이 있기 때문에 얘를 청크로 나눠서 관리를 하게 돼요. 그럼 청크로 나누는 것도 기법이 굉장히 여러 가지가 있는데 일단은 여기에서는 달락 기준이나 글자 수 기준으로 나눈다고 해도 이렇게 여러 개로 나누게 돼요. 그러면 API를 호출을 하다가 중간에 API가 끊길 수가 있잖아요. 이런 식으로 번역을 하는데 우리가 이 API를 계속 호출을 하는데 이 API를 한두 번 호출을 하는 것도 아니고 API를 호출을 하고 나서 그 호출된 결과도 관리를 해야 되는데 그럴 때는 차라리 데이터베이스에다가 답변을 받은 API로 답변을 받은 내용을 하나씩 하나씩 업데이트하면서 관리하는 것을 추천을 합니다. 그래서 이 데이터베이스 열어서 보게 되면 일단 오리지널 텍스트가 있다고 하게 되면 오리지널 텍스트에서 이 번역을 한 것을 하나씩 하나씩 API 답변을 받을 때마다 업데이트를 해준다 라고 하게 되면 만약에 중간에 우리가 API를 보내다가 끊겼어요 그러면 처음부터 다시 요청을 하게 되면 API 과금이 발생을 하고 그 다음에 시간도 오래 걸리게 되죠 만약에 중간에 보내다가 끊겼다라든지 하게 되면은 이 번역이 되지 않은 데부터 다시 번역을 해주면 되죠. 그러면은 이 트랜슬레이션이라는 이 컬럼에 데이터가 없는 것들 위주로 API를 호출을 해서 거기에서 이제 API 응답 결과를 받게 되면은 그 응답 받은 결과 여기 리스판스 받은 내용을 업데이트해서 이제 하나씩 하나씩 넣어 주면은 우리가 api 비용을 더 효율적으로 이제 사용할 수 있고 api 호출도 훨씬 더 효율적으로 관리할 수가 있다 라고 볼 수가 있어요 우리가 자막 내용을 이렇게 텍스트 형태로 저장을 했다 할지라도 이걸 청크해서 api 를 따로 호출을 해야 된다 라고 하게 되면은 저는 데이터베이스 형태로 관리하는 것을 추천을 드립니다 SQLite 데이터베이스 같은 경우에는 따로 설치할 필요가 없죠 파이썬에 내장이 되어 있기 때문에 파이썬에 내장이 되어 있는 SQLite 데이터베이스 에다가 오리지널 텍스트를 먼저 넣어주고 그 다음에 api 호출에서 받은 응답 결과를 하나씩 하나씩 채워 나가게 되면은 이렇게 API를 어디까지 주고 받았는지를 우리가 조금 더 확실하게 파악을 해 볼 수가 있죠. 그 다음에 여기에서 우리가 뭔가 검색을 한다든지 요약을 한다든지 질의응답을 하고 싶다라고 하게 되면 이렇게 만들어준 번역한 내용들을 가지고 벡터 DB에 저장을 해서 사용할 수 있을 거예요. 벡터 DB로는 크로마 DB에다가 벡터화해서 넣어주게 되면 이런 식으로 데이터베이스 안에 데이터들이 이렇게 들어가 있는 것을 확인해 보실 수가 있어요. 그래서 이런 식으로 데이터들이 저장이 되어 있다는 것을 확인해 보실 수가 있어요. 그럼 이렇게 번역한 내용을 한번 웹페이지 형태로 보고 싶어요. 그럼 이제 안드레이 카파씨의 영상을 번역을 한 건데 바이브 코딩을 해서 이렇게 서버를 하나 띄워서 보도록 하겠습니다.

번역 결과를 html 형태로 만들어서 서버를 띄워서 한번 봤는데요. 그냥 글자수 기준으로 이제 청크를 했기 때문에 이런 식으로 글자가 뒤에 잘렸다. 그래서 you go to the google call app 이 이어져서 번역이 돼야 되는데 이 텍스트가 이어져서 번역이 되지 않았어요. 그래서 우리가 텍스트 데이터를 인베딩 할 때는 보통 청크를 여러 가지 방법으로 해주는데 이 청크를 할 때 윈도우 방식으로 밀면서 볼 때 이렇게 겹쳐서 청크를 하기도 합니다. 그렇게 되면 이 중간에 이렇게 잘리는 부분 그래서 맥락이 이상하게 번역이 되죠. You go to the Google Core 앱, Google Core 앱으로 가서 뭘 해라 이런 건데 그래서 여러분이 갈 때마다 Google Core 앱에서 그 비디오를 보면 이런 식으로 조금 이상하게 번역이 되죠. 나중에 번역하고 나서 이걸 하나로 합치게 되면 원문하고 번역하고 합쳐서 비교를 해 볼 수가 있는데 이렇게 잘게 토크나를 하게 되면 원문하고 번역된 거하고 이렇게 해서 비교를 해 보실 수가 있는데 중간중간에 이렇게 좀 끊겨 있는 부분이 약간 어색하다. 그래서 완전히 이제 다 합쳐주고 이 원문 데이터를 조금 더 정제한 다음에 문단 단위나 의미 단위로 청크를 하고 번역을 하게 되면 훨씬 더 의미 있게 번역을 해 보실 수가 있겠죠.

그리고 이렇게 번역된 내용을 가지고 와서 우리가 데이터베이스에 넣고 뭔가 이제 토크나란 무엇인가 이런 질문을 해 볼 수도 있겠죠. 스터디에 있는 내용을 질문을 했는데요. 여기에서 토크나란 무엇인가? 이 영상에 있는 내용으로 질문을 했더니 토크나란 언어모델에서 사용되는 단어들을 작은 단위로 분리하는 과정을 말한다. 이 과정은 복잡하고 헷갈리며 주의해야 할 숨겨진 문제들이 많기 때문에 중요한 작업이다. 많은 이상한 문제들이 토크나에 기인하기 때문에 이해하고 실제로 적용하는 것이 중요하다. 라는 것을 문서에서 찾아왔습니다. 그래서 벡터디비에서 검색을 해서 찾아왔는데요. 이 벡터디비하고 관계형 데이터베이스는 따로 사용하는 게 아니라 우리가 같이 사용을 하게 된다. 그래서 정확한 내용을 찾을 때는 키워드 검색을 하거나 할 때는 이런 RDBMS를 사용을 하고요. 그리고 우리가 유사도 검색을 해서 비싼 문서를 찾아오거나 할 때는 이런 크로마 DB와 같은 벡터 DB를 사용하게 됩니다. 그래서 데이터 유형과 처리 목적에 맞는 데이터베이스를 선택을 해서 정확도냐 유사도냐 혹은 두 가지가 다 필요하냐에 따라서 하이브리드 접근 방식을 활용을 해서 다양한 비즈니스 문제 해결에 활용을 해보시면 좋겠습니다. 감사합니다.