From RAG to GraphRAG , What is the GraphRAG and why i use it?

Mar 12, 2024

Contents

RAG, GraphRAG 를 이야기하기에 앞서, RAG 에 대한 간략한 소개 RAG 한계점 GraphRAG 를 쓸 때 RAG 의 어떤 한계점을 보완할 수 있을지.Pre-Retrieval Post-Retrieval Prompt Compression GraphRAG 아키텍쳐 Query Rewriting Pre-Retrieval & Post-Retrieval GraphRAG를 하기 위해 준비해야할것들 GraphRAG 한계점 GraphRAG 를 어떻게 적용하는지 GraphRAG 를 언제 쓰는게 좋을지 끝으로,Reference

RAG, GraphRAG 를 이야기하기에 앞서,

ChatGPT 시대가 왔다. 제3의 산업혁명이라는 말이 불리울만큼 거대언어모델의 영향력이 큰 시대를 살아가고 있는 요즘입니다. 저희 어머니도 궁금하신점이 있으면 ChatGPT를 사용하실만큼 세대를 가리지않고 그 활용 범주가 더더욱 넓어지고 있습니다.

이렇게 활용 범주가 넓어지는 이유에 대해 생각해보면 아마 사용자가 원하는 정보를 정확하게 잘 가져와 전달해주기에 그렇지 않을까 싶습니다. 정보의 과잉에 지친 사람들에게 '필요한'정보를 잘 선별하여 가져다 주는거죠.

장족의 발전이 이루어지고 있는 지금까지 그 역경 또한 많이 존재했는데요. 하나를 예로 들어보자면, '환각현상'이라고 할 수 있습니다. 정보는 가져다주는데, 부정확한 정보를 가져다주는거죠. 이 현상에는 여러 원인이 존재합니다. 가장 대표적인 원인을 말해보자면, 사용자의 의도를 잘못 오인해 관련없는 정보를 가져다주는겁니다. 이 원인을 해결하기 위한 방식은 간단합니다. 사용자의 의도를 '잘' 파악해서 '관련있는' 정보를 전달하는겁니다.

이를 개선하기 위해 다양한 시도들이 이루어지고있습니다. 주로 4가지 방식으로 이를 분류할 수 있습니다. 1.대형언어모델 처음부터 구축하는 방식 , 2.'잘'학습된 대형언어모델을 가져와 원하는 영역에 걸맞게 추가로 학습하는 방식, 3.대형언어모델을 그대로 사용하되, 유저 질의에 추가적인 맥락을 부여해주는 방식 ,4. 대형 언어모델을 두되, 사용자에게 답변하는 과정 중 '관련된 정보'에 대한 맥락을 추가로 제공하여 그 관련성을 부각하는 방식. 방식이 다양한 만큼 그 장단점 또한 존재합니다.

1은 처음부터 구축하기에 처음부터 데이터의 명확한 맥락을 대형언어모델에게 제시할 수 있다 라는 장점이 있는 반면, 처음부터 구축하기에 그 구축 비용이 만만치 않다는 단점이 있습니다.

2는 '잘'학습된 대형언어모델의 맥락을 가져와서 도메인에 특화된 소량의 데이터를 선별 적용하기에 상대적으로 비용도 저렴하고, 그 정확도도 어느정도 보장된다 라는 장점이 있는 반면, 대형언어모델의 맥락을 잃어버리지 않고 도메인에 특화된 맥락을 조화롭게 유지하는게 어렵다는 단점이 있습니다.

3은 유저의 질의를 가공해 의도에 대한 맥락을 '잘' 부여하면 되기에 비용이 저렴하다라는 장점이 있는 반면에, 맥락을 부여하는 과정에서 맥락 부여자의 주관이 개입될 수 있기에 맥락의 객관성이 결여될 수 있다 라는 점때문에 만일 편향이 강하게 반영될시 오히려 맥락이 부정적으로 작용한다라는 단점이 존재합니다.

