RAG 는 죽었는가

“RAG is dead” 라는 아티클이 눈에 많이 밟힌다. 정말 희대의 어그로가 아닐 수 없다. 그 배경은 이렇다. Gemini 1.5가 10M 토큰 이상의 comtext를 인풋으로 처리한다는 것을 시작으로 LlaMa 4 등 후속 모델들이 엄청난 양의 컨텍스트를 인풋으로 처리함을 모델의 성능 지표로 강조하고 있다. LLM 활용에 고질병이었던 Context 길이 제한 때문에 RAG 가 필요했다면, 이젠 그런것 없이 다 프롬프트에 때려 넣으라는 것이다.

 

이런 맥락에서 “RAG is dead” 라는 말은 새로 출시된 모델의 마케팅용 캐치프레이즈에 가까웠다고 볼 수 있을 듯 하다. LLM 의 제한된 Context Length 는 모두의 골칫거리였고 RAG 만큼 핫한 키워드도 없었기 때문에 모두의 관심을 끄는 소재임에는 분명했다. 어그로가 잘 끌린 것을 보니, 증대된 Context Length 를 홍보하기에도 분명 효과적이었던 듯 하다.

 

문제는 많은 이들이 이를 다른 의미로 받아들였는데, “새로운 기술이 나오면서 RAG가 다른 기술로 대체됐다” 또는 “트렌드에서 밀렸다” 로 인식하는 듯 하다. 하지만 이는 분명 사실이 아니다. RAG는 여전히 기업들에 널리 쓰이고 있고 long context 추론에 대체된 적이 없으며, 그럴 수도 없다. 그 이유는 다음과 같은데,

• 확장성 및 비용: 수백만개의 토큰을 한번에 처리하는것은 계산량이 많고 비용도 많이 듬. 추론 시간 또한 길어짐.
• 낮은 성능: LLM 은 여전히 “중간 망각(Lost in middle)” 이라는 문제를 안고 있음. 컨텍스트가 길어지면 중간에 있는 정보를 잘 활용하지 못함.
• 데이터 보안: 모델에 선별되지 않은 모든 데이터를 제공하는것은 보안에 치명적일 수 있음.

이런 한계를 극복하는데 RAG는 분명 효과적이고 계속 사용 될 것이다. 애초에 RAG는 죽은적도, 대체된 적도 없는 것이다.

 

다만 정의에 따라, 죽지 않는 것은 “Retrieval” 이고, “RAG는 죽었다” 라고 말하는 사람도 있다.

 

예를들어, vector db 기반의 RAG는 대체될 수 있다. Langchain 또는 vector db 를 써서 직접 RAG를 구축해보았다면 느끼겠지만, 생각보다 잘 안된다. 내가 원하는 답변을 척 하고 가져오지 않을 뿐더러 잘못된 정보를 기반으로 generation 되는 경우도 많다. 이는 vector db 기반의 문장 retrieval 이 갖는 고질적인 문제에서 비롯되는데, 다음과 같이 정리할 수 있을 것이다.

• 일관성 없는 Chunk split: 문장을 길이 단위로 자르다보니 소실되는 문맥들이 생긴다. 물론 문장간 겹치는 범위를 포함하긴 하지만 문맥 소실은 여전히 발생한다.
• Needle-in-a-haystack 문제: 긴 문서속에 정보가 조각조각 숨어있는 경우, 벡터검색으로 정보를 가져올 수 없다.
• Vector embedding 성능: 긴 문장의 embedding 은 뉘앙스와 관계 등 정보의 소실을 유발한다. 또 종종 모델의 한계로 도메인 지식과 전문용어를 잡아내지 못하는 경우가 많다.
• Ranking 정확도: 단순 cosine similarity 를 기준으로 retrieval 한 문장들은 문맥적 중요도를 반영하지 못한다.
• Garbage in, garbage out: 잘못된 문장의 top-k retrieval은 잘못된 문장의 생성으로 연결된다. Hallucination 을 막기 위해 RAG 를 쓴다고 하는데 Retrieval 결과가 틀리면 무슨 소용인가?

정리하면, Vector RAG 의 일관성 없는 Chunking, Embedding 성능의 의존성, 부정확한 Ranking 모델 등이 Vector 기반 RAG 의 문제로 제기되고 있다.

 

이런 vector db 기반의 RAG 의 문제들을 해결하기 위해 굉장히 많은 새로운 방법이 제시되고 있는데

• Graph RAG: Vector 대신 Graph 로 정보 관계를 구성하여 Retrieval
• ReRanker: Cosine Similarity 로 1차적으로 가져온 정보들을 Bert 등 모델로 적합도 필터링
• Agent RAG: 단순 ranking 이 아닌, Agent 를 구축해서 Retrieval 아키텍처를 구성
• Contextual RAG: Anthropic 에서 제안, chunking 된 문장을 문맥을 고려하여 LLM을 통하여 증강하여 저장

등이 있다. (이 외에 또 재밌는 방법이 있으면 알려달라)

 

즉, 기존의 langchain 등 vector db 기반의 RAG 가 여러 문제를 안고 있는 상황이고 이를 해결하기 위해 새로운 방식의 RAG 가 연구 및 제안되고 있다. 그럼에도 불구하고, 이 방법들은 Retrieval and Generation, 정보를 추출하고 생성하는 RAG 임에는 분명하다.

RAG 는 죽었는가? 아니, RAG 는 Transformer 기반 모델이 대세로 남아있는 한 죽지 않는다.

 

당신이 공부한 RAG 는 죽었는가? 아마 몇년 안에 그럴 것이다. 그리고 새로운 RAG 가 나올 것이다. 요즘 나오는 대부분의 AI 기술들이 그러하듯이.

 

 

RAG IS DEAD

 

출처:

RAG is dead:

• https://medium.com/@ethanbrooks42/rag-is-dead-why-retrieval-augmented-generation-is-no-longer-the-future-of-ai-27734ba456a1
• https://www.linkedin.com/posts/804250ab_rag-has-been-dying-since-the-first-large-activity-7305155666992680961-0qxY/

Graph RAG: https://www.ibm.com/think/topics/graphrag

Agent RAG: https://www.llamaindex.ai/blog/rag-is-dead-long-live-agentic-retrieval

Context RAG: https://www.anthropic.com/news/contextual-retrieval

ReRanker: https://aws.amazon.com/ko/blogs/tech/korean-reranker-rag/