# 로빙 임베딩 모델 경량화 및 최적화 가이드

작성일: 2025년 8월 4일
작성자: Claude (51124 서버)

## 배경

rb10508_micro 경량화 과정에서 ONNX 기반 임베딩 모델로 전환했으나, 예상보다 높은 메모리 사용량(987.9MB)을 보이고 있다. 이미지 크기는 6.19GB → 1.16GB로 경량화했지만, 런타임 메모리는 여전히 1GB에 가깝다.

## 현재 상황 분석

### 현재 사용 모델
- **모델**: `sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2`
- **크기**: 449MB ONNX 파일
- **차원**: 384
- **메모리 사용량**: 987.9MB (런타임)

### 성능 벤치마크 (한국어)
```
1. 동일 의미, 다른 표현: 0.949 (매우 좋음)
   "안녕하세요, 오늘 날씨가 좋네요." ↔ "안녕, 오늘 날씨 정말 좋다."

2. 감정 표현 유사: 0.818 (좋음)
   "오늘 기분이 좋아요." ↔ "기분이 매우 좋습니다."

3. 연관 의미: 0.317 (보통)
   "배가 고파요." ↔ "밥 먹고 싶어요."

4. 시간-음식 연관: 0.622 (괜찮음)
   "점심 시간이 되었네요." ↔ "밥 먹고 싶어요."

5. 무관한 문장 (기준): 0.334
   "컴퓨터가 고장났어요." ↔ "배가 고파요."
```

## 메모리 사용량 높은 원인

### 메모리 분석 결과
- **Python process RSS**: 1.06GB
- **ONNX 모델 파일**: 449MB (메모리 상주)
- **ONNX Runtime**: 모델 실행용 추가 메모리
- **transformers 토크나이저**: 14MB+ 토크나이저 파일들
- **ChromaDB**: 벡터 데이터베이스 메모리 사용
- **Python + FastAPI**: 기본 웹 프레임워크 오버헤드

### 벡터 DB 필요성
일반 DB(PostgreSQL/NoSQL) 대신 벡터 DB를 사용해야 하는 이유:

**벡터 DB의 핵심 기능**:
- 의미적 유사도 검색: "배고프다" ↔ "밥 먹고 싶다" 연결
- 코사인 유사도: 벡터 간 거리로 관련성 측정
- 임베딩 기반: 문맥과 의미를 고차원 벡터로 표현

**일반 DB 사용 시 문제점**:
- 의미적 검색 불가능 (키워드 매칭만)
- 컨텍스트 이해 부족
- 기억 패턴 인식 실패

## 대안 임베딩 모델 비교

### 1. 기준 조건
- **한국어 지원**
- **임베딩 차원 수** (낮을수록 경량)
- **모델 크기** (작을수록 좋음)
- **성능** (Semantic Search 기준)
- **로컬 실행 가능 여부**

### 2. 모델 후보군

| 모델명 | 크기 | 차원 | 한국어 지원 | 특징 / 장단점 |
|--------|------|------|-------------|---------------|
| **paraphrase-multilingual-MiniLM-L12-v2** | 449MB | 384 | O | 현재 사용 중. 균형형 |
| **paraphrase-multilingual-MiniLM-L6-v2** | 120MB | 384 | O | 가장 가벼운 multilingual 모델 중 하나 |
| **intfloat/multilingual-e5-small** | 175MB | 384 | O | E5 시리즈. 검색 최적화. "query: …" 문맥 활용 필요 |
| **intfloat/multilingual-e5-base** | 440MB | 768 | O | 성능 ↑, 경량 ↓. MTEB 성능 상위권 |
| **jinaai/jina-embeddings-v2-base-ko** | 약 400MB | 768 | O (한국어 특화) | **한국어 전용**. 문맥 이해 성능 우수 |
| **LaBSE (Google)** | 약 500MB | 768 | O | 대규모 언어 간 의미 정렬. 성능은 뛰어나나 무겁고 느림 |
| **bge-m3 (BAAI)** | 약 360MB | 1024 | O (다국어) | RAG + 검색 최적화. 문서용. 다소 무거움 |
| **nomic-ai/nomic-embed-text-v1.5** | 120MB | 768 | 제한적 (한국어 일부) | 최신 경량 + 빠름. 고속 의미 검색용 |