4는 상대적으로 최신의 정보를 반영한 답변으로 유저의 질의에 대답할 수 있고 도입비용이 저렴하다는 장점이 있는 반면에, 관련 문서에 따라 질문의 품질이 가지각색이기에 어떻게 관련 문서를 잘 판별하고 가져올지에 대해 전략적으로 접근하여 다양한 요소들을 고루 배합하는 등 복잡성이 높다는 단점이 존재합니다.

이외에도, cost , accuracy , domain-specific terminology , up-to-date response, transparency and interpretability 5가지 측면으로 고루고루 비교한 자세한 내용이 https://deci.ai/blog/fine-tuning-peft-prompt-engineering-and-rag-which-one-is-right-for-you/ 에 잘 기록되어있으니, 한 번 참조하시는걸 추천드립니다.

지금까지 거대언어모델에서 발생하는 문제인 환각현성을 해결하기 위해 시도하고 있는 여러 방법론들에 대해 이야기했습니다. 이번 포스팅에서는 방법론들중 4번에 해당하는 '관련된 정보'를 잘 가져와 맥락을 부여하는 기술인 RAG(Retrieval Augment Generation) 에 대해 살펴보고, RAG의 한계점 그리고 그 한계를 보완하기 위한 방식 중 하나인 GraphRAG까지 알아보겠습니다.

RAG 에 대한 간략한 소개

RAG(Retrieval Augmented Generation) 란 무엇일까요? 앞서 말씀드린바와같이, 유저의 질의를 '잘' 해석해서 관련된 정보를 '잘' 가져와 맥락으로 가공한 뒤, 답변에 유용한 정보를 전달하는 기술을 의미합니다. 위에서 참조한 사이트에서 언급한바와 같이 cost 가 저렴하다 , accuracy 가 비교적 정확하다 , domain-specific terminology 도메인에 대한 맥락 부여가 비교적 잘 된다. up-to-date response 최신성을 반영한 정보를 제공할 수 있다. , transparency and interpretability 무슨 관련 문서로부터 정보를 가져오는지 확인할 수 있기에 답변 근거를 추적하기에 용이하다 라는 점 때문에, 대부분

그림1. RAG 작동 프로세스 / https://deci.ai/blog/fine-tuning-peft-prompt-engineering-and-rag-which-one-is-right-for-you/

질의를 '잘' 해석하고, 관련된 정보를 '잘' 가져와서, 맥락으로 가공하는 것은 핵심입니다. 그림 1에서 볼 수 있듯이, 기존의 사용자 질의 → 사전 훈련된 대규모 언어 모델(Large Language Model, LLM)을 통한 응답 생성 → 사용자에게 응답 전달의 과정에, 검색 모델(Retrieval Model)이 추가되어 질의에 대한 관련 정보를 가져오는 과정이 삽입되었습니다. 여기서 추가된 검색 모델은 앞서 언급된 세 가지 요소가 진행되는 곳입니다.

이 세 가지를 잘 수행하기 위해 다음과 같은 네 단계로 구분하여 구현 및 개선합니다: 1. 사전 검색(Pre-Retrieval) 2. 청크 나누기(Chunking) 3. 검색(Retrieval) 4. 사후 검색(Post-Retrieval).

사전 검색(Pre-Retrieval)

데이터의 세분성(Data-granularity): 검색 단계 전에 주어진 입력을 사전에 가공해 RAG 모델이 생성 과정을 보강하기 위해 검색하는 데이터의 세부 정도나 정밀도를 의미합니다. RAG 모델은 대규모 사전 훈련된 언어 모델의 강력함과 검색 구성 요소를 결합하여 관련 정보를 찾기 위해 텍스트 세그먼트(예: 문장, 단락, 또는 문서) 데이터베이스를 검색하는 방식으로 응답을 생성하는 데 도움을 줍니다.
데이터의 세분성은 문장 단위(예: 개별 사실, 문장 또는 짧은 단락)에서부터 문단 단위(예: 전체 문서나 기사)까지 다양할 수 있습니다. 데이터의 세분성 선택은 모델의 성능과 정확하고 문맥상 관련성 있는 텍스트를 생성할 수 있는 능력에 영향을 미칩니다. 세밀한 데이터는 생성 작업에 더 구체적이고 상세한 정보를 제공할 수 있는 반면, 조대한 데이터는 더 넓은 맥락이나 일반 지식을 제공할 수 있습니다.
RAG 모델의 효과를 최적화하기 위해 적절한 데이터의 세분성을 선택하는 것이 중요합니다. 이는 세부적이고 관련성 있는 정보를 제공하는 필요성과 모델에 너무 많은 데이터를 제공하거나 너무 일반적인 데이터를 제공하여 유용하지 않게 하는 위험 사이의 균형을 맞추는 것을 포함합니다.

