온톨로지 구축 여정

AI 에이전트로 이메일을 분석하는 프로젝트를 시작했다. LangGraph 기반 RAG 파이프라인을 구축하고, 벡터 검색으로 관련 문서를 찾아 답변을 생성하는 구조.

벡터 검색만으로는 맥락이 누락됐다. 키워드가 비슷해도 의미가 다르고, 엔티티 간 관계 정보를 전혀 잡지 못했다. "삼성생명이 삼성전자의 최대주주"같은 관계는 임베딩으로 찾을 수 없었다.

엔티티 간 관계를 구조화해야 한다는 결론. Neo4j를 도입하고, 그래프 기반으로 데이터를 재구성하기로 했다.

Community Edition은 DB를 하나밖에 못 만든다. 개발/운영 환경 분리가 안 되는 치명적인 제약. Docker 볼륨 기반으로 우회했지만, 이것만으로 반나절을 날렸다.

그래프 ML을 돌리려면 GDS(Graph Data Science) 플러그인이 필요한데, Docker 환경에서 설치하는 과정이 문서대로 되지 않았다.

NodeSimilarity와 LinkPrediction을 돌렸더니, 사람이 수동으로 잡지 못한 노드 간 연결이 자동으로 드러났다. 그래프 구조 자체가 정보를 품고 있었다.

문서에서 LLM이 핵심 개념(엔티티)을 자동 추출하여 지식그래프에 적재하는 파이프라인을 만들었다. 수작업 대비 속도가 압도적이었다.

LLM이 새 개념을 발견할 때마다 스키마에 타입을 추가하니, 타입이 무한 증식했다. 비슷한 의미의 타입이 수십 개 생기고, 그래프 구조가 무너졌다.

같은 뜻인데 이름이 다른 개념들이 대량 발생. 'ML'과 '머신러닝', '기계학습'이 전부 별개 노드로 존재. 온톨로지가 뻑났다.

Levenshtein 거리로 표면적 유사도를 먼저 걸러내고, LLM으로 의미적 유사도를 2차 판별. 중복 후보를 자동 탐지하고 병합하는 프로세스를 만들었다.

LLM이 제안하고, 사람이 승격/거절하는 거버넌스 체계를 구축했다. 스키마에 아무나(LLM 포함) 직접 추가할 수 없게 관문을 만들었다.

데이터를 다시 넣어야 할 때 전체 삭제 후 재적재 vs 차분 업데이트. 뭘 지우고 뭘 남길지가 설계의 핵심이었다.

거버넌스를 운영하다 보니, 새로운 타입을 승격하는 건 쉬운데 잘못 승격한 걸 되돌리는 게 훨씬 위험했다. 의존성이 꼬이면 연쇄 삭제가 발생.

엔티티 의존성을 추적하여 롤백 시 영향 범위를 사전에 파악. 안전하게 되돌릴 수 있는 프로세스를 만들었다.

도메인을 엔티티에 붙일지, 관계에 붙일지, 별도 노드로 뺄지. 정답이 없는 설계 문제를 만났다.

도메인을 나눴을 뿐인데, 서로 다른 팀이 같은 엔티티를 참조하는 교차점이 자동으로 드러났다. 사일로였던 조직에 연결고리가 생겼다.

온톨로지를 얹은 GraphRAG가 단순 벡터 RAG보다 맥락을 훨씬 정확하게 잡았다. 같은 질문인데 답의 깊이가 다르다.

RAG 응답이 37초나 걸렸다. 원인을 추적하니 의도분석 단계에서 LLM이 과도하게 추론하고 있었다.

Gemini의 ThinkingBudget을 조절하여 불필요한 추론을 줄였다. 의도분석 속도가 극적으로 개선.

전체 여정을 돌아보며 정리. 스키마 거버넌스를 처음부터 갖추고, 도메인 설계를 먼저 하고, 재임포트를 전제로 설계했어야 했다.