---
tags: [troubleshooting, embedding, gemini, rag, robeing, deprecated]
---

# 임베딩 Gemini Embedding 2 전환 문제 오픈

> **1차·2차로 분리됨.**  
> - [1차: 로빙](./260316_임베딩_1차_로빙_Gemini2_전환_문제오픈.md) (완전 닫힘 가능)  
> - [2차: StarsAndI·TheGooseCouncil](./260316_임베딩_2차_StarsAndI_GooseCouncil_전환_문제오픈.md) (열어둠)

---

## 상위 원칙

- [0_VALUE 임베딩 정책](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/embedding-policy.md)
- [로빙 문서 작성 원칙](../../book/300_architecture/312_writing-principles.md)
- [백엔드 PostgreSQL ChromaDB Vector Memory](../../book/300_architecture/330_백엔드_PostgreSQL_ChromaDB_Vector_Memory.md)

## 문제 정의

**로빙의 임베딩 구조가 0_VALUE 임베딩 정책과 불일치한다.**

0_VALUE 정책은 Gemini Embedding 2, 768d, 전수 교체, 멀티모달을 요구한다. 현재 구현은 이를 충족하지 않는다.

### 왜 문제인가

- **상태함수=벡터 철학**: 임베딩은 정보의 상태(ψ)를 벡터로 표현한다. 현재 ko-sroberta·텍스트 전용 구조는 이 표현을 제한한다.
- **멀티모달 미지원**: PDF·이미지는 캡셔닝 파이프라인을 거쳐야 하므로 비용·지연·정보 손실이 발생한다.
- **차원 혼재**: 768/384 드리프트는 검색 품질·유지보수 부담을 증가시킨다.

### 현상(증상)

| 현상 | 내용 |
|------|------|
| 모델 | ko-sroberta(multitask) 768d, 텍스트 전용 |
| 경로 | skill-embedding + 서비스별 혼재 (skill-rag-file 384d, intent_prototypes 768d) |
| 차원 | rb8001 메모리 ChromaDB 768/384 드리프트 잔존 |
| 멀티모달 | 미지원 (이미지·PDF는 텍스트 추출 후 임베딩) |
| 청킹 | Micro-chunking(300~500 단어) 위주 |

## 현재 상태

- skill-embedding: ko-sroberta 768d
- skill-rag-file: Company X 384d, intent_prototypes pgvector 768d
- rb8001 메모리: ChromaDB 768/384 차원 드리프트
- 기존 데이터: 적음 → 전수 교체 시 기술 부채 거의 없음

## 기대 상태 (0_VALUE 정책 기준)

| 항목 | 내용 |
|------|------|
| 모델 | Gemini Embedding 2 |
| 차원 | 768 (MRL). 향후 3,000 이상 확장 검토 |
| 적용 | 전 프로젝트 전수 교체 |
| 멀티모달 | PDF·이미지 직접 임베딩 |
| 청킹 | Macro-chunking(2,000~4,000 토큰) 검토 |

## 영향 범위

**robeing**: skill-embedding(전체, /embed), skill-rag-file(embedding.py, upload.py, config), rb8001(memory_manager, intent_store, database.py, docker-compose), ChromaDB 컬렉션, intent_prototypes pgvector, migrate_chromadb_collections.py, DOCS/skills/companyx-rag, 330_백엔드 설계 문서

**StarsAndI**: recommend.py, add_star_embeddings.py, 카탈로그 5044개 재임베딩(153MB), time_recommend_*.py, usage_repository.py

**TheGooseCouncil**: calibrate_value_model.py, test_value_state_decision.py, .env.local

**companyx-knowledge-base**: skill-rag-file 경유 연쇄 반영

**인프라**: ivada-infra skill-embedding 배포, 23/24 서버 docker, workspace-config(반영됨: EMBEDDING_SERVICE_URL, EMBEDDING_DIM)

**DB·스키마**: ChromaDB dimension, PostgreSQL intent_prototypes.embedding, NAS RAG 컬렉션

전수 목록: [임베딩 전체 프로젝트 현황 및 SSOT 리서치 §3 영향 범위](../research/rag/260316_임베딩_전체프로젝트_현황_및_SSOT_리서치.md#3-영향-범위-전수)

## 재현 조건

- NAS RAG, Company X RAG, rb8001 메모리에서 임베딩 요청 시
- PDF·이미지 기반 검색 수행 시
- 0_VALUE 임베딩 정책과 현재 구현을 대조할 때

## 확인된 사실

- 0_VALUE 임베딩 정책 확정: Gemini 2, 768d, 전수 교체, 멀티모달
- 리서치(260315)에서 Gemini Embedding 2 특징·비용·청킹 전략 정리됨
- `rb8001/scripts/test_gemini_embedding_2.py` API 테스트 스크립트 존재
- 기존 데이터 적음 → 전수 교체 부담 낮음

## 미확정 항목

- skill-embedding 교체 vs Gemini API 직접 호출 경로 설계
- 청킹 단위 확대 적용 시점 및 검증 기준

## 이 문서가 여는 리서치

- [임베딩 전체 프로젝트 현황 및 SSOT 리서치](../research/rag/260316_임베딩_전체프로젝트_현황_및_SSOT_리서치.md)
- [Gemini Embedding 2 리서치: 비용·청킹·도입 검토](../research/rag/260315_Gemini_Embedding_2_리서치_비용_청킹_도입검토.md)

## 관련 문서

- [0_VALUE 임베딩 정책](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/embedding-policy.md)
- [임베딩 Gemini Embedding 2 전환 계획](../plans/260316_임베딩_Gemini_Embedding_2_전환_계획.md)
- [rb8001 메모리 ChromaDB 768/384 차원 드리프트](./260312_rb8001_memory_chromadb_768_384_dimension_drift.md)
- [skill-embedding 서비스 구축](./250805_happybell80_skill-embedding서비스구축.md)