청크 나누기(Chunking)

원천 데이터를 대형 언어 모델에 입력하여 정량화하기 위해 입력 형태를 적절하게 가공하는 과정입니다. 대형 언어 모델에 입력하는 토큰이 제한되어 있기 때문에, 적절한 정보들을 잘 분절하여 입력하는 것이 중요합니다. 예를 들어, 사람 간 대화하는 상황을 생각해볼 때, 주어진 시간 내에 사람들 간 대화가 고루 분배되는 상황을 이상적인 대화 상황으로 가정합니다.
1시간 동안 한 사람이 59분을 이야기하고 나머지 한 사람이 1분을 이야기한 상황은, 한 사람이 주도적으로 정보를 '입력'만 했기에 정보 교류가 아닌 정보 주입의 형태를 띈 대화라고 할 수 있습니다. 반대로, 한 사람이 30분을 이야기하고 나머지 한 사람이 30분을 이야기하는 상황은 고루고루 정보를 교류했기에 효율적인 대화라고 볼 수 있습니다.
다시 말해, 대형 언어 모델에게 '좋은' 정보를 제공받기 위해서는 '적절한' 맥락을 부여하는 것이 중요합니다. 이 맥락을 부여하는 데 있어 제한된 길이(토큰)가 있기 때문에, 주어진 맥락 제한 동안 맥락 간 유기적인 관계를 잘 보존하여 입력하는 것이 중요합니다. 이러한 이유로, 관련 있는 데이터를 잘 가공하는 데 있어 '데이터 제한 길이' 문제가 발생합니다.

검색(Retrieval)

사용자의 질의와 관련된 내용을 찾기 위해 문서나 텍스트 세그먼트 데이터베이스를 검색하는 단계입니다. 이는 질의의 의도와 맥락을 이해하고, 이를 바탕으로 데이터베이스에서 가장 관련성 높은 문서나 텍스트를 선택하는 과정을 포함합니다.
예를 들어, "녹차의 건강상 이점"에 대한 질의를 처리할 때, 모델은 녹차와 관련된 건강 이점을 언급하는 문서를 찾아 유사성 지표에 따라 선택합니다.

사후 검색(Post-Retrieval)

검색된 정보를 효과적으로 생성 과정에 통합하기 위해 처리하는 단계입니다. 이는 검색된 텍스트를 요약하고, 가장 관련성 높은 사실을 선택하며, 사용자의 질의와 더 잘 일치하도록 정보를 정제하는 과정을 포함할 수 있습니다.
예를 들어, 녹차의 건강상 이점에 대한 문서를 분석하고 "녹차는 항산화제가 풍부하여 특정 만성 질환의 위험을 줄이고 뇌 기능을 개선하는 데 도움을 줄 수 있습니다."와 같은 주요 포인트를 요약하여, 사용자 질의에 대한 포괄적이고 정보적인 응답을 생성합니다.

RAG 한계점

RAG 가 cost, uptodate, domain-specific 등 타 방식대비 효율적인 점들이 존재하나, 역시나 고유 한계점들이 있기마련입니다. 아래 그림이 RAG 프로세스 중 그 한계점을 잘 그려놓은것 같네요. 그림을 기반으로 대표적인 몇 가지를 살펴보겠습니다.

Barnett, Scott, et al. "Seven failure points when engineering a retrieval augmented generation system." arXiv preprint arXiv:2401.05856 (2024).

