로컬 RAG 문서 질의응답, 직접 돌려본 속도·품질 비교 (임베딩·벡터DB·청킹)

로컬 RAG 문서 질의응답의 속도·품질은 LLM이 아니라 임베딩 모델·벡터DB·청킹이 가른다. 직접 비교하면 자체호스팅 품질 기본값은 BGE-M3(568M, 밀집+희소 하이브리드, MTEB 약 63)이고, CPU 노트북이라면 nomic-embed-text(137M·274MB·MTEB 62.4)가 맞다. 저장소는 빠른 검색이면 FAISS, 메타데이터 필터·영속성이면 Chroma다.

쉽게 말하면: RAG는 사서를 둔 도서관이다. 임베딩이 책을 주제별로 꽂고(검색 품질), 벡터DB가 그 서가에서 빨리 찾아오며(속도), 청킹이 책을 얼마나 잘게 자를지를 정한다.

우선 RAG가 한 질문에 답하기까지 데이터가 어떻게 흐르는지부터 보면 세 부품의 역할이 또렷해진다.

임베딩 모델은 무엇을 골라야 하나?#

검색 품질의 토대라 가장 중요하다. BGE-M3는 한 모델로 밀집(의미)·희소(키워드) 검색을 동시에 해 별도 키워드 인덱스 없이 하이브리드가 되고 100개 언어를 덮어, 2026년 자체호스팅 RAG의 사실상 기본값이다(MIT). nomic-embed-text는 137M·274MB로 GPU 없이 노트북 CPU에서 돌고 8192 토큰 컨텍스트라 Ollama에서 가장 많이 받는다. 초경량 엣지면 all-MiniLM-L6-v2가 가장 빠르다.

벡터DB는 FAISS와 Chroma 중 무엇인가?#

용도가 다르다. FAISS는 빠른 검색 라이브러리, Chroma는 애플리케이션 DB다. FAISS는 IVF·HNSW로 수십억 벡터를 밀리초에 검색하고 GPU 가속까지 되지만, 영속성·메타데이터 같은 DB 기능이 없다. Chroma는 임베디드형으로 50만 청크에서도 부서·날짜 같은 메타데이터로 걸러 약 20ms에 결과를 주고 재시작 후에도 데이터가 남는다. 대신 규모가 커지면 느려져, 한 실무자는 실험 반복 시 50~100배 느릴 수 있다고 했다. 빠른 프로토타입·메타데이터 필터는 Chroma, 대규모·최저지연은 FAISS(또는 Qdrant)다.

청킹이 왜 숨은 변수인가?#

광고된 컨텍스트 한계보다 훨씬 먼저 품질이 무너지기 때문이다. 한 벤치에서 상위 모델은 컨텍스트 안에선 만점이지만, BGE-M3도 8K에서 0.920으로 미끄러지고, 경량 모델(mxbai·nomic)은 4K자(약 1000토큰)만 돼도 검색 정확도가 0.4~0.6으로 급락했다. 특히 512토큰 모델은 문서 대부분을 잘라버린다. 즉 경량 모델일수록 청크를 작게 쪼개야 한다.

직접 측정하려면?#

내 데이터로 재라. MTEB 점수는 내 문서를 대변하지 않는다(MTEB v2는 v1과 직접 비교도 안 된다).

• 같은 질문 20~50개로 모델별 Top-k 정답 포함률(recall)과 임베딩 시간을 비교한다.
• 벡터DB는 VectorDBBench 같은 도구로 같은 데이터에서 지연·처리량을 공정하게 잰다.
• 청크 크기(256·512·1024 토큰)를 바꿔가며 recall이 어디서 꺾이는지 찾는다.

참고: MTEB·지연 수치는 2025~2026년 공개 측정치이며 데이터·버전·하드웨어에 따라 달라진다(MTEB는 내 도메인과 다를 수 있음). 정확한 값은 본문 방법으로 내 문서에 직접 측정하라. 모델·도구는 자주 바뀌니 분기별 갱신.

참고 링크#

• BGE-M3 / FlagEmbedding(레포)
• nomic-embed-text(모델 카드)
• FAISS(레포)
• Chroma(레포)
• MTEB 리더보드