- RAG 검색 품질은 LLM보다 corpus, chunking, embedding 설계에서 먼저 갈린다.
- Chunk가 크면 비용과 context가 늘고, 작으면 문맥이 끊긴다.
- Chunking과 embedding 모델은 함께 튜닝해야 한다.
RAG, 즉 Retrieval-Augmented Generation를 도입하면 대부분 이런 기대를 한다. “이제 사내 문서를 잘 찾아서 정확히 답해주겠지.”
하지만 실제로 구현해보면, RAG의 성능은 모델보다 훨씬 앞단의 설계 요소에서 갈리는 경우가 많다. 그 대표적인 요소가 바로 Chunking과 Embedding이다.
RAG 성능이 기대만큼 나오지 않는 이유
RAG 품질이 낮을 때 흔히 나오는 증상은 다음과 같다.
- 질문과 관련 없는 문서가 검색된다.
- 중요한 문서가 검색 결과에서 빠진다.
- 답변이 두루뭉술하다.
이때 많은 경우 문제는 LLM이 아니라 검색 단계, 더 정확히는 문서를 어떻게 쪼개고 어떤 방식으로 벡터화했는가에 있다.
Chunking은 단순 분할이 아니다
Chunking은 문서를 일정 길이로 나누는 작업처럼 보이지만, 실제로는 검색 단위 자체를 설계하는 과정에 가깝다.
Chunk가 너무 큰 경우
- 검색 결과는 맞을 수 있다.
- LLM에 전달되는 context가 불필요하게 길어진다.
- latency와 비용이 증가한다.
Chunk가 너무 작은 경우
- 검색은 많이 되지만 문맥이 끊긴다.
- 문서가 가진 의미가 약해진다.
고정된 정답 크기는 없다. 문서 구조와 질문 유형을 기준으로 시작값을 정하고, overlap 여부를 포함해 정답 문서 검색률과 비용을 반복 측정해야 한다. 제조 사양서, 상담 기록, 표 데이터에 같은 Chunk 크기를 일괄 적용하면 의미 경계가 달라질 수 있다.
Chunking은 자동화로 끝낼 문제가 아니라 RAG 품질을 좌우하는 핵심 튜닝 포인트다.
Embedding 모델 선택의 중요성
Chunking 다음으로 중요한 것이 Embedding 모델이다. Embedding은 텍스트를 벡터로 변환해 의미적 거리를 계산하게 만든다.
문제는 어떤 embedding 모델을 쓰느냐에 따라 “비슷하다”라고 판단하는 기준이 달라진다는 점이다.
특히 기업 환경에서는 도메인 특화 용어, 한국어 문맥, 기술 문서 표현이 일반적인 영어 중심 모델과 맞지 않는 경우가 많다.
그래서 embedding 모델은 처음 선택이 매우 중요하고, 변경 시에는 전체 corpus를 다시 embedding 해야 한다는 점도 고려해야 한다.
Chunking과 Embedding은 함께 튜닝해야 한다
실무에서 자주 겪는 실수는 chunking만 바꾸거나 embedding 모델만 바꾸는 것이다. 하지만 이 둘은 항상 세트로 움직인다.
- Chunk가 커지면 embedding이 잡는 의미도 달라진다.
- Embedding 모델이 바뀌면 적절한 chunk size도 달라진다.
그래서 RAG 품질 개선은 보통 다음 순서로 진행된다.
- Chunking 전략 조정
- Embedding 모델 비교
- 검색 결과 평가
- 다시 Chunking 미세 조정
이 과정을 거쳐야 검색이 잘 되는 RAG에 가까워진다.
문서 유형에 따라 Chunking 전략이 달라진다
| 전략 | 적합한 데이터 | 장점 | 주의점 |
|---|---|---|---|
| 고정 크기 + overlap | 긴 일반 문서, 메모, 상담 기록 | 구현이 단순하고 기준 비교가 쉽다 | 제목·표·문단 경계가 끊길 수 있다 |
| 문단·제목 기반 | 매뉴얼, 규정, 기술문서 | 의미와 문서 계층을 보존하기 쉽다 | 문서 형식별 전처리가 필요하다 |
| 행·레코드 기반 | 클레임, 정비, 견적, 센서 테이블 | ID와 필드 관계를 그대로 유지한다 | 텍스트 검색과 정확 일치 조건을 함께 설계해야 한다 |
| 질문·요약 메타데이터 | 복합 질문이 많은 지식베이스 | 검색 recall을 높일 수 있다 | 색인 비용과 갱신 복잡도가 증가한다 |
재현 가능한 자체 검증 방법
데모에 준비된 8개 대표 질문을 고정 평가셋으로 두고, Chunking 또는 Embedding 설정을 바꿀 때 동일 질문으로 다시 확인한다.
- 정답 레코드가 Top-k 안에 포함되는지 확인한다.
- 답변의 원인 후보가 반환 근거와 일치하는지 검토한다.
- 근거 없는 확정 표현과 잘못된 LOT·부품번호가 없는지 기록한다.
- 응답시간과 입력된 근거 수를 함께 비교한다.
2026-07-12 스모크 테스트에서는 “최근 A100 팬 소음 클레임” 질문에 9,065ms로 응답했고 티켓 테이블 근거 5건을 반환했다. 이는 1회 정상 동작 확인이며 Chunk 크기 간 우열을 증명하는 벤치마크는 아니다.
관련 Agent 데모
티켓·LOT·부품 이력을 레코드 단위 근거로 검색합니다.
데모 실행 ↗FAQ·매뉴얼·유사상담처럼 문서 유형이 다른 근거 검색을 확인합니다.
데모 실행 ↗장비·점검·서비스 문서의 구조화 검색 시나리오를 확인합니다.
데모 실행 ↗문서와 테이블 구조가 다른 16가지 RAG 시나리오를 확인합니다.
전체 데모 보기- Microsoft Learn · RAG solution design and evaluation — 평가 문서·질문과 검색 방식 선택
- Microsoft Learn · RAG chunking phase — 문서 구조별 Chunking 접근과 trade-off
- Microsoft Learn · Chunk enrichment — 제목·요약·키워드·질문 메타데이터 보강
작성·검증: KMWORKS AI Tech Lab. 공개 Reference Demo 01의 고정 질문과 반환 근거를 확인했으며, 수치 비교는 동일 데이터·질문·모델 조건에서 반복 측정할 때만 성능 결과로 사용한다.
정리하며
RAG에서 가장 흔한 오해는 “검색이 안 되면 모델을 바꾸면 된다”는 것이다. 하지만 비율을 일반화할 수는 없으며, 모델 교체 전에 corpus 품질, Chunking, Embedding과 검색 결과를 같은 평가셋으로 분리해 확인하는 것이 우선이다.
RAG 성능이 기대에 못 미친다면, LLM을 의심하기 전에 문서를 어떻게 쪼개고 어떻게 벡터화했는지부터 다시 보는 것이 훨씬 빠른 해결책이다.