RAG 시스템의 최대 난제, 임베딩 불일치 원인과 실무 보완 기법 총정리

궁금하면 500원·2025년 12월 5일

LLM보완기법 Reranker VectorDB chromadb rag 다중벡터스토어 리랭커 벡터데이터베이스 시맨틱검색 인공지능아키텍처 임베딩불일치 크로마db

AI 미생지능

목록 보기

80/117

임베딩 불일치의 본질

검색 증강 생성 시스템을 구축할 때 마주하는 가장 큰 장벽은 임베딩 불일치입니다.
사용자가 질문을 던졌을 때 원하는 결과가 정확히 나오지 않는 현상인데, 이는 기술적으로 임베딩 벡터 간의 유사도 계산이 인간의 실제 의도를 제대로 반영하지 못하기 때문에 발생합니다.
이 문제가 발생하는 원인은 크게 두 가지로 나눌 수 있습니다.

1. 임베딩 불일치가 발생하는 근본적인 원인

① 인코더 모델의 기술적 정체와 한계

현재 문장을 벡터로 변환하는 임베딩 작업에는 주로 인코더 기반의 모델이 사용됩니다.
인코더와 디코더는 모두 트랜스포머 아키텍처를 공유하지만, 구조적 목적과 데이터 처리 방식에서 결정적인 차이가 있습니다.

디코더의 특징: 텍스트를 지속적으로 생성합니다.
토큰을 하나 만들면, 그 생성된 토큰을 다시 입력에 포함하여 다음 토큰을 예측하는 과정을 반복합니다.
이 과정에서 컨텍스트를 분석하는 어텐션 계산이 끊임없이 누적됩니다.
인코더의 특징: 텍스트 생성을 하지 않기 때문에 입력된 문장이 끝입니다.
디코더처럼 출력 편향이 발생하지 않으며, 주어진 입력 안에서 모든 어텐션을 한 번에 계산하고 종료하는 폐쇄망 구조를 가집니다.
한 번의 계산으로 결론을 내리기 때문에 속도가 매우 빠르다는 장점이 있습니다.

인코더 기반 임베딩 모델의 시드 혹은 파운데이션 모델로 가장 유명한 것이 구글의 BERT입니다.
허깅페이스 등에서 최신 고성능 모델을 찾을 때 'Seed'라는 키워드를, 비교적 과거 모델을 찾을 때 'Foundation'이라는 키워드를 주로 사용하는 경향이 있습니다.

문제는 현재 인공지능 생태계의 자원과 연구가 디코더 모델에만 편향되어 있다는 점입니다.
컴퓨팅 파워가 비약적으로 저렴해지고 성능이 좋아지면서, 미디어와 학계는 인코더의 '빠른 연산'이라는 장점에 매달릴 이유가 없어졌습니다.
연산 비용이 더 들더라도 성능이 뛰어난 디코더를 활용하여 Mixture of Experts, Grouped-Query Attention 등 극도로 발전된 어텐션 시스템을 디코더 위주로만 개발해 온 것입니다.

반면 BERT를 비롯한 인코더 계열은 기술적 발전이 거의 정체되었습니다.
최신 어텐션 기법이 적용된 인코더 모델이 시장에 존재하지 않다 보니, 임베딩을 생성할 때 2021년 수준의 구형 어텐션 메커니즘을 사용할 수밖에 없습니다.
그 결과, 문장이 가진 깊은 문맥과 의미론을 정밀하게 추출하지 못하고 허접한 수준의 수치 배열을 반환하게 되며, 이것이 곧 임베딩 불일치로 이어집니다.
OpenAI조차 최신 생성형 모델을 계속 쏟아내는 것에 비해, 임베딩 모델의 업데이트 주기는 극히 드문 이유가 여기에 있습니다.

② 임베딩 대상 간의 속성 불일치

모델 자체의 한계 외에도, 비교하려는 두 데이터의 태생적 성격이 완전히 다릅니다.

사용자 질의: 사용자의 질문 속에는 다양한 맥락, 주관적 의도, 배경지식, 감정 등이 복합적으로 얽혀 있습니다.
이를 임베딩하면 여러 레이어의 의미가 섞인 복잡한 시맨틱 벡터가 형성됩니다.
보유 데이터: 반면 RAG 시스템에 저장된 PDF나 텍스트 청크 데이터는 가치중립적인 '사실' 위주로 기술되어 있습니다.
주관적 맥락이나 의도가 배제된 건조한 형태입니다.

의도와 맥락이 가득 찬 질문 벡터와 건조한 사실 정보 벡터를 가지고 코사인 유사도를 비교하니, 수학적 거리가 멀게 계산되어 엉뚱한 문서가 검색되는 구조적 한계가 존재합니다.

