Data Eng Wiki

From Unstructured Chaos to Queryable Knowledge

12 min read

From Unstructured Chaos to Queryable Knowledge: Designing Ontology-Backed Knowledge Graphs for Agentic Applications

Author: Dhilip Kumar | Source: Medium | Published: 2026-07-15

한 줄 요약

도메인을 모를 때는 스키마 우선이 추측일 뿐이므로 discover-then-formalize로 온톨로지를 데이터에서 얻어내되, 이것은 프로젝트가 아니라 서로 다른 템포로 도는 두 개의 루프(build loop와 query loop)임을 인정해야 한다.

핵심 주장/내용

  • 벡터 스토어만으로는 부족한 지점: 시맨틱 검색은 유사한 텍스트를 찾는 데 훌륭하지만 “1980년 이전에 Cupertino에 본사를 둔 회사를 설립한 사람은 누구인가” 처럼 유사성이 아니라 구조를 요구하는 질문에는 훨씬 약하다
  • 지식 그래프는 그 뒤의 스키마만큼만 유용하다. 스키마 없는 노드와 엣지는 검증·추론·일관된 질의 방법이 없는 triple 더미일 뿐이다. 그 스키마가 온톨로지이고, 온톨로지와 그래프를 어떤 순서로 짓고 새 데이터가 올 때 둘을 어떻게 최신으로 유지하느냐가 계속 유용한 지식 베이스와 조용히 노이즈로 썩어가는 지식 베이스의 차이를 만든다
  • 왜 schema-first가 아닌가: 전통적 지식 공학은 온톨로지를 먼저 정의하고 데이터를 거기에 맞춰 추출하라고 한다. 이미 도메인을 이해할 때는 통하지만 모를 때는 무너진다 — 현실과 맞지 않는 스키마를 추측하거나, 추출 코드 한 줄 쓰기 전에 도메인 전문가와 몇 주간 워크숍을 하게 된다
  • discover-then-formalize (LLM 덕분에 점점 실용적이 됨):
    1. 벡터 검색으로 비정형 코퍼스를 먼저 탐색해 사람이 도메인 감각을 얻는다
    2. LLM이 schema-free 개방 추출로 후보 엔티티·관계를 표면화
    3. 후보에서 starter 온톨로지 유도(near-duplicate 라벨 클러스터링, 타입 정규화, 사람 승인)
    4. 그 seed 온톨로지에 대해 추출을 재실행해 제대로 타입된 그래프 구축
    5. 새 데이터가 올 때 온톨로지와 그래프 둘 다 계속 진화시키고 어느 쪽도 “완료”로 취급하지 않는다
    • 이것은 온톨로지 우선 설계의 거부가 아니라, LLM이 루프에 있으면 가정에서 저작하는 대신 실제 데이터에서 온톨로지를 벌어들일(earn) 수 있다는 인식이다
  • 온톨로지 vs 지식 그래프 — 두 개의 다른 레이어:
    • 온톨로지 (스키마 / TBox) — 클래스(존재할 수 있는 것들의 타입: Organization, Person, Location), 서브클래스 계층(Company는 Organization의 서브클래스), 관계 타입(headquartered_in, founded_by — domain과 range 제약 포함), datatype property(founded_year 같은 속성으로 다른 노드가 아닌 리터럴 값을 가리킴)
    • 지식 그래프 (인스턴스 데이터 / ABox) — 노드(Apple은 Company의 인스턴스), 엣지(Apple —headquartered_in→ Cupertino), 리터럴(독립적 identity가 없는 속성 값)
    • 리터럴이 추출 파이프라인에서 가장 흔한 실수다. 리터럴은 identity가 없고 다른 무엇도 그것을 가리키지 않는다. 반면 Tim Cook 같은 엔티티는 identity가 있다 — 나중에 다른 사실(다른 역할, 다른 조직)에 연결될 수 있으므로 평탄화된 속성이 아니라 노드가 되어야 한다
    • 한 문장 요약: 온톨로지는 Company와 Location 사이에 그런 관계가 존재할 수 있다고 말하고, 그래프는 Apple에 대해 구체적으로 그것이 존재한다고 단언한다
  • AI 네이티브 브릿지 — 탐색을 스키마로 바꾸는 명시적 단계: “탐색한 다음 온톨로지를 만들자”는 계획의 빈틈은 어떻게 벡터 탐색이 구조화된 타입이 되느냐다. 시맨틱 검색은 유사한 구절을 표면화할 뿐 “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 생산). 추출 후보가 사람 검토로 가고, 검토는 두 가지를 한다: 유효한 노드/엣지를 스토어에 승인, 그리고 결정적으로 진짜 새로운 것(새 클래스, 새 관계 타입)이 나타나면 온톨로지 자체를 갱신하도록 피드백. 갱신된 온톨로지가 다음 추출 패스를 안내한다. 파이프라인 단계가 아니라 루프다
    • 두 가지 추출 모드: 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 지점은 진짜로 다른 일을 한다: build-time 검토는 스키마와 데이터의 정확성에 대한 것이고 query-time 검토는 특정 답변의 disambiguation과 리스크에 대한 것이다. “HITL”이라고 말할 때 어느 쪽인지 명시하는 게 값지고, 이 둘을 뒤섞으면 양쪽에 다 어중간한 리뷰 UI가 나오는 경향이 있다
  • 결론: 벡터만으로는 유사성을 얻지 진실을 얻지 못하고, 온톨로지 없는 지식 그래프는 더 화려한 이름을 쓴 제약 없는 triple 더미일 뿐이다. 온톨로지가 원시 추출을 에이전트가 신뢰하고 검증하고 자신 있게 순회할 수 있는 것으로 바꾼다. 더 큰 전환은 이것이 결승선 있는 프로젝트가 아니라는 깨달음 — build loop와 query loop가 서로 다른 템포로 돌고, 어느 쪽이든 일회성 셋업 작업으로 취급하면 시스템이 조용히 현실과 어긋난다
  • 시작 조언: 작게 시작하라. 코퍼스의 좁은 슬라이스 하나를 골라 discover-then-formalize 시퀀스를 end-to-end로 돌리고 seed 온톨로지가 진짜로 거칠도록 두어라. 작고 정직한 온톨로지를 확장하는 것이 크고 틀린 것을 되돌리는 것보다 훨씬 쉽다

관련 위키

Source: 원문 보기

그래프 뷰

백링크