Missing Content : 첫번째는 유저 질의와 관련있는 문서를 가져와서 유저 질의에 맥락을 부여하는데 활용해야하나, 이를 인덱싱 하지 못해 유저 질의에 활용하지 못하는 거죠. 기껏, 열심히 전처리해서 데이터베이스에 잘 적재해놓았는데 이를 활용하지 못하는 케이스라고 할 수 있습니다.

Missed the Top Ranked Documents : 두번째는 유저 질의와 관련된 문서를 가져오긴했으나, 그 관련도가 미미한 문서들만 가져왔기에 유저가 만족할만한 답변 품질에 충분치 못한 경우입니다. 그 이유는 결국 사용자가 “몇 개의 문서”를 Retriever 과정에서 가져올 지 지정하는 부분에서 주관이 개입된다는 점이 가장 큰 한계점으로 작용합니다. 따라서, 여러 실험을 거듭하며 이 k라는 하이퍼 파라미터를 지정해줘야한다는거죠.

Not in Context - Consolidation Strategy Limitations :

Documents with the answer were retrieved from the database but did not make it into the context for generating an answer. This occurs when many documents are returned from the database and a consolidation process takes place to retrieve the answer.

Not Extracted : 네번째는 LLM의 근본적인 한계죠. ‘정확’한 값을 가져오기보다 ‘근사’한 값을 가져온다. 때문에 ‘근사’ 혹은 ‘유사’한 값을 가져올 때, 불필요한 정보가 발생하여 나비효과처럼 작은 노이즈이나 향후 답변시 큰 차이를 초래할 수 있습니다.

Wrong Format : 다섯번째는 LLM 모델을 Instruction 데이터셋을 통해 fine-tuning을 진행하고 이를 통해 zero-shot 성능을 높이는 방법인 Instruction tuning 과 연관이 깊어보입니다. 질의 이 후 응답 생성전에 context 와 더불어 Prompt 에 추가적인 instruction 을 입력할 때, 이 입력에 대한 포멧을 잘못입력해 LLM이 인지를 못하거나 오인하여 잘못된 답변을 생성하는 현상을 말합니다.

Incorrect Specificity : 여섯번째는 유저 질의 정보를 충분치 못하게 활용하거나 혹은 너무 과도하게 활용하여 그 질의에 대한 경중을 고려하는 과정에서 문제가 발생하는 현상을 말합니다. 적절치 못한 input 과 retrieval output 조합이 적절치 못할 때, 발생할 가능성이 높습니다.

Incomplete : 일곱번째는 context를 답변 생성에서 사용할 수 있음에도 불구하고 일부 정보가 부족하여 사용자 쿼리에 대한 불완전한 응답을 초래하는 현상을 말합니다.

위 한계점들을 결국 정리해보면 주된 원인들은 1.인덱싱 - 유저 질의와 관련된 적절한 문서를 가져오는 것. 2 - 답변 생성전 적절한 정보 부여 , 3 - input 과 pre,post retrieval 간의 적절한 조합 3가지 요소가 RAG에서 중요함을 알 수 있습니다. 그렇다면 이를 어떻게 개선할까요?

GraphRAG 를 쓸 때 RAG 의 어떤 한계점을 보완할 수 있을지.

위에서 언급한 문제들을 RAG의 Pre-Retrieval , Post-Retrieval 그리고 Prompt Compression 관점에서 GraphRAG 를 통해 보완할 수 있습니다. Knowledge graph 의 Retrieval , Reasoning 맥락으로 보시면 좋을거 같네요.

Graph Retrieval 은 적절한 정보를 가져와서 context 증강을 중점으로 한다면, Graph Reasoning 은 chunking , context 입력 등 정보들이 어떤 흐름으로 RAG에 적용이 되는지를 traversing , searching 한다는 점을 중점으로 두고 적용합니다.

그럼 Graph Retrieval 과 Graph Reasoning 은 RAG 에 어떻게 , 어느 부분에서 적용이 될까요?

Pre-Retrieval

