개요

위키 의미 검색 시스템. sqlite-vec + BGE-M3 + bge-reranker-v2-m3 완전 로컬 (Hindsight/TencentDB 하이브리드+RRF 패턴)

메모

적용 완료 (2026-08-13) — ① wiki-embed-search 스킬 등록 ② wiki-sync.sh 자동 인덱싱 통합 (09/21시: 서버 자동 기동 → 재인덱싱, 위키 추가 시 검색 자동 반영) ③ PoC 실측: 58문서→512청크 ~2분, 의미 검색 정확 (muse-glimmer[경로] 1위, "채굴기 풀 설정"→bitaxe 1위) ④ bitaxe 엔티티 문서 작성으로 데이터 커버리지 해결. ARM64 실측 (sqlite-vec aarch64 wheel). 사용법: python3 [로컬] "검색어"

조사 상세

위키 임베딩 검색 시스템 — 조사 + 설계 (로컬 하이브리드 검색)

1. 현재 상태 (실측, 2026-08-13)

항목	현재
검색 도구	`search_files` — ripgrep 키워드/정규식 검색 (임베딩 없음)
인덱스	`log_index.md` (월별 자동 생성) + `` 구조
벡터 DB / 임베딩 / 리랭커	❌ 없음
위키 규모	75개 md (entities 46 / concepts 12 / 나머지 로그·설계)

한계: 키워드 일치만 가능 — "그때 조사했던 그 모델"처럼 단어가 기억나지 않거나 동의어/유사 개념을 쓴 문서는 검색 안 됨. 의미 기반 검색 도입 여지.

2. 참고 — 위키 메모리 시스템 조사에서 얻은 패턴

기존 조사 문서 (, )가 공통으로 쓰는 검색 구성:

시스템	저장	임베딩	리랭커	융합
Hindsight	PostgreSQL + pgvector	bge-small-en-v1.5	ms-marco-MiniLM-L-6-v2 (cross-encoder)	Semantic+BM25+Graph+Temporal → RRF + 재랭킹
TencentDB Agent Memory	SQLite + sqlite-vec	BGE-M3 등 (원격/로컬)	—	BM25 + 벡터 + RRF

→ 공통 결론: 하이브리드(키워드+벡터) + RRF 융합 + 크로스인코더 리랭커가 로컬 검색 품질의 정석. 둘 다 "완전 로컬"을 전제로 설계됨.

3. 로컬 서빙 가능한 시스템 비교 (실측 포함)

벡터 저장소

시스템	형태	ARM64	위키 규모(75문서) 판단
sqlite-vec (Mozilla Builders)	SQLite 확장, 파일 임베디드	✅ aarch64 wheel 실측 (0.1.9)	✅ 적합 — 인프라 0, DB 1개 파일
ChromaDB	파이썬 임베디드	✅	✅ 간단하나 metadata 필터 recall 이슈 (대규모 한계 — 위키엔 무관)
LanceDB	임베디드 (Lance 포맷)	✅	✅ 대규모 지향 — 위키엔 과함
Qdrant	서버형 (Rust)	✅ arm64 이미지 실측	⚠️ 확장성 최강이나 프로세스 1개 추가 운영
pgvector	PostgreSQL 확장	✅	❌ DB 인프라 필요 — Hindsight 경로지만 위키엔 과함

임베딩 모델 (로컬 서빙)

모델	크기	특징
BGE-M3 (BAAI)	568M (~2.3GB)	100+ 언어, 한국어 최강. dense+sparse+multi-vector 3-in-1
bge-reranker-v2-m3	~568M	크로스인코더 리랭커 (질문+문서 쌍 → 점수)
nomic-embed-text	137M	경량, 영어 중심
Qwen3-Embedding	다양	최신 (검토만)

서빙 경로 (GB10): ① llama.cpp 임베딩 서버 (GB10에 이미 구축 — ARM64 네이티브) ② Ollama 임베딩 API ③ embedding_api 오픈소스 (BGE-M3+reranker CPU 최적화, OpenAI [경로] 호환)

4. 설계 (권장안) — 위키 하이브리드 검색 (sqlite-vec + BGE-M3 + reranker)

