Data Eng Wiki

Ontology-Backed Knowledge Graphs

12 min read

Ontology-Backed Knowledge Graphs

온톨로지 없는 지식 그래프는 더 화려한 이름을 쓴 제약 없는 triple 더미다

핵심 개념

에이전틱 애플리케이션을 만들면 결국 같은 벽에 부딪힌다. 에이전트가 PDF·위키·트랜스크립트·티켓·계약서 더미 위에서 추론해야 하는데 벡터 스토어만으로는 부족하다.

시맨틱 검색은 유사한 텍스트를 찾는 데 훌륭하다. 구조를 요구하는 질문에는 훨씬 약하다.

“1980년 이전에 Cupertino에 본사를 둔 회사를 설립한 사람은 누구인가”

지식 그래프가 그 자리를 채운다. 다만 지식 그래프는 그 뒤의 스키마만큼만 유용하다. 스키마 없는 노드와 엣지는 검증·추론·일관된 질의 방법이 없는 triple 더미일 뿐이고, 그 스키마가 온톨로지다.

두 레이어 — 흔한 혼동

노드와 엣지가 클래스와 관계와 같은 것인가? 아니다.

온톨로지 (스키마 / TBox)

  • 클래스 — 존재할 수 있는 것들의 타입 (Organization, Person, Location)
  • 서브클래스 계층 — Company는 Organization의 서브클래스
  • 관계 타입 — headquartered_in, founded_by. domain과 range 제약 포함
  • datatype property — founded_year 같은 속성. 다른 노드가 아니라 리터럴 값을 가리킨다

지식 그래프 (인스턴스 / ABox)

  • 노드 — 클래스의 인스턴스 (Apple은 Company의 인스턴스)
  • 엣지 — 관계 타입의 인스턴스 (Apple —headquartered_in→ Cupertino)
  • 리터럴 — 독립적 identity가 없는 속성 값 (1976)

리터럴이 가장 흔한 실수다

리터럴은 identity가 없고 다른 무엇도 그것을 가리키지 않는다. 반면 Tim Cook 같은 엔티티는 identity가 있다 — 나중에 다른 사실(다른 역할, 다른 조직)에 연결될 수 있으므로 평탄화된 속성이 아니라 노드가 되어야 한다.

추출 파이프라인에서 이 구분을 놓치면 나중에 되돌리기 어려운 구조적 손실이 생긴다.

온톨로지는 Company와 Location 사이에 그런 관계가 존재할 수 있다고 말하고, 그래프는 Apple에 대해 구체적으로 그것이 존재한다고 단언한다.

Discover-then-formalize — 도메인을 모를 때

전통적 지식 공학은 온톨로지를 먼저 정의하고 데이터를 거기에 맞춰 추출하라고 한다. 이미 도메인을 이해할 때는 통한다.

모를 때는 무너진다. 현실과 맞지 않는 스키마를 추측하거나, 추출 코드 한 줄 쓰기 전에 도메인 전문가와 몇 주간 워크숍을 하게 된다.

LLM 덕분에 점점 실용적이 된 대안:

1. 벡터 검색으로 비정형 코퍼스 탐색 → 사람이 도메인 감각 획득
2. LLM의 schema-free 개방 추출 → 후보 엔티티·관계 표면화
3. 후보에서 starter 온톨로지 유도 (near-duplicate 클러스터링, 타입 정규화, 사람 승인)
4. seed 온톨로지에 대해 추출 재실행 → 제대로 타입된 그래프
5. 새 데이터가 올 때 온톨로지와 그래프 둘 다 계속 진화

이것은 온톨로지 우선 설계의 거부가 아니다. LLM이 루프에 있으면 가정에서 저작하는 대신 실제 데이터에서 온톨로지를 벌어들일(earn) 수 있다는 인식이다.

탐색을 스키마로 바꾸는 명시적 단계

“탐색한 다음 온톨로지를 만들자”는 계획의 빈틈은 어떻게 벡터 탐색이 구조화된 타입이 되느냐다. 시맨틱 검색은 유사한 구절을 표면화할 뿐 “Contract 클래스와 governed_by 관계가 필요하다”를 자동으로 알려주지 않는다.

  1. 비정형 소스 ingest·청킹
  2. 벡터 스토어 임베딩 — 탐색 기반
  3. 사람 탐색 — SME가 의미론적으로 질의·브라우징해 무엇이 중요한지 감을 잡는다
  4. schema-free 개방 추출 — 고정 스키마 없이 후보를 추출하되, 낯선 것은 버리거나 억지로 맞추지 않고 태깅
  5. 온톨로지 유도 — 임베딩 유사도 + LLM 보조 병합으로 클러스터·정규화. “Apple Inc”, “Apple”, “AAPL”이 하나로 붕괴하고 near-duplicate 관계 라벨이 하나의 술어로. 사람이 검토·승인해 seed 온톨로지 확정
  6. seed 온톨로지에 대해 재추출

