GraphRAG를 실무에 적용하기 위한 고려요소

 

본 포스팅은 아래 유투브 방송을 기반으로 정리하였습니다.

https://www.youtube.com/live/zHN2jDZHvI0?si=6qdOcUgd0PvbX_ke

 

GraphRAG의 경우 기술 자체의 매력도 있지만, 빅테크의 기술 마케팅 활동, 마이크로 소프트의 GraphRAG 기술 공개, (확실하진 않지만) 팔란티어 사례로 주목을 받고 있는 것으로 판단됨

하지만, GraphRAG의 경우 비용 문제가 큰 걸림돌인데, 그 이유는 특정 기준을 만족할 때까지 계속 반복되는 현상 때문임. 따라서, 엔티티의 정확도를 기반으로 비용이 달라질 수 있음. 따라서, 문서간의 데이터나 관계 파악이 중요하지 않는다면 기존 RAG를 사용하는 것이 더 나을 수 있음. 특히 관계 정의가 부실하다면 기존 벡터 기반 RAG보다 성능이 더 떨어질 수 있음. 

1. GraphRAG를 제대로 활용하기 위해 중요한 것

GrpahRAG에서 중요한 요소 : 1.온톨로지 2. 스키마 설계임

온톨로지는 일종의 합의된 세계관, 공통된 체계로 볼 수 있음. 예를 들어 '핀테크 A가 고객B에게 C를 제공한다'의 경우 A, B, C는 노드, 제공한다는 엣지가 됨. 더 나아가 명시적 참조, 언어적 애매모호함을 해결하는 것이 중요한데, 정규 표현식, 키워드 뿐만 아니라 LLM을 활용하여 의미를 분석하고 연결하는 작업도 수행하고 있음.

1. 문제 정의 및 목표 명확화

기존 벡터 RAG의 한계를 명확하게 인지하고, 그래프 구조가 유리한 문제 상황을 정의

특히 멀티 홉 쿼리나 추론 복잡성이 높은 질문 등 관계 기반 추론이 필요한 경우 GraphRAG를 도입. 성공 기준은 기술 구현이 아닌 상용화되어 유저에게 서비스 되는 것

2. 관계 중심 문서 선정

모든 문서(데이터)에 GraphRAG를 적용할 필요는 없으므로, 관계의 중요성이 높은 문서(보험, 법률 관련)부터 시작

3. 온톨로지 및 스키마 협의

그래프에서 노드 간의 관계 생성은 주관적인 해석이 많이 들어가므로, 엔지니어, 분석가, 도메인 전문가 간의 합의를 이루는 것이 필수적. 이 합의를 체계화 하는 도구로 온톨로지가 사용되고, 스키마는 노드가 가질 라벨과 프로퍼티를 정의

예를 들어, 제조 공정에서 결함 추적 사례로, 현장 전문가와 분석가가 정의하는 연결의 의미가 다를 수 있기 때문에, 주관적인 차이를 극복하고 관계를 정의하는 온톨로지부터 만드는 것이 성공의 열쇠

 또한, 요구 사항이 바뀌면 스키마를 계속 진화되는데 기존 엔티티를 업데이트 진행하여 수행해야 함

4. 구체화된 엔티티 추출

이 지점에서 LLM은 하드 또는 소프트 프롬프팅으로 나누게 됨. 하드 프롬프팅은 추출된 서브 그래프를 텍스트 형태로 LLM에 직접 주입하는 방식이며, 소프트 프롬프팅은 그래프 인코드(GNN)을 사용하여 노드와 엣지의 피처를 벡터로 변환하여 사용하는 방식으로, 구조적인 정보를 직접 넣어주는 방식임. 최근에는 이 두 가지를 활용하여 텍스트 정보랑 구조 정보를 함께 활용하는 것이 많음

결국, 공통적으로 얼마나 정확하게 관계를 추출하고, 필요한 정보를 어떻게 효율적으로 찾아내느냐가 제일 중요함.

현실적으로 현장에서는 특히, 표 데이터를 어떻게 그래프로 구조화할 것인가 같은 문제가 있음. 이를 해결하기 위해서, 문서나 데이터 간의 복잡하고 암묵적인 연결성을 명시적으로 구축하는데 중점을 둔 관계 중심 접근과 LLM이 표를 요약하고, 이 요약을 노드 정보로 활용하여 검색 효율성을 높이는 요약 중심으로도 해결하고 있음. 특히, 요약 중심에서는 LLM 기반 프롬프팅 엔지니어링이 중요함.  다양한 참조 표현을 LLM을 통해 학습을 시켜, 참조 표현 사전을 구축해서 다양한 형태의 참조 관계를 잡아내기도 함. (문서가 업데이트 되면 참조 관계가 변경될 수 있음)