관련 있는 문서를 가져오기 위해 지식그래프 인덱싱을 활용할 수 있습니다. 지식그래프 장점인 노드와 엣지에서 엣지에 ‘시멘틱’을 부여하여 직접적으로 관련 있을법한 문서들을 의미론적으로 인덱싱 한 후 이를 Retrieval 하는거죠.

두 가지 방법이 있습니다. 노드를 가져올 것인지, 서브그래프를 가져올 것인지를 고민해보아야합니다. 예를 들어, 노드를 가져온다면 유저 질의와 청크로 나누어진 노드의 벡터값을 비교하여 가장 유사한 노드를 추출하고 이 노드와 연관되어 있는 경로를 질의 구문으로 가져오는거죠.

다만, 이 때 path 내 몇 개의 노드를 가져올지 지정해줘야 한다는 단점이 있습니다. 또한 path 생성을 위해 사용된 정보 추출모델(지식그래프 생성)의 작동 여부에 따라 경로의 맥락이 달라지기 때문에, 정보 추출모델의 성능이 중요하다라고 할 수 있습니다.

추가로 연관되어 있는 정보를 가져오기 위해 VLE(Variable Length Edges)라고 하는 질의문을 활용하게 될텐데, 이 과정에서 데이터베이스의 최적화가 선행되어야 이를 신속하게 추출할 수 있다는 단점이 있습니다. 이 때 DBA, MLE, DE 등 데이터 관련자들이 함께하여 어떻게 데이터베이스를 설계할것인가에 대한 논의가 필요하고 하드웨어 소프트웨어 측면에서 어떤 방식으로 최적화 할지에 대한 논의 또한 필요합니다.

다음은, 서브그래프입니다. 서브그래프는 관련 있는 노드와 연결되어 있는 ego-graph를 가져온다 라고 생각하시면 되겠습니다. 혹은 여러개가 관련되어 있다면 각 관련되어 있는 노드들의 ego-graph를 그래프 임베딩하여 연결되어 있는 노드들의 맥락까지 종합하여 총체적으로 유저 질의와 비교하는 방식을 활용할 수 있습니다.

하지만, ego-graph 를 임베딩하는 과정에서 그래프 임베딩 방식을 활용해야하기에, 어떤 그래프 임베딩을 활용할지에 따라 그 성능이 다르기에, 다양한 실험이 필요하다라는 한계점이 있습니다.

Post-Retrieval

Re-Ranking 과정에서 기존 RAG값과 GraphRAG 값을 조화롭게 활용하는 방식입니다. RAG 유사도 검색값과 GraphRAG의 시멘틱 검색의 값을 활용해 Context를 생성합니다.

GraphRAG의 값은 어떤 시멘틱을 기반으로 Retrieval 을 했는지 확인할 수 있기때문에, 이를 활용해 Retrieval 이 잘 되었는지를 확인할 수 있습니다.

vectorDB와 GraphDB를 별개로 활용하지 않고, single-DB(graphDB)를 활용한다면, 단일 데이터 베이스 내에서 semantic(GraphRAG) , vector(RAG) indexing이 가능하기에 Retrieval 을 잘 가져왔는지를 확인하고, 부정확한 정보를 가져왔다면 이를 개선할 수 있습니다.

Prompt Compression

프롬프트 템플릿 , 멀티 쿼리 입력 등 프롬프트 엔지니어링시 어떤 chunk 정보를 주입하면 좋을지를 설계할 때 그래프가 유용합니다.

그래프는 RAG의 프롬프트 측면에서 Retrieval 이 후, 문서를 그대로 돌려주는것이 아닌 주어진 질의의 맥락과 문서간 관계를 이해해 관련 정보만 돌려줄 수 있고, 만일 해당 정보가 유의미하지 않을시 그 정보의 출처를 추적해 어느 부분에서 그 정보를 가져왔는지를 파악하고 개선할 수 있습니다.

예를 들어, 부적절한 답변이 도출되었을시 해당 답변이 어느 부분인지를 그래프 질의를 통해 역추적을 할 수있기에 이를 통해 답변을 개선할 수 있는 부분을 즉각적으로 파악하고 조치할 수 있습니다.

