AWS 기술 블로그
GraphRAG Toolkit으로 지식 그래프 쿼리하기
시리즈 안내
이 글은 3편으로 기획된 GraphRAG Toolkit 시리즈의 3번째 글입니다.
시리즈의 첫 번째 글인 Neptune GraphRAG Toolkit을 활용하여 정교한 비정형 데이터 검색하기에서는 비정형 데이터에서 벡터 임베딩이 포함된 그래프를 자동으로 구축하고, 구조적으로 관련된 정보를 검색하는 질의응답 전략 프레임워크를 소개했습니다. 두 번째 글인 GraphRAG Toolkit으로 지식 그래프 인덱싱하기에서는 해당 toolkit을 활용하여 지식 그래프를 단계별로 인덱싱하는 과정을 심도 있게 설명했습니다. 그리고 이번 세 번째 글인 GraphRAG Toolkit으로 지식 그래프 쿼리하기에서는 다양한 그래프 탐색 전략을 통해 효율적인 검색이 가능하도록 안내합니다.
GraphRAG Toolkit 시리즈를 통해 그래프 기반 탐색의 이해도를 높이고 Neptune 기반의 GraphRAG 구현을 손쉽게 할 수 있었으면 합니다.
왜 벡터 검색만으로는 부족할까?
AI 챗봇을 도입한 많은 기업이 겪는 고민 중 하나는 “검색은 잘 되는데, 왜 정답은 엉뚱할까?”입니다. 그 답은 ‘벡터 검색’의 한계에 있습니다. 구체적인 사례를 통해 왜 GraphRAG Toolkit이 필요한지 알아보겠습니다.
사례로 보는 벡터 검색의 맹점
지난 시리즈 1편에서 활용하였던 샘플 시나리오를 다시 한번 살펴보도록 하겠습니다.
AI 챗봇에게 “Example 기업의 영국 시장 판매 전망은?”이라고 물었다고 가정해 봅시다.
- 벡터 검색 기반 RAG의 답변 : “영국 시장에서 제품 수요가 증가하고 있으며, 크리스마스 시즌에 매출이 급증할 것입니다.”
- 결과 : 매우 낙관적이고 논리적인 답변처럼 보입니다.
하지만 숨겨진 진실은 다릅니다.
실제로는 Example 기업의 물류 파트너인 AnyCompany Logistics가 ‘Fictitious 운하’를 통해 제품을 운송하고 있는데, 현재 이 운하가 막혀 공급망에 심각한 차질이 생길 위기입니다.
벡터 검색은 왜 이 정보를 놓쳤을까요?
벡터 검색은 오직 “영국 판매 전망”과 의미적으로 유사한 문서만 찾기 때문입니다. “운하 막힘”이라는 정보는 단어 자체로는 판매 전망과 거리가 멀어 보이지만, 구조적으로는 매우 밀접하게 연관된 리스크입니다. 이런 정보를 놓친 채 내린 의사결정은 결국 수백만 달러의 손실로 이어질 수 있습니다.
GraphRAG가 꼭 필요한 경우
단순한 검색을 넘어 데이터 간의 연결 고리를 읽어야 할 때 GraphRAG는 빛을 발합니다.
- 복잡한 관계망 데이터 : 여러 문서에 걸쳐 공급망, 조직 구조, 규제 등 복잡한 관계가 얽혀 있는 경우
- 숨겨진 연결 정보 : 질문과 직접적인 단어 유사성은 낮지만, 비즈니스 맥락상 중요한 연결 정보가 필요한 경우
- 의사결정의 무게 : 정보의 정확성과 완전성이 비즈니스 의사결정에 직격타를 미치는 경우
벡터 검색만으로도 충분한 경우
모든 상황에 복잡한 그래프가 필요한 것은 아닙니다. 다음과 같은 경우에는 기존 벡터 검색이 더 효율적일 수 있습니다.
- 단순 질의응답 : 단일 문서 내의 FAQ나 간단한 Q&A 처리
- 단순한 데이터 구조 : 데이터 간의 복잡한 관계가 거의 없는 경우
- 명확한 유사성 : 질문과 답변이 단어와 의미상으로 매우 유사하게 매칭되는 경우
핵심 용어 정리
이 글에서 사용하는 주요 용어들을 먼저 정리합니다.
| 용어 | 설명 |
|---|---|
| RAG (Retrieval-Augmented Generation) | LLM이 답변을 생성하기 전에 외부 데이터에서 관련 정보를 검색한 후 이를 바탕으로 응답을 생성하는 기법 |
| LLM / FM (대규모 언어 모델 / 파운데이션 모델) | 대량의 텍스트 데이터로 학습된 AI 모델. 자연어를 이해하고 생성할 수 있음 (예: Amazon Bedrock의 Claude, Amazon Titan 등) |
| 지식 그래프 (Knowledge Graph) | 정보를 노드(엔티티)와 엣지(관계)로 표현하는 데이터 구조. “Example 기업 → 사용한다 → AnyCompany Logistics”처럼 관계를 명시적으로 저장 |
| 임베딩 (Embedding) | 텍스트를 고차원 숫자 벡터로 변환한 것. 의미가 유사한 텍스트는 벡터 공간에서 가까운 위치에 놓임 |
| 청크 (Chunk) | 문서를 LLM이 처리할 수 있는 크기로 나눈 텍스트 조각 |
| 문장(Statement) | LLM에 전달되는 컨텍스트의 기본 단위 |
| 주제(Topic) | 같은 문서 내 관련 문장들의 그룹 (로컬 연결) |
| 팩트(Fact) | 여러 문서에 걸친 동일 사실의 연결 (글로벌 연결) |
| 엔티티 네트워크 | 질문에서 추출된 엔티티 중심의 1~2단계 관계 네트워크 |
| top-k 검색 | 가장 유사한 상위 k개 결과를 반환하는 검색 |
| TF-IDF | 단어 빈도와 희소성 기반의 중요도 계산 방법 |
| 빔 검색 | 각 단계에서 상위 N개 유망한 경로만 유지하는 탐색 알고리즘 |
| Amazon Neptune | AWS의 완전관리형 그래프 데이터베이스 서비스. 엔티티 간의 관계를 저장하고 탐색하는 데 최적화 |
| Amazon OpenSearch Serverless | AWS의 관리형 검색 및 벡터 스토어 서비스. 임베딩 기반 유사도 검색을 수행 |
전체 아키텍처와 쿼리 프로세스 한눈에 보기
GraphRAG 시스템은 크게 저장(Indexing)과 찾기(Querying)라는 두 가지 축으로 움직입니다.
GraphRAG 워크플로
인덱싱 단계 (데이터의 구조화)
문서가 입력되면 LLM이 텍스트에서 엔티티(예: “Example 기업”, “AnyCompany Logistics”)와 이들 사이의 관계(예: “제휴하다”)를 추출합니다. 이 정보는 Neptune에 그래프 형태로 저장되고, 텍스트 청크의 임베딩은 OpenSearch에 저장됩니다.
해당 단계에 대한 좀 더 자세한 내용은 시리즈 두 번째 블로그를 참조하시면 더욱 쉽게 이해되실 겁니다.
쿼리 단계 (지능형 검색)
사용자의 질문이 들어오면, 단순히 단어만 찾는 것이 아니라 벡터 검색과 그래프 탐색을 결합하여 가장 관련성이 높은 정보를 찾아냅니다. 이후 LLM이 이 정보를 종합해 최종 답변을 생성합니다.
쿼리 프로세스 개요
쿼리는 크게 검색(Retrieve)과 생성(Generate) 두 단계로 나뉩니다. 그중 검색 단계의 구체적인 과정을 살펴보겠습니다.
Retrieve (검색)
- 질문 임베딩 생성 : 사용자의 질문을 AI가 이해할 수 있는 수치 형태(Embedding)로 변환합니다.
- Top-k 유사도 검색 : 질문의 임베딩과 가장 가까운(유사한) 상위 k개의 청크(Chunk) ID를 찾습니다.
top-k similarity 검색이란? 질문의 임베딩 벡터와 가장 가까운(유사한) k개의 청크를 찾는 것입니다. 예를 들어 k=10이면 가장 유사한 상위 10개 청크를 반환합니다.
- 그래프 탐색의 시작점(Entry Points): 위에서 찾은 청크 ID들은 이제 그래프 내에서 관련 정보를 더 깊게 찾아 들어가기 위한 ‘탐색 시작점’이 됩니다.
Generate (생성)
단순히 데이터를 나열하는 것이 아닙니다. 앞선 단계에서 얻은 그래프 탐색 결과와 사용자의 질문을 LLM(거대언어모델)에게 함께 전달합니다. 그러면 LLM은 이 방대한 연결 정보를 종합하여, 사람이 대화하듯 자연스러운 문장으로 답변을 생성합니다.
모든 사용자가 긴 줄글의 답변만을 원하는 것은 아닙니다. GraphRAG Toolkit은 사용자의 목적(워크로드)에 맞춰 두 가지 형태의 결과물을 모두 지원하는 유연함을 갖추고 있습니다.
옵션 A. 구조화된 검색 결과 (Structured Results)
- 대상: 1~3단계의 검색 작업에서 얻은 정제된 데이터 자체가 필요한 경우
- 활용: 데이터 분석, 다른 시스템과의 연동, 혹은 자체적인 가공이 필요한 기술적인 워크로드에 적합합니다.
옵션 B. 자연어 응답 (Natural Language Response)
- 대상: 4단계 생성 작업을 통해 도출된 친절한 설명이 필요한 경우
- 활용: 고객 응대 챗봇, 지식 탐색 서비스 등 최종 사용자에게 직접 정보를 전달해야 하는 서비스에 최적화되어 있습니다.
그래프 탐색과 검색 전략
그래프라는 거대한 지식의 바다에서 원하는 정보를 어떻게 정확히 찾아낼까요? GraphRAG는 단순히 무작위로 뒤지는 것이 아니라, ‘길을 찾는 논리적인 단계’ 를 거칩니다.
그래프 탐색의 첫 번째 성공 열쇠는 바로 ‘어디서부터 시작할 것인가’ 를 정하는 것입니다.
- 벡터 스토어의 역할: 질문과 가장 관련이 깊은 데이터 노드를 찾아내어 탐색의 진입점(Entry Point) 역할을 수행합니다. 마치 복잡한 미로의 입구를 정확히 찾아주는 나침반과 같습니다.
일단 입구를 찾았다면, 그 노드와 연결된 관련 문장(Statement)들을 따라가며 탐색을 확장합니다. 이를 통해 질문에 답하기 위해 필요한 맥락을 입체적으로 수집하게 됩니다.
요약 계층(Summary Layer)의 역할
GraphRAG Toolkit은 원본 문서를 단순히 저장하지 않습니다. 검색의 효율을 극대화하기 위해 데이터를 세 가지 요소로 정교하게 분해하여 저장하는데, 이를 요약 계층(Summary Layer)이라고 부릅니다.
왜 요약 계층이 중요한가요?
텍스트를 무분별하게 쌓아두는 대신 세 가지 요소로 나누어 저장하면, 검색 시 각 요소가 서로 다른 책임(Responsibility) 을 다하게 됩니다.
- 맞춤형 검색: 질문의 성격에 따라 어떤 요소는 ‘전체적인 흐름’을, 어떤 요소는 ‘구체적인 사실’을 담당하며 최적의 답변 정보를 제공합니다.
- 구조적 저장: 원본의 복잡함을 걷어내고 그래프가 이해하기 쉬운 형태로 최적화되어, 더 빠르고 정확한 탐색이 가능해집니다.
요약 계층의 요소들은 검색에서 각각 다른 책임을 수행합니다.
| 요소 | 역할 |
|---|---|
| 문장(Statement) | FM에 반환되는 컨텍스트의 주요 단위 |
| 주제(Topic) | 동일한 소스에서 파생된 문장들 간의 로컬 연결성 제공 |
| 사실(Fact) | 서로 다른 소스에서 파생된 문장들 간의 글로벌 연결성 제공 |
지식 그래프의 가장 큰 매력은 데이터 사이의 ‘거리’와 ‘범위’를 조절하며 정보를 찾을 수 있다는 점입니다. 로컬(Local) 과 글로벌(Global) 연결성을 어떻게 구분하느냐에 따라, 우리는 목적에 맞는 최적의 검색 전략을 선택할 수 있습니다.
- 로컬 우선 탐색 (Local-first Search)특정 주제에 대해 ‘깊이 있는 정보’ 가 필요할 때 사용하는 전략입니다.
- 방식: 탐색의 대부분을 현재 위치한 로컬(가까운 범위) 영역에 집중합니다.
- 특징: 관련성이 높은 핵심 정보를 먼저 꼼꼼히 살피면서, 정말 필요한 경우에만 조심스럽게 먼 연결 고리(원격 기회)를 잠정적으로 탐색합니다. 세부적인 사실 확인에 유리합니다.
- 글로벌 우선 탐색 (Global-first Search)전체적인 ‘맥락과 조감’ 이 필요할 때 사용하는 전략입니다.
- 방식: 아주 광범위한 범위에서 거시적으로 탐색을 시작합니다.
- 특징: 전체 지도를 먼저 훑어본 뒤, 답변과 가장 관련이 깊고 유망해 보이는 특정 주제로 범위를 점차 좁혀(Drill-down) 나갑니다. 여러 문서에 흩어진 정보를 종합할 때 효과적입니다.
고수준 검색기 (High-Level Retrievers)
GraphRAG Toolkit은 사용자의 질문에 가장 적합한 답을 찾기 위해 두 가지 고수준 검색기를 제공합니다. 고수준 검색기 구조 흐름도를 보면 전체 구조를 이해하기 쉽습니다.
사용자 질문
│
├──> TraversalBasedRetriever (모든 경로를 체계적으로 탐색)
│ ├─ ChunkBasedSearch (벡터 유사성 → 좁은 범위)
│ ├─ EntityBasedSearch (엔티티 키워드 → 넓은 범위)
│ └─ EntityNetworkSearch (구조적 관계 → 비유사 콘텐츠)
│
└──> SemanticGuidedRetriever (유망한 경로만 선택적으로 탐색)
├─ 진입점 식별 (의미 + 키워드 복합 검색)
├─ 빔 검색 기반 그래프 탐색
└─ 결과 정제 (재순위화 + 다양성 필터링)
TraversalBasedRetriever
모든 가능성 있는 경로를 하나하나 체계적으로 훑어보는 방식입니다. 이 검색기는 데이터를 위아래로 훑으며 빈틈없이 정보를 수집합니다.
- 하향식(Top-down) : 벡터 유사성으로 청크를 먼저 찾고, 그와 연결된 주제 → 문장 → 사실 순으로 좁혀 들어갑니다.
- 상향식(Bottom-up) : 특정 엔티티(Entity) 키워드를 먼저 조회한 뒤, 그와 관련된 사실 → 문장 → 주제 순으로 확장하며 맥락을 파악합니다.
| 검색기 | 진입점 | 탐색 방향 | 결과 범위 |
|---|---|---|---|
| ChunkBasedSearch | 벡터 유사성으로 찾은 청크 | 청크 → 주제 → 문장 → 사실 | 좁은 범위 (유사 내용 중심) |
| EntityBasedSearch | 엔티티 네트워크의 엔티티 | 엔티티 → 사실 → 문장 → 주제 | 넓은 범위 (이웃 엔티티 기반) |
| EntityNetworkSearch | 엔티티 네트워크의 텍스트 표현 | 비유사 청크 → 주제 → 문장 → 사실 | 구조적 범위 (비유사 콘텐츠) |
TraversalBasedRetriever의 세부 전략
이 검색기들 중 가장 눈여겨볼 것은 ‘EntityNetworkSearch’ 입니다. 질문과 단어 자체가 비슷하지 않아도 ‘구조적으로 연결된 정보’ 를 찾아내기 때문입니다.
시리즈 1편에서 언급한 ‘Fictitious 운하 막힘’ 사례를 기억하시나요? “영국 판매 전망”이라는 질문과 직접적인 연관어는 없었지만, 공급망이라는 구조적 관계를 타고 들어가 이 결정적인 정보를 찾아낸 주인공이 바로 이 검색기입니다.
SemanticGuidedRetriever
벡터 기반의 의미 검색과 구조화된 그래프 탐색이 만난 이 하이브리드 방식의 작동 원리를 3단계로 살펴보겠습니다.
- 진입점 식별 (Entry Point Identification)
- 탐색을 시작하기 전, 가장 유망한 출발지를 찾는 과정입니다.
- 하이브리드 검색 : 단순히 단어가 같은지(키워드 검색)만 보지 않고, 질문의 숨은 의미(Semantic Search)까지 동시에 분석합니다.
- 초기 노드 선별 : 질문과 맥락적으로 가장 밀접하게 연결된 그래프 속 첫 번째 단서(노드)들을 찾아냅니다.
- 지능적 그래프 탐색 (Intelligent Graph Traversal)
- 입구를 찾았다면 이제 그래프의 거미줄 같은 관계망을 타고 이동합니다.
- 빔 검색 (Beam Search) : 모든 길을 다 가보는 대신, 각 단계에서 가장 가능성 높은 상위 N개의 경로만 유지하며 나아갑니다. 덕분에 대규모 그래프에서도 속도와 효율성을 모두 잡을 수 있습니다.
- 경로 분석 (Path Analysis): 노드 사이의 관계를 단순히 잇는 것이 아니라, 그 연결이 질문에 답하는 데 얼마나 ‘의미 있는 연결’인지 분석합니다.
- 결과 정제 (Result Refinement)
- 찾아낸 정보들을 사용자가 읽기 좋게 다듬는 최종 공정입니다.
- 재순위화 (Re-ranking): TF-IDF와 같은 통계적 기법을 활용해 결과의 중요도를 다시 계산합니다. 단어의 빈도와 희소성을 고려해 가장 가치 있는 정보에 높은 점수를 부여합니다.
- 다양성 필터링 (Diversity Filtering): 비슷한 내용이 중복되어 답변이 지루해지지 않도록, 중복되거나 유사한 결과는 과감히 제거합니다.
SemanticGuidedRetriever 사용 시나리오:
이 지능형 검색기는 다음과 같은 상황에서 진가를 발휘합니다.
- 방대한 데이터 규모: 그래프가 너무 커서 모든 경로를 다 뒤지기에는 효율성이 떨어질 때
- 복잡한 다중 개념 질문: 질문 하나에 여러 개념이 얽혀 있어, 입체적인 연결이 필요한 답변을 원할 때
- 고품질의 다양한 답변: 정답의 정확도는 기본, 중복 없는 풍부한 정보를 동시에 확보해야 할 때
어떤 검색기를 선택해야 할까?
GraphRAG 시스템을 구축할 때 가장 고민되는 지점은 바로 “어떤 검색 방식(Retriever)이 내 데이터에 최적일까?” 하는 것입니다. 두 검색기의 핵심 차이점과 상황별 선택 기준을 정리해 보았습니다.
| 구분 | TraversalBasedRetriever (경로 기반) | SemanticGuidedRetriever (의미 기반) |
|---|---|---|
| 핵심 컨셉 | “모든 길을 꼼꼼하게” | “유망한 지름길로 똑똑하게” |
| 탐색 방식 | 연결된 모든 경로를 전수 조사 | 의미를 분석해 정답 확률이 높은 경로만 선택 |
| 강점 | 정보 누락 최소화, 높은 신뢰도 | 압도적인 검색 속도, 대규모 데이터 최적화 |
TraversalBasedRetriever를 추천하는 경우
- 데이터 규모가 중소형일 때: 그래프가 아주 크지 않아 모든 경로를 탐색해도 속도 저하가 없을 때.
- 정확성이 최우선일 때: 단 하나의 단서도 놓치면 안 되는 규제 준수(Compliance)나 법률, 의료 분야의 답변이 필요할 때.
- 복잡한 관계 추적이 핵심일 때: 겉으로 드러나지 않는 아주 깊은 관계까지 모두 훑어야 하는 정밀 분석 업무일 때.
SemanticGuidedRetriever를 추천하는 경우
- 데이터가 방대할 때: 수백만 개의 노드가 얽힌 거대 그래프에서 빠른 응답 속도가 생명일 때.
- 사용자 경험(UX)이 중요할 때: 실시간 대화형 서비스처럼 사용자가 즉각적인 답변을 기대할 때.
- 비용 효율성을 고려할 때: 불필요한 LLM 호출과 탐색 과정을 줄여 인프라 비용을 절감하고 싶을 때.
벡터 검색 vs 그래프 기반 검색: 결과 비교
똑같은 질문을 던졌을 때, 단순 벡터 검색과 지식 그래프 기반 검색이 얼마나 다른 수준의 답변을 내놓는지 실제 사례를 통해 확인해 보겠습니다.
벡터 검색만 사용한 답변
“영국 시장 전망은 긍정적입니다. 수요가 꾸준히 늘고 있고 크리스마스 시즌 매출 급증이 예상됩니다. 강력한 브랜드 인지도도 보유하고 있습니다.”
→ 겉으로 드러난 텍스트 유사성만 찾다 보니, 공급망 리스크를 전혀 언급하지 못하는 치명적인 한계를 보입니다.
그래프 기반 검색을 사용한 답변
“Example 기업의 영국 시장 판매 전망은 전반적으로 긍정적이나, 주의해야 할 리스크가 있습니다. 위젯 수요는 증가 추세이며 크리스마스 시즌 매출 급증이 예상됩니다. 그러나 Example 기업의 물류 파트너인 AnyCompany Logistics가 Fictitious 운하를 통해 제품을 운송하고 있는데, 현재 이 운하가 막혀 있어 배송 지연이 발생할 수 있습니다. 이는 크리스마스 시즌 재고 확보에 영향을 미칠 수 있으므로 대체 운송 경로를 검토할 필요가 있습니다.”
→ 질문에는 없지만 구조적으로 연결된 ‘물류’와 ‘운하’ 정보를 찾아내어 비즈니스 임팩트까지 포함한 완벽한 인사이트를 제공합니다.
코드 예제
아래 코드를 실행하려면 GRAPH_STORE와 VECTOR_STORE 환경 변수가 설정되어 있어야 합니다.
- 그래프 스토어 : Amazon Neptune (엔티티와 관계를 저장)
- 벡터 스토어 : Amazon OpenSearch Serverless (임베딩 기반 유사도 검색)
- 실행 환경 : Amazon SageMaker 노트북 또는 로컬 Python 환경
자세한 설정 방법은 GraphRAG Toolkit GitHub 리포지토리를 참고하세요.
import os
from graphrag_toolkit.lexical_graph import LexicalGraphQueryEngine
from graphrag_toolkit.lexical_graph.storage import GraphStoreFactory, VectorStoreFactory
with (
GraphStoreFactory.for_graph_store(os.environ['GRAPH_STORE']) as graph_store,
VectorStoreFactory.for_vector_store(os.environ['VECTOR_STORE']) as vector_store
):
query_engine = LexicalGraphQueryEngine.for_traversal_based_search(
graph_store,
vector_store,
streaming=True,
tenant_id='ecorp' # 멀티테넌시 지원: 동일한 그래프에서 테넌트별로 데이터를 격리
)
response = query_engine.query("Example 기업의 영국 시장 판매 전망은 어떻습니까?")
GraphRAG 쿼리 실행 결과
상세 검색 결과 확인
검색 과정에서 GraphRAG Toolkit은 각 문장에 점수를 매기고 해당 문장을 찾은 검색 전략(retriever)의 이름을 주석으로 표시합니다.
import json
for n in response.source_nodes:
print(json.dumps(n.metadata, indent=2))
출력 예시:
{
"score": 0.85,
"retrievers": ["ChunkBasedSearch", "EntityNetworkSearch"],
"statement": "Example Corp has partnered with AnyCompany Logistics for UK distribution",
"topic": "Example Corp UK Supply Chain",
"source": "supply_chain_report_2024.pdf"
}
검색 결과 메타데이터 출력
여러 Retriever의 동시 실행과 엔티티 네트워크
GraphRAG Toolkit은 기본적으로 ChunkBasedSearch와 EntityNetworkSearch라는 두 개의 retrievers를 함께 가동합니다. 성격이 다른 두 전문가가 각자의 방식으로 정답(Statement)을 찾아오는 것이죠.
- ChunkBasedSearch (의미 중심): 질문과 단어 뜻이 비슷한 텍스트 조각(Chunk)에서 시작합니다. [주제 → 문장 → 사실] 순서로 깊이 있게 탐색하며 문맥을 파악합니다.
- EntityNetworkSearch (구조 중심): 질문과 직접적인 단어 유사성은 낮더라도, 엔티티 네트워크를 통해 구조적으로 연결된 정보를 찾아냅니다. 겉으로 드러나지 않는 ‘숨은 연결 고리’를 찾는 탐정 역할을 합니다.
서로 다른 경로로 탐색했는데 동일한 정보(Statement)에 도달했다면, 그 결과는 훨씬 더 신뢰할 수 있기 때문입니다. “교차 검증”을 통해 정답의 확실성을 높이는 전략입니다.
Score 계산과 Reranking
찾아온 수많은 정보 중 진짜 알짜배기를 골라내는 과정입니다. 마치 오디션 프로그램의 순위 결정전과 같습니다.
- 초기 수집: 각 retrievers가 가져온 후보 문장(Statement)들을 한데 모읍니다.
- Reranking (재순위화): TF-IDF 방식을 사용해 질문과의 관련성을 점수로 환산합니다. 단순히 많이 나온 단어가 아니라, 핵심적인 정보를 담은 문장에 가중치를 줍니다.
- Pruning (가지치기): 최고 점수의 하위 5% 미만인 낮은 점수의 문장들은 과감히 제거합니다. 답변의 질을 떨어뜨릴 수 있는 ‘노이즈’를 걸러내는 작업입니다.
엔티티 네트워크 컨텍스트
그래프 기반 검색이 효과적인 진짜 이유는 바로 이 ‘엔티티 네트워크’를 활용하기 때문입니다.
엔티티 네트워크란?
질문에서 추출된 중요한 키워드(엔티티)를 중심으로 1~2단계 정도 연결된 관계망을 말합니다. 이 네트워크는 질문과 직접적인 단어는 다르더라도, 그 질문이 가리키는 대상이 무엇인지 알려주는 일종의 ‘지문(Fingerprint)’ 역할을 합니다.
엔티티 네트워크 활용 방식
- 비유사성 검색 (Dissimilarity Search)때로는 정답이 질문 속에 쓰인 단어와 전혀 상관없어 보일 때가 있습니다. 이때 엔티티 네트워크는 의미상으로는 멀어 보이지만, 사실은 밀접하게 연결된 콘텐츠를 찾기 위한 초기값(Seed) 역할을 수행합니다.
- 작동 원리 : 질문과 직접적인 유사도가 낮은 정보라도, 그래프의 경로를 따라가며 탐색의 시작점으로 삼습니다.
- 실제 사례 : “Example 기업의 영국 판매 전망은?”
- 질문에는 ‘운하’나 ‘물류’라는 말이 없습니다.
- 하지만 GraphRAG는 그래프를 타고 Example Corp → AnyCompany Logistics → Fictitious 운하 → 운하 막힘 이라는 경로를 자동으로 찾아냅니다.
- 결과 : “판매 전망”이라는 질문에 대해, 의미적으로는 다르지만 구조적으로 치명적인 리스크인 “운하 막힘” 정보를 정확히 찾아내어 답변에 포함합니다.
- 프롬프트 강화 (Prompt Enhancement)찾아낸 소중한 엔티티 네트워크 정보는 단순히 검색 결과로만 머물지 않습니다. 응답을 생성할 때 LLM(거대언어모델)에게 전달되는 프롬프트의 추가 컨텍스트로 포함됩니다.
- 효과 : LLM이 수많은 검색 결과 중에서 ‘어떤 정보가 진짜 핵심 관계인지’를 정확히 인지하게 합니다.
- 결과 : LLM은 이 가이드라인을 따라 겉도는 답변이 아닌, 핵심 맥락을 정확히 짚어내는 고품질의 응답을 생성하게 됩니다.
- 엔티티 네트워크 시각화이 모든 복잡한 연결 고리를 글로만 보는 것이 아니라, 실제로 눈으로 확인할 수 있다면 어떨까요?GraphRAG Toolkit은 검색 결과로 도출된 엔티티 네트워크를 시각적으로 보여주는 기능을 제공합니다. 이를 통해 사용자는 AI가 왜 이런 답변을 내놓았는지, 데이터들이 어떻게 얽혀 있는지 그 ‘논리적인 지도’를 한눈에 파악할 수 있습니다.
from graphrag_toolkit.lexical_graph.visualisation import GraphNotebookVisualisation v = GraphNotebookVisualisation(nb_classic=True) v.display_entity_contexts(response)
엔티티 네트워크 시각화
엔티티 연결 구조
데이터는 서로 징검다리처럼 연결되어 있습니다. 이 연결 구조가 탄탄할수록 AI는 더 똑똑한 추론을 할 수 있습니다.
- 시장과 물류의 결합 : UK ↔ AnyCompany Logistics ↔ Fictitious Canal
- 영국 시장으로 가는 길목에 어떤 물류 경로가 있는지 지도로 그립니다.
- 파트너와 제품의 결합 : AnyCompany Logistics ↔ Example Corp ↔ Widget
- 우리의 제품이 어떤 파트너의 손을 거쳐 이동하는지 파악합니다.
- 제품과 시장의 결합 : Widget ↔ United Kingdom
- 최종적으로 제품이 도달해야 할 목적지를 명확히 연결합니다.
검색 프로세스 상세
엔티티 네트워크를 활용한 검색은 단순히 정보를 긁어모으는 것이 아니라, 마치 탐정이 단서를 쫓듯 체계적으로 진행됩니다.
엔티티 네트워크 기반 검색 프로세스
- 엔티티 추출 (Entity Extraction) : 사용자의 질문에서 핵심 키워드(엔티티)를 정확히 뽑아내어 탐색의 뼈대를 잡습니다.
- 그래프 탐색 (Graph Traversal) : 추출된 엔티티를 시작점으로 삼아, 거미줄처럼 이어진 그래프의 경로를 따라가며 숨은 단서를 찾습니다.
- Fact 수집 (Fact Gathering) : 탐색 과정에서 발견된 구체적인 사실(Fact)들을 하나하나 수집합니다.
- Statement 생성 (Statement Generation) : 수집된 정보들을 주제(Topic)별로 그룹화하고, 출처(Source)를 명확히 하여 LLM이 이해하기 좋은 형태의 문장으로 재구성합니다.
LLM 프롬프트 구성
이렇게 정교하게 수집된 엔티티 네트워크 컨텍스트는 최종적으로 LLM에게 전달됩니다. 단순히 검색 결과만 던져주는 것이 아니라, 데이터 간의 ‘관계망’ 자체를 프롬프트에 포함하여 LLM이 맥락을 완벽히 이해하고 답변하도록 돕습니다.
LLM 프롬프트 구성 구조
성능 및 비용 고려사항
그래프 기반 검색은 분명 강력하지만, 현실적인 비즈니스 도입을 위해서는 성능과 비용의 균형을 꼼꼼히 따져봐야 합니다.
| 항목 | 설명 |
|---|---|
| 지연 시간 (Latency) | 그래프 탐색은 여러 단계(Hop)를 거치므로 응답 시간이 길어질 수 있습니다. 특히 모든 경로를 훑는 TraversalBasedRetriever는 SemanticGuidedRetriever보다 느릴 수 있습니다. |
| 인프라 비용 | 그래프(Neptune)와 벡터(OpenSearch) 저장소를 동시에 운영해야 하므로, 벡터 검색만 사용할 때보다 유지 비용이 높습니다. |
| 그래프 규모 | 데이터가 방대해질수록 탐색 범위가 넓어집니다. 따라서 효율적인 검색기(Retriever) 선택과 파라미터 튜닝이 필수적입니다. |
Tip : 정확성과 완전성이 생명인 비즈니스 의사결정 시나리오라면 GraphRAG의 추가 비용은 충분히 가치가 있습니다. 하지만 단순한 FAQ 답변이나 문서 조회가 목적이라면 기존 벡터 검색만으로도 충분합니다.
직접 시작하기 : 내 손으로 만드는 GraphRAG
이 강력한 기능을 직접 체험해보고 싶으신가요? 다음 단계를 따라 바로 시작해 보세요.
- GitHub 리포지토리 방문 : GraphRAG Toolkit 내 Workshop에서 전체 소스 코드와 예제 노트북을 확인하세요.
- 필요한 AWS 서비스:
- Amazon Neptune: 복잡한 관계를 저장할 그래프 데이터베이스
- Amazon OpenSearch Serverless: 효율적인 벡터 스토어
- Amazon Bedrock: 강력한 LLM 및 임베딩 모델
- 실행 환경 : Amazon SageMaker 노트북을 활용하면 복잡한 설정 없이 예제를 즉시 실행할 수 있습니다.
결론
이번 가이드를 통해 우리는 GraphRAG Toolkit의 핵심을 모두 살펴보았습니다.
- 쿼리 프로세스 : 단순 검색을 넘어 검색(Retrieve) → 생성(Generate)의 정교한 2단계 과정을 거칩니다.
- 검색 전략 : 질문의 성격에 맞춰 진입점을 찾고 최적의 문장(Statement)으로 이동하는 스마트한 검색기들을 활용합니다.
- 벡터 검색의 한계 극복 : 의미만 비슷한 불완전한 답변을 넘어, 구조적으로 연결된 진짜 정보를 찾아냅니다.
- 엔티티 네트워크 : 비유사성 검색과 프롬프트 강화를 통해 답변의 품격을 한 차원 높입니다.
GraphRAG Toolkit은 벡터 유사성 검색의 한계를 넘어섭니다. 비즈니스 의사결정에 꼭 필요한 ‘구조적 인사이트’를 제공함으로써, 가장 정확하고 완전한 답변을 생성하는 파트너가 되어줄 것입니다.
Amazon Neptune GraphRAG Toolkit 시리즈를 통해 기술 소개부터 인덱싱, 쿼리 전략까지의 전체 여정을 함께 살펴보며 단순 텍스트 검색을 넘어 데이터 간의 복잡한 연관 관계와 맥락을 반영하는 지식 그래프의 차별화된 가치를 확인했습니다. 특히 비정형 문서에서 개체와 관계를 추출해 그래프와 벡터 저장소를 결합한 최적의 인덱스를 구축하는 방법을 학습하고, 다양한 그래프 탐색 전략을 기반으로 효율적인 검색에 대한 이해를 높였습니다. 이번 3부작 시리즈가 LLM의 환각 현상을 줄이고 고도화된 엔터프라이즈급 AI 애플리케이션을 성공적으로 구현하는 데 든든한 나침반이 되기를 바랍니다.