2. Text-to-Cypher

사용자의 자연어 질문을 GDBMS가 이해하고 처리할 수 있는 질의 언어닌 Cypher로 자동 변환하는 Text-to-Cypher가 시스템의 가장 큰 병목 현상임. 기존 벡터DB는 사용자의 쿼리를 임베딩하여 벡터 검색을 수행하는 것으로 충분하지만, GDBMS는 둘 중 하나는 수행해야 함.

1. 사용자 쿼리를 임베딩하여 그래프 DB내 벡터와 조화하는 방식

2. 사용자 쿼리에서 엔티티를 추출하여 엔티티 기반의 키워드 검색을 수행하는 방식

궁극적으로 GDB는 유저 쿼리를 Cypher로 변환하여 데이터를 조회해야 하므로, 이 변환 및 조회 과정에서 병목 현상이 발생함. 이는 Text2SQL이 격는 어려움과 유사한 맥락임. 

결국 Text-to-Cypher의 성공률을 높이기 위해서는

1. 프롬프트 엔지니어링 및  Few-shot 

LLM이 복잡한 그래프 스키마를 이해하고 정확한 Cypher를 생성하도록 돕기 위해서는 정교한 프롬프트 엔지니어링이 필수로, few-shot을 통해 스키마를 인지 시켜줘야 함. few-shot 예시로는 특정 기간과 같은 수치형 데이터를 처리하는 방식, 그리고 필터링을 위한 내용 등이 반영되어야 함.

성공적인 퓨삿 예시는 사용자가 직접 만들지 않고도, LLM에 요청하여 초벌 Cypher를 생성하게 한 뒤, 이를 튜닝하는 방식으로 효율적으로 로 구축 가능

2. 라우팅 전략

단일 프롬프트가 모든 그래프 검색 시나리오를 커버하는 것은 비현실적이므로, 쿼리에 따라 사전에 설정된 Text-to-Cypher 프롬프트를 활용하여 라우팅하는 것이 합리적.

라우팅을 위해 사전에 쿼리마다 셋업하고, 유저의 쿼리, 사전에 설정된 텍스트 투 사이퍼 프롬프트, 그리고 그 결과물(혹은 예시)이 함께 들어가야 LLM이 거기에 맞게 쿼리를 번형해줌.

이 라우팅 방식은, 기존 유저의 쿼리를 분석하여 쿼리의 유사성, 길이, 그리고 난이도 등을 기준으로 설정

3. 결국 DB 최적화

LLM이 성공적으로 Cypher 쿼리를 생성했더라도, 대규모 데이터 환경에서는 DB 자체에서 성능 병목이 발생할 수 있음. LangGraph와 같은 에이전트 도구를 활용하여 Text-to-Cypher의 생성-검증-보정 과정을 체계적으로 수행. 또한,  메모리 증설, 인덱싱, 가비지 컬렉터 튜닝, 실행 계획 강제 적용 등에 따라 데이터베이스 차원의 쿼리 튜닝이 병행되어야 함

3. 평가 시스템 선정

GraphRAG의 고유한 추론 능력을 정량적으로 평가하기 위해, 기존의 평가 방식에 의존하기 보다 추론 복잡성에 따라 쉬움/중간/어려움으로 나눈 특화 데이터셋을 자체적으로 구축하는 것이 필요함. 또한, 실질적인 비즈니스 지표로도 평가 필요함

4. GDBMS 선정 기준

1. 생태계 : DB-Engines 랭킹, LangChain/LlamaIndex와의 통합 여부, 지원하는 언어(Cypher, Gremlin 등)을 확인

2. 성능 검증 : LDBC(Linked Data Benchmarking Council)에서 제공하는 표준화된 벤치마크 결과를 참고하여 스케일 팩터(데이터량) 대비 비용 및 성능 예측 필요

3. 적합성 : 데이터의 성격(CRUD 빈도, 인메모리 필요 여부) 등을 고려

주요 GDBMS 예시 : Neo4j(생태계 우수, 엔터프라이즈 비용 높음), KuzuDB(디스크 기반, 확장성 좋음), TigherGraph(매트릭스 형태로 속도 빠름)