docs: Gemini Embedding 2 멀티모달 직접 임베딩 전환 방향 명시

리서치 Fact 17: PDF만이 아닌 이미지/docx 등 모든 파일 형식을 텍스트
변환 없이 직접 임베딩해야 함을 명시. 현재 텍스트 변환 파이프라인이
Gemini Embedding 2 전환의 의미를 절반 이상 버리는 것임을 지적.
계획 Phase 0: 인덱싱 파이프라인 전환 항목 추가 (미완료).
계획 구현 원칙: 멀티모달 직접 임베딩 전환 플로우 및 기존 텍스트 추출
파이프라인 제거 방향 명시.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

journey/plans/260315_companyx_rag_답변합성_시나리오동시종결_계획.md

@@ -86,6 +86,10 @@ tags: [plans, companyx, rag, answer-composition, scenario, troubleshooting]
   - `내부 문서만으로는 단정 불가`
 
 ## 4. 구현 원칙
+- **인덱싱 파이프라인 전환**: 텍스트 변환 후 청킹하는 현재 방식을 Gemini Embedding 2의 멀티모달 직접 임베딩으로 전환합니다.
+  - 대상: PDF, 이미지, docx 등 모든 파일 형식 — 텍스트 추출 없이 원본 파일 직접 임베딩
+  - 제한: 텍스트 8,192 토큰, PDF 6페이지 단위, 영상 120초, 오디오 80초
+  - 기존 텍스트 추출 파이프라인(pdftotext, PyPDF2, OCR)은 제거 대상
 - **RAG 구조 전환**: 현재 규칙 기반 문자열 조합은 RAG가 아닙니다. 검색된 청크를 컨텍스트로 LLM에 전달해 답변을 생성하는 구조로 전환합니다.
   - 플로우: 질문 임베딩 → pgvector 유사도 검색 → 적합 청크 선별 → LLM 컨텍스트 전달 → 답변 생성
   - LLM: 현재 rb8001 기준 모델 사용 (gpt-4o-mini 계열)
@@ -107,7 +111,7 @@ tags: [plans, companyx, rag, answer-composition, scenario, troubleshooting]
 | SKILL.md 전제 | `384d` → `Gemini Embedding 2 / 768d` 갱신 완료 (2026-03-17) | **확정** |
 | 저장 경로 (rb8001 메모리) | PostgreSQL `memory_vectors` 등 중심 전환 확인 | **확정** |
 | 저장 경로 (skill-rag-file 문서 청크) | 현재 ChromaDB(`/app/chroma_db`) 저장 중. 운영 원칙(PostgreSQL 중심)과 불일치. PostgreSQL(pgvector)로 전환 필요 | **미완료** |
-| 청킹 리스크 | `char_per_token = 4` 한국어 과소 청킹 리스크 인지. Gemini 2 PDF 직접 임베딩은 미구현 상태로 인지하되, 이 문제 세트 스코프 밖 | **인지/보류** |
+| 인덱싱 파이프라인 | 현재 모든 파일을 텍스트 변환 후 청킹. Gemini Embedding 2의 멀티모달(PDF, 이미지, docx 등 직접 임베딩) 능력을 미활용. 원본 파일 직접 임베딩으로 전환 필요 | **미완료** |
 | NAS 동기화 경로 | NAS → skill-rag-file 반영 경로/시점 미확인. Phase 5에서 검증 후 Phase 0 표에 반영 | **미완료** |
 | 재오픈 질문 20개 재현 | Slack 실응답 재현 미실시 | **미완료** |
 

journey/research/260315_companyx_rag_답변합성_시나리오동시종결_리서치.md

@@ -184,12 +184,16 @@ tags: [research, companyx, rag, answer-composition, scenario, troubleshooting]
 - 근거 문서:
   - https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/research/260313_internal_nas_direct_go_sync_feasibility_research.md
 
-### 17. 현재 청킹은 한국어 기준 과소 청크를 만들 가능성이 높다
-- `skill-rag-file/app/services/chunking.py`는 `char_per_token = 4`로 고정하고, `max_tokens * char_per_token`로 청크 크기를 계산합니다.
-- 이 값은 **영어 기준 근사**이며, 한국어는 통상 `1~2자 ≈ 1토큰` 범위로 알려져 있어 현재 방식이면 **실제보다 작은 청크**가 생성될 가능성이 큽니다.
+### 17. 현재 텍스트 변환 기반 청킹은 Gemini Embedding 2의 멀티모달 능력을 전혀 활용하지 못하고 있다
+- `skill-rag-file`은 모든 파일(PDF, 이미지, docx 등)을 텍스트로 변환한 뒤 문자 단위로 청킹합니다.
+- Gemini Embedding 2는 텍스트뿐 아니라 **이미지, PDF, 오디오, 비디오를 직접 임베딩**할 수 있는 멀티모달 모델입니다. 텍스트 변환 없이 원본 파일을 그대로 넣을 수 있습니다.
+- 현재 방식의 문제:
+  - PDF: pdftotext/PyPDF2로 텍스트 추출 시 레이아웃, 표, 이미지 정보 손실
+  - 이미지 문서: 텍스트 변환 불가하거나 OCR로 품질 저하
+  - `char_per_token = 4` 한국어 과소 청킹으로 정보 단절
 - 의미:
-  - 한국어 문서가 많은 Company X 경로에서는 과도한 청킹으로 **검색 품질/비용/속도**에 영향을 줄 수 있습니다.
-  - Gemini Embedding 2 전환 여부와 별개로 **청킹 근사값 자체가 리스크**로 남아 있습니다.
+  - 임베딩 모델을 Gemini Embedding 2로 바꿨으면, 인덱싱 파이프라인도 **원본 파일 직접 임베딩** 방식으로 전환해야 일관성이 있습니다.
+  - 텍스트 변환 파이프라인을 유지하는 것은 Gemini Embedding 2로 전환한 의미를 절반 이상 버리는 것입니다.
 
 ## 해석(Interpretation)