LLM은 2024년까지만 학습되어 있고, 여러분 회사의 내부 문서는 모릅니다.
RAG(Retrieval-Augmented Generation)는 "LLM이 모르는 정보를 검색해서 컨텍스트로 넣어주는" 패턴입니다.
LLM의 지식 한계와 환각(Hallucination)을 모두 해결합니다.
1. RAG가 필요한 이유
LLM만 쓸 때의 문제
// 문제 1: 지식 한계 (Knowledge Cutoff)
// "우리 서비스의 2026 Q1 장애 원인이 뭔가요?"
// → LLM은 모름 (학습 데이터에 없음)
// 문제 2: 환각 (Hallucination)
// "우리 API 스펙이 어떻게 되나요?"
// → LLM이 그럴듯하게 지어냄 → 틀린 정보 제공
// 문제 3: 개인 데이터 없음
// "이 고객의 최근 주문 이력을 기반으로..."
// → LLM은 실시간 DB 접근 불가
RAG로 해결
// 1. 사용자 질문 → 관련 문서 검색
String query = "2026 Q1 장애 원인";
List<Doc> relevant = vectorDB.search(query, 5);
// 2. 검색된 문서를 컨텍스트로 주입
String prompt = """
아래 문서를 참고해서 답변해주세요:
---
%s
---
질문: %s
""".formatted(relevant.stream()
.map(Doc::getContent)
.collect(joining("\n\n")), query);
// 3. 근거 있는 답변 생성
String answer = llm.generate(prompt);
// → 문서에 기반한 정확한 답변
2. RAG 파이프라인 전체 흐름
── INDEX TIME (문서 사전 처리) ──────────────────
① 수집PDF/웹/DB에서 원본 문서 로드
② 청킹문서를 적절한 크기로 분할 (보통 512~1024 토큰)
③ 임베딩각 청크를 벡터로 변환 (Embedding 모델 호출)
④ 저장벡터 + 원본 텍스트 + 메타데이터를 Vector DB에 저장
── QUERY TIME (실시간 요청 처리) ────────────────
① 쿼리 임베딩사용자 질문을 벡터로 변환
② 검색Vector DB에서 유사도 Top-K 문서 검색
③ Re-ranking(선택) Cross-encoder로 정확도 향상
④ 프롬프트 조립시스템 프롬프트 + 검색 결과 + 사용자 질문
⑤ LLM 호출근거 기반 응답 생성 + 출처 인용
3. 청킹 전략 — 가장 중요한 설계 결정
고정 크기 청킹 — 단순하고 빠름
// 512 토큰씩 자르되 50토큰 겹침(overlap)
// 장점: 구현 쉬움
// 단점: 문장/단락 중간에 끊길 수 있음
List<String> chunks = new ArrayList<>();
int chunkSize = 512, overlap = 50;
String[] tokens = tokenize(text);
for (int i = 0; i < tokens.length; i += chunkSize - overlap) {
int end = Math.min(i + chunkSize, tokens.length);
chunks.add(join(tokens, i, end));
}
의미 단위 청킹 — 품질 좋음
// 단락/섹션 경계에서 자름
// 장점: 의미 완결성 유지 → 검색 품질↑
// 단점: 청크 크기가 불균일
// Markdown 섹션별 분리
String[] sections = text.split("\n## ");
for (String section : sections) {
if (tokenCount(section) > 1024) {
// 너무 크면 단락(\\n\\n) 단위로 재분할
for (String para : section.split("\n\n")) {
chunks.add(para.trim());
}
} else {
chunks.add(section.trim());
}
}
4. Hybrid Search — 키워드 + 벡터 결합
순수 벡터 검색의 한계
벡터 검색은 의미가 비슷한 문서를 잘 찾지만, 정확한 고유명사(제품명, 코드, 에러 메시지)는 놓칩니다.
예를 들어 "NullPointerException at OrderService.java:142"를 벡터로만 검색하면
"에러가 발생한 코드"라는 의미의 문서를 찾지, 정확한 파일명/라인 번호를 담은 문서는 못 찾습니다. Hybrid Search는 BM25 키워드 검색과 벡터 유사도 검색의 결과를 RRF(Reciprocal Rank Fusion)로 합쳐서
두 방식의 장점을 모두 취합니다. Weaviate는 이 기능이 내장되어 있고, Elasticsearch/OpenSearch도 kNN 쿼리를 지원합니다.
5. 면접 대비 핵심 Q&A
Q1. "RAG의 검색 품질을 높이는 방법은?"
세 가지 접근이 있습니다.
첫째, 청킹 개선입니다. 의미 단위(단락, 섹션)로 자르고, 작은 청크는 큰 청크의 요약을 함께 저장하는 Parent-Child 청킹을 씁니다.
둘째, Hybrid Search입니다. BM25 키워드 검색과 벡터 검색을 결합하면 정확한 고유명사도 놓치지 않습니다.
셋째, Re-ranking입니다. 벡터 검색으로 Top-20을 가져온 뒤, 더 정밀한 Cross-encoder 모델로 Top-5만 추려서 LLM에 주면 정확도가 크게 오릅니다.
Q2. "RAG와 Fine-tuning의 차이는? 언제 뭘 쓰나요?"
RAG는 LLM 가중치는 건드리지 않고 검색된 문서를 컨텍스트로 제공합니다.
데이터가 자주 업데이트되거나, 출처 인용이 필요하거나, 데이터가 기밀인 경우에 적합합니다.
Fine-tuning은 특정 스타일, 형식, 도메인 특수 용어를 LLM에 직접 학습시킵니다.
지식 추가보다는 응답 형식이나 어조를 조정할 때 효과적입니다.
실무에서는 "최신 내부 문서 기반 Q&A" → RAG, "회사 특유의 어조/형식 학습" → Fine-tuning으로 구분합니다.