지난 몇 년 동안 LLM (Large Language Models)을 사용하여 무언가를 구축해 보았다면, 당신은 RAG (Retrieval-Augmented Generation) 파이프라인을 구축해 보았을 것입니다. 쿼리를 임베딩(Embed)하고, 벡터 스토어(Vector Store)를 검색하며, 상위 청크(Chunks)를 프롬프트(Prompt)에 집어넣고, 모델이 답변하게 만드는 방식입니다. 이는 실제 데이터에 LLM을 접지(Grounding)시키는 방식의 "Hello World"와 같으며, 오랫동안 그것만으로도 충분했습니다.

하지만 이제는 더 이상 그렇지 않습니다.

당신의 유스케이스가 멀티 홉 추론 (Multi-hop reasoning), 도구 호출 (Tool calls), 또는 수천 개의 문서에 흩어져 있는 엔티티 (Entities) 간의 관계를 포함하는 순간, 단순한 RAG는 한계를 드러내기 시작합니다. 이로 인해 깊이 이해할 가치가 있는 두 가지 진화 형태인 Agentic RAG와 Graph RAG가 등장했습니다. 이들은 서로 다른 문제를 해결하며, 이 둘을 혼동하면 재구축하는 데 몇 주를 허비하게 될 것입니다. 이제 세 가지 방식을 단계별로 살펴보겠습니다.

RAG vs. Agentic RAG vs. Graph RAG: 당신의 유스케이스에 실제로 적합한 것은 무엇인가? - BezKoder

세 가지 검색 아키텍처(Retrieval Architectures)인 RAG, Agentic RAG, Graph RAG에 대한 분석 - 왜 "그냥 RAG를 추가하라"는 조언이 얼마 전부터 더 이상 충분하지 않게 되었는지에 대하여

bezkoder.com