RAG를 과도하게 엔지니어링하고 있는 건 아닐까? 진짜 문제는 데이터 구조인데.
Are we overengineering RAG when the real problem is structure?
핵심 요약
RAG 성능 개선에 매몰되기보다 데이터 자체를 구조화하는 것이 훨씬 효과적이라는 의견.
- RAG 과잉 엔지니어링 — 검색 성능 개선에만 집착하는 현재의 개발 방식이 비효율적임.
- 데이터 구조화의 중요성 — 원천 데이터를 깔끔하게 정리하는 것이 모델의 예측 가능성을 높임.
- 비정형 데이터의 한계 — PDF 등 지저분한 데이터는 RAG로 해결하려 해도 한계가 명확함.
- 구조화된 지식 접근 — 비즈니스 규칙이나 내부 문서는 RAG보다 구조화된 방식이 더 효과적임.
최근 몇 가지 엔터프라이즈 AI 유스케이스를 작업하면서 계속 떠오르는 한 가지가 있습니다.
우리는 검색 성능을 개선하는 데 많은 시간을 씁니다. 더 나은 청킹, 더 나은 임베딩, 더 나은 벡터 검색 튜닝 등이죠. 하지만 그 모든 노력을 기울여도 결과는 여전히 일관되지 않을 때가 있습니다.
제가 느끼기 시작한 건 이겁니다:
문제는 항상 검색에 있는 게 아닙니다. 지식이 애초에 어떻게 구조화되어 있느냐의 문제입니다.
원본 데이터가 지저분할 때(PDF, 문서, 혼합 형식 등), 우리는 RAG가 '알아서 해결해주길' 기대하며 의존합니다. 하지만 동일한 지식을 깔끔하고 구조화된 방식(적절한 섹션이 있는 간단한 마크다운이라도)으로 다시 작성하면, 모델은 훨씬 적은 노력으로도 훨씬 더 나은 성능을 냅니다.
추측은 줄고, 더 예측 가능한 결과가 나옵니다.
RAG가 쓸모없다는 건 아닙니다. 대규모 비정형 데이터셋에는 여전히 필수적이죠. 하지만 다음과 같은 경우에는:
- 비즈니스 규칙
- 워크플로우
- 내부 지식
때때로 우리가 잘못된 문제를 해결하고 있는 것 같다는 느낌이 듭니다.
다른 분들도 같은 경험을 하셨는지 궁금합니다.
여러분은 여전히 RAG 중심의 파이프라인을 고수하고 계신가요, 아니면 더 구조화된 지식 접근 방식으로 넘어가고 계신가요?

