tags
tags
troubleshooting
embedding
gemini
rag
robeing
1차
임베딩 1차: 로빙 Gemini 2 전환 문제 오픈
상위 원칙
문제 정의
로빙의 임베딩 구조가 0_VALUE 임베딩 정책과 불일치한다.
0_VALUE 정책은 Gemini Embedding 2, 768d, 전수 교체, 멀티모달을 요구한다. 로빙 현재 구현은 이를 충족하지 않는다. (1차 범위: robeing만. StarsAndI·TheGooseCouncil는 2차 )
왜 문제인가
상태함수=벡터 철학 : 임베딩은 정보의 상태(ψ)를 벡터로 표현한다. 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 배포
닫힘 조건
skill-embedding 또는 skill-rag-file이 Gemini 2, 768d로 동작한다.
rb8001이 새 임베딩 경로를 참조한다.
ChromaDB·pgvector 스키마가 768d로 통일된다.
Company X RAG, NAS RAG가 새 경로로 동작한다.
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 호출
청킹 단위 확대 적용 시점
이 문서가 여는 리서치
관련 문서