2. 전통적인 키워드 검색과의 비교 및 임베딩의 가치

그렇다면 왜 성능이 불완전한 임베딩 검색을 계속 사용할까요? 엘라스틱서치나 솔라 같은 검색 엔진, 관계형 데이터베이스의 풀텍스트 인덱싱에서 사용하는 BM25 알고리즘 기반의 키워드 검색과 비교해 보면 이유가 명확해집니다.

키워드 검색과 시맨틱 검색 비교

구분	키워드 검색	시맨틱 검색
작동 원리	형태소 분석 후 토큰 인덱스 생성, 토큰의 빈도수 기반 매칭	데이터를 다차원 벡터 공간의 숫자로 변환 후 기하학적 유사도 비교
특징	희소 벡터 기반, 텍스트가 정확히 일치해야 검색 가능	밀집 벡터 기반, 단어가 달라도 문맥적 의미로 검색 가능
장점	명확한 키워드 매칭에 강함, 연산 속도가 극도로 빠름	사용자의 숨은 의도 분석 가능, 멀티모달 확장 가능
한계	문맥과 동의어 처리가 불가능하며, 사용자의 의도를 파악할 수 없음	모델의 구형 아키텍처로 인한 임베딩 불일치 및 비용 발생

임베딩의 가장 독보적인 장점은 텍스트를 넘어 멀티모달 데이터까지 동일한 시맨틱 공간으로 끌고 올 수 있다는 점입니다.
이미지나 사운드 같은 바이너리 데이터도 Word2Vec과 유사한 방식으로 확률적 인접성을 계산하여 토크나이징하고 학습시키면 벡터 공간에 매핑할 수 있습니다.

과거의 구글 이미지 검색은 사람이 수동으로 입력한 메타데이터에 의존한 키워드 검색이었으나, 현재의 구글 검색이나 스마트폰 갤러리의 사진 검색 예를들어 '카드 사진', '슈퍼카' 입력 시 해당 사진을 찾아내는 기능 은 모두 이 임베딩 기반의 시맨틱 검색 기술이 적용된 결과입니다.
인코더 기반 임베딩 모델은 용량이 작고 가볍기 때문에 온디바이스나 API 형태로 효율적으로 구동됩니다.

3. RAG 기본편에서 다루는 임베딩 보완 기법

기본적인 RAG 아키텍처에서는 이러한 불일치를 완화하기 위해 다음과 같은 검색 전략들을 활용합니다.

문서 압축: 검색된 결과 데이터에서 불필요한 노이즈를 제거하고 핵심 내용만 요약하여 컨텍스트 효율을 높이는 방법입니다.
하이브리드 검색: 사용자 질의로 BM25 키워드 검색을 먼저 수행하여 후보군을 좁힌 뒤, 그 결과 안에서 벡터 검색을 다시 수행하여 키워드 매칭과 시맨틱 매칭의 장점을 결합합니다.
부모 문서 추가 검색: 원본 PDF나 대형 문서를 페이지 단위로 쪼개고, 이를 다시 문장 단위로 세분화합니다.
자식 청크와 페이지를 모두 임베딩해 두면, 사용자가 구체적인 내용을 물어볼 때는 자식 청크가 매칭되고, 추상적인 내용을 물어볼 때는 페이지 단위의 부모 임베딩이 매칭되어 검색 품질이 유연해집니다.

질의 변형과 다중 벡터 스토어

임베딩 불일치를 근본적으로 해결하려면 '사용자 질의'와 '데이터' 중 어느 한쪽의 형태를 전처리하여 둘의 성격을 일치시켜야 합니다.

① 쿼리 변형 (Query Transformation - 질의를 데이터에 맞추기)

사용자 질의에 담긴 배경, 복합적 의도를 LLM에게 먼저 입력합니다.
LLM에게 "우리 벡터 DB의 사실데이터를 검색하기 가장 좋은 형태의 하위 질문들로 분해해줘"라고 요청하는 방식입니다.
LLM이 정제하고 분해한 팩트 기반의 질문들로 임베딩을 만들어 검색을 수행하므로, DB 내의 데이터 임베딩과 높은 일치율을 보입니다.
단, 사용자 요청마다 LLM을 매번 거쳐야 하므로 비용과 지연 시간이 증가합니다.

② 다중 벡터 스토어 (Multi-Vector Store - 데이터를 질의에 맞추기)

