RAG 가 사라지지 않는 이유

“컨텍스트 창이 1M 토큰이 됐으니 RAG 는 이제 필요 없는 것 아닌가?” 이런 질문이 팀 안에서도 여러 차례 나왔다. 결론부터 말하면 우리는 여전히 RAG 를 쓰고 있고, 앞으로도 당분간은 그럴 것 같다.

긴 컨텍스트가 해결하지 못하는 것

컨텍스트가 길어지면 문서 전체를 넣을 수 있게 된다. 하지만 문제는 ‘무엇을 넣느냐’가 아니라 ‘비용과 지연’이다. 수백만 토큰을 채워 호출하면 응답 시간이 늘어나고 비용도 선형적으로 증가한다. 반면 RAG 는 관련 청크만 추려서 넘기기 때문에 프롬프트를 작고 빠르게 유지할 수 있다.

더 근본적인 문제도 있다. 긴 컨텍스트에서 모델이 중간에 묻힌 정보를 얼마나 정확하게 참조하는지는 아직 일관적이지 않다. “Lost in the Middle” 현상 — 앞뒤에 있는 정보는 잘 참조하지만 중간에 있는 정보는 놓치는 경향 — 은 컨텍스트 길이와 무관하게 남아 있다.

RAG 가 실제로 해주는 것

RAG 의 핵심 가치는 검색이다. 수만 건의 문서 중에서 지금 이 질문에 관련 있는 것만 빠르게 고르는 역할을 한다. 벡터 검색은 이 작업에 최적화돼 있고, 모델이 전체 말뭉치를 훑는 것보다 훨씬 효율적이다.

또한 데이터가 자주 바뀌는 환경에서 RAG 는 파인튜닝보다 훨씬 가볍다. 새 문서가 추가되면 임베딩하고 인덱스에 넣으면 끝이다. 모델을 재학습할 필요가 없다.

# 단순화된 RAG 흐름
query = user_input
chunks = vector_store.search(query, top_k=5)
context = "\n".join(chunks)
response = llm.generate(prompt=f"{context}\n\nQ: {query}")

우리 팀이 내린 결론

긴 컨텍스트와 RAG 는 경쟁 관계가 아니다. 긴 컨텍스트는 ‘필요한 문서가 무엇인지 이미 알 때’ 잘 맞고, RAG 는 ‘수많은 문서 중에서 무엇이 필요한지 찾는 것’이 목표다. 두 도구가 해결하는 문제가 다르다.

실무에서 우리는 소규모 문서는 직접 컨텍스트에 넣고, 규모가 커지면 RAG 파이프라인을 붙이는 방식을 쓴다. 이 경계는 문서 수가 수백 건을 넘어가거나, 업데이트 주기가 잦아질 때 자연스럽게 정해진다.

— by slecs