2026 04 02

2026-04-02¶

Embedding Model¶

qwen3-embedding-8b를 예시로...

Parameters: 8B
- 모델이 학습한 가중치의 갯수
  - 8B = 80억 개의 파라미터를 가지고 있다
- 파라미터가 많을수록 언어의 미묘한 차이를 포착. 하지만 GPU와 메모리 연산 비용 올라감
  - 모델을 사용한다 = 80억 개의 파라미터를 메모리에 올려놓고 계산을 돌린다
  - 8B 모델을 float16(반정밀도)으로 로드하면 약 16GB의 메모리가 필요
    - float16 (2 byte) * 80억 = 16GB
    - CPU로 임베딩 연산을 하면 한 문장 처리하는데 수초가 걸릴 수 있음
    - GPU가 있어야 정상적으로 뚝딱

Context Length: 32k
- 한 번의 입력으로 받을 수 있는 최대 텍스트 길이
- 32K 토큰: 한국어 기준 대략 1만~1.5만자 정도
- 이 길이를 넘어가면 텍스트 짤리기 때문에, 긴 문서 임베딩할 때 청킹이 필요하기도 함

Dimension: 4096
- 임베딩 결과로 나오는 벡터의 길이
```
embed("환불 어떻게 해요?")
→ [0.12, -0.34, 0.56, ..., 0.08]  ← 이 숫자가 4,096개
```
- 차원이 높을수록 의미의 미세한 차이를 더 세밀하게 표현 가능
- 벡터 하나당 저장 공간과 검색 비용이 비례해서 올라감

RAG¶

완벽한 정답 보다는, 주어진 제약 조건 내에서 충분히 좋은 답변을 빠르게 제공하는 것이 목표

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #1 : 핵심 개념과 시스템 구조 이해¶

참고: https://tech.ktcloud.com/entry/2025-08-ktcloud-ai-rag-시스템구조-이해

문서 전처리 과정
1. 텍스트 추출: PDF, HTML, 스캔 이미지 등에서 본문 텍스트와 메타 정보 추출
2. 정제: 불필요한 공백, 제어 문자, 마크업 태그 제거 및 표준화
3. 분할: 긴 문서를 작은 텍스트 조각으로 나눠 검색 효율성 확보
4. 메타데이터 태깅: 작성자, 생성일, 출처, 카테고리 같은 속성을 붙여 정밀 지원

벡터 임베딩과 벡터 데이터베이스

임베딩 모델
- 초창기 단어 수준에서 출발 -> 문장/문서 수준까지 진화
- OpenAI의 text-embedding-3-small 모델은 단락을 1,536 차원 벡터로 표현해 대규모 의미 공간에서 비교할 수 있게 해줌

벡터 데이터베이스

벡터를 저장하고, 빠르게 검색하는 역할 (수백만 개 이상의 고차원 벡터를 실시간으로 탐색할 수 있도록 최적화 됨)

* FAISS: Meta가 개발한 고성능 라이브러리. GPU 가속으로 초당 수백만 쿼리를 처리할 수 있지만 인프라 관리가 복잡해요.
* Pinecone: 완전 관리형 서비스. 자동 확장과 일관된 100ms 미만 지연을 제공하고, 보안·컴플라이언스도 지원해요.
* Weaviate: 오픈소스 벡터 DB. 하이브리드 검색(sparse+dense)을 지원하고, 모듈화된 AI 통합 기능을 제공하며 평균 100ms 미만의 지연을 보여줘요.
* Milvus: 대규모 분산 처리에 특화된 오픈소스 솔루션. 클라우드 네이티브 인프라와 높은 확장성, 기업급 기능을 갖췄어요.
* Annoy: Spotify에서 개발한 근사 최근접 탐색 라이브러리. 메모리 효율이 높고 정적 데이터에 강점을 보여요.
* ChromaDB: 개발자 친화적인 오픈소스 벡터 DB. $18M 시드 펀딩을 받으며 단순성과 사용 편의성으로 주목 받고 있어요.
* Qdrant: HNSW 알고리즘 기반의 오픈소스 벡터 DB. 고급 압축 기술과 4~6ms의 매우 낮은 지연시간으로 신흥 강자로 떠오르고 있어요.
* Redis: 대표적인 인메모리 DB에서 벡터 검색 기능이 추가되어, 기존 서비스와 쉽게 연계하며 빠른 검색 성능을 경험할 수 있어요.

