벡터 검색이 "질문과 의미적으로 유사한" 문서만 찾아, 단어는 달라도 구조적으로 연결된 핵심 리스크를 놓치는 한계를 GraphRAG 로 푸는 방법을 다룬다. AWS GraphRAG Toolkit 이 Amazon Neptune 그래프와 OpenSearch 임베딩을 결합해 엔티티·관계를 따라가며 검색하는 구조와, 두 가지 검색기의 선택 기준을 코드까지 짚어 설명한다.
핵심 포인트- 인덱싱 때 LLM 이 텍스트에서 엔티티·관계를 추출해 Neptune 그래프에, 임베딩은 OpenSearch 에 저장하는 2축 구조다.
- 원본을 문장(Statement)·주제(Topic, 로컬 연결)·사실(Fact, 글로벌 연결)의 요약 계층으로 분해해 검색 단위로 쓴다.
- 쿼리는 질문 임베딩으로 top-k 청크를 찾아 그래프 진입점으로 삼고, 그 경로를 따라 연결 정보를 모아 LLM 이 답한다.
- 검색기는 모든 경로를 훑는 TraversalBasedRetriever 와 의미 기반으로 유망 경로만 고르는 SemanticGuidedRetriever 두 가지다.
- 핵심은 EntityNetworkSearch — 질문과 단어가 안 비슷해도 엔티티 네트워크의 구조적 연결을 따라 숨은 리스크 정보를 찾아낸다.
상세 정리- 문제 사례: "Example 기업의 영국 시장 판매 전망" 질문에 벡터 검색은 낙관적 매출 전망만 답하고, 물류 파트너의 운하 봉쇄로 인한 공급망 차질은 놓친다.
- 누락 이유: 벡터 검색은 "영국 판매 전망"과 의미적으로 유사한 문서만 찾는데, 운하·물류는 단어가 멀어 보여 구조적으로 밀접해도 걸리지 않는다.
- 인덱싱: LLM 이 "Example 기업", "AnyCompany Logistics" 같은 엔티티와 "제휴" 같은 관계를 뽑아 Neptune 에 그래프로 넣고, 청크 임베딩은 OpenSearch 에 둔다.
- 요약 계층: 문장은 FM 에 돌려줄 컨텍스트 단위, 주제는 같은 문서 내 문장의 로컬 연결, 사실은 여러 문서에 걸친 동일 사실의 글로벌 연결을 담당한다.
- 쿼리 2단계: Retrieve 에서 질문을 임베딩해 top-k 청크 ID 를 찾아 그래프 진입점으로 쓰고, Generate 에서 탐색 결과와 질문을 LLM 에 함께 넣어 구조화 결과 또는 자연어로 답한다.
- TraversalBasedRetriever: ChunkBasedSearch(청크→주제→문장→사실, 좁은 범위), EntityBasedSearch(엔티티→사실→문장→주제, 넓은 범위), EntityNetworkSearch(비유사 청크에서 구조적 연결) 세 전략으로 모든 경로를 전수 조사한다.
- SemanticGuidedRetriever: 하이브리드 검색으로 진입점을 잡고, 빔 검색으로 단계마다 상위 N개 경로만 유지하며, TF-IDF 재순위화와 다양성 필터로 노이즈를 줄여 빠르게 답한다.
- 선택 기준: Traversal 은 중소규모·정확성 우선(규제·법률·의료)·복잡한 관계 추적에, Semantic 은 수백만 노드 대규모·실시간 UX·비용 효율이 중요할 때 적합하다.
- 엔티티 네트워크: 질문에서 뽑은 엔티티 중심의 1~2단계 관계망이 "지문" 역할을 해, 비유사성 검색·프롬프트 강화·시각화에 쓰인다.
- 결과 정제: 후보 문장을 TF-IDF 로 재순위화하고, 최고 점수의 하위 5% 미만 문장을 가지치기해 답변 품질을 떨어뜨리는 노이즈를 제거한다.
- 비교 결과: 벡터 검색은 공급망 리스크를 전혀 못 짚는 반면, 그래프 검색은 운하 봉쇄로 인한 배송 지연·대체 경로 검토까지 포함한 답을 낸다.
- 비용 고려: Neptune+OpenSearch 동시 운영과 다단계 그래프 탐색으로 지연·인프라 비용이 벡터 단독보다 높아, 의사결정 가치가 클 때만 권장한다.
왜 읽나여러 문서에 흩어진 복잡한 관계를 다뤄야 하는 RAG 설계자에게, GraphRAG 의 검색기 선택과 엔티티 네트워크 활용을 코드 수준까지 짚어주는 실무 가이드.
AWS Korea Tech·
인프런 (인프랩)·
네이버 D2·
Vercel Blog·