지식 그래프란 '개체(엔티티)'와 '개체 간의 관계'를 그물처럼 조직화한 지식 표현 방식이다. 예를 들어 '장웨이—어느 IT 기업에 근무—직책은 엔지니어'와 같은 '주어—관계—목적어' 트리플을 이어 붙이면 하나의 그래프가 된다. 표 형식과의 가장 큰 차이는 관계가 일급 시민이라는 점이다. 조인 없이도 연관 관계를 바로 조회할 수 있다.
먼저 그 모습을 이해하자
가장 직관적인 이미지는 '노드+엣지'다. 노드는 사람·기업·장소·사건 같은 개체이고, 엣지는 '~년에 설립', '~에 위치', '~을 인수' 같은 관계다. 관계 자체에 이름이 붙어 있어 기계는 컬럼명을 추측하는 대신 관계를 읽고 의미를 이해할 수 있다. 검색 엔진의 지식 패널이나 백과사전의 정보 상자 뒤에는 지식 그래프의 발상이 숨어 있는 경우가 많다.
세 가지 경계: 지식 그래프가 아닌 것
첫째, 의미 검색이 된다고 해서 지식 그래프가 아니다. 그것은 벡터 데이터베이스다. 벡터가 저장하는 것은 '무엇과 닮았는가'이고, 지식 그래프가 저장하는 것은 '어떤 관계인가'이다. 둘째, 그래프 데이터베이스는 지식 그래프와 같지 않다. 그래프 데이터베이스는 저장 엔진이고, 지식 그래프는 지식을 조직하는 방식이다. 엔진은 지식 그래프를 담는 데 쓸 수 있지만 다른 그래프를 담을 수도 있다. 셋째, 대규모 언어 모델 자체는 지식 그래프가 아니다. 모델 파라미터에 암묵적으로 담긴 지식은 확률적이고 틀릴 수 있지만, 지식 그래프의 모든 관계는 명시적으로 선언되고 추적 가능하다.
비교표: 지식 그래프·벡터 데이터베이스·RAG의 역할 분담
세 자의 관계를 한 문장으로 정리하면, RAG는 일을 처리하는 흐름이고, 벡터 데이터베이스와 지식 그래프는 그 흐름에 지식을 공급하는 두 종류의 지식 저장소다.
| 비교 항목 | 지식 그래프 | 벡터 데이터베이스 | | 저장 내용 | 개체와 명확한 관계 | 텍스트를 변환한 벡터 | | 강점 | 다중 홉 추론, 정확한 질의응답 | 모호한 의미 매칭 | | 대표 질문 | 'A사 창업자가 또 창업한 회사는?' | '의미가 비슷한 문단 찾기' | | 약점 | 구축 비용이 크고 업데이트가 느림 | 엉뚱한 답이 나오기 쉬움 |
RAG(검색 증강 생성)는 검색한 지식을 대규모 모델에 넘겨 답변하게 하는 전체 파이프라인이다. 벡터 데이터베이스의 의미 검색도, 지식 그래프의 관계 질의도 쓸 수 있고, 둘을 함께 쓸 수도 있다. 이 방식은 학계에서 GraphRAG라고 불린다.
흔한 세 가지 오해
오해 하나, '지식 그래프는 구식이라 벡터 검색에 대체됐다'. 정반대다. 관계형 질문은 벡터 검색의 약점 그 자체다. 여러 단계를 거치는 질문(예: '어떤 제품 창업자의 전 직장을 인수한 회사는?')은 벡터 검색에서 연결이 끊기기 쉽고, 그래프의 관계 추론으로 메워야 한다. 오해 둘, '지식 그래프 구축=그래프 데이터베이스 설치'. 엔진은 그릇일 뿐이고, 진짜 일은 온톨로지 설계와 개체 정렬에 있다. '베이징'과 '베이징시'를 같은 노드로 볼 것인지는 어떤 데이터베이스를 고르느냐보다 훨씬 중요하다. 오해 셋, '중소기업은 못 쓴다'. 전 영역을 수작업으로 구축하는 건 확실히 비싸지만, 현실적인 방법은 '작고, 전문적으로'다. 제품 고장 사례집이나 법규 조항 DB처럼 하나의 업무 영역에만 집중하면 가장 효과를 내기 쉽다.
진짜로 잘하는 장면
금융 리스크 관리의 특수관계인 추적, 이커머스의 상품 지식 질의응답, 의료의 약물 상호작용 조회, 고객센터의 약관 조항 추적—공통점은 답이 정확하고, 설명 가능하며, 구체적인 관계까지 추적될 수 있어야 한다는 점이다. '비슷해 보이는' 텍스트로는 부족하다. 지식 그래프가 답하는 것은 '그것이 도대체 무엇인가'라는 질문이며, 업무가 모호한 답을 용납하지 않을 때 관계가 명확한 지식의 그물은 여전히 빠질 수 없는 기반 시설이다.
