RAG 성능은 Chunking과 Embedding에서 갈린다

RAG, 즉 Retrieval-Augmented Generation를 도입하면 대부분 이런 기대를 한다. “이제 사내 문서를 잘 찾아서 정확히 답해주겠지.”

하지만 실제로 구현해보면, RAG의 성능은 모델보다 훨씬 앞단의 설계 요소에서 갈리는 경우가 많다. 그 대표적인 요소가 바로 Chunking과 Embedding이다.

RAG 성능이 기대만큼 나오지 않는 이유

RAG 품질이 낮을 때 흔히 나오는 증상은 다음과 같다.

• 질문과 관련 없는 문서가 검색된다.
• 중요한 문서가 검색 결과에서 빠진다.
• 답변이 두루뭉술하다.

이때 많은 경우 문제는 LLM이 아니라 검색 단계, 더 정확히는 문서를 어떻게 쪼개고 어떤 방식으로 벡터화했는가에 있다.

Chunking은 단순 분할이 아니다

Chunking은 문서를 일정 길이로 나누는 작업처럼 보이지만, 실제로는 검색 단위 자체를 설계하는 과정에 가깝다.

Chunk가 너무 큰 경우

• 검색 결과는 맞을 수 있다.
• LLM에 전달되는 context가 불필요하게 길어진다.
• latency와 비용이 증가한다.

Chunk가 너무 작은 경우

• 검색은 많이 되지만 문맥이 끊긴다.
• 문서가 가진 의미가 약해진다.

그래서 실무에서는 보통 500~1,000 token 수준에서 시작하고, overlap을 두고, 질문 유형에 따라 반복적으로 튜닝한다.

Chunking은 자동화로 끝낼 문제가 아니라 RAG 품질을 좌우하는 핵심 튜닝 포인트다.

Embedding 모델 선택의 중요성

Chunking 다음으로 중요한 것이 Embedding 모델이다. Embedding은 텍스트를 벡터로 변환해 의미적 거리를 계산하게 만든다.

문제는 어떤 embedding 모델을 쓰느냐에 따라 “비슷하다”라고 판단하는 기준이 달라진다는 점이다.

특히 기업 환경에서는 도메인 특화 용어, 한국어 문맥, 기술 문서 표현이 일반적인 영어 중심 모델과 맞지 않는 경우가 많다.

그래서 embedding 모델은 처음 선택이 매우 중요하고, 변경 시에는 전체 corpus를 다시 embedding 해야 한다는 점도 고려해야 한다.

Chunking과 Embedding은 함께 튜닝해야 한다

실무에서 자주 겪는 실수는 chunking만 바꾸거나 embedding 모델만 바꾸는 것이다. 하지만 이 둘은 항상 세트로 움직인다.

• Chunk가 커지면 embedding이 잡는 의미도 달라진다.
• Embedding 모델이 바뀌면 적절한 chunk size도 달라진다.

그래서 RAG 품질 개선은 보통 다음 순서로 진행된다.

1. Chunking 전략 조정
2. Embedding 모델 비교
3. 검색 결과 평가
4. 다시 Chunking 미세 조정

이 과정을 거쳐야 검색이 잘 되는 RAG에 가까워진다.

정리하며

RAG에서 가장 흔한 오해는 “검색이 안 되면 모델을 바꾸면 된다”는 것이다. 하지만 실제로는 Chunking과 Embedding이 70%, 모델은 그 다음인 경우가 많다.

RAG 성능이 기대에 못 미친다면, LLM을 의심하기 전에 문서를 어떻게 쪼개고 어떻게 벡터화했는지부터 다시 보는 것이 훨씬 빠른 해결책이다.