RAG 의 사망 선고는 매해 발표된다

긴 컨텍스트 윈도우 모델이 발표될 때마다 비슷한 패턴이 반복된다. “이제 문서 전체를 프롬프트에 넣을 수 있으니 RAG 는 필요 없다”는 글이 올라오고, 반론이 달리고, 한 달쯤 지나면 조용해진다. 우리 팀은 이 주기를 몇 번 겪으면서 나름의 관점을 정리했다.

컨텍스트 길이와 검색 정확도는 다른 문제다

100만 토큰짜리 컨텍스트 윈도우가 있다고 해서 모델이 그 안에서 원하는 정보를 정확하게 찾아낸다는 보장은 없다. “Lost in the Middle” 연구처럼, 긴 컨텍스트의 중간부에 있는 정보는 시작과 끝에 비해 활용 비율이 낮아지는 경향이 실험적으로 확인되었다.

반면 RAG 는 검색 단계에서 이미 관련 조각을 골라낸다. 노이즈를 줄이고 관련성 높은 내용만 모델에게 전달하는 것이 핵심이다. 이 역할은 컨텍스트 윈도우가 아무리 커져도 대체되지 않는다.

비용 문제는 사라지지 않는다

100만 토큰을 매번 넘기는 것은 가능하더라도 저렴하지 않다. 우리가 구축한 문서 기반 질의 시스템에서 전체 문서를 매번 프롬프트에 포함시키면 토큰 비용이 수십 배 달라진다. 검색으로 관련 청크만 선별해서 넣는 방식과 비교하면 실용 서비스에서 이 차이는 결정적이다.

RAG 가 나쁜 경우도 있다

그렇다고 RAG 를 항상 써야 한다고 생각하지는 않는다. 문서 규모가 작고 업데이트 빈도가 낮다면, 잘 정리된 시스템 프롬프트에 내용을 직접 포함시키는 것이 더 단순하고 안정적이다. 검색 파이프라인을 구축하고 유지하는 비용이 실제 이점보다 클 수 있다.

또 RAG 의 품질은 청크 전략, 임베딩 모델, 재순위 알고리즘에 크게 의존한다. 이 부분을 제대로 구현하지 않으면 긴 컨텍스트 직접 입력보다 오히려 나쁜 결과가 나오는 경우도 있다.

우리가 지금 사용하는 기준

팀 내부에서 RAG 사용 여부를 결정할 때 적용하는 기준은 세 가지다.

1. 참조 문서 규모가 모델 컨텍스트 예산을 초과하는가?
2. 문서가 자주 업데이트되어 정적 프롬프트 관리가 어려운가?
3. 검색 정확도가 응답 품질에 직접 영향을 주는가?

셋 중 하나라도 해당하면 RAG 파이프라인을 구성한다. 해당하지 않으면 프롬프트에 직접 포함시키는 것으로 시작해서 필요할 때 전환한다.

기술의 사망 선고는 보통 실제보다 과장된다. RAG 도 사라지지 않을 것이다. 다만 쓰는 이유를 분명히 알고 써야 한다는 것이 지금까지의 결론이다.

— by slecs