개인정보 안 보내는 Nomic Embed 로컬 RAG, 무엇으로 판단하나
요약: Nomic Embed란 문장과 문서를 벡터로 바꾸는 오픈소스 임베딩 모델로, 인터넷 연결 없이 로컬에서 완전히 실행되어 원문과 검색 질의가 외부 서버로 전송되지 않아 개인정보 잔류와 로그를 사용자가 직접 통제할 수 있는 로컬 RAG 전용 임베딩이다. 즉 '밖으로 안 보낸다'는 말의 근거는 마케팅 문구가 아니라, 모델 가중치가 내 디스크에 있고 추론이 내 CPU 또는 GPU에서 끝난다는 실행 구조 그 자체다.
Nomic Embed란 문장과 문서를 벡터로 바꾸는 오픈소스 임베딩 모델로, 인터넷 연결 없이 로컬에서 완전히 실행되어 원문과 검색 질의가 외부 서버로 전송되지 않아 개인정보 잔류와 로그를 사용자가 직접 통제할 수 있는 로컬 RAG 전용 임베딩이다. 즉 '밖으로 안 보낸다'는 말의 근거는 마케팅 문구가 아니라, 모델 가중치가 내 디스크에 있고 추론이 내 CPU 또는 GPU에서 끝난다는 실행 구조 그 자체다.
first_response_latency_ms 120.8 ms
Hax가 자체 인프라에서 직접 측정한 실측값은?#
아래는 Hax가 자체 인프라에서 직접 계측·공개한 참고 수치입니다(측정값, 출처 표기).
| 데이터 항목 | 실측값 | 날짜 | 출처 |
|---|---|---|---|
| first_response_latency_ms | 120.8 ms | 2026-07-04 | bench_harness.probe_unified_latency |
| 저장된 메모리 수 | 10839 개 | 2026-07-23 | bench_harness.probe_curator (curator stats 실측) |
| 활성 메모리 수 | 10495 개 | 2026-07-23 | bench_harness.probe_curator (curator stats 실측) |
- 표본
- 실측 지표 3개 (Hax /data 큐레이션)
- 수집일
- 2026-07-04 ~ 2026-07-23
- 방법
- bench_harness.probe_unified_latency; bench_harness.probe_curator (curator stats 실측)
이 수치는 어떻게 재현하나?#
측정 방법은 표의 출처와 우리 공개 데이터셋(/data)에서 확인할 수 있습니다.
| 항목 | Hax 실측 | 클라우드 임베딩 API(추정) |
|---|---|---|
| 활성 벡터·메모리 수 | 10,495개(측정 2026-07-23) | 계정 종속·외부 보관(추정) |
| 평균 신뢰도 | 0.6161(측정 2026-07-23, 원값 0.6161051567178863) | 비공개(추정) |
| recall@5 | 측정대기 | 로컬 약 0.82(추정) |
| 디스크 풋프린트 | 측정대기 | 모델 약 274MB(추정, F16) |
| 원문 외부 전송 | 없음(로컬 실행) | 있음(추정) |
활성 로컬 메모리 10,495개·평균 신뢰도 0.6161
로컬 RAG는 무엇으로 판단하나#
로컬 RAG의 품질은 세 축으로 갈린다. 첫째 검색 정확도(recall@5), 둘째 디스크·메모리 풋프린트, 셋째 데이터 잔류·로그 정책이다. 이 중 앞의 둘은 성능표에 자주 오르지만, 프라이버시를 이유로 로컬을 택한 사람에게 실제로 결정적인 것은 셋째다.
recall@5란 질의에 대한 정답 문서가 상위 5개 검색 결과 안에 들어오는 비율(0~1)이다. Nomic Embed Text v1.5는 768차원 임베딩과 8192 토큰 문맥을 지원하며(추정), 공개 벤치마크에서 상위권 오픈 임베딩과 비슷한 recall을 낸다고 알려져 있다(추정 약 0.82). 다만 이 값은 데이터셋과 청킹 전략에 크게 좌우되므로, 내 문서로 직접 측정하기 전에는 추정치로만 다뤄야 한다. 모델 파일은 약 274MB(추정, F16 기준)이며 여기에 벡터 인덱스가 문서 규모에 비례해 더해진다.
데이터 잔류와 로그가 진짜 판단 기준이다#
로컬 실행의 핵심 이점은 '데이터 잔류'의 정의권이 사용자에게 있다는 점이다. 클라우드 임베딩 API는 요청 본문이 제공사 로그나 파이프라인에 남을 수 있다(추정). 반면 로컬 Nomic Embed는 원문이 프로세스 메모리를 벗어나지 않으므로, 로그를 끄면 잔류는 0에 수렴한다.
그러나 로컬이라고 잔류가 저절로 관리되지는 않는다. Hax가 운영하는 로컬 메모리 스토어의 실측이 이를 잘 보여준다. 2026-07-04 활성 8,919개·평균 신뢰도 0.721(측정)에서 2026-07-23 활성 10,495개·평균 신뢰도 0.6161(측정)로, 약 19일 동안 메모리는 1,576개 늘고 평균 신뢰도는 0.105 내려갔다(측정값 기반). 저장은 append로 쉽게 늘지만, 무효화·삭제 같은 정리를 게을리하면 평균 신뢰도가 꾸준히 희석된다는 뜻이다. 로컬 RAG를 데이터 잔류·로그 정책으로 '판단'한다는 말의 실체가 이것이다. 봐야 할 지표는 저장량이 아니라 활성 대비 신뢰도와 잔류 정책이다.
판단 체크리스트#
로컬 Nomic Embed RAG를 도입할 때 다음을 실제로 측정하거나 설정으로 확인하라. (1) 내 문서로 recall@5를 직접 재서 추정치를 실측으로 바꾼다. (2) 모델 파일과 벡터 인덱스가 차지하는 디스크를 합산한다. (3) 임베딩 서버·인덱서의 로그 레벨을 낮추고 원문 로깅을 끈다. (4) 무효화·삭제 루틴을 정기화해 활성 대비 신뢰도를 관리한다. 이 넷을 갖추면 '개인정보를 밖으로 안 보낸다'는 주장이 실행 구조와 운영 정책 양쪽에서 성립한다.
FAQ#
Q. 로컬이면 무조건 안전한가. A. 전송은 막히지만 잔류는 로그·인덱스 정리 정책에 달려 있다. 위 실측처럼 신뢰도는 관리 없이는 희석된다.
Q. recall@5 0.82는 믿어도 되나. A. 추정치다. 데이터셋 의존이 커서 내 코퍼스로 재측정 전에는 참고선으로만 쓰라.
참고: Nomic Embed 사양과 recall 수치는 2026-07 시점 공개 자료 기반 추정이며, 표와 본문의 메모리 스토어 수치만 실측이다. 근거는 Hax data의 bench_harness.probe_curator 기록이다.
함께 읽기: Nomic Embed 로컬 RAG, 클라우드 비용을 줄일까, 로컬 RAG 청킹 전략 — 문서 쪼개기가 검색 품질을 좌우한다
종합 가이드: 노트북에서 돌리는 AI 모델, 흔한 함정과 해결법
Responses
No responses yet. Be the first to respond.