[임베딩] 백엔드 관점에서 보는 임베딩 파이프라인 분석
회사에서 갑자기 발표할 일이 생겼다. AI 사업을 시작하는 중인데, 기존에 다른 직원들은 AI 관련 업무를 하고 있지 않다보니 그에 대한 지식이 부족해서 내가 교육을 해야 한다는 것이다.
다만, 난 백엔드 개발자로 입사했기 때문에 개념적인 내용들은 최소한으로만 다루고, 동작 방식들을 백엔드적인 관점에서 분석을 중점으로 두고 발표해야만 했다.
어차피 AI 개념들에 대해서 설명하는건 GPT로 딸깍 하면 그만이니 사실상 큰 의미가 없긴 하다.
이 내용들을 나중에 다시 보기 위해서 여기에 기록해두고자 한다.
백엔드 관점에서 보는 임베딩의 과정의 메커니즘과
RAG의 개념, 백터DB 저장 파이프라인 분석
‘임베딩’을 통해 데이터를 다량의 숫자가 담긴 차원으로 보내서 벡터를 만들고, 이들 사이의 코사인 유사도를 계산해 데이터의 의미적 관계를 알아내는 전체 메커니즘, RAG의 개념, 그리고 벡터DB 저장시 실제로 임베딩 모델이 어떻게 호출이 되고 어떤 식으로 동작하는지 최종적으로 어떻게 저장되는지 백엔드 관점에서 분석한 내용입니다.
개요
- 임베딩과 관련된 개념 설명
- RAG의 개념 + 벡터DB 저장 파이프라인
1. 임베딩과 관련된 개념 설명
임베딩
- 데이터는 어떤 특징을 가지고 있는가? 를 분석해서, 그 데이터를 특정한 다차원 공간에 배치하는 작업
- 현대적인 AI 모델이 만들어지는 설계 순서: 차원 → 기법(코사인 유사도) → 임베딩 모델 학습
차원
- 데이터를 설명하는 기준의 개수
- 1차원: 선 (데이터 1개: 점수)
- 2차원: 면 (데이터 2개: 점수, 학년)
- 3차원: 입체 (데이터 3개: 점수, 학년, 나이)
- N차원: (데이터 N개: 점수, 학년, 나이, 지역, 성별, 로그인 시간 …)
코사인 유사도
- 좌표(벡터) 사이의 각도를 측정하여 각이 좁을수록 유사함을 표현하는 수학적 기법
이해하기 쉽게 2차원으로 표현한 코사인 유사도
기타와 피아노는 비슷한 방향으로 뻗어있습니다.
그렇기 때문에 두 화살표 사이 각도는 좁습니다.
즉, 비슷한 의미를 가진 단어라는 뜻입니다.
그에 반해 풋볼은 기타와 90도에 가까운 각도로 되어있습니다.
그 말은 기타라는 단어랑은 의미적으로 멀다는 뜻입니다.
이처럼 코사인 유사도는 방향이 중요합니다.
다차원 임베딩을 시각화 한 자료
중앙의 한 점이 기준이 되어 벡터들이 여러 방향으로 뻗어나간 걸 확인할 수 있습니다.
여기서 기타라는 단어를 찾아봤습니다.
찾아보니 기타 근처에 베이스, 피아노, 바이올린, 보컬 등 비슷한 단어들이 포진해있는 것을 알 수 있습니다.
비슷한 의미를 가져, 비슷한 방향으로 뻗어나갔기 때문에 모여있는 형태가 된 것입니다.
그리고 이 각도를 계산하기 위해 필요한 끝점의 좌표가 바로 벡터입니다.
이렇게 설계되어 AI 학습을 거쳐, 만들어진 것을 임베딩 모델이라고 합니다.
아래는 표준으로 많이 쓰이는 오픈AI의 임베딩 모델 공식 문서입니다.
2. RAG의 개념 + 벡터DB 저장 파이프라인
벡터 DB는 맥락과 유사도를 다루는 모든 서비스에서 사용이 가능합니다. 이번에는 그중에서도 RAG에 관해서 설명하겠습니다.
RAG
- AI가 학습하지 않은 우리 회사의 최신 데이터나 내부 문서를 벡터 DB에 저장해놓고, 검색해서,그 내용을 바탕으로 답변을 생성하는기술
벡터 DB 저장 과정
- 벡터 DB는 보통 문서(비정형 데이터)를 주로 다루기 때문에, 긴 문서를 적절하게 잘라서 저장하는 작업이 필요합니다.
- 그래서 보통 데이터(문서) -> 청킹 -> 벡터화 -> 벡터 DB 저장 순으로 이루어집니다.
청킹
- 만약에 저장해야 할 문서가 1000페이지가 된다면, 전체 내용을 한 번에 저장했을 시 추후 검색에서 효율이 많이 떨어지게 됩니다.
- 그때, 문서를 의미 있는 단위(단락, 페이지 등)로 쪼개는 작업을 청킹이라고 합니다.
다만, 문서를 일일이 확인하여 확실하게 의미있는 단위로 쪼개는 것은 힘듭니다.
그래서 일정 부분을 겹치게 하여 조각 사이의 맥락을 연결하는 청킹 오버랩을 사용합니다.
이처럼 조각 사이의 연결 고리를 만들면, 맥락 단절의 문제를 해결할 수 있습니다.
벡터 DB에 저장하는 데이터
- 청킹된데이터(원본 데이터)
- 청킹된 데이터 -> 임베딩 -> 벡터 데이터
- 메타 데이터(저장 날짜, 관련 문서 정보, 문서 페이지 번호 등)
벡터 데이터를 만드는 과정
- 임베딩 모델을 사용하여 데이터를 벡터 데이터로 만듭니다.
- 여러 방법이 있지만 여기서는 기본적인 API를 사용하여 만드는 것을 설명하겠습니다.
오픈AI 임베딩 API 공식 문서입니다.
좌측에는 요청/응답 파라미터 설명이, 우측에는 API 요청/응답 사용 예시가 나와있습니다. 해당 API를 실제로 호출해보겠습니다.
API 스펙에 맞춰 서버 주소, 변환할 데이터, API Key, 임베딩 모델을 지정하여 호출하니 data:embedding 값에 벡터 데이터로 변환되어 리턴되었습니다. 하단에 토큰값이 20이라고 써 있는것을 볼 수 있는데, 이건 모델이 ‘하이퍼정보 openai 임베딩 api 테스트입니다’ 라는 문장을 계산한 값 입니다.
토큰
- 컴퓨터가 텍스트를 이해하기 위해 의미있는 최소 단위로 자른 것
서비스마다, 모델마다 토큰 계산 방식은 달라 정확하지는 않지만 대략적으로 이렇게 나뉘어졌을 거라고 추측합니다. 한글은 거의 글자마다 1토큰으로 계산되고, 공백도 1토큰이지만 영어는 단어가 1토큰으로 계산됩니다. 서비스 이용시 토큰 수에 따라 금액을 청구하는 방식이기에, 한글보다 영어가 비용적인 측면에서 유리합니다.
임베딩 API는 비즈니스 로직에서 호출할 수도 있고, 벡터 DB(오픈 서치)에 설정을 하여 사용자로부터 데이터를 전달 받았을 시 내부에서 직접 호출하게 하여 사용하는 방법도 있습니다.
메타 데이터 또한 비즈니스 로직에서 넘겨줄 수도 있고, DB 설정을 통하여 생성할 수도 있습니다.
벡터 DB 설정
벡터 DB 설정 예시입니다.
- 상단에 벡터 데이터를 만들기 위한 API 주소, Key, 모델을 입력합니다.
- 중간에 벡터 DB의 차원수, 유사도 기법을 세팅하였습니다.
- 하단에는 메타 데이터 관련 설정을 하였습니다.
최종 저장 데이터
최종적으로 벡터 DB에 저장될 원본 데이터 + 벡터 데이터 + 메타 데이터의 형태입니다.
후기
결과적으로 이번 발표를 준비하며 백엔드 관점에서 임베딩 파이프라인을 뜯어보니, AI도 결국은 정교하게 설계된 데이터 엔지니어링의 영역이라는 점이 명확해졌다.
단순히 모델이 알아서 해주는 게 아니라, 데이터를 어떻게 쪼개고 어떤 메타데이터와 함께 벡터 DB에 밀어 넣느냐에 따라 RAG의 응답 품질이 완전히 달라지기 때문이다.
처음에는 생소한 개념들이 많아 막막했지만, API 호출과 DB 인덱싱 구조로 치환해서 분석해 보니 결국 우리가 늘 하던 데이터 처리의 연장선이었다.
비즈니스 로직에서 임베딩 모델을 직접 제어할지, DB 설정에 맡길지 고민하는 과정 자체가 백엔드 개발자로서 RAG를 이해하는 가장 빠른 지름길이었던 것 같다.
앞으로는 단순히 API를 호출하는 수준을 넘어, 다양한 임베딩 기법이나 모델 최적화 같은 AI 관련 지식도 차근차근 파볼 생각이다.
인프라와 로직만 잘 짜는 것을 넘어, 모델이 데이터를 해석하는 원리까지 이해해야 더 단단한 AI 서비스를 만들 수 있을 것 같기 때문이다.
AI의 발전 속도와 내 학습 속도의 무한 굴레에서 벗어날 수 있을까…