데이터를 벡터 DB에 적재하는 시점에 가공을 수행합니다.
원본 데이터를 LLM에 입력한 뒤, "이 사실을 기반으로 사용자들이 던질 법한 예상 질문 5개를 생성해줘"라고 요청합니다.
그리고 원본 데이터 하나에 LLM이 생성한 5개의 예상 질문 임베딩을 매칭하여 저장합니다.
하나의 데이터 레코드가 여러 개의 벡터 키를 가지게 되는 구조입니다.
실시간 질의 시 LLM 비용이 들지 않고 검색 효율이 매우 뛰어나기 때문에 현업에서 선호도가 높습니다.

4. 벡터 데이터베이스의 특성과 운영상의 한계

① 셀프 쿼리를 통한 복합 질의 수행

개념적으로 벡터 DB는 숫자 배열을 Key로 하고 텍스트 데이터를 Value로 하는 구조처럼 보이지만, 현대의 프로덕션용 벡터 DB는 고도화된 메타데이터 필터링 기능을 함께 제공합니다.

셀프 쿼리 기법은 사용자의 자연어 질의에서 메타데이터 조건과 시맨틱 질의를 동시에 추출하는 방식입니다.
예를 들어, 데이터 적재 시 임베딩 외에 '평점'이라는 메타데이터 필드를 함께 저장해 두었다면, LLM이 사용자 질문을 분석하여 "평점 7점 이상"이라는 필터링 조건과 "내용 유사도" 조건을 분리해 냅니다. 이를 통해 벡터 DB 내부에서 구조화된 쿼리와 비구조화된 벡터 검색을 동시에 수행하는 복합 질의가 가능해집니다.

실습 팁: 프로덕션 환경에서는 기존 인프라와 통합된 Elasticsearch 벡터 플러그인을 활용하는 것이 가장 안정적입니다.
단 가볍게 로컬 실습을 진행할 때는 파이썬 환경에서 pip install chromadb로 쉽게 구동 가능한 Chroma DB를 추천합니다.
3계층(Tenant -> Database -> Collection) 구조의 완전한 HTTP API 기반 DB 서버이므로 실무 환경을 모사하기에 적합합니다.
(인메모리 벡터 스토어는 휘발성 및 기능 제약으로 인해 실제 서비스 구현에는 한계가 있습니다.)

② 엔터프라이즈 정형 데이터의 시맨틱 한계

대기업의 엔터프라이즈 데이터 대부분은 카프카 파이프라인이나 RDB의 정형화된 테이블 형태로 존재합니다.
이 수억 건의 레코드들은 구조가 완벽히 동일하고 명사나 수치만 바뀌는 형태입니다.

이러한 정형 데이터를 강제로 문장으로 만들어 LLM에 학습시키거나 임베딩하더라도, 문장 구조가 완전히 동일하기 때문에 생성되는 임베딩 벡터 역시 거의 같은 공간에 뭉치게 되어 시맨틱 변별력이 사라집니다.
LLM과 임베딩 모델은 문장 구조와 문맥이 다채롭게 변화해야 유의미한 시맨틱 파라미터를 학습할 수 있습니다.

따라서 실제 실무에서는 직원들이 작성한 가공된 매뉴얼, 블로그 형태의 문서, 인간이 기술한 다채로운 컨텍스트 텍스트가 있어야만 유의미한 시맨틱 검색 시스템을 구축할 수 있습니다.

③ 데이터 삭제 및 관리의 난제

전통적인 RDB는 Row ID나 고유 키를 기준으로 원하지 않는 데이터를 명확히 삭제할 수 있습니다. 그러나 문서를 청크 단위로 쪼개어 밀어 넣은 벡터 DB는 특정 텍스트 내용이 최신 정보에 의해 적재되더라도, 과거의 구형 청크 데이터를 찾아내어 정밀하게 삭제하는 것이 기술적으로 극히 어렵습니다.

결과적으로 데이터가 선형적으로 계속 쌓이게 되며, 내부에는 "A 약품은 안전하다"는 과거 청크와 "A 약품은 부작용이 발견되었다"는 최신 청크가 공존하는 데이터 오염 상태가 발생합니다.

이를 해결하기 위해 검색 쿼리 연산 시 유사도 점수 외에 시간 가중치를 산식에 결합해야 합니다.
동일하거나 유사한 맥락의 데이터가 검색되었을 때 최신 날짜의 메타데이터를 가진 청크가 더 높은 상위 점수를 받도록 설계하는 것입니다.
또한, 장기적인 운영을 위해서는 데이터 적재 시점부터 메타데이터에 유효기간이나 우선순위를 명확히 부여하고, 주기적으로 오래된 컬렉션을 정리하는 아키텍처 관리가 필수적입니다.

5. 리랭커와 랩터

① 리랭커

