로컬 RAG 문서 질의응답, 5분 시작 가이드
요약: 로컬 RAG는 5분이면 시작하고, 핵심은 내 문서를 '쪼개→임베딩→검색→LLM이 인용과 함께 답'하게 잇는 것이다. 초보는 코드 없이 AnythingLLM(문서 특화)이나 Open WebUI(범용, RAG 내장)를 Ollama 위에 올리면 된다. 그런데 단 하나의 결정이 한국어 성패를 가른다 — 기본 임베딩 nomic-embed-text는 영어 전용이라 한국어 의미 검색이 실패한다. 한 벤치에서 검색 정확도가 측정상 bge-m3 72% 대 nomic 57%였다. 그러니 한국어면 무조건 bge-m3를 임베딩 모델로 골라라.
로컬 RAG는 5분이면 시작하고, 핵심은 내 문서를 '쪼개→임베딩→검색→LLM이 인용과 함께 답'하게 잇는 것이다. 초보는 코드 없이 AnythingLLM(문서 특화)이나 Open WebUI(범용, RAG 내장)를 Ollama 위에 올리면 된다. 그런데 단 하나의 결정이 한국어 성패를 가른다 — 기본 임베딩 nomic-embed-text는 영어 전용이라 한국어 의미 검색이 실패한다. 한 벤치에서 검색 정확도가 측정상 bge-m3 72% 대 nomic 57%였다. 그러니 한국어면 무조건 bge-m3를 임베딩 모델로 골라라.
쉽게 말하면: RAG는 오픈북 시험이다. LLM이 전부 외우는(파인튜닝) 대신, 질문이 오면 내 노트(문서)에서 관련 쪽을 펴서(검색) 보고 답한다 — 그래서 노트 정리(청크)와 찾기 실력(임베딩)이 점수를 정한다.
용어부터 정리하자. RAG(Retrieval-Augmented Generation, 검색증강생성)는 LLM이 답하기 전에 내 문서에서 관련 조각을 먼저 찾아와 근거로 삼는 방식이다. 임베딩(embedding)은 문장을 '의미 좌표(숫자 벡터)'로 바꾸는 것 — 뜻이 비슷하면 좌표가 가깝다. 청크(chunk)는 문서를 검색 단위로 쪼갠 조각이고, top-k는 질문마다 가장 가까운 조각 k개를 꺼내오는 것이다.
최소 RAG는 무엇으로 이루어지나?#
쪼개기→임베딩→벡터저장→top-k 검색→답변 다섯 조각이다. ① 문서를 청크(조각)로 쪼개고, ② 임베딩 모델이 각 조각을 의미 벡터로 바꾸고, ③ 벡터 DB에 저장한다(AnythingLLM은 LanceDB 내장이라 설정 0). ④ 질문이 오면 가장 비슷한 top-k 조각을 꺼내, ⑤ LLM이 그 조각을 근거로 인용과 함께 답한다. 도구만 깔면 이 배선은 자동이고, 초보는 기본값 + bge-m3로 바로 시작하면 된다.
다섯 조각이 어떻게 이어지는지 그림으로 보자. 위 세 단계는 문서를 넣을 때 한 번, 아래 두 단계는 질문할 때마다 돈다.
| 구성요소 | 추천 | 왜 |
|---|---|---|
| 런타임 | Ollama(도커) | LLM+임베딩을 한 번에 |
| 프런트엔드 | AnythingLLM·Open WebUI | 노코드·RAG 내장·인용 |
| 임베딩 | bge-m3 | 다국어·8K·검색 정확도 측정상 72% |
| 청크/겹침 | 약 1000 / 100 | 너무 작으면 의미 빈약 |
| top-k | 3~5 | 늘리면 문맥창 먼저 키워야 |
| 리랭커 | bge-reranker(나중) | 기본 동작 후 정밀도↑ |
한국어면 무엇을 가장 조심하나?#
임베딩 모델과 문맥창 두 가지다. 첫째, 영어 전용 임베딩(nomic)으로 한국어 문서를 넣으면 같은 뜻의 한·영 문장이 안 붙어 검색이 헛돈다 → bge-m3(MIT·100여 언어·8K 토큰)로 바꾼다. 둘째, Ollama 기본 문맥창이 2048토큰이라 꺼내온 조각이 다 안 들어가 RAG가 반쪽이 된다 → 8192+로 키운다(가장 흔한 초보 실패 둘). 그리고 임베딩 모델을 바꾸면 기존 문서를 반드시 재색인하라 — 벡터는 같은 모델에서 나와야 의미가 맞다.
영어 전용 임베딩이 왜 한국어에서 헛도는지 그림으로 보자. 같은 뜻의 한·영 문장이 좌표상 멀리 떨어지면 검색이 못 붙인다.
초보가 자주 막히는 곳은?#
검색 품질·청크·인용 세 가지가 초보 RAG에서 가장 자주 막히는 지점이다.
- 검색이 핵심: 쓰레기를 꺼내오면 답도 쓰레기다. RAG는 나쁜 검색을 못 고친다 → 임베딩·청크부터 맞춘다.
- 청크: 너무 작으면 의미가 빈약해 검색이 나빠진다 → 최소 청크 크기를 키워 작은 조각을 병합한다.
- 인용: 출처(인용)가 없으면 검증 불가다. 인용을 켜고 답의 근거 조각을 확인하라.
문맥창이 작으면 왜 RAG가 반쪽이 되는지도 그림으로 보자. 꺼내온 조각이 2048토큰을 넘으면 뒷부분이 잘려 LLM이 못 본다.
직접 5분 안에 해보려면?#
가장 쉬운 길부터 차례로 밟으면 5분 안에 첫 인용 답변까지 확인할 수 있다.
- Ollama로 LLM과 bge-m3 임베딩을 받고(한국어면 필수), AnythingLLM이나 Open WebUI에 문서를 넣는다.
- 문맥창을 8192+로 키우고, 기본 청크/ top-k로 몇 개 질문을 던져 인용을 확인한다.
- 품질이 부족하면 한 번에 하나씩(청크→top-k→리랭커) 바꾸고, 벤치보다 내 문서로 재라.
참고 링크
- Ollama(LLM+임베딩 런타임)
- Open WebUI(범용 프런트·RAG)
- AnythingLLM(문서 특화 RAG)
- BGE-M3/FlagEmbedding(다국어 임베딩)
- LlamaIndex(RAG 프레임워크)
참고: 정확도·설정 수치는 2026년 공개 측정·가이드 기준이며 문서·언어·임베딩·청크에 따라 달라진다. 임베딩을 바꾸면 재색인이 필요하고, 정확한 품질은 내 문서로 직접 측정하라(리더보드는 출발점일 뿐). RAG 도구는 자주 갱신되니 분기별로 다시 본다.
Responses
No responses yet. Be the first to respond.