Loop 1 — Build loop

도메인 모델이 성숙하며 느려질 뿐 진짜 끝나지 않는다.

비정형 데이터
  ├─ 벡터 스토어 경로 ──── 청킹 · 임베딩
  └─ 추출 경로 ──── 현재 온톨로지로 제약/안내되는 LLM 추출 → 후보 triple
                          ↓
                    conformance check
                          ↓
                     사람 검토
                    ├─ 유효한 노드/엣지 승인 → 스토어
                    └─ 진짜 새로운 것 → 온톨로지 자체 갱신 ┐
                                                            │
                    다음 추출 패스를 안내 ←─────────────────┘

파이프라인 단계가 아니라 루프다.

두 가지 추출 모드

  • closed / constrained — LLM이 이미 온톨로지에 있는 클래스·관계의 인스턴스만 추출. 온톨로지가 꽤 안정적일 때
  • 온톨로지를 가이드로 쓰는 open — 텍스트가 정의된 것에 맞지 않으면 LLM이 새 후보 타입을 제안하고 버리거나 억지로 맞추는 대신 별도로 태깅. 초기나 주기적 재감사 때

Conformance check — 값싼 규율

매 추출 패스 후 모든 triple의 subject/object 타입이 그 관계의 선언된 domain·range와 실제로 맞는지 확인하라.

LLM은 온톨로지 경계 근처에서 가끔 관계 타입을 환각한다. 그것을 사람 검토에 도달하기 전에 자동으로 잡으면 리뷰어 시간을 많이 절약한다.

Loop 2 — Query loop

모든 요청마다 실행된다.

  1. 쿼리 도착
  2. 온톨로지가 해석하고 계획한다 — 답을 가진 게 아니라 지도를 가지고 있다
    • “누가 Apple을 설립했나?” → 온톨로지가 플래너에게 founded_by가 존재하고 domain이 Company, range가 Person이니 “Apple”과 일치하는 Company 노드를 찾아 그 엣지를 순회하라고 알려준다
    • 여기가 disambiguation이 일어나는 곳이기도 하다. “Apple”이 회사일 수도 다른 것일 수도 있다면 온톨로지의 타입 시스템이 에이전트가 추측하는 대신 날카로운 명확화 질문을 하게 해준다
  3. 두 검색 경로로 분기 — 그래프 순회(정밀하고 구조화된 multi-hop 사실)와 벡터 검색(모호하고 서술적인 자유 텍스트 맥락)
  4. 둘에서 답을 조합
  5. 사람 검토 — 모호하거나 고위험 쿼리에 대해서만 조건부

두 HITL은 다른 일을 한다

“HITL”이라고 말할 때 어느 쪽인지 명시하는 게 값지다.

build-time 검토query-time 검토
대상스키마와 데이터의 정확성특정 답변의 disambiguation과 리스크
빈도추출 패스마다 (점점 드물게)모호·고위험 쿼리만
리뷰어도메인 전문가요청 맥락을 아는 사람

이 둘을 뒤섞으면 양쪽에 다 어중간한 리뷰 UI가 나오는 경향이 있다.

시작 조언

작게 시작하라. 코퍼스의 좁은 슬라이스 하나를 골라 discover-then-formalize 시퀀스를 end-to-end로 돌리고, seed 온톨로지가 진짜로 거칠도록 두어라.

작고 정직한 온톨로지를 확장하는 것이 크고 틀린 것을 되돌리는 것보다 훨씬 쉽다.

프로덕션에 가져갈 때 남는 문제

  • 온톨로지 버저닝과 마이그레이션 — 이미 추출된 데이터를 깨지 않고 클래스·관계 정의를 진화시키는 법
  • 충돌 해소 — 두 문서가 같은 엔티티에 대해 모순되는 사실을 단언할 때
  • 평가 지표 — 추출 품질과 온톨로지 커버리지를 눈대중이 아니라 실제로 측정하는 법
  • 접근 통제와 멀티테넌시 — 소비자마다 그래프의 다른 슬라이스를 봐야 한다면
  • 비용·레이턴시 트레이드오프 — 규모에서 LLM 추출·재추출은 공짜가 아니다. 언제 배치하고 언제 스트리밍할지

연관 개념

Source: From Unstructured Chaos to Queryable Knowledge, Closing the Context Gap - Ontology plus LLM for Data Modernization

그래프 뷰

백링크