벡터 거리 측정
- 코사인 유사도: 벡터간 각도 기준으로 유사성 평가. 벡터 크기 무시하고 의미적 유사성에 집중
- 내적 (Dot Product): 벡터의 크기와 방향 모두 고려하는 방식
- 유클리드 거리 (L2 Distance): 두 벡터간 절대적인 직선 거리 계산
대부분의 텍스트 임베딩 모델은 코사인 유사도를 기준으로 학습되기에, 검색에서도 코사인 유사도 사용하는 것이 일관성 있음

검색기(Retriever)
- 사용자의 질의와 관련된 문서를 벡터 디비에서 빠르고 효율적으로 찾아내는 역할
  - 희소 검색(Sparse Retrieval): BM25, TF-IDF 같은 전통 IR 기법을 활용한 "키워드 일치 기반"으로 문서 찾음. 동의어나 의미적 변형에는 취약
  - 밀집 검색(Dense Retrieval): 트랜스포머 기반 임베딩 모델 활용해 질의/문서 "고차원 벡터로 변환". "코사인 유사도나 내적"으로 의미적 유사성 평가

재순위화(Re-ranker)
- 초기 검색으로 수백개의 후보 문서 추린 뒤, 진짜 관련성 높은 문서 골라내는 정교한 필터링 단계

Chunking - 검색 성능을 좌우하는 핵심 전처리
- 고정 크기 청킹: 일정 토큰 수나 문자수 기준으로 균일하게 분할. 계산 비용 낮고 구현 쉽지만, 단락 경계 무시해 의미 끊길 수 있음
- 재귀적 문자 청킹: 구두점이나 개행 문자 우선적으로 고려해 분할하는 방식
- 의미적 청킹: LLM이나 임베딩 활용해 의미 단위로 잘라내는 정교한 방법. 학술 논문이나 기술 보고서 처럼 복잡한 문서에서 효과적
- 구조 기반 청킹: 문서 자체의 형식을 활용하는 방식

Metadata
- 검색 정확도와 응답 품질 좌우하는 전략적 자산
- 정보
  - 문서 출처
  - 저자, 작성/발행일자
  - 문서 종류
  - 주제 분류, 부서/프로젝트 구분
  - 보안 등급, 중요도, 신뢰도 점수

검색 실패
- 지식 베이스에 문서가 없거나, 질의가 모호하거나, 벡터 검색의 한계로 적절한 컨텍스트 못찾을 수 있음. fallback 전략 필요 1. 질의 확장 & 재검색
  - 다중 쿼리 재작성 2. 검색 모드 전환 & 가중치 조정
  - Dense 검색 실패시 Sparse 검색으로 전환 3. 메타데이터 필터 완화
  - 조건이 너무 엄격하면 검색이 막히기도 함

RAG 측정
- Recall@K: 상위 K개 검색 결과중 실제 문서가 포함될 비율
- MRR: 첫번째 관련 문서가 얼마나 상위에 위치하는지 평가
- Precision@K: 상위 K개 검색 결과 중 실제로 관련 있는 문서의 비율.

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화¶

참고: https://tech.ktcloud.com/entry/2025-09-ktcloud-ai-rag-parsing-전처리-최적화

RAG 데이터 유형별 파싱 전략
1. 정형 데이터(DB, CSV)
  - 값만 뽑지말고, 구조까지 보존해라
  - 테이블을 행 단위로 풀어서 문장 형태로 변환하거나
  - 스키마를 포함한 row로 저장
2. 반정형 데이터 (JSON, HTML, 로그)
  - JSON 계층 구조
```
{ 
  "user": { 
    "name": "김케클", 
    "contacts": [
      {"type": "email", "value": "kim@ktcloud.com"}
    ] 
  }
}
--->>> 
user.name: 김케클  
user.contacts[0].type: email  
user.contacts[0].value: kim@ktcloud.com
```
  - HTML: DOM 구조 유지할 것
  - 로그: 시간과 패턴을 챙겨라
    1. 비정형 데이터 (PDF, PPT, 이미지, 코드 등)
  - 틀이 없는 데이터. 사람이 읽던 의미/맥락을 어떻게 파싱에서 지켜낼 것인가
  - 좌->우/상->하 흐름으로 복원해야 맥락이 살아남

