임베딩 검색 방식 - dense·sparse·hybrid
🌿 자라는 중
임베딩과 RAG 기본
- 임베딩은 텍스트를 의미가 담긴 벡터로 바꾸는 것. 뜻이 비슷한 문장일수록 벡터 공간에서 가깝게 배치된다. “정책서버 부팅 실패”와 “정책서버가 재시작 안 됨”은 표현이 달라도 가까운 벡터가 된다.
- “가깝다”는 코사인 유사도로 잰다 (1에 가까울수록 유사).
- RAG는 LLM이 답을 만들기 전에 관련 문서를 먼저 검색해 참고하게 하는 방식이고, 그 검색 단계를 임베딩이 담당한다.
- 검색 대상 문서는 청킹(문단·수백 토큰 단위 분할)해서 조각별로 임베딩한다.
- 정형 필드(버전·분류 같은 메타데이터)는 임베딩이 아니라 벡터DB의 payload 필터로 쓰고, 자유 텍스트만 벡터로 임베딩한다.
검색 방식 세 가지
- dense: 의미 벡터 기반. 표현이 달라도 뜻이 비슷하면 잡아냄
- sparse: 어휘(토큰) 기반. 명령어나 버전 문자열처럼 정확히 일치해야 하는 토큰 매칭에 강함
- hybrid: dense + sparse 결합. 한국어 문장과 제품 고유 용어가 섞인 도메인에 유리할 것으로 기대
직접 실험하며 배운 것
- 하이브리드는 모델이 지원해도 별도로 지정해야 동작한다. 지원 모델을 골라놓고 dense만 걸려 있는 걸 뒤늦게 발견함
- 하이브리드가 항상 우세하지 않다. 구어체 질문에서는 dense 단독이 더 잘 나오는 경향이 있었다. 모수가 적으면 희소(sparse) 벡터 쪽이 점수를 흔드는 것으로 보임
- 문서 내용을 많이 넣을수록 잘 찾아질 줄 알았는데, 짧고 정제된 필드(제목+개요)만 임베딩하는 쪽이 항상 같거나 더 좋았다. 임베딩 모델이 약 1,000차원으로 압축하기 때문에 원문이 길면 그 내용이 벡터에 온전히 반영되기 어렵다
- 지저분한 원문을 그대로 넣는 것보다 “증상/확인 내용/조치”처럼 일관된 형태로 요약해서 넣었을 때 검색 품질이 크게 올랐다. 검색 품질은 기법보다 넣기 전 데이터 손질이 좌우한다
- 평가 질문이 정답 문서를 만들 때 쓰인 원본과 같은 출처면 단어가 그대로 겹쳐 시험으로서 무효다. 문제와 정답은 출처가 달라야 한다
- 자기가 만든 질문으로 잰 점수는 객관적인 성적표가 아니다. 외부 기준선(다른 검색 시스템)과 같은 질의로 대조하는 평가가 필요하다
용어
- BGE-M3: dense + sparse + ColBERT 세 검색 방식을 한 모델로 제공하는 임베딩 모델. 100개 이상 언어, 8192 토큰 지원
- MTEB (Massive Text Embedding Benchmark): 임베딩 모델을 같은 데이터셋으로 채점해 비교하는 표준 벤치마크
- nDCG@10: 검색 결과 상위 10개에 정답 문서가 얼마나 잘 배치됐는지를 재는 순위 품질 지표
- Bi-Encoder / Cross-Encoder: 질의·문서를 각각 인코딩해 빠르게 1차 검색(Bi) ↔ 둘을 함께 넣어 정밀 리랭킹(Cross). RAG는 보통 이 2단계를 조합
- Matryoshka / MRL: 벡터 앞부분만 잘라 차원을 줄여도 성능이 유지되도록 학습한 임베딩. 저장·검색 비용 절감용