happybell80 38eeb53587 docs: 260323 에이전트 협업 연구 자료 8건 — 로빙 개선·양자임베딩·세션관리

NAS shared-editing drafts에서 검증 완료된 연구 자료를 DOCS로 이관:

- research/: 양자 복소수 임베딩 팩트체크, 베이즈/힐베르트 대화 검토, 임베딩 한계 대조
- plans/: 로빙 성장 전 에이전트 중지 종합, 코드 기반 원인 분석 개선안
- ideas/: OpenAI/오픈라우터 하이브리드 세션 관리
- troubleshooting/: 로빙 슬랙 대화 문제 7에이전트 종합 보고서
- skills/: hwpx-skill 검증 메모

참여: 23-claude, 23-codex, 23-Cursor, 23-Gemini, 24-claude, 24-codex, 24-Cursor, 24-Gemini

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-03-23 18:04:40 +09:00

5.5 KiB

Executable File

Raw Permalink Blame History

writer, date, subject, tags

writer

date

subject

임베딩 모델의 현실적 한계와 로빙 현황 대조

Gemini와의 임베딩 관련 대화 내용을 정리하고, 로빙(rb8001)의 실제 구현과 대조합니다.

1. Gemini가 지적한 임베딩 한계 요약

1-1. 청킹의 맥락 단절

고정 크기로 텍스트를 자르면 문장 간 상관관계가 끊김
표/차트/이미지는 단순 임베딩으로 구조적 의미 포착 어려움

1-2. 의미와 키워드의 괴리

동음이의어 혼동 (사과 vs Apple)
부정어 처리 약점 ("A는 B가 아니다" vs "A는 B다"가 벡터 공간에서 가까움)

1-3. 차원의 저주와 비용

고차원 벡터 → 저장 용량 증가, 검색 지연
모델 변경 시 전체 재인덱싱 필수

1-4. 언어·도메인 편향

대부분 영어 기반 학습 → 한국어 조사/뉘앙스 처리 한계
특수 도메인 용어 인식 부족

2. 로빙의 현재 임베딩 구현

항목	현재 값
모델	gemini-embedding-2-preview (768차원)
벡터 DB	PostgreSQL pgvector (HNSW) + ChromaDB (레거시)
청크 크기	1000자, 오버랩 200자
검색 전략	하이브리드 (벡터 + 키워드 FTS + 파일명 + 그래프)
서비스 구조	skill-embedding(8515) → skill-rag-file(8508) → rb8001
멀티모달	텍스트 + 이미지 base64 지원

3. 한계 vs 로빙 현황 대조

청킹 맥락 단절

로빙 현황: 1000자 고정 + 200자 오버랩, 문장/단락 경계 최적화 있음
부족한 점: 오버랩이 200자로 짧음. 긴 논리 흐름(예: 계약서 조건 → 예외 → 벌칙)은 여전히 끊길 수 있음
개선 고려: 의미 단위 청킹(semantic chunking) 도입 — 임베딩 유사도가 급변하는 지점에서 분할

의미·키워드 괴리

로빙 현황: RRF(Reciprocal Rank Fusion)로 벡터+키워드 결합 → 이 부분은 이미 Gemini가 권한 "하이브리드 검색" 전략을 적용 중
부족한 점: Reranking 단계 없음. 1차 검색 결과를 그대로 사용
개선 고려: 검색 결과 상위 N개를 LLM으로 재정렬(reranking)하면 정밀도 상승

차원·비용

로빙 현황: 768차원은 적절한 수준. HNSW 인덱스로 검색 속도 최적화됨
리스크: 모델을 바꾸면 전체 재인덱싱 필요 (Gemini 지적대로)
현실적 판단: 현재 768차원 + HNSW 조합은 비용 대비 효율적. 당장 변경 불필요

한국어 편향

로빙 현황: gemini-embedding-2-preview는 다국어 지원이지만, 한국어 전문 용어(금융, 법률)에 대한 튜닝은 없음
실제 문제: 슬랙 대화에서 "fear & greed"를 금융 용어로 인식 못한 것이 이 한계의 실례
개선 고려: 자주 사용하는 도메인 용어 사전을 검색 쿼리 재작성에 반영 (임베딩 튜닝보다 비용 낮음)

4. 임베딩 벡터 계산 과정 (Gemini 설명 정리)

과거 방식 (Word2Vec)

각 단어의 고정 벡터를 산술 평균 → 어순/문맥 무시

현대 방식 (Transformer)

Attention으로 단어 간 상호작용 계산 후 풀링
CLS 토큰: 문장 앞 특수 토큰이 전체 정보 흡수
Mean Pooling: 모든 토큰 벡터의 평균 (가장 보편적, 로빙도 이 방식)
Max Pooling: 각 차원별 최댓값 추출
핵심: 평균을 내기 전에 이미 단어들이 문맥을 반영한 동적 벡터가 됨

5. 임베딩 튜닝 가능성

튜닝 기법

MNRL (Multiple Negatives Ranking Loss): (질문, 정답) 쌍만 있으면 학습 가능
Triplet Loss: (질문, 정답, 오답) 세트로 학습
LoRA: 적은 GPU 메모리(3~6GB)로 빠른 튜닝

로빙에 적용한다면

사내 문서/슬랙 대화에서 (질문, 정답문서) 쌍을 LLM으로 자동 생성 (Synthetic Data)
sentence-transformers로 오픈소스 모델(BGE 등) 튜닝 후 skill-embedding 교체
주의: 튜닝 후 전체 재인덱싱 필수

현실적 판단

현 단계에서 임베딩 튜닝은 우선순위 낮음
검색 품질 개선은 쿼리 재작성 + reranking이 ROI가 훨씬 높음
튜닝은 문서량이 충분히 쌓이고, 검색 실패 패턴이 명확해진 후에 검토

6. 23서버 클로드 의견 — 단기 개선 우선순위

순위	항목	이유
1	검색 쿼리 재작성	코드 변경 최소, 체감 효과 최대
2	Reranking 도입	검색 정밀도 즉시 향상
3	도메인 용어 사전	fear & greed 같은 케이스 방지
4	의미 단위 청킹	긴 문서 검색 품질 개선
5	임베딩 튜닝	장기 과제, 데이터 축적 후

Gemini가 제안한 features.md 추출 → 임베딩 파이프라인도 흥미롭지만, 현재는 기존 파이프라인의 검색 품질 개선이 먼저입니다.

23-server-cursor 추가 의견 (2026-03-23)

이론 한계와 로빙 스택 대조가 균형 잡혀 있고, 단기 ROI는 재작성·rerank·도메인 사전 순서에 동의합니다.
슬랙 사례의 "fear & greed"류는 임베딩 튜닝보다 검색 질의 레이어에서 먼저 막는 것이 비용 대비 맞습니다.
모델·차원 변경 시 재인덱싱 리스크는 문서/런북에 한 줄 SSOT로 남겨 두면 운영 혼선이 줄어듭니다.

— 23-server-cursor

5.5 KiB Executable File Raw Permalink Blame History