happybell80
60a892e5ab
SSOT는 로컬 0_VALUE/. GitHub URL은 복사본 참조로 SSOT 원칙 위반. 02_Governance는 존재하지 않는 구 경로로 전부 깨진 링크. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
7.4 KiB
7.4 KiB
status, closed_date, closed_reason, tags
| status | closed_date | closed_reason | tags | ||||||
|---|---|---|---|---|---|---|---|---|---|
| closed | 2026-03-21 | 260320 다형식문서 RAG 계획으로 흡수 또는 구현 완료 |
|
status: closed closed_date: 2026-03-21 closed_reason: 260320 다형식문서 RAG 계획으로 흡수 또는 구현 완료
임베딩 1차: 로빙 Gemini 2 전환 문제 오픈
상태
- closed
상위 원칙
문제 정의
로빙의 임베딩 구조가 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차 결정 고정
- 대상 레포:
skill-embedding,skill-rag-file,rb8001,DOCS - 공식 경로: 1차 대상 서비스는 모두
skill-embedding만 공식 임베딩 게이트웨이로 사용합니다. - 모델/차원:
Gemini Embedding 2,768d - 입력 범위: 텍스트, PDF, 이미지까지 1차 닫힘 범위에 포함합니다.
- 메모리 범위:
rb8001메모리 차원 드리프트도 1차에서 함께 닫습니다. - 혼재 정책: 1차 대상 범위 안에서는
384/768혼재를 닫힘 상태로 인정하지 않습니다. - 새 자료 정책: 앞으로 들어오는 새 정보/자료도 모두 같은 경로와 차원을 따라야 합니다.
- 배포 기준: 문서·코드·로컬 검증만으로는 닫지 않고, 실제 배포와 운영 검증까지 완료돼야 닫습니다.
- 검증 강도: 자동 테스트 + 대표 질문셋 수동 검증 + 운영 구조화 로그를 모두 닫힘 근거로 요구합니다.
- fallback 정책: 배포 중 일시적 구형 임베딩 fallback은 허용할 수 있으나, fallback 발생은 구조화 로그로 남겨야 하며 최종 닫힘 시점에는 제거돼야 합니다.
- 재임베딩 시작점: Company X 문서 컬렉션과
rb8001메모리 컬렉션을 우선 정리하고, 이후 1차 대상 레포의 기존 데이터로 확장합니다.
기대 상태 (1차 닫힘 기준)
| 항목 | 내용 |
|---|---|
| 모델 | Gemini Embedding 2 |
| 차원 | 768 (MRL) |
| 경로 | skill-embedding 교체 (ONNX→Gemini 2) |
| 적용 | robeing 전역 (skill-embedding, skill-rag-file, rb8001) |
| env | workspace-config SSOT, 서비스별 오버라이드 금지 |
| 멀티모달 | PDF·이미지 직접 임베딩 |
| 청킹 | 1차 Micro 유지, 2단계 Macro 검토 |
| 운영 데이터 | 1차 대상 범위에서 신규/기존 데이터 모두 768d 단일 경로로 수렴 |
| 메모리 | rb8001 메모리 컬렉션까지 768d로 정리되어 차원 드리프트 로그가 사라짐 |
영향 범위 (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,EMBEDDING_MODEL반영됨 (SSOT)
닫힘 조건
- skill-embedding이 Gemini 2, 768d로 동작한다. (경로: skill-embedding 교체 확정)
- rb8001·skill-rag-file이 기존 /embed URL로 새 모델을 참조한다.
skill-rag-file컬렉션과rb8001메모리 컬렉션에서 384/768 혼재가 제거되고, ChromaDB·pgvector가 768d로 통일된다.- Company X RAG와
rb8001메모리 저장/검색이 새 경로로 동작한다. - PDF·이미지 직접 임베딩이 동작하고, 검색 품질은 대표 질문셋 기준 기존 대비 유지 또는 개선된다.
- 자동 테스트, 수동 질문셋 검증, 운영 구조화 로그가 모두 남는다.
- 실제 배포 후 fallback 없이 운영 경로가 Gemini 2 단일 경로로 유지된다.
- worklog와 배포/검증 근거 문서에서 닫힘 선언한다.
재현 조건
- NAS RAG, Company X RAG, rb8001 메모리에서 임베딩 요청 시
- 0_VALUE 임베딩 정책과 로빙 구현을 대조할 때
확인된 사실
- 0_VALUE 임베딩 정책 확정: Gemini 2, 768d, 전수 교체, 멀티모달
- 리서치(260315)에서 Gemini Embedding 2 특징·비용·청킹 전략 정리됨
robeing/tests/test_gemini_embedding_2.pyAPI 테스트 존재, 확장 예정- 기존 데이터 적음 → 전수 교체 부담 낮음
- workspace-config env SSOT: 로빙 전역이 따르고 서비스별 오버라이드 금지
확정 항목 (리서치·계획 반영)
- 경로: skill-embedding 교체 (ONNX→Gemini 2). 리서치 §7
- 청킹: 1차는 기존 Micro 유지. 2단계에서 Macro 검토. 리서치 §8
- 메모리:
rb8001메모리 차원 드리프트도 1차 닫힘 범위에 포함 - 배포/검증: 실제 배포, 구조화 로그, 대표 질문셋 검증까지 확보해야 닫힘