핵심 요약
- RAG의 정확도는 LLM 성능 하나가 아니라 검색·데이터·검증 시스템 전체에서 결정됩니다.
- 가장 흔한 실패 원인은 모델이 아니라 나쁜 데이터와 잘못된 Chunking입니다.
- Vector Search만 믿지 말고 키워드 검색을 결합한 하이브리드 검색 + Reranking을 써야 합니다.
- 좋은 기업용 AI는 모르면 모른다고 답하고, 근거(출처)를 제시합니다.
- RAG는 만들고 끝이 아니라 정량 지표로 지속 평가·개선해야 합니다.
사내 데이터를 벡터DB에 넣고, 질문과 비슷한 문서를 찾아, LLM에 넣으면 끝. 많은 조직이 RAG를 이렇게 이해하고 시작합니다. 그런데 막상 붙여보면 관련 문서가 있는데 못 찾거나, 엉뚱한 부분을 가져오거나, 오래된 자료로 답하거나, 근거가 부족한데도 자신 있게 틀린 답을 내놓습니다.
결론부터 말하면, 기업용 RAG의 정확도는 어떤 LLM을 썼느냐보다 어떻게 설계했느냐에서 결정됩니다. 이 글에서는 RAG 정확도를 결정하는 전체 구조를 먼저 보고, 실무에서 정확도를 끌어올리는 7가지 방법을 순서대로 정리합니다.
RAG는 검색이 전부가 아니다 — 품질을 결정하는 전체 구조
많은 사람이 RAG = Vector Search라고 생각합니다. 하지만 실제 기업 환경에서 정확도를 좌우하는 것은 검색 이전과 이후에 붙는 여러 단계입니다.
데이터 품질 → 문서 구조화 → Chunking → Retrieval → Reranking → Context 구성 → LLM 생성 → 검증/Evaluation
즉 RAG는 단일 기능이 아니라 다음의 합입니다.
RAG = 검색 시스템 + 데이터 파이프라인 + LLM + 품질관리 시스템
이 정의가 중요한 이유는, 정확도가 낮을 때 대부분의 조직이 ‘LLM을 더 좋은 걸로 바꾸자’는 방향으로만 움직이기 때문입니다. 실제 병목은 보통 검색과 데이터 쪽에 있습니다.
방법 1. 좋은 데이터를 넣어라 — Garbage In, Garbage Out
기업 RAG에서 의외로 가장 큰 문제는 데이터 자체입니다. 회사 내부에는 다음처럼 서로 충돌하는 문서가 뒤섞여 있는 경우가 많습니다.
- 2024·2025·2026년 가격표가 동시에 존재
- 초안 / 수정본 / 최종본이 구분 없이 섞임
- 이미 퇴사한 담당자가 만든 옛 매뉴얼
이런 상태에서는 검색 성능이 아무리 좋아도 잘못된 답변이 나옵니다. 최신 가격표 대신 2024년 자료를 자신 있게 인용할 수 있기 때문입니다. 그래서 데이터에 다음과 같은 메타데이터를 붙여야 합니다.
| 메타데이터 | 역할 |
|---|---|
| 작성일 / 업데이트일 | 최신 문서 우선, 오래된 자료 필터링 |
| 문서 유형 / 버전 | 초안·최종본 구분, 유효 버전 지정 |
| 부서 / 제품 | 질문 맥락에 맞는 범위로 검색 제한 |
| 중요도 | 신뢰할 수 있는 출처에 가중치 부여 |
💡 핵심: 많은 데이터를 넣는 것보다 어떤 데이터를 믿어야 하는지 정의하는 것이 정확도를 좌우합니다.
방법 2. Chunking을 제대로 하라 — 의미 단위를 지켜라
대부분 ‘문서를 500자씩 잘라 넣자’로 Chunking을 끝냅니다. 하지만 의미 단위가 중간에 잘리면 검색 품질이 급격히 나빠집니다.
나쁜 Chunk 예시
Chunk A: “환불은 구매일로부터 7일 이내 가능합니다. 단, 디지털 상품의 경우”
Chunk B: “다운로드 이후에는 환불할 수 없습니다.”
검색이 Chunk A만 가져오면, AI는 ‘디지털 상품도 7일 내 환불 가능’이라고 정반대로 답합니다. 그래서 Chunking은 다음 방향으로 발전해야 합니다.
Fixed Chunking → Semantic / Structure-aware Chunking
고정 길이로 자르는 대신 제목·문단·FAQ·표·조항 등 문서 구조를 기준으로 분리하면 하나의 조건과 예외가 한 덩어리로 유지됩니다.
방법 3. Vector Search만 믿지 마라 — 하이브리드 검색
의미 유사도 기반의 Vector Search는 강력하지만 만능이 아닙니다. 기업 데이터에서는 정확한 문자열(코드·모델명·조항 번호)이 결정적일 때가 많기 때문입니다.
| 질문 | 유리한 검색 방식 |
|---|---|
| “AWS c7a.large 요금” | Keyword(BM25) — 정확한 문자열이 중요 |
| “서버 비용을 줄이는 방법” | Semantic(Vector) — 의미 유사도가 중요 |
그래서 두 방식을 결합한 하이브리드 검색이 유리합니다.
BM25(키워드) + Vector Search → Hybrid Retrieval
방법 4. 검색 결과를 다시 평가하라 — Reranking
일반적인 RAG와 고급 RAG를 가르는 지점이 바로 여기입니다. Vector DB가 20개의 후보 문서를 가져왔다고 해서, 그 순서가 곧 정답 순서는 아닙니다.
- Retriever(검색기): 후보를 넓게 찾는다 → 후보 찾기
- Reranker(재정렬기): 질문과 가장 관련 높은 순서로 다시 정렬한다 → 진짜 정답 찾기
Retriever가 넓게 던지고, Reranker가 정밀하게 좁힙니다. LLM에는 재정렬된 상위 3~5개만 넘기므로, 불필요한 문맥을 줄이고 정확도를 크게 올릴 수 있습니다.
방법 5. 질문 자체를 다시 만들어라 — Query Rewriting & Multi Query
사용자 질문은 생각보다 검색하기 어렵습니다. 예를 들어 “그거 환불돼요?”는 검색엔진 입장에서 정보가 턱없이 부족합니다.
Query Rewriting — 맥락으로 질문 보완
AI가 대화 맥락을 활용해 다음처럼 질문을 재작성합니다.
“그거 환불돼요?” → “디지털 콘텐츠 다운로드 이후 환불 가능 여부”
Multi Query — 하나의 질문을 여러 검색어로 분해
“강아지 심장병 초기 증상 알려줘”라는 질문을 여러 검색어로 확장한 뒤 결과를 통합합니다.
- 강아지 심장병 초기 증상
- 반려견 심장질환 임상징후
- 개 심장병 초기 진단
- canine heart disease early symptoms
이렇게 하면 표현이 조금 다른 문서까지 폭넓게 회수할 수 있어 검색 누락(Recall)을 줄입니다.
방법 6. 모르면 모른다고 하게 만들어라 — Grounding & Citation
기업용 AI에서 가장 중요한 원칙 중 하나입니다. 소비자용 AI는 어느 정도의 창작이 허용되지만, 기업 AI는 틀린 답 하나가 곧 리스크가 됩니다.
그래서 검색 결과의 신뢰도가 일정 수준 이하라면, 억지로 답을 만들지 않고 다음처럼 답하게 해야 합니다.
“제공된 자료에서는 확인할 수 없습니다.”
이를 위해 다음 장치를 적용합니다.
- Confidence Threshold: 신뢰도 기준 미달 시 답변 보류
- Citation / Source Link: 답변에 근거 문서·출처 링크 표시
- Answer Grounding: 답변이 실제 근거 문서에 기반하는지 확인
💡 좋은 기업용 AI는 모든 질문에 답하는 AI가 아니라, 답할 수 있는 질문을 구분하는 AI입니다.
방법 7. RAG도 테스트하라 — Evaluation 루프
많은 기업이 “몇 번 물어보니 잘 되던데?”로 RAG 개발을 끝냅니다. 그러면 안 됩니다. 실제 업무 질문 200개 규모의 평가셋을 만들어 정량적으로 측정해야 합니다.
| 항목 | 측정 내용 |
|---|---|
| Retrieval Recall | 정답 문서를 찾아냈는가 |
| Precision | 불필요한 문서를 얼마나 덜 가져왔는가 |
| Answer Correctness | 최종 답변이 맞는가 |
| Groundedness | 답변이 근거 문서에 기반하는가 |
| Citation Accuracy | 출처가 실제 답변을 뒷받침하는가 |
그리고 다음 개선 루프를 상시로 돌려야 합니다.
실패 질문 → 원인 분석 → Retrieval 개선 → 재평가
결국 잘 만든 RAG는 이렇게 생겼다 — 전체 아키텍처
사용자 질문
↓
Query Rewriting / Intent Classification
↓
Hybrid Search (Vector + Keyword)
↓
Metadata Filtering
↓
Top 20 Documents
↓
Reranker
↓
Top 3~5 Context
↓
LLM
↓
Grounding / Citation / Confidence Check
↓
최종 답변
그리고 이 흐름의 뒤에서 Evaluation → 실패 분석 → 지속 개선 루프가 별도로 돌아갑니다. 이 구조 전체가 갖춰졌을 때 비로소 ‘틀리지 않는’ 기업용 RAG에 가까워집니다.
Basic → Advanced → Enterprise: RAG의 3단계
RAG는 성숙도에 따라 세 단계로 나눌 수 있습니다. 본인 조직이 지금 어디에 있는지 점검해 보세요.
| 단계 | 구성 |
|---|---|
| Basic RAG | Document → Embedding → Vector DB → LLM |
| Advanced RAG | Hybrid Search + Query Rewrite + Reranker + Metadata |
| Enterprise RAG | Advanced RAG + 권한관리 + 데이터 최신성 + Citation + Evaluation + Monitoring |
대부분의 시행착오는 Basic RAG에 머문 채 Enterprise 수준의 정확도를 기대하기 때문에 발생합니다.
RAG 구축 전 반드시 함께 설계해야 할 6가지
기업용 RAG의 경쟁력은 어떤 LLM을 썼느냐보다 기업 데이터를 얼마나 정확하게 찾고·검증하고·관리할 수 있도록 설계했느냐에서 만들어집니다. 그래서 구축을 시작하기 전, 최소한 다음 6가지는 함께 설계해야 합니다.
- 데이터 구조 — 메타데이터·문서 유형·버전 정의
- 검색 방식 — 하이브리드 검색 여부와 가중치
- Reranking — 후보 재정렬 파이프라인
- 업데이트 정책 — 데이터 최신성 유지·폐기 규칙
- 출처 표시 — Citation·근거 링크
- 평가 시스템 — 정량 지표와 개선 루프
외주 업체를 검토할 때도 마찬가지입니다. “어떤 LLM을 쓰나요?”보다 “위 6가지를 어떻게 설계하나요?”를 물어야 진짜 실력을 가늠할 수 있습니다. RAG는 누구나 만들 수 있지만, 정확한 RAG는 다릅니다.
자주 묻는 질문
Q. RAG가 자꾸 틀리는데, 더 좋은 LLM으로 바꾸면 해결되나요?
대부분 해결되지 않습니다. 정확도 문제의 상당수는 데이터 품질, Chunking, 검색 방식에서 발생합니다. LLM은 검색이 좋은 근거를 넘겨줬을 때 좋은 답을 낼 수 있을 뿐, 잘못된 근거를 스스로 바로잡지는 못합니다. 검색·데이터 파이프라인을 먼저 점검하는 것이 순서입니다.
Q. Vector Search만 쓰면 안 되나요? 하이브리드 검색이 꼭 필요한가요?
모델명·요금제·조항 번호처럼 정확한 문자열이 중요한 질문에서는 의미 유사도 기반 Vector Search만으로는 놓치기 쉽습니다. 키워드 검색(BM25)과 결합한 하이브리드 검색을 쓰면 정확한 용어 매칭과 의미 매칭을 모두 잡을 수 있어 기업 데이터에 유리합니다.
Q. AI가 모르면 모른다고 답하게 하려면 어떻게 하나요?
검색 결과의 신뢰도 기준(Confidence Threshold)을 두고, 기준 미달 시 답변을 보류하도록 설계합니다. 여기에 출처 표시(Citation)와 답변 근거 검증(Answer Grounding)을 함께 적용하면, 근거가 부족할 때 ‘제공된 자료에서는 확인할 수 없습니다’라고 답하게 만들 수 있습니다.
Q. RAG 성능은 어떻게 측정하나요?
실제 업무 질문 기반 평가셋을 만들어 Retrieval Recall(정답 문서 회수), Precision(불필요 문서 최소화), Answer Correctness(답변 정확성), Groundedness(근거 기반성), Citation Accuracy(출처 신뢰성)를 측정합니다. 실패 질문의 원인을 분석해 검색을 개선하고 재평가하는 루프를 상시 운영해야 합니다.