임베딩 벡터의 코사인 유사도 검색은 '인코더의 한계'로 인해 정밀도가 떨어집니다.
이를 2차로 보완하는 핵심 기술이 바로 리랭커입니다.
리랭커 역시 토큰을 생성할 필요가 없고 정해진 스코어만 출력하면 되므로 비용 효율성을 위해 인코더 기반 아키텍처를 주로 사용합니다.

[사용자 질의] 
     │
     ▼
[1차 벡터 검색] ───> 가볍고 빠른 유사도 계산으로 상위 문서 10~20개 추출 (Bi-Encoder 방식)
     │
     ▼
[2차 리랭킹]   ───> (질의, 각 문서) 쌍을 리랭커 모델(Cross-Encoder)에 입력하여 정밀 재평가
     │
     ▼
[최종 컨텍스트] ───> 재정렬된 순위 중 최상위 문서들만 LLM에 최종 전달

1차 벡터 검색 시에는 질문 벡터와 문서 벡터를 각각 독립적으로 생성한 뒤 거리만 계산하는 구조를 취해 속도를 확보합니다.
그 후 추출된 상위 10~20개의 문서에 대해서만 사용자의 원래 질문과 문서를 한 쌍으로 묶어 리랭커 모델에 통째로 입력합니다.

리랭커는 두 입력문 간의 교차 어텐션을 아주 세밀하게 계산하여 실제 시맨틱 연관성 점수를 다시 매깁니다.
이 과정을 통해 1차 검색에서 상위에 올랐던 노이즈 데이터가 걸러지고, 하위에 있던 핵심 문서가 최상위로 올라오게 됩니다.
현재 상용 프로덕션 RAG 시스템 중 리랭커 아키텍처를 도입하지 않은 곳은 없다고 보아도 무방할 만큼 필수적인 단계입니다.

② 랩터

랩터는 텍스트 청크들을 벡터 공간에 배치한 뒤, 이를 수학적 알고리즘으로 군집화하는 기법입니다.
군집화된 유사 청크들을 모아서 LLM에게 전달하여 상위 수준의 요약본을 만들게 하고, 그 요약본에 대한 임베딩을 다시 생성합니다.
이 과정을 거듭하여 거대한 트리 구조의 임베딩 레이어를 형성하는 방식입니다.

구조적으로는 매우 획기적인 접근으로 보일 수 있으나, 현재 시장 및 실무 아키텍트들의 평가는 다소 회의적입니다.
트리를 형성하고 유지하는 과정에서 발생하는 LLM 요약 비용과 컴퓨팅 연산량에 비해, 실제 현업 데이터셋에서 검색 정확도의 향상 폭이 그리 크지 않기 때문입니다.
특수한 연구 목적의 데이터셋이 아닌 이상, 일반적인 엔터프라이즈 환경에서는 생 임베딩 검색에 고성능 리랭커를 결합한 아키텍처가 비용 및 성능 측면에서 훨씬 우수하다는 것이 지배적인 결론입니다.

6. 혼동하기 쉬운 인공지능 기초 용어 명확화

인공지능 및 벡터 검색을 공부할 때 가장 큰 진입장벽이 되는 핵심 용어들의 관계를 직관적으로 정리합니다.

임베딩:
동사로서의 의미: 문장, 이미지, 사운드 등 컴퓨터가 이해할 수 없는 비수치형 데이터를 다차원의 숫자 배열로 변환하는 행위 자체를 뜻합니다.
명사로서의 의미: 그 결과물로 변환되어 나온 숫자 배열 그 자체를 의미합니다. 과거 Word2Vec 모델의 임베딩은 어텐션이 없어 단순 단어 간의 '확률적 분포'만을 반영한 배열이었지만, 현대 트랜스포머 기반 모델의 임베딩은 문맥과 '시맨틱 의미론'을 내포한 배열이라는 차이가 있습니다.

벡터: 임베딩과 본질적으로 동일한 용어입니다.
다만 컴퓨터 공학 및 수학적으로
순서가 엄격히 정해진 숫자의 배열임을 강조할 때 벡터라고 표현합니다.
차원: 어렵게 생각할 필요 없이, 숫자 배열의 인덱스(Index) 개수 또는 방의 개수를 의미합니다.
예를 들어 512차원 임베딩이란 숫자가 512개 들어있는 배열을 뜻하며, 각 인덱스 자리는 모델이 학습한 특정 시맨틱 요소 예를들어 문장의 우울함 정도, 경제 관련성 등의 수치를 담당하게 됩니다.

궁금하면 500원

레거시를 이해하면서도 새로운 기술을 현실적으로 적용할 수 있는 백엔드 개발자가 되는 것이 목표입니다.

이전 포스트

인코더를 버리고 디코더로 가야 하는 이유

다음 포스트