텍스트 추출/정규화
1. 토큰화, 언어감지, 불용어 처리
  - 토큰화: 텍스트를 모델이 이해할 수 있는 단위로 쪼개는 과정
    - 임베딩 모델이 제공하는 토크나이저를 그대로 쓰는게 기본
    - 토크나이저 특성까지 고려하는게 중요
  - 언어감지: 계층적 언어 감지
    - 문서 전체에서 주요 언어 먼저 식별
    - 문단/문장 단위에서 세부 변화 추적
    - 다국어 문서가 섞여있다면 언어 감지 -> 토큰화 순서 지키는 게 필수
  - 불용어 처리: 맥락 살리고, 잡음 줄이기
2. 표/수식/코드블록
  - 표: 행/열 구조를 유지해 맥락을 살리기. HTML/md 형태로 표 보존시 검색 성능 높음
  - 수식: LaTeX, MathML 원형 보존
  - 코드 블록: 들여쓰기/펜스(```) 지키기
  - 메타데이터 & 문맥 연결: 본문 맥락과 연결해 의미 강화
3. 특수문자/줄바꿈/메타데이터 정리
  - 특수문자 처리: 의미없는건 제거, 중요한건 변환/보존
  - 줄바꿈과 공백 정리: 일관성 유지하며 단어 쪼개짐 복원
  - 메타데이터 관리: 본문에 섞지말고 별도 필드에 구조화
    - 페이지 번호, 헤더/푸터, 문서명 같은 반복 데이터는 본문에 섞어두면 벡터 유사도 왜곡

데이터 클렌징 & 품질 관리
1. 중복/노이즈 제거
  - 중복 제거 -> 고유 답변 비율 40% 증가
  - 노이즈 제거: 저품질/짧은 문서/HTML 파편 필터링
2. 버전 관리와 출처 추적
  - 데이터 버전 관리: 최신판만 기본 제공, 과거판은 아카이브로 보존

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화¶

참고: https://tech.ktcloud.com/entry/2025-11-ktcloud-rag-ai-청킹전략-최적화

어떻게 자르느냐가 중요한 이유
- 검색 정확도, 토큰 예산 & LLM 입력 한계, 운영 효율성

Chunking 전략과 최적화
- 크기/오버랩/중복의 최적의 균형 찾기 1. 고정 길이 청킹
  - 텍스트를 일정한 토큰/문자 단위로 균등하게 나누기에 간단하고 처리속도도 일정.
    - LangChain 기본 전략
  - 다만, 문장/문단이 중간에서 짤리면 개념이 분해됨. 의미적 일관성 떨어지고, Precision도 떨어짐
  - 그럼에도 baseline 전략으로 높은 평가
  - 오버랩
    - 10~25% 구간 포함하여 안정적으로 짜르길 권장
    - 문서 유형별로 오버랩 크기 조금씩 바꿔가며 안정적인 조합을 찾는 과정이 필수
    - 중복된 구간이 생기면 경계에 걸린 중요한 문장도 한 청크 이상에서 온전히 포함되기에 recall 손실을 줄이는데 큰 도움
    - Qdrant 가이드: 10~20% 오버랩이 가장 안정적인 기본값
    - 의료/법률 문서처럼 문맥 연속성이 특히 중요하다면 25~30% 오버랩 2. 의미론 Semantic 청킹
  - 문서 안의 의미 경계를 기준으로 텍스트 분할
  - 청크 내부 의미 자연스럽게 보전
  - ClusterSemanticChunker > RecursiveCharacterTextSplitter
  - 모든 문장을 임베딩하고 유사도/클러스터링 계산 수행해야 해서, 초기 인덱싱 비용이 고정 길이보다 3~5배 증가
  - 유사도 임계값을 엄격하게 잡으면 문서가 지나치게 잘게 쪼개짐. -> latency 악화
  - 최대 길이 (max chunk length) 제한 함께 적용 3. 문서 구조 Structure-aware 청킹
  - 형식적 구조 헤더, 섹션, 문단, 리스트, 표, 코드 블록 등 텍스트를 나누는 전략
  - 사람의 글쓰기 방식이 가진 논리적 단위를 그대로 반영해 분할. -> 문맥 단절 최소화
  - 주변 설명과 함께 해석되어야 의미가 살아나는 데이터
  - 구조 기반 + 의미 기반의 결합도 많이 쓰임 4. 지연 청킹
  - 압도적인 길이를 처리하는 모델이 등장함에 따라, 긴 문서 통쨰로 임베딩해 문맥을 충분히 반영한 뒤, 마지막에 청크를 나누는 방식

RAG 도구 기반 청킹 기능과 실전 활용
- RAG 프레임워크들이 제공하는 청킹 기능
  - LangChain
    - RecursiveCharacterTextSplitter: 개행 -> 문장 -> 단어 순 자연스러운 경계 고려해 분할
  - Haystack
  - LlamaIndex
    - TokenTextSplitter: 임베딩 모델의 실제 토크나이저를 활용한 정확한 토큰 단위 분할 수행
- 도구 선택보다 중요한 것은 파이프라인 전반의 일관성 유지
  - 청킹은 독립적인 단계가 아님. 도구의 성능은 파이프라인이 전체 일관성이 확보 되었을 때만 의미가 있음
  - 파서 > 청킹 > 임베딩 > 인덱싱이 같은 문서 스키마로 연결되는 구조
- 청킹은 RAG의 흐름을 설계하는 일에 가까움
  - 잘 설계해두면 검색 정확도나 응답 품질 같은 핵심 지표들이 놀라울 만큼 안정적으로 유지됨
- 임베딩 모델 선정과 청킹은 결코 분리할 수 없으며, 이 둘의 최적 조합을 찾는 것이 RAG 시스템 성공의 핵심 변수

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #4 : 임베딩(Embedding)과 벡터 인덱싱 기술¶

참고: https://tech.ktcloud.com/entry/2026-03-ktcloud-rag-embedding-vectorindex-검색-색인

개요
- 모델의 표현력과 인프라의 검색 효율이 완벽한 밸런스를 이뤄야만 진정한 RAG 시스템이 완성됨

임베딩 모델
- 비정형 데이터를 얼마나 정교한 수치적 표현으로 변환하느냐 (텍스트/이미지 등을 고정된 길이의 고차원 벡터 공간 내 한점으로 매핑) 1. Dense 임베딩
  - 인코더를 활용해 텍스트의 전체 의미를 실수 값의 고정 크기 벡터로 압축하는 기술
  - 동의어나 문장 구조가 달라도 의미적 유사성을 탁월하게 포착 2. Sparse 임베딩
  - 전체 어휘 사전 크기만큼 차원이 크지만, 대부분의 값이 0으로 채워진 벡터
  - BM25를 넘어 SPLADE 같은 학습 기반 모델이 주류. 3. Mutlimodal 임베딩
  - 텍스트와 이미지가 혼합된 기업용 문서 니즈
  - PDF 스크린샷 등 시각적 요소 직접 벡터화해 복잡한 파싱 과정 줄임
```
[임베딩 유형별 특징 요약]

유형  | 벡터 구조 | 대표 모델 | 주요 강점 | 한계
Dense   | 고정 차원, 모든 값 활성    | Gemini, NV-Embed  | 의미적 유사성, 문장 변형 포착 | 정확한 키워드 매칭에 약함
Sparse  | 어휘 크기 차원, 대부분 0   | SPLADE, BGE-M3    | 정확한 키워드 매칭, 의미 확장 | 깊은 의미적 추론에는 한계
Multimodal  | 공유 벡터 공간  | Cohere Embed v4, SigLIP   | 텍스트와 이미지 통합 검색    | 상대적으로 높은 계산 비용
```

다국어 및 SOTA 모델 성능 분석
- MTEB v2, MMTEB의 등장 (다국어 평가인듯)
- 단순 텍스트를 넘어 표/이미지/레이아웃 까지 포괄하는 문서 표현 계층으로 확장
- 영어권 최상위권 모델
  - Gemini EMbedding, NV-Embed-v2, Cohere Embed v4, OpenAI text-embedding-3
- 비영어권 환경에서는 모델 크기보다 사전 학습 데이터의 다국어 비중이 훨씬 더 중요
  - Solar 임베딩, BGE-M3, KoE5 등 다국어 특화 모델이 성능 더 잘나오는 경우도 있어.
  - 리더보드 평균 점수에만 의존하지 말고, 사내 데이터 기반 자체 벤치마크 교차 검증 + 태스크별 분해 점수 포함하여 선정할 것

인덱스 알고리즘 (in Vector DB)
- HNSW 알고리즘 : 데이터 간의 연결을 다층적인 그래프로 구성하여 빠르고 정확하게 이웃을 찾는 근사 최근접 이웃 검색