GraphRAG 아키텍쳐

크게 Query Rewriting , Augment , Retrieval 에서 Semantic Search , Similarity Search 4가지 모듈로 구성되어 있습니다.

Query Rewriting

유저 질의를 재가공하는 단계입니다. 유저가 질의를 작성하였을시, 해당 질의에 추가로 어느 내용을 추가로 부여하면 좋을지 한 번 더 깔끔하게 다듬는 과정이라고 생각하시면 됩니다.

https://towardsdatascience.com/advanced-retrieval-augmented-generation-from-theory-to-llamaindex-implementation-4de1464a9930 , Leonie Monigatti

Pre-Retrieval & Post-Retrieval

어떤 정보를 가져오고, 가져온 그 정보를 어떻게 처리할것인지에 대해 고민하는 단계입니다.

Pre-Retrieval 단계에서는 주로, chunking size 를 어떻게 설정할지 , 인덱싱을 어떻게할지 , 데이터 정제를 잘 했는지 만일 관련 없는 데이터가 있으면 이를 어떻게 탐지하고 제거할지 등과 같은 작업을 진행합니다.

Post-Retrieval 단계에서는 데이터를 어떻게 잘 조화롭게 만들지를 고민하는 단계입니다. 주로 , Reranking , Prompt Compression 두 과정을 주로 진행합니다. Prompt Compression 에서는 질의 결과인 Graph Path 를 answer generation 에 활용할 Context + Prompt 에서 Prompt 요소로 넣어줍니다. Reranking은 Graph Embedding 한 결과와 LLM Embedding 결과를 조합하여 Ranking 의 다양성과 정확도를 높이는 용도로 활용합니다.

GraphRAG를 하기 위해 준비해야할것들

그래프 형태를 저장, 관리 그리고 불러오기 위한 그래프 데이터 베이스

데이터를 지속 저장ㆍ관리하기 위해서는 데이터 고유의 특성이 반영된 소프트웨어가 필요합니다. 테이블 형태를 잘 관리하기 위한 시스템으로서, RDBMS가 있듯이 그래프 형태를 잘 관리하기 위한 시스템으ꃠ서 GDBMS가 존재합니다.
특히, Knowledge Graph Reasoning 측면에서 관련된 정보들을 불러오기 위해 그래프 구조에 최적화된 데이터베이스로 적용되어 있지 않을시에는 관련성을 역으로 연산하기 위한 비용인 JOIN 비용이 부과되어 Bottleneck이 발생할 확률이 대폭 상승하게 됩니다.
때문에, 이 모든것을 효율적으로 구성해놓은 GDBMS가 GraphRAG에서 필수적입니다.

그래프를 불러오기 위해 그래프 쿼리를 생성하는 모델

무슨 데이터가 관련있는지는 파악이 되었으나, 특정 데이터로부터 어떤 연관이 있는 데이터를 불러오는것 또한 자동화 구축이 되어야 합니다. 다시말해, 그래프 쿼리 생성을 전담으로 맡는 자연어처리 모델이 필요한거죠. 아쉽게도, 그래프 쿼리를 생성하기 위해 그래프 쿼리 데이터셋이 부족한 상황인터라 데이터 수급이 절대적으로 필요한 상황입니다. 이를 위해, 현재 Neo4j에서 앞서서 데이터 크라우드 소싱을 런칭했습니다. 만약 해당 내용이 궁금하신분이 계시다면 아래 링크를 통해 관련내용을 확인 및 크라우드 소싱에 참여하실 수 있습니다.
https://community.neo4j.com/t/crowdsourcing-a-text2cypher-dataset/65961

그래프 형태로 만들기 위한 정보 추출 모델