### 3. L12 vs L6 성능 차이 예상

**L6 모델 예상 성능** (L12 대비):
- **전체 성능**: 5-10% 저하
- **한국어 특화**: 10-15% 저하 (다국어 모델 특성상)

**구체적 예상**:
- 동일 의미: 0.949 → 0.850-0.900 (-5~10%)
- 감정 표현: 0.818 → 0.720-0.780 (-5~12%)
- 연관 의미: 0.317 → 0.250-0.300 (-5~20%)

**실용적 영향**:
- **크게 문제없는 경우**: 직접적 대화 기억, 명확한 감정 표현
- **문제가 될 수 있는 경우**: 미묘한 연관성, 한국어 관용어, 복합 감정

## 권장 전략

### 1. 단계별 경량화 접근

**Phase 1: 즉시 적용 가능**
```yaml
# L6 모델로 교체 (330MB 메모리 절약)
model: paraphrase-multilingual-MiniLM-L6-v2
예상 메모리: 987MB → 650-700MB
성능 저하: 10-15%
```

**Phase 2: 성능 최적화**
```yaml
# E5-small 모델 (검색 특화)
model: intfloat/multilingual-e5-small
크기: 175MB
특징: "query: " prefix 활용으로 성능 보완
```

**Phase 3: 한국어 특화**
```yaml
# 한국어 전용 고성능
model: jinaai/jina-embeddings-v2-base-ko
크기: 400MB
차원: 768 (정확도 최우선 시)
```

### 2. 하이브리드 아키텍처

**메모리 효율적 접근**:
```python
# 핵심 기억만 벡터 DB (최근 100개)
recent_memories = ChromaDB(embedding_function=ONNX_Light)

# 오래된 기억은 PostgreSQL (키워드 기반)
old_memories = PostgreSQL(full_text_search=True)

# 검색 시 두 단계로 진행
1. 벡터 검색 (의미적 유사도)
2. 키워드 검색 (보완)
```

### 3. 운영 최적화

**메모리 내 벡터 제한**:
```python
# 메모리에 최근 50개 임베딩만 유지
# 나머지는 디스크 저장 후 필요시 로딩
MAX_MEMORY_EMBEDDINGS = 50
```

**모델 지연 로딩**:
```python
# 앱 시작 시 모델 로딩하지 않고 첫 요청 시 로딩
lazy_load = True
```

## 구체적 추천

### 메모리 절약 우선
- **1순위**: `paraphrase-multilingual-MiniLM-L6-v2` (120MB)
- **2순위**: `multilingual-e5-small` (175MB)

### 성능 우선 (한국어)
- **1순위**: `jina-embeddings-v2-base-ko` (400MB, 768차원)
- **2순위**: `multilingual-e5-base` (440MB, 768차원)

### 균형형 (현재 유지)
- **현재**: `paraphrase-multilingual-MiniLM-L12-v2` (449MB, 384차원)

## 결론

1. **즉시 적용**: L6 모델로 변경하여 330MB 메모리 절약
2. **장기 계획**: 하이브리드 구조로 메모리와 성능 모두 최적화
3. **성능 모니터링**: 실제 사용자 피드백 기반으로 모델 선택

로빙의 정확한 용도(검색/요약/의미 연결 중 어디에 중점?)에 따라 최적 조합을 조정할 수 있다.

## 다음 단계

1. **L6 모델 성능 테스트**: 실제 한국어 데이터로 A/B 테스트
2. **메모리 프로파일링**: 각 모델별 정확한 메모리 사용량 측정
3. **사용자 피드백**: 실제 대화에서 의미 연결 정확도 비교
4. **하이브리드 아키텍처 설계**: ChromaDB + PostgreSQL 통합 방안