---
tags: [troubleshooting, embedding, gemini, rag, robeing, 1차]
---

# 임베딩 1차: 로빙 Gemini 2 전환 문제 오픈

## 상위 원칙

- [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, 전수 교체, 멀티모달을 요구한다. 로빙 현재 구현은 이를 충족하지 않는다. (1차 범위: robeing만. StarsAndI·TheGooseCouncil는 [2차](./260316_임베딩_2차_StarsAndI_GooseCouncil_전환_문제오픈.md))

### 왜 문제인가

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

### 현상(증상)

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

## 현재 상태

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

## 기대 상태 (1차 닫힘 기준)

| 항목 | 내용 |
|------|------|
| 모델 | Gemini Embedding 2 |
| 차원 | 768 (MRL) |
| 적용 | robeing 전역 (skill-embedding, skill-rag-file, rb8001) |
| 멀티모달 | PDF·이미지 직접 임베딩 |
| 청킹 | Macro-chunking(2,000~4,000 토큰) 검토 |

## 영향 범위 (1차)

- skill-embedding (전체, /embed)
- skill-rag-file (embedding.py, upload.py, config, docker-compose)
- rb8001 (memory_manager, intent_store, database.py, config, docker-compose)
- ChromaDB 컬렉션, intent_prototypes pgvector
- migrate_chromadb_collections.py
- DOCS/skills/companyx-rag, 330_백엔드 설계 문서
- ivada-infra skill-embedding 배포
- workspace-config: `EMBEDDING_SERVICE_URL`, `EMBEDDING_DIM` 반영됨 (SSOT)

## 닫힘 조건

1. skill-embedding 또는 skill-rag-file이 Gemini 2, 768d로 동작한다.
2. rb8001이 새 임베딩 경로를 참조한다.
3. ChromaDB·pgvector 스키마가 768d로 통일된다.
4. Company X RAG, NAS RAG가 새 경로로 동작한다.
5. worklog에서 닫힘 선언한다.

## 재현 조건

- NAS RAG, Company X RAG, rb8001 메모리에서 임베딩 요청 시
- 0_VALUE 임베딩 정책과 로빙 구현을 대조할 때

## 확인된 사실

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

## 미확정 항목

- skill-embedding 교체 vs skill-rag-file 내부 직접 Gemini API 호출
- 청킹 단위 확대 적용 시점

## 이 문서가 여는 리서치

- [임베딩 1차 로빙 현황 및 SSOT 리서치](../research/rag/260316_임베딩_1차_로빙_현황_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)
- [임베딩 1차 로빙 Gemini 2 전환 계획](../plans/260316_임베딩_1차_로빙_Gemini2_전환_계획.md)
- [임베딩 2차 StarsAndI·GooseCouncil 전환 문제 오픈](./260316_임베딩_2차_StarsAndI_GooseCouncil_전환_문제오픈.md)
- [rb8001 메모리 ChromaDB 768/384 차원 드리프트](./260312_rb8001_memory_chromadb_768_384_dimension_drift.md)
- [skill-embedding 서비스 구축](./250805_happybell80_skill-embedding서비스구축.md)