청크로 잘 나누어진 문서들 사이로 어떤 관계가 있는지를 유추하기 위한 정보 추출 모델이 필요합니다. 이를 위해, 접근할 수 있는 방식이 크게 두 가지로 나누어 볼 수 있습니다. 하나는 NLP의 NER을 활용하는 방식이고, 나머지는 Knowledge Graph의 Foundation model을 사용하는 방식입니다. 두 방식 각각 차이점이 존재합니다. 먼저 NLP는 말 그대로 텍스트 관점에서 Semantic을 유추하기 때문에, ‘단어’에 초점을 맞춰서 단어간 발생할 수 있는 사전에 의존성이 큰 반면에, Knowledge Graph는 Knowledge base 로 부터 Foundation model 이 형성되었고, ‘노드’에 초점을 맞춰 Edge간 정보 전달량을 조절할 수 있다는 점이 차이점으로 볼 수 있습니다.

그래프 데이터를 임베딩하기 위한 모델

Reranker 에 추가적인 맥락을 부여하기위해 기존 LLM 의 Sequence 관점과 다르게 Graph Embedding 을 통해 Holistic 관점을 접목하여 구조적인 특성을 부여합니다.이를 통해 선후관계에 치중했던 Sequence 관점과 더불어 모든 청크(노드)들이 고루 표현된 Graph 관점을 더하여 놓쳤을 정보를 보완할 수 있다는 점에서 활용합니다.

GraphRAG 한계점

Luo, Linhao, et al. "Reasoning on graphs: Faithful and interpretable large language model reasoning." arXiv preprint arXiv:2310.01061 (2023).

GraphRAG는 RAG와 마찬가지로 한계점이 명확합니다. 바로 어떻게 그래프를 형성하고 이를 질의하는 질의문을 생성하고 최종적으로 그 질의문을 입력하여 어느부분까지 정보를 가져올것인가라는 점이 그 한계점으로 말할 수 있습니다. 결국 위에서 언급한 바와 같이 ‘쿼리 생성’ , ‘Reasoning boundary’ , ‘정보 추출’ 3가지 라고 할 수 있는데요. 특히 Reasoning boundary 측면에서, 어느 정보까지가 과연 질의와 관련있을지를 정보량을 계산하며 Optimization을 하다보면 어느새 정보를 가져올 때, 과부하가 걸려 GraphRAG핵심인 Answer generation 에 부정적인 영향을 줄 수 있다는 점이 명확한 한계점으로 꼽힙니다.

GraphRAG 를 어떻게 적용하는지

GNN(graph neural network) 의 결과값인 그래프 임베딩을 활용하여 유저 질의 응답추론에 활용하는 텍스트 임베딩에 그래프 임베딩을 덧붙여 활용합니다.이 방식은 Soft-prompting 이라고 불리며, 프롬프트 엔지니어링 방식 중 하나입니다.

프롬프트 엔지니어링은 크게 Hard, Soft 두 가지로 분류를 나누어 볼 수 있습니다. Hard 는 Explicit 형태로 프롬프트를 제공하는 형태를 의미합니다. 주어진 유저 질의문에 맥락을 임의로 작성해 부여해주는 방식입니다.

예를 들자면, '나는 오늘 빵을 먹고 싶어' 형태로 유저 질의가 주어졌다면, '[task] 당신은 고객에게 빵을 잘 제공해야하는 임무가 있습니다. [context]질의가 온 시각은 아침시간대이니, 되도록 소화가 잘되는 빵종류를 제공하는게 좋을거 같습니다. 또한 [persona] 고객의 주 특징은 다이어트 중인 20대 여성분이오니, 정제된 탄수화물이 들어간 흰빵 종류는 추천 대상에서 자제해주세요. [example] 좋은 예시로는 추천 빵 이름과 빵을 맛있게 먹는 방법 그리고 빵 칼로리를 같이 이야기해주세요. [tone] 친절한 어투로 작성해주세요' 와 같이 task , context , persona, example, format , tone 6가지를 임의로 입력해주어야합니다.

보시다시피, '임의'로 작성하였기에 프롬프트를 작성하는 사람의 주관이 많이 개입되어 있고 해당 프롬프트가 최적인지 판단하기에 어렵다는 단점이 있습니다. 하지만, 간단하게 구현할 수 있다는 장점이 있죠.

