지식 그래프
사람·회사·제품 같은 대상을 점(노드)으로, 그 사이 관계를 선(엣지)으로 저장한 데이터베이스로, "A가 세운 회사가 만든 제품은?"처럼 관계를 여러 단계 따라가야 답이 나오는 질문에 쓴다. AI에서는 RAG 검색을 더 정확하게 하거나 LLM 답변을 사실로 받쳐 주는 데 쓴다.
| 방식 | 데이터 모양 | 잘하는 질문 |
|---|---|---|
| 관계형 DB | 표(행·열) | 집계, 조건 검색 |
| 벡터 검색 | 문서 조각의 의미 벡터 | 비슷한 내용 찾기 |
| 지식 그래프 | 노드와 관계 | 관계를 여러 단계 따라가기 |
사실을 '주어-관계-대상'으로 쌓는다
"스티브 잡스 — 공동창업 — Apple", "Apple — 제조 — 아이폰"처럼 사실 하나를 세 칸짜리 묶음으로 저장한다. 관계형 DB가 표로 데이터를 표현한다면, 지식 그래프는 연결로 의미를 표현한다. 연결을 따라가면 "잡스가 세운 회사의 제품"이 바로 나온다.
2012년 구글이 Knowledge Graph를 발표하고 검색 결과 옆 정보 상자(Knowledge Panel)에 쓰면서 널리 알려졌다.
LLM에 붙이는 순서
흔한 방법은 Neo4j나 Amazon Neptune 같은 그래프 DB에 데이터를 넣고, LLM이 자연어 질문을 그래프 쿼리로 바꾸게 하는 것이다. LangChain의 GraphCypherQAChain이 이 흐름을 묶은 도구로, 질문을 Neo4j의 쿼리 언어인 Cypher로 바꿔 실행하고 그 결과로 답을 만든다.
| 단계 | 하는 일 |
|---|---|
| 모델링 | 둘 엔티티·관계를 정한다 (예: 직원-소속-팀) |
| 적재 | 문서·DB에서 사실을 뽑아 넣는다 |
| 질의 변환 | LLM이 질문을 Cypher로 바꾼다 |
| 답변 | 쿼리 결과를 근거로 LLM이 답한다 |
문서 검색과 섞는 Graph RAG 방식도 있다. 벡터 검색으로 관련 문서를 찾고, 거기 나온 엔티티의 연결을 그래프에서 더 가져와 LLM에 함께 넘긴다.
관계가 핵심일 때만 쓴다
| 상황 | 추천 |
|---|---|
| 조직도, 제품 의존성, 규정 간 참조 | 지식 그래프 |
| 매뉴얼·FAQ에서 비슷한 내용 찾기 | 벡터 검색 |
| 매출 합계, 기간별 통계 | 관계형 DB |
질문 대부분이 "문서에 뭐라고 쓰여 있나"라면 그래프를 만드는 수고가 아깝다. "무엇이 무엇과 연결되나"가 자주 나올 때 효과가 크다.
만드는 것보다 유지가 어렵다
엔티티를 뽑고 관계를 정하는 데 손이 많이 가고, 같은 대상이 다른 이름("애플"과 "Apple Inc.")으로 들어가면 연결이 끊긴다. LLM으로 자동 추출하면 빠르지만 틀린 관계가 섞이니 검수가 필요하다.
LLM이 만든 쿼리가 틀리면 엉뚱한 답이 나오고, 데이터를 바꾸는 쿼리가 실행될 위험도 있다. DB 계정은 읽기 전용으로 주고, 그래프 구조(스키마)를 프롬프트에 함께 넣으면 쿼리가 더 정확해진다.
검색 보강과 사내 데이터 질의에 주로 쓴다
가장 흔한 건 RAG에 관계 정보를 더하는 방식이다. 벡터 검색만으로는 놓치는 "누가 누구와, 무엇이 무엇과 연결되나"를 그래프에서 채워 LLM에 넘긴다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 사내 문서 검색 (Graph RAG) | 벡터 검색으로 찾은 문서의 엔티티를 그래프에서 따라가 관련 사실까지 함께 답변 근거로 |
| 사내 데이터 질의 챗봇 | 조직도·제품 의존성을 그래프 DB에 넣고, LLM이 질문을 Cypher로 바꿔 읽기 전용으로 조회 |
| 검색 엔진 정보 상자 | 인물·회사를 검색하면 관련 사실과 연결된 대상을 결과 옆에 정리해 보여준다 |