[인덱싱 — wiki-sync.sh에 통합, 09/21시 자동]
위키 md 스캔 (entities[경로])
 → 섹션 단위 청킹 (## 헤더 기준, ~500자)
 → BGE-M3 로컬 임베딩 (llama.cpp 서버, OpenAI 호환)
 → sqlite-vec 저장: 문서 경로 / 섹션 / 벡터 / 메타(태그·날짜)
 → 인덱스 DB 1개 파일 (수십 MB) + 변경분만 증분 갱신

[검색 — wiki-search 스크립트]
① 쿼리 → BGE-M3 임베딩 → 벡터 top-K (의미 검색)
② ripgrep/BM25 키워드 top-K (기존 정확 매칭 유지)
③ RRF(Reciprocal Rank Fusion) 융합
④ (선택) bge-reranker-v2-m3 재랭킹 → 상위 5개 출력
 → Hermes가 결과 문서 읽어 답변

[운영]
- 전부 GB10 로컬 — 외부 API 없음, 비용 0
- Hermes 통합: 스킬로 `wiki-search "질문"` 제공 — 에이전트 조사 시작 시 하이브리드 검색
- 기존 ripgrep 검색은 유지 (폴백)

구성 요소 선택 근거

sqlite-vec: 위키 75문서 규모에서 서버형(Qdrant)은 과함. TencentDB가 같은 조합으로 검증. 파일 1개라 백업/이동 쉬움
BGE-M3: 한국어 최강 + 다국어 (위키에 한/영 혼재) + sparse 검색도 지원 (키워드 대체 가능)
reranker: 리랭킹은 검색 시에만 실행 (인덱싱 비용 0) — 20~30개 후보 중 상위 5개만 재점수 → GB10 CPU로도 충분 (bge-reranker-v2-m3 fp16 ~1GB)
RRF: Hindsight/TencentDB 모두 채택한 표준 융합 — 가중치 튜닝 불필요

5. 예상 효과 / 리스크

효과

의미 기반 검색: "그때 조사한 에이전트 메모리 시스템" → hindsight/tencentdb 자동 연결
동의어·한/영 혼재 문서 검색 가능 (기존 ripgrep의 사각지대 해소)
조사 시작 시 위키 탐색 품질↑ → 중복 조사·문서 누락 감소

리스크 / 부담

bge-m3 568M 상주 (~2.5GB) — GB10 128GB에 무시 가능
인덱스 갱신: wiki-sync 통합 시 문서 변경분만 증분 (수 초)
리랭커는 CPU 추론 (~수백 ms/20건) — 검색 시에만 부담
초기 구축: 스크립트 1~2개 (인덱서 + 검색기) + 임베딩 서버 기동

6. 적용 판단

위키 규모(75문서) → sqlite-vec + BGE-M3 + (선택) reranker 조합이 최적 — 제로 인프라, 완전 로컬, ARM64 실측 완료
Hindsight/TencentDB가 같은 패턴으로 벤치마크 검증 완료 (WideSearch +51%, PersonaMem 48→76%)
PoC 순서: ① llama.cpp 임베딩 서버 기동 ② 인덱서·검색기 프로토타입 ③ 위키 전체 인덱싱 ④ Hermes 스킬 등록 → 사장님 검토 후 실제 위키-sync 통합

7. PoC 실측 결과 (2026-08-13, GB10)

구성

임베딩: llama.cpp llama-server + BGE-M3 Q8 (634MB), 포트 8082, --ubatch-size 2048 필수 (기본 512는 긴 청크 500 에러)
리랭커: llama.cpp + bge-reranker-v2-m3 FP16 (1.16GB), 포트 8083 (--reranking)
저장: SQLite + sqlite-vec v0.1.9 (aarch64 wheel), `[로컬]
스크립트: wiki-index.py (인덱서) / wiki-search.py (검색기) / start-embed-server.sh (서버 기동·중지)

인덱싱

대상: entities[경로] 58문서 (내비게이션 문서 제외) → 503청크, 전체 인덱싱 ~2분 (배치 8)

검색 품질 테스트 (벡터+키워드 RRF+리랭커)

쿼리	1위 결과	판정
"Meta가 만든 로컬에서 돌아가는 에이전트 모델"	muse-glimmer-30b	✅ 정확
"그때 조사했던 에이전트 메모리 시스템"	tencentdb/hindsight	✅ 정확
"한국어 음성 합성 모델"	qwen3-tts	✅ 정확
"채굴기 풀 설정"	(관련 문서 없음)	⚠️ 데이터 부재

발견한 것들 (PoC 과정)

벡터 단독 검색은 매우 정확 — RRF 융합 시 키워드 OR 폴백이 노이즈를 만들어 AND 우선 + 벡터 가중치 2.0으로 해결
문서 단위 dedup 필요 — 같은 문서의 청크가 결과를 도배 → 문서별 최고 청크 1개만
내비게이션 문서 제외 필요 — research-backlog 같은 목록 문서가 리랭커에서 높은 점수 → SKIP 목록
⚠️ 데이터 커버리지 한계: bitaxe/채굴기 지식이 위키에 문서로 없음 (스킬·로그에만) — 검색 안 되는 게 정상. 위키 엔티티 문서 보강 필요 (예: bitaxe 엔티티)
llama.cpp 임베딩 서버는 --ubatch-size 기본 512 — 긴 입력 시 500 에러 → 2048로

사용법

# 서버 기동 (임베딩+리랭커) / 중지
bash [로컬]
bash [로컬] stop

# 인덱싱 (위키 변경 후)
python3 [로컬]

# 검색
python3 [로컬] "검색어"

출처

sqlite-vec: https://github.com/asg017/sqlite-vec (aarch64 wheel 실측, v0.1.9)
Qdrant: https://qdrant.tech (arm64 이미지 실측)
BGE-M3: https://huggingface.co/BAAI/bge-m3
bge-reranker-v2-m3: https://huggingface.co/BAAI/bge-reranker-v2-m3
embedding_api (BGE-M3+reranker CPU 서버): https://github.com/smallOpenSource/embedding_api
로컬 벡터 DB 비교 (2026): https://aliteq.com/best-vector-database-for-local-rag-2026
참고: / — 하이브리드+RRF+리랭커 패턴

Wiki Embedding Search — 위키 임베딩 검색 시스템 (로컬 하이브리드 설계)

개요

메모