이와 반대로, Soft 는 Implicit 형태로 프롬프트를 제공하는 형태를 의미합니다. 모델이 질의와 유사한 추론 결과를 도출할 때 기존 텍스트 임베딩에 추가로 임베딩 정보를 부여하는 방식을 뜻합니다.

'학습'된 맥락인 임베딩 정보를 부여하였기에 객관성이 보장되며, 최적화된 가중치 값을 도출할 수 있습니다. 하지만, 간단하게 텍스트로 입력하는게 아닌 직접 모델을 설계 및 구현 해야한다는 점때문에 구현이 어렵다는 단점이 있죠.

GraphRAG 를 언제 쓰는게 좋을지

GraphRAG가 만능은 아닙니다. 기존 RAG 가 잘 작동하는데 무리해서 Advanced RAG 인 GraphRAG를 사용한다? 주변 시선이 그렇게 좋지만은 않을거라 생각되네요. 기존 시스템에 무언가를 개선하려 할 때, 당위성이 필요합니다. 즉, 이걸 왜 해야돼 라는 주변의 물음에 사실 근거를 통해 답변하고 설득해야 하는거죠.

Retrieval 단계에서 가져오는 정보들과 유저 질의 의도가 매칭이 잘 되지 않을때, 시도해볼만합니다. Vector Search 의 근본적인 한계와 비슷한 맥락입니다.

Similarity 측정을 통해 Retrieval 하기에 엄밀히 말하면 '정확'한 값을 기반으로 정보를 가져오는게 아닌, '근사'한 값을 기반으로 정보를 가져오기 때문에 부정확한 정보를 가져올 수 있습니다.

이를 개선하려고 주로 BM25 를 도입하여 exact search 를 추가한 hybrid search 방식을 활용하거나, Ranking process 를 개선하여 Reranker function 을 만든다거나, 혹은 embedding 품질 개선을 위한 Fine-tuning 등 다양한 시도를 하게됩니다.

이 다양한 시도를 했음에도 불구하고 RAG 성능 개선이 미미하다 싶을때 GraphRAG 도입을 고민해보시는걸 추천합니다.

끝으로,

이번 포스팅에서는 RAG 부터 GraphRAG 까지 알아보았습니다. 적절한 답변을 위해 주로 Finetuning , from scratch , 프롬프트 엔지니어링 , RAG 등 방법을 통해 개선하고 있고, 그 중 RAG는 관련된 문서를 잘 가져와서 답변할 수 있으며 성능에 비해 상대적으로 소요 비용이 적다는 측면에서 굉장히 각광받고 있습니다. 하지만 , RAG 프로세스 중 Retrieval 관점에서 어떤 문서를 가져오는게 좋을지 질의와 비교해야하며, 어떤 문서를 몇 개 가져오는게 좋을지 등 과 같은 여러 제한이 있기 때문에, 이를 개선하기 위한 Advanced RAG가 대두되고 있습니다. 그 중 정확한 값이 아닌 ‘근사 유사’ 값 기반으로 접근한다는 기존 Retrieval 한계점을 개선하고자, ‘Semantic’ 측면으로 Reasoning, Retrieval 하는 Graph-RAG가 대안으로 많이 언급되고 있습니다. Graph-RAG 를 잘 활용하기 위해서 고려해야할 사항인 1.Chunking 데이터간 무슨 연관성이 있는지 추론하고 생성해주는 Information Extraction 기술, 2. 잘 저장하고 가져오는 Knowledge Indexing, 3.저장된 정보와 질의를 비교하여 관련 그래프를 가져오는 구절을 생성하는 그래프 질의 생성 모델 Cypher Generation Model 까지에 대해서도 알아보았습니다. 하루가 멀다하고 신기술이 계속 나오고 있어, 트렌드에 지쳐있는 여러분들에게 GraphRAG 교보재로 쓰일 수 있게 여러 논문들과 테크기업 블로그 등을 추려 핵심들만 기록해놓았으니, 본 포스팅을 통해 여러분들께서 GraphRAG 와 한 층 가까워지셨으면 합니다. 긴 글 읽어주셔서 감사드립니다.