Graph RAG (지식 그래프, Memgraph, 쿼리 생성)

검색 성능이 좋아지면 답변 품질도 자연스럽게 올라갈 것 같지만, 실제로는 정보를 찾는 방식만큼 정보가 서로 어떻게 연결되는지가 중요합니다. Graph RAG는 바로 그 연결의 문제를 정면으로 다루는 기술입니다. 이 글에서는 IBM이 공개한 튜토리얼을 바탕으로 Memgraph와 Llama-3를 묶어 Graph RAG를 구현하는 흐름과, 그 과정에서 알아둘 점을 정리했습니다.

지식 그래프, 검색이 아니라 관계를 읽는 기술

Graph RAG를 벡터 검색의 변형 정도로 여기기 쉽지만, 출발점인 지식 그래프(Knowledge Graph)는 구조부터 다릅니다. 지식 그래프란 데이터 포인트를 노드(Node), 즉 정보의 단위로 표현하고, 그 사이를 엣지(Edge)라고 불리는 관계선으로 연결하는 구조입니다. 쉽게 말해, 단어나 개념을 점으로 찍고 그 점들 사이에 "누가 누구와 함께 일하는지", "어떤 직책을 갖는지"처럼 맥락 있는 선을 잇는 방식입니다.

기존 벡터 검색 방식은 텍스트를 수치 벡터로 변환해 유사도를 계산하는 방식입니다. 관련 문서를 꽤 잘 찾아주지만, '왜 관련 있는지', '어떤 경로로 연결되는지'는 설명하지 못합니다. 그래서 복잡한 조직 관계나 인과관계가 얽힌 데이터에서는 맥락을 놓치기 쉽습니다. 반면 지식 그래프 기반 RAG, 즉 Graph RAG는 관계 자체가 데이터입니다. 노드 못지않게 엣지가 중요하다는 발상 전환이 핵심입니다.

Neo4j나 Amazon Neptune 같은 그래프 데이터베이스가 이 구조를 저장하고 탐색하는 역할을 합니다. 이 튜토리얼에서는 오픈소스 그래프 데이터베이스인 Memgraph를 사용했는데, Memgraph는 인메모리 방식으로 동작해 속도가 빠르고 Cypher라는 선언형 쿼리 언어를 지원합니다. Cypher란 SQL처럼 데이터를 질의하는 언어인데, 테이블과 행 대신 노드와 관계를 다룬다는 점이 다릅니다. "MATCH (p:Person)-[:COLLABORATES]->(c:Person)"처럼 관계의 방향과 유형을 직관적으로 표현할 수 있어서 처음 보는 사람도 구조를 금방 파악할 수 있습니다.

정리하면, 데이터를 '찾는' 시스템과 데이터를 '읽는' 시스템 사이에는 생각보다 큰 간극이 있습니다. 지식 그래프는 후자에 훨씬 가까운 접근법입니다. 특히 챗봇, 추천 엔진, 사기 탐지처럼 맥락과 관계가 핵심인 도메인에서 그 차이가 두드러집니다.

Memgraph에 그래프를 심다, LLM이 구조를 만드는 순간

Graph RAG를 구현하는 첫 번째 고비는 사실 데이터베이스 연결이 아니라 "어떻게 텍스트에서 그래프를 만드는가"입니다. 사람이 직접 노드와 엣지를 정의하면 규모가 조금만 커져도 금방 한계에 부딪힙니다. 그 부분을 LLM이 상당 부분 자동화해주는 게 Graph RAG의 진짜 가치입니다.

LangChain의 LLMGraphTransformer(LLM 그래프 변환기)를 사용하면 비정형 텍스트에서 엔터티와 관계를 자동으로 추출해 그래프 구조로 변환할 수 있습니다. LLMGraphTransformer란 LLM에게 텍스트를 주면 노드 유형과 관계 유형을 지정된 형식으로 뽑아내는 파이프라인입니다. watsonx를 통해 Meta의 Llama-3-3-70b-instruct 모델을 연결하고, "Person", "Title", "Group"이라는 노드 유형과 "TITLE", "COLLABORATES", "GROUP"이라는 관계 유형을 사전에 정의하면, 모델이 텍스트를 읽고 자동으로 Cypher 쿼리 구문을 생성합니다.

튜토리얼 예시처럼 "John's title is Director of the Digital Marketing Group. John works with Jane whose title is Chief Marketing Officer."라는 짧은 문장을 넣었을 때, 모델이 John, Jane, Sharon이라는 Person 노드와 그들의 직책, 소속 그룹을 올바르게 추출하고 관계까지 연결합니다. 환각(hallucination), 즉 LLM이 존재하지 않는 정보를 그럴듯하게 만들어내는 현상을 억제하기 위해 temperature를 0.3 정도로 낮게 설정하는 것이 도움이 됩니다.

구현 흐름을 정리하면 다음과 같습니다.

1. watsonx.ai 프로젝트를 생성하고 API 키와 프로젝트 ID를 발급받습니다.
2. Docker를 이용해 Memgraph를 로컬에 설치하고, bolt://localhost:7687 포트로 연결합니다.
3. LLMGraphTransformer로 텍스트를 그래프 문서로 변환하고, Memgraph에 노드와 엣지를 삽입합니다.
4. Memgraph Lab 뷰어에서 생성된 네트워크 구조를 시각적으로 확인합니다.

Memgraph Lab에서는 생성된 네트워크 그래프를 화면으로 확인할 수 있습니다. 텍스트 한 줄이 노드와 화살표로 시각화되는 모습을 보면 지식 그래프가 단순한 데이터 저장소가 아니라는 점을 쉽게 이해할 수 있습니다. 관련 기술 스택에 대한 공식 문서는 Memgraph 공식 문서에서 확인할 수 있습니다.

쿼리 생성, 프롬프트 엔지니어링이 전부를 결정한다

그래프가 만들어졌다고 끝이 아닙니다. 사용자가 자연어로 "John의 직함이 뭐야?"라고 물었을 때, LLM이 이를 정확한 Cypher 쿼리로 변환해야 합니다. 이 단계의 성패를 가르는 것이 프롬프트 엔지니어링(Prompt Engineering)입니다. 프롬프트 엔지니어링이란 LLM이 원하는 형식과 내용의 출력을 내놓도록 입력 지시문을 설계하는 기술입니다.

LangChain의 FewShotPromptTemplate(퓨샷 프롬프트 템플릿)을 사용하면 여러 예시 질문과 그에 대응하는 Cypher 쿼리를 LLM에게 미리 보여줄 수 있습니다. 퓨샷 프롬프트란 몇 가지 입출력 예시를 함께 제공해 LLM이 패턴을 학습하도록 유도하는 기법입니다. 예시 없이 프롬프트를 던지면 모델이 쿼리 외에 불필요한 설명을 덧붙이거나 잘못된 Cypher 구문을 생성하는 경우가 생깁니다. 반면 FewShotPromptTemplate으로 정확한 예시를 제공하면 출력이 훨씬 안정적입니다.

핵심은 모델의 출력을 Cypher 구문으로만 제한하는 지시문을 prefix에 넣는 것입니다. "Respond with ONE and ONLY ONE query", "Do not include any explanations" 같은 직접적인 제약이 LLM의 과잉 응답을 막아줍니다. 또한 질문 답변 단계에서도 별도의 QA 프롬프트를 구성해, 그래프 데이터베이스에서 반환된 결과를 자연어로 변환하는 과정을 제어합니다.

MemgraphQAChain(Memgraph 질의응답 체인)은 이 두 단계, 즉 자연어를 Cypher로 변환하고 결과를 다시 자연어로 해석하는 과정을 하나의 파이프라인으로 묶어줍니다. query_gen_parameters에서 temperature를 0으로 설정하고 length_penalty를 적용한 것도 이 단계에서 모델의 출력을 간결하게 유지하기 위해서입니다. 프롬프트 설계의 세부 전략은 프롬프트 엔지니어링 개요 문서에서도 참고할 수 있습니다.

Graph RAG의 한계, 데이터 구조가 추론 품질을 결정한다

Graph RAG에서 가장 중요한 점은, 기술 스택보다 데이터 구조의 정교함이 결과의 질을 좌우한다는 사실입니다. 일반적으로 LLM이 강력하니까 데이터가 조금 엉성해도 알아서 채워주겠거니 하는 기대를 하기 쉽지만, 실제로는 그렇지 않습니다.

노드 간의 관계(엣지) 정의가 모호하거나 누락된 경우, 추론 엔진이 틀린 결론을 논리적인 것처럼 포장해서 내놓는 상황이 발생할 수 있습니다. 예를 들어 "협력(COLLABORATES)" 관계와 "소속(GROUP)" 관계가 혼재되어 설정된 데이터에서는 쿼리 결과가 예상과 전혀 다르게 나올 수 있습니다. 데이터의 양보다 관계의 정확도가 더 중요한 이유입니다.

현실 세계의 데이터는 항상 깔끔하지 않습니다. 조직 내 비공식 관계, 역할 중복, 시간에 따른 변화처럼 규칙화하기 어려운 정보들이 넘칩니다. 이런 데이터를 무리하게 노드와 엣지로 고정해버리면, 오히려 추론이 경직되고 엉뚱한 결과를 낳을 수 있습니다. 이것이 Graph RAG의 가장 큰 숙제입니다. 기술 자체의 문제라기보다는, 도메인 지식을 가진 사람이 그래프 설계에 깊이 개입해야 한다는 구조적 한계입니다.

또 한 가지, LLM의 환각 문제는 그래프 생성 단계에서도 여전히 존재합니다. allowed_nodes와 allowed_relationships로 생성 범위를 제한하면 상당 부분 억제할 수 있지만, 복잡한 원문에서는 의도하지 않은 엔터티가 등장할 수 있습니다. 결국 기계가 만든 그래프를 인간이 검토하고 재검증하는 단계는 생략할 수 없습니다. 완벽해 보이는 추론 결과라도 바탕 구조를 확인하는 주체적 시각이 반드시 필요합니다.

자주 묻는 질문

Q. Graph RAG와 일반 RAG는 뭐가 다른가요?

A. 일반 RAG는 벡터 데이터베이스를 이용해 텍스트 유사도 기반으로 관련 문서를 검색합니다. 반면 Graph RAG는 지식 그래프 구조를 활용해 데이터 간의 관계와 맥락까지 추론합니다. 복잡한 관계가 얽힌 데이터일수록 Graph RAG가 더 정확한 컨텍스트를 제공합니다. 단순 유사도 검색으로는 잡아내기 어려운 인과관계나 계층 구조를 표현할 수 있다는 점이 핵심 차이입니다.

Q. Memgraph 말고 다른 그래프 데이터베이스도 사용할 수 있나요?

A. 네, Neo4j나 Amazon Neptune도 같은 방식으로 활용할 수 있습니다. LangChain은 다양한 그래프 데이터베이스 커넥터를 지원하기 때문에 큰 코드 변경 없이 전환이 가능합니다. 튜토리얼에서 Memgraph를 사용한 이유는 오픈소스이면서 인메모리 방식으로 속도가 빠르고, Cypher 쿼리를 그대로 사용할 수 있어 학습 곡선이 낮기 때문입니다.

Q. LLM이 Cypher 쿼리를 잘못 생성하면 어떻게 대응하나요?

A. FewShotPromptTemplate으로 올바른 예시를 충분히 제공하고, prefix에 출력 형식을 엄격하게 제한하는 지시문을 넣는 것이 가장 효과적입니다. 그래도 오류가 발생할 수 있으므로, 중요한 쿼리는 Memgraph Lab에서 직접 실행해 결과를 검증하는 과정을 습관화하는 것이 좋습니다. 완전한 자동화보다 인간 검수를 병행하는 구조가 현실적입니다.

Q. Graph RAG 구축에 가장 많은 시간이 걸리는 부분은 어디인가요?

A. 일반적으로 그래프 스키마, 즉 어떤 노드와 관계 유형을 사용할지 설계하는 단계가 가장 까다롭습니다. 코드 작성보다 도메인을 이해하고 정보 간 관계를 구조화하는 작업에 훨씬 더 많은 고민이 필요합니다. LLM이 텍스트에서 자동으로 그래프를 생성해주긴 하지만, 그 결과물이 의도한 대로 나오려면 초기 스키마 설계가 탄탄해야 합니다.

Q. watsonx 없이 다른 LLM으로 구현할 수 있나요?

A. 가능합니다. LangChain은 OpenAI GPT-4, Anthropic Claude 등 다양한 LLM과 통합을 지원합니다. Microsoft의 GraphRAG 프레임워크나 LlamaIndex를 활용하는 방법도 있습니다. watsonx는 기업 환경에서 모델 관리와 거버넌스 측면에서 편리하지만, 개인 프로젝트나 프로토타입 수준에서는 OpenAI API나 로컬 모델로도 충분히 구현할 수 있습니다.

Graph RAG는 아직 완성된 기술이라기보다 빠르게 성숙하고 있는 방법론입니다. 구현 자체는 생각보다 접근하기 어렵지 않지만, 의미 있는 결과를 뽑으려면 도메인 지식과 데이터 설계 역량이 함께 필요합니다. 지식 그래프 기반 AI에 관심이 생겼다면, 작은 데이터셋부터 직접 노드와 관계를 정의해보는 것을 권합니다. 코드를 읽기만 하는 것보다 그래프가 만들어지는 과정을 직접 확인해 보면 이해가 훨씬 빨라집니다.

---

참고: https://www.ibm.com/kr-ko/think/tutorials/knowledge-graph-rag