
복잡하게 얽혀있는 정보를 이해하는 건 여러 분야에서 정말 중요한 과제인데요. 이 글에서는 이 문제를 해결하기 위한 새로운 AI 접근 방식을 소개하려고 해요. 기계가 데이터를 이해하고 탐색하는 방식을 개선하면, 법률 분석부터 과학 연구까지 다양한 분야에서 새로운 통찰력을 얻을 수 있는 가능성이 열린답니다. 특히, 대법원 판례 데이터 탐색을 통해 더욱 일관성 있는 그래프 구성을 위해 메타데이터 기반의 Ontology를 사용하는 새로운 방법을 소개해 드릴 거예요.
AI 시스템은 어떻게 추론할까요?
AI 추론은 계속 발전하고 있지만, 여전히 해결해야 할 과제들이 남아있어요. 어떻게 하면 정확하고 유연하게 추론할 수 있는 시스템을 만들 수 있을까요?
최근에는 Retrieval-Augmented Generation(RAG)과 같이 구조화된 지식 검색과 LLM의 생성 능력을 결합하여 이러한 격차를 해소하려는 시도가 이루어지고 있지만, 아직 갈 길이 멀답니다.
우리는 기계가 인간의 지능을 어떻게 시뮬레이션할 수 있을지에 대한 사고방식을 계속 발전시켜 나가고 있어요. 초기에는 추론을 논리와 규칙으로 풀어야 하는 수수께끼처럼 여겼죠. AI 시스템은 지식이 깔끔하게 정리된 전문가 시스템, 즉 Ontology (사실과 관계를 구조화해서 표현한 것)와 조건부 규칙으로 이루어져 있었어요. 예를 들어, MYCIN이라는 초기 AI는 의료 진단을 위해 설계되었는데, "if-then" 규칙을 적용해서 질병과 치료의 관계망을 탐색하고 정확하고 설명 가능한 결정을 내렸답니다.
하지만 이런 상징 체계는 결국 정해진 규칙만큼만 효과적이라는 문제가 있어요. 온톨로지랑 다르게, 실제 지식은 복잡하고 불확실하며 계속 변하잖아요. 이렇게 딱딱한 시스템은 새롭거나 예상치 못한 정보에 적응하기 어렵죠. AI가 좁은 영역을 벗어나려고 할수록, 추론이 엄격한 논리에만 갇혀 있을 수 없다는 게 분명해졌어요.
1990년대에는 또 다른 패러다임 전환이 있었는데, 바로 확률 모델의 등장이에요. 이런 시스템은 엄격한 규칙을 따르기보다는 통계를 사용해서 교육적인 추측을 하는 방식으로 불확실성을 받아들였어요. 예를 들어, 베이지안 네트워크를 사용하면 AI는 불완전한 정보를 바탕으로 다양한 결과가 나올 가능성을 확률적으로 추론할 수 있죠. 정말 중요한 발전이었어요! 이제 AI 시스템은 더 많은 모호성을 처리하고 데이터로부터 학습할 수 있게 되면서, 이전의 상징적인 시스템보다 훨씬 유연해졌으니까요.
하지만 이런 유연성에는 대가가 따랐어요. 확률 모델은 강력하지만, 상징 체계만큼 투명하지 않았거든요. 결정을 추적하고 설명하기가 더 복잡해졌죠. 추론 과정의 모든 단계를 볼 수 있었던 전문가 시스템의 해석 가능성은 일반화 및 확장 능력을 위해 희생된 셈이에요.
오늘날 AI 추론은 GPT-4, Llama 3 같은 Large Language Model(LLM)의 등장으로 계속 발전하고 있어요. 이런 모델들은 명시적인 규칙이나 확률보다는 엄청난 양의 데이터에서 학습된 패턴에 따라 추론하는 것처럼 보이거든요.
LLM은 인간 대화의 흐름을 흉내 내서 굉장히 상세하고 상황에 맞는 답변을 만들어내요. 연구자들은 LLM이 세상에 대한 "진짜" 이해를 나타내는 건지, 아니면 그냥 그런 "척"하는 건지에 대해 의견이 분분하죠. LLM이 실제로 추론 능력이 있든 없든, 이전에는 불가능했거나 자동화하기 매우 어려웠던 다양한 작업을 효과적으로 수행할 수 있다는 건 분명해요.
하지만 LLM은 강력한 만큼 단점도 있어요. 이전 시스템과 달리 구조화된 지식 기반이 부족해서 추론 과정이 불투명하죠. 설득력 있는 텍스트를 생성할 수는 있지만, 사실에 대한 확실한 근거가 없으면 엉뚱한 소리를 할 수도 있어요. 즉, 듣기에는 그럴듯하지만 실제로는 틀린 정보를 만들어내는 거죠. LLM의 이런 블랙박스 같은 특성은 AI의 근본적인 긴장, 즉 해석 가능성과 유연성 사이의 균형을 강조하고 있어요.
- LLM은 훈련 데이터에 의해 제한돼요.
- 환각 (Hallucination): LLM은 그럴듯하지만 잘못된 정보를 생성할 수 있어요.
- 최신 정보 부족: 실시간 또는 최근 업데이트된 데이터에 접근할 수 없어요.
Vector Database는 대부분의 Retrieval-Augmented Generation(RAG) 시스템의 핵심이에요. 문서 Vector Embedding을 효율적으로 저장하고 검색해서, 빠른 유사성 검색을 통해 관련 문서를 찾을 수 있게 해주죠. 이건 LLM에 정확하고 최신 정보를 제공하는 데 정말 중요해요.
GraphRAG: 한 단계 더 나아가기
RAG는 외부 지식에 접근하고 활용하는 AI 시스템의 능력을 크게 향상시켰지만, 한계가 없는 건 아니에요. RAG는 관련 문서를 찾는 데는 뛰어나지만, 서로 다른 정보 사이의 복잡한 관계망을 포착하고 활용하는 데는 어려움을 겪는 경우가 많아요.
GraphRAG는 Microsoft Research와 Neo4j 연구자들이 발표한 이후 업계에 등장한 새로운 개념이에요. Microsoft Research 와 에서 발표했죠. 지식을 그래프 구조로 표현해서 이런 단점을 해결하는 걸 목표로 해요. GraphRAG에 대한 접근 방식도 계속 발전하고 있어서, 앞으로 이 최첨단 분야에서 다양한 구현 방식을 보게 될 거예요.
이번 글에서는 LLM 중심 접근 방식(Microsoft GraphRAG 문서에서 설명하는 방식)과 그래프 구성 시 LLM에 대한 의존도를 줄이는 접근 방식을 비교해 볼 거예요.
LLM 중심 GraphRAG 접근 방식
GraphRAG는 그래프 기반 지식 표현을 도입해서 RAG를 기반으로 구축되었어요. 이 접근 방식을 사용하면 시스템은 다음과 같은 작업을 할 수 있어요.
- 지식을 그래프로 표현: GraphRAG는 문서를 고립된 단어 모음으로 취급하는 대신, 엔터티와 그 관계를 캡처해요. 이건 사람이 정보를 생각하고 연결하는 방식과 비슷하죠.
- 다중 홉 추론 활성화: GraphRAG는 관계 체인을 따라서 지식을 그래프로 표현함으로써 복잡한 Query에 답할 수 있어요. 이걸 통해 단순한 문서 검색을 뛰어넘는 더 정교한 추론이 가능해지죠.
- 더 상황에 맞는 결과 제공: 그래프 구조를 사용하면 시스템이 정보의 맥락을 더 잘 이해할 수 있어서, 더 미묘하고 관련성 높은 응답을 얻을 수 있어요.
- 구조화된 데이터와 구조화되지 않은 데이터를 결합: GraphRAG는 전통적인 지식 기반을 구조화되지 않은 텍스트와 통합해서 더 포괄적인 지식 표현을 만들 수 있어요.
- 설명 가능성 향상: 그래프 구조를 사용하면 추론 과정을 더 쉽게 추적할 수 있어서, 시스템의 투명성과 신뢰성을 높일 수 있죠.
GraphRAG 사용 사례
GraphRAG는 다음과 같은 다양한 사용 사례에 활용될 수 있어요.
- 의료 진단 및 치료 계획: GraphRAG는 증상, 질병, 치료 간의 관계를 네트워크로 표현해서 의료 진단을 향상시킬 수 있어요. 의사가 증상을 입력하면 관련 정보를 찾기 위해 의학 문헌을 검색하죠. 구조화된 의학 지식과 지능형 검색을 결합하면 의사가 놓칠 수 있는 복잡한 진단 경로, 희귀 질환, 예상치 못한 치료 상호 작용을 발견하는 데 도움이 될 수 있어요.
- : GraphRAG는 금융 생태계를 계정, 개인, 거래의 네트워크로 모델링할 수 있어요. 잠재적인 사기 행위를 조사할 때 관련 기록과 패턴을 검색하죠. 분석가는 구조화된 재무 데이터 표현과 AI 기반 Query 생성을 결합해서 자금 흐름을 추적하고, 페이퍼 컴퍼니를 식별하거나, 기존 분석에 숨겨져 있을 수 있는 조직화된 사기 활동을 찾아낼 수 있어요.
- : GraphRAG는 공급업체, 제조업체, 유통업체의 네트워크를 나타낼 수 있어요. 프로세스를 최적화할 때 관련 공급업체 정보와 시장 동향을 검색하죠. 이 접근 방식을 사용하면 병목 현상을 빠르게 식별하고, 경로를 최적화하거나, 중단 시 대체 공급업체를 찾을 수 있어요. 구조화된 공급망 표현과 유연한 분석을 통합하면 복잡한 글로벌 시장에서 더 탄력적이고 효율적인 운영에 대한 통찰력을 얻을 수 있답니다.
LLM 중심 GraphRAG 접근 방식의 한계
GraphRAG가 매우 유용할 수 있지만, 자체적인 문제점도 가지고 있어요.
- LLM 종속적인 그래프 구성: GraphRAG는 보통 LLM을 사용해서 Knowledge Graph를 구성하는데, 이 방식은 다음과 같은 결과를 초래할 수 있어요.
- 그래프 구조의 불일치
- 지식 표현의 LLM 편향 또는 오류 전파
- 정보를 구성하는 데 사용되는 온톨로지에 대한 통제력 부족
- : 그래프가 커지면 쿼리의 복잡성과 필요한 계산 리소스가 엄청나게 증가할 수 있어요.
- 구조화된 데이터의 기반 부족: 그래프 구성 과정에서 기존의 구조화된 데이터(온톨로지나 메타데이터 등)를 제대로 활용하지 못할 수 있어요. 그래프 구성 작업을 LLM에 맡기면, 다중 홉 추론을 효과적으로 수행하기 어려울 정도로 가능한 Node 및 Edge 유형의 수가 폭발적으로 증가할 위험이 있죠.
이러한 제한 사항 때문에, 더 포괄적이고 통제된 지식 표현 및 검색 접근 방식이 필요하게 된답니다.
에이전트 그래프 탐색을 향한 길
데이터에 대한 추론은 여러 가지 형태로 나타날 수 있어요. RAG와 GraphRAG는 검색에 더 집중하는 반면, 저희는 Vector와 Graph Database를 함께 사용해서 구조화된 (그리고 궁극적으로는 자동화된) 데이터 탐색을 가능하게 하는 방법을 탐구하고 싶었어요. 기본적인 전제는 이렇습니다. Semantic Search를 사용해서 하위 그래프 필터링을 제한한 다음, 그래프 쿼리를 생성해서 ask and answer 상황에 맞는 질문을 던지는 거죠. 이 반복적인 탐색 과정은 수동으로 할 수도 있고, 에이전트 방식으로도 할 수 있어요.
이 접근 방식은 몇 가지 중요한 측면에서 GraphRAG와 다른데요, 이번 포스팅에서 자세히 살펴볼 거예요. 중요한 차이점 중 하나는, 그래프 구성을 위해 LLM에 의존하는 GraphRAG와는 달리, 저희는 메타데이터 데이터 세트 자체 (그리고 엔터티 및 관계에 대한 다른 "안정적인" 소스)에 내재된 정보를 활용한다는 점이에요. 이 메타데이터는 데이터의 기본적인 존재론적 구조를 형성하고, 이는 그래프에 그대로 반영된답니다.
앞으로 보여드리겠지만, 저희는 효과적으로 이 그래프에서 문맥상 관련 있고 유용한 답변을 얻을 가능성이 높은 쿼리를 만들 수 있어요. 이는 주로 그래프를 구성하는 제한된 방식 덕분이었죠.
잘 정의된 온톨로지에 따라 LLM이 생성할 수 있는 효과적인 쿼리의 수는, 엔터티 및 관계 유형에 부과된 제약에도 불구하고 실제로 증가해요. 이 접근 방식의 주요 이점은 다음과 같아요.
- : LLM은 엔터티 및 관계 유형을 제한함으로써 의미 있는 도메인별 연결에 집중하고 관련 없는 조합을 줄일 수 있어요.
- : 정의된 온톨로지는 도메인별 지식 구조에 맞춰 일관되고 상호 연결된 쿼리를 보장해 줘요.
- : 검색 공간이 좁아지면 뉘앙스에 대한 심층 분석이 가능해지고, 처리 속도가 빨라지며, 통찰력 있는 쿼리의 비율이 높아진답니다.
모든 데이터 세트가 이렇게 풍부한 메타데이터를 제공하는 건 아니에요. 그런 경우에는 온톨로지를 구성하고 적용하기 위한 대체 방법이 필요할 텐데요, 이 부분은 앞으로 다룰 포스팅에서 자세히 살펴볼 예정이에요. 하지만 지금은 그래프 구성을 안내하는 이러한 메타데이터 기반 방법에 집중해 볼게요.
저희 작업의 핵심은 다음과 같은 네 가지 주요 구성 요소를 결합하는 것이에요.
- 문서 데이터베이스(DDB): 문서, 기사 또는 기타 텍스트 기반 정보의 실제 콘텐츠와 같은 구조화되지 않은 원시 데이터를 저장하는 기반 역할을 해요.
- 벡터 데이터베이스(VDB): 문서의 고차원 Vector Embedding을 생성해서 Semantic Search를 가능하게 하고, 개념적으로 유사한 콘텐츠를 찾을 수 있게 해 줘요. (물론 Vector Database는 임베딩 모델의 사용에 의존하겠죠?)
- Graph Database(GDB): 이 유형의 데이터베이스는 엔터티(예: 사람, 장소 또는 기타 개념)를 Node로 나타내고, 이들 간의 관계를 Edge로 나타내기 때문에 상호 연결된 정보에 대한 복잡한 쿼리가 가능해요.
- LLM: LLM은 요약 및 그래프 쿼리 생성을 수행해요. 이 부분은 나중에 더 자세히 설명할게요.
시스템 흐름도를 한번 살펴볼까요?
의미 공간에서 그래프 쿼리까지
저희 작업 흐름은 에서 시작돼요. 문서, 문장, 단락 등 구조화되지 않은 원시 텍스트 데이터가 자연스러운 형태로 존재하는 곳이죠. 문제는 이 데이터를 도메인별 지식을 바탕으로 구조화되고 실행 가능한 데이터로 변환하는 것이에요.
저희 데이터는 두 개의 병렬 경로를 사용해요. 하나는 Vector Database로 이동하고, 다른 하나는 Graph Database로 이동하죠. 둘 다 원시 의미 데이터와 그래프를 구성하는 데 사용되는 메타데이터를 모두 포함하는 문서 저장소에서 시작된답니다.
- 그래프로 표시할 구조화된 문서: 저희는 문서의 구조를 분석하고, 문서로부터 개체와 관계를 추론하는 것부터 시작해요. 이는 데이터 세트의 온톨로지를 위한 기본 구성 요소를 제공하죠. 문서에서 발견된 모든 엔터티를 연결하는데, 문서 자체를 나타내는 Node를 포함해서요.
- 명명된 엔터티 인식(NER)을 통한 그래프 강화: 원시 데이터에서 보다 구조적으로 건전한 정보를 추출하기 위해, 저희는 구식 NER을 적용해서 텍스트에서 사람, 조직, 장소 등의 이름을 추출해요. 이 작업에 LLM을 사용하는 것과는 달리, 이 프로세스의 일부로 생성되는 관계 유형의 다양성은 상당히 제한적이어서 나중에 유용하게 사용될 거예요.
- 의미 공간에서 임베딩까지: 이 단계에서는 원시 텍스트를 고차원 벡터 표현, 즉 Vector Embedding으로 변환해요. 다른 RAG 프로세스와 마찬가지로 원시 텍스트 데이터를 더 작은 세그먼트로 나누어 포함하죠. 그런 다음 각 세그먼트가 포함되어 상위 문서를 가리키는 메타데이터와 함께 Pinecone에 저장돼요. 중요한 점은, 이 단계에서 사용된 문서 ID는 Graph Database에서 사용된 문서 ID와 일치한다는 거예요.
- RAG에 대한 Semantic Search: 다른 RAG 애플리케이션에서와 마찬가지로 검색된 일치 항목을 LLM의 컨텍스트로 사용해서 초기 쿼리와 관련된 요약을 생성해요. 이 요약 프로세스는 검색된 청크에서 주요 정보를 추출해서 사용자 쿼리에 대한 간결하고 관련성 높은 응답을 제공하는 데 도움이 되죠. 요약은 추가 탐색이나 보다 구체적인 후속 질문을 위한 출발점이 될 수도 있어요.
- 그래프 필터링으로서의 Semantic Search: 사용자가 쿼리를 수행하면 유사성 검색을 통해 청크를 찾아내요. 시스템은 일치하는 청크와 연관된 문서 ID를 반환하는데, 이는 Knowledge Graph의 Node ID에 해당하죠. 효과적으로 Semantic Search는 그래프를 필터링해서 초기 쿼리와 상황에 맞는 관련성을 갖는 Node와 Edge를 생성하는 거예요.
- 그래프 컨텍스트를 사용한 루프백: 이렇게 구조화된 그래프 컨텍스트를 가지고 시스템은 LLM으로 돌아가요. 이제 LLM은 이 그래프 기반 관점을 사용해서 더 정확하고 상황에 맞는 쿼리를 생성할 수 있죠. LLM은 맹목적으로 작동하는 대신 그래프로 정의된 관계와 제약 조건을 반영하는 쿼리를 작성해서 더 미묘하고 도메인 관련 질문을 할 수 있게 돼요.
데모 사용 사례: 대법원 사건 탐색
에이전트 그래프 탐색 접근 방식의 실제 적용을 보여주기 위해, 우리는 대법원 사건 탐색을 중심으로 한 예제를 개발했어요. 이 데모는 Semantic Search, Graph Database, 그리고 AI 기반 쿼리 생성 기능을 활용해서 우리 시스템이 어떻게 복잡한 법률 데이터에서 효과적으로 탐색하고 통찰력을 추출할 수 있는지 보여주죠.
우리가 선택한 대법원 사건 영역은 다음과 같은 여러 가지 이유로 이상적인 테스트 기반을 제공해요.
- 사건, 판사, 법적 개념 간의 풍부한 상호 연결
- 자연스럽게 그래프 표현에 적합한 구조화된 메타데이터
- Semantic Search와 그래프 순회를 모두 활용하는 복잡한 쿼리
다음 섹션에서는 이 데이터를 처리하고 시스템을 활용해서 의미 있는 통찰력을 생성하는 방법에 대한 구체적인 내용을 설명할게요.
우리 파이프라인은 세 가지 주요 구성 요소에 걸쳐 원시 사례 데이터를 수집하고 처리하는 것으로 시작돼요.
- 문서 데이터베이스(MongoDB): 각 사례의 전문과 메타데이터에 대한 기본 아카이브 역할을 해요.
- 벡터 데이터베이스(솔방울): Vector Embedding을 통해 Semantic Search 기능을 활성화하죠.
- Graph Database(Neo4j): 법률 영역 내의 복잡한 관계를 포착해서 Knowledge Graph의 기초를 형성해요.
파이프라인에 대한 자세한 분석은 다음과 같아요.
- 초기 수집 파이프라인:
- 에서 원시 데이터를 검색해요. Oyez API
- 검색된 HTML 데이터를 마크다운으로 변환하죠.
- Document DB에 데이터를 저장해요.
Raw → Document DB 파이프라인
- 우리는 각각에 내재된 메타데이터를 활용해서 온톨로지 기반 접근 방식을 적용해요.
caseDocument DB에서:
- 다음과 같은 주요 엔터티
Case,Party,Justice, 그리고Advocate정의되죠 (처리 파이프라인– 셀 8) - 다음과 같은 관계
advocated_by,decided_by,won_by데이터에서 파생돼요. (처리 파이프라인– 셀 14) - 데이터를 더욱 풍부하게 하기 위해 각 항목을 분석해요.
opinion"좋은 구식" NER를 사용한 텍스트flair(처리 파이프라인– 셀 10). - All
entitiesandrelations다음과 같이 저장됩니다.nodesandedgesNeo4j에서. - 동시에 고급 Semantic Search를 준비해요.
- 각 의견의 텍스트를 관리 가능한 덩어리로 나누죠.
- 의미론적 본질을 포착하기 위해 각 청크를 Vector Embedding으로 변환해요.
- 향후 의미론적 쿼리를 위해 이러한 임베딩을 벡터 데이터베이스에 저장하죠.
Document DB → Vector DB + GraphDB 파이프라인
Knowledge Graph와 임베딩을 적용한 후 데이터에서 통찰력 있는 쿼리를 생성하는 단계로 넘어갈게요.
프로세스는 포괄적인 맥락을 수집하는 것부터 시작해요(참조:graphStatsQueries.ts) :
- : Node 수, 관계 유형 및 공통 속성에 대한 자세한 정보를 수집해서 데이터 환경에 대한 거시적인 보기를 제공해요.
- : Node 및 관계 유형을 포함한 그래프 구조를 매핑하죠.
그런 다음 쿼리 생성기는 이 컨텍스트를 활용해서 Cypher 쿼리를 생성해요(참조: cypherQuestionsPromptBuilder.ts):
- 타겟 분석을 위해 특정 관심 영역을 입력할 수 있어요.
- 제로샷 학습 예시: 쿼리를 생성하는 방법에 대한 몇 가지 구체적인 예를 LLM에 제공하는 거죠. 이는 모델이 퍼지 일치, 선택적 일치 등을 활용하는 쿼리를 선호하는 데 도움이 돼요. 이 기술을 사용하면 쿼리 품질이 크게 향상된답니다.
- Chain of Thought Prompting: 일반적으로 사용되는 Chain of Thought를 사용해서 생성된 쿼리의 품질을 향상시키는 일반적인 방법으로 문제에 접근하는 방법에 LLM을 집중시켜요.
Demo
AI 추론은 상당한 변화를 겪어왔고, 각 반복은 구조와 유연성 사이의 상충관계를 해결하기 위해 고심하고 있어요. 그래프 탐색에 대한 우리의 작업은 이러한 상충되는 요구 사항을 조정하기 위한 단계를 나타내죠. Semantic Search, Graph Database 및 LLM 기반 쿼리 생성을 통합함으로써 우리는 정밀성과 상황별 이해를 바탕으로 복잡한 데이터 세트를 탐색할 수 있는 시스템을 개발했어요.
우리의 대법원 사건 데모는 실제 애플리케이션에서 이러한 접근 방식의 잠재력을 보여주며, 메타데이터 기반 온톨로지가 복잡한 도메인에 대한 의미 있는 탐색을 어떻게 안내할 수 있는지 보여준답니다. 과제는 여전히 남아 있지만 이 방법은 AI 지원 지식 발견을 위한 새로운 길을 열어 잠재적으로 구조화된 시스템의 해석 가능성과 현대 언어 모델의 적응성 사이에 다리를 제공하는 것 같아요.
- GenAI
- RAG
에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.
'GraphRAG' 카테고리의 다른 글
| 그래프 데이터베이스를 거닐며 발견하는 의미: Neo4j와 GraphRAG의 세계 (0) | 2026.06.08 |
|---|---|
| NEuler에서 그래프 임베딩 알고리즘 결과 시각화하기 (0) | 2026.06.08 |
| Neo4j v2026.01 (미리보기): 필터와 함께 쓰는 벡터 검색 (1) | 2026.06.07 |
| 벡터 인덱스와 비정형 데이터 입문 - 새로운 GraphAcademy 강좌 (0) | 2026.06.07 |
| BAML을 활용한 비정형 데이터의 Neo4j 그래프 데이터 변환 (0) | 2026.06.07 |
