AI 용어집 · 심화 · 데이터 엔지니어링 · 언어 모델
임베딩 파이프라인 Embedding Pipeline
임베딩 파이프라인은 문서를 모으고, 잘게 나누고, 임베딩(의미를 담은 숫자 목록)으로 바꿔 벡터 DB에 넣는 과정을 자동으로 이어 붙인 작업 흐름입니다. RAG나 시맨틱 검색이 제대로 동작하려면 이 준비가 먼저 되어 있어야 합니다.
어떻게 작동하나
먼저 사내 위키, PDF, 웹 페이지 같은 원본 문서를 모읍니다. 그다음 표·머리글 같은 군더더기를 정리하고, 검색하기 좋은 크기로 문서를 잘게 나눕니다(청킹). 나눈 조각마다 임베딩 모델이 의미를 숫자 목록(벡터)으로 바꾸고, 출처·날짜 같은 메타데이터와 함께 벡터 DB에 저장합니다. 사용자가 질문하면 질문도 같은 모델로 벡터로 바꾼 뒤, 가까운 조각을 찾아 LLM에 건넵니다.
왜 중요한가
RAG의 답변 품질은 결국 '무엇을 찾아 오느냐'에 달려 있고, 찾을 재료는 이 파이프라인이 미리 만들어 둡니다. 조각을 너무 크게 나누면 엉뚱한 내용이 섞이고, 너무 작게 나누면 앞뒤 맥락이 사라집니다. 문서가 계속 바뀌는 회사라면 한 번 만들고 끝나는 게 아니라, 바뀐 문서만 골라 다시 처리하는 일이 계속 돌아가야 합니다. 그래서 일회성 스크립트가 아니라 '파이프라인'으로 관리합니다.
알아 둘 점
임베딩 모델을 바꾸면 기존 벡터와 새 벡터는 서로 비교할 수 없어서, 저장된 문서를 전부 다시 임베딩해야 합니다. 같은 문서가 여러 번 들어가면 검색 결과가 한쪽으로 쏠리므로 중복 제거가 필요합니다. 개인정보가 담긴 문서는 저장 전에 비식별화하거나 접근 권한 정보를 함께 붙여 두어야 합니다. 검색이 잘되는지 주기적으로 평가하지 않으면 품질이 조용히 떨어져도 알아채기 어렵습니다.
운영 전 점검 항목
데이터
- 같은 문서가 중복으로 들어가지 않는가
- 개인정보를 저장 전에 걸러 내는가
- 접근 권한 정보를 함께 저장하는가
운영
- 바뀐 문서만 골라 다시 처리하는가
- 모델 교체 시 전체 재임베딩 계획이 있는가
- 검색 품질을 주기적으로 평가하는가
예시
사내 규정 챗봇을 만든다고 해 봅시다. 인사·보안 규정 문서를 매일 밤 확인해 새로 바뀐 문서만 골라 문단 단위로 나누고, 임베딩해서 벡터 DB에 갱신합니다. 직원이 "재택근무 신청은 어떻게 하나요?"라고 물으면 챗봇은 미리 저장된 조각 중 가장 가까운 것을 찾아 근거로 답합니다. 문서 갱신이 밀리면 챗봇은 옛 규정으로 답하게 되므로, 파이프라인을 안정적으로 돌리는 일이 곧 답변 품질 관리입니다.