Embedding 기본
3줄 요약
- Embedding은 텍스트나 데이터를 벡터로 바꿔 의미적 유사도를 계산할 수 있게 하는 방식이다.
- RAG, 추천, 중복 탐지, 의미 검색의 기반이지만 모델 버전과 데이터 lifecycle을 함께 관리해야 한다.
- 백엔드에서는 embedding을 단순 변환이 아니라 색인 가능한 데이터 파이프라인으로 봐야 한다.
핵심 정리
- Embedding 모델은 입력 텍스트를 고차원 벡터로 변환한다.
- 의미가 비슷한 문장은 벡터 공간에서 가까운 위치에 놓이도록 학습된다.
- 같은 embedding 모델로 만든 벡터끼리 비교해야 한다.
- embedding 모델을 바꾸면 기존 vector index 재색인이 필요할 수 있다.
- 원본 문서, chunk, vector, metadata, model version을 함께 저장해야 운영이 가능하다.
헷갈리는 지점
- embedding은 한 번 만들어두면 영구적으로 쓸 수 있다고 생각하기 쉽다.
- 핵심은 모델 변경, 문서 변경, 권한 변경, 삭제 이벤트가 모두 vector에 반영되어야 한다는 점이다.
- vector는 원본 데이터의 파생물이다.
- embedding이 의미를 완벽히 이해한다고 생각하기 쉽다.
- 핵심은 embedding은 유사도 신호일 뿐 정답 판단이 아니라는 점이다.
확인 질문
- embedding model version을 저장해야 하는 이유는 무엇인가?
- 같은 의미 공간에서 비교되는지 확인하고 모델 변경 시 재색인 범위를 알기 위해서다.
- vector는 원본 데이터와 어떤 관계인가?
- 원본 문서에서 파생된 검색용 데이터이며 원본 변경과 삭제에 맞춰 갱신되어야 한다.
3줄 요약
- Vector Search는 query embedding과 가까운 벡터를 찾아 의미적으로 관련 있는 문서를 검색한다.
- 실무에서는 유사도 점수만으로 부족하고 metadata filter, 권한, 최신성, source 신뢰도를 함께 봐야 한다.
- metadata filter가 실제 DB 권한 모델과 어긋나면 개인정보와 권한 사고가 날 수 있다.
핵심 정리
- vector search는 semantic similarity를 기준으로 검색한다.
- keyword search보다 표현 차이에 강하지만 정확한 필터링은 metadata가 필요하다.
- tenant id, document type, allowed role, updated_at, deleted flag 같은 metadata가 중요하다.
- 검색 결과는 최종 권한 검증을 한 번 더 거치는 편이 안전하다.
- vector DB는 운영 인프라이므로 latency, backup, scaling, index build를 고려해야 한다.
헷갈리는 지점
- vector search가 keyword search를 대체한다고 생각하기 쉽다.
- 핵심은 둘은 강점이 다르다는 점이다.
- 정확한 식별자, 코드, 날짜, 숫자는 keyword나 DB filter가 더 나을 수 있다.
- metadata filter를 넣으면 권한 문제가 끝난다고 생각하기 쉽다.
- 핵심은 metadata가 실제 권한 source of truth와 동기화되어야 한다는 점이다.
확인 질문
- vector search에 metadata filter가 필요한 이유는 무엇인가?
- tenant, 권한, 문서 유형, 삭제 상태, 최신성 같은 구조적 조건을 함께 적용하기 위해서다.
- vector search와 keyword search를 함께 볼 수 있는 이유는 무엇인가?
- 의미 유사도와 정확한 단어/식별자 검색의 강점이 다르기 때문이다.
Indexing Pipeline
3줄 요약
- Indexing Pipeline은 문서 수집, parsing, chunking, embedding, metadata 생성, vector 저장, 검증으로 이어진다.
- 운영에서는 문서 생성보다 삭제, 수정, 권한 변경, 재색인이 더 어렵다.
- 백엔드 개발자는 batch indexing과 online serving이 서로 영향을 주지 않게 설계해야 한다.
핵심 정리
- 문서가 들어오면 chunk로 나누고, 각 chunk에 source id와 metadata를 붙이고, embedding을 만든 뒤 vector DB에 저장한다.
- 문서가 수정되면 기존 chunk를 제거하거나 version을 올리고 새로 색인해야 한다.
- 문서가 삭제되면 vector index에서도 제거해야 한다.
- embedding batch가 online query 성능을 떨어뜨리지 않게 worker와 리소스를 분리한다.
- 재색인 작업은 실패와 재시작을 견딜 수 있어야 한다.
헷갈리는 지점
- 색인은 한 번 돌리면 끝이라고 생각하기 쉽다.
- 핵심은 문서와 권한은 계속 변한다는 점이다.
- indexing은 지속적으로 운영되는 파이프라인이다.
- chunking은 적당히 자르면 된다고 생각하기 쉽다.
- 핵심은 chunk 크기가 retrieval 품질과 비용에 직접 영향을 준다는 점이다.
확인 질문
- 운영 indexing에서 가장 놓치기 쉬운 이벤트는 무엇인가?
- batch indexing과 online serving을 분리해야 하는 이유는 무엇인가?
- 대량 embedding과 색인 작업이 실시간 검색 latency와 리소스를 잠식할 수 있기 때문이다.