추론 — 추론기의 동작 원리와 첫 실행

추론기가 하는 세 가지 일

추론기(reasoner)는 공리들로부터 논리적 귀결을 끌어내는 프로그램이다. 서비스는 세 가지로 요약된다. 첫째, 일관성 검사 — 공리 전체에 모순이 있는지 판정한다. 둘째, 분류(classification) — 적지 않은 is_a 관계를 도출해 계층을 완성한다. 셋째, 충족 가능성 검사 — 어떤 사례도 가질 수 없게 공리가 꼬인 클래스(충족 불가능 클래스)를 찾아낸다. 대표 추론기로 HermiT(범용 DL), ELK(EL 전용 고속)가 있으며, Protégé의 추론 버튼과 파이썬 라이브러리 Owlready2가 이들을 불러 쓴다.

아래 두 실험은 이 작업 환경에서 Owlready2와 HermiT로 실제 실행한 것이다. 출력은 그대로 옮겼다.

실험 1 — 숨은 계층을 도출하는 분류

미니 온톨로지를 만든다. 기억과 측정 과제 클래스, measures 관계(정의역 측정과제, 치역 기억), 그리고 정의된 클래스 하나 — "작업기억과제 ≡ 측정과제이면서 작업기억을 measures하는 것". 숫자폭과제는 측정과제이며 작업기억을 잰다고만 적고, 작업기억과제라고는 적지 않는다.

from owlready2 import *

onto = get_ontology("http://example.org/memdemo.owl")
with onto:
    class 기억(Thing): pass
    class 작업기억(기억): pass
    class 측정과제(Thing): pass
    class measures(ObjectProperty):
        domain = [측정과제]; range = [기억]
    # 정의된 클래스: 필요충분조건으로 정의
    class 작업기억과제(Thing):
        equivalent_to = [측정과제 & measures.some(작업기억)]
    # 숫자폭과제: '작업기억과제'라고는 적지 않았다
    class 숫자폭과제(측정과제):
        is_a = [측정과제, measures.some(작업기억)]
    AllDisjoint([기억, 측정과제])

sync_reasoner([onto])   # HermiT 실행

# 추론 전
숫자폭과제의 상위 클래스: [측정과제, measures.some(작업기억)]
# 추론 후 (HermiT)
숫자폭과제의 상위 클래스: [측정과제, measures.some(작업기억), 작업기억과제]

코드 1분류 추론의 실제 실행 결과. 아무도 "숫자폭과제는 작업기억과제다"라고 적지 않았지만, 정의된 클래스의 필요충분조건을 숫자폭과제가 충족하므로 추론기가 그 is_a를 도출했다.

이것이 정의된 클래스(2-5)의 힘이다. 조건을 한 번 정의해 두면, 조건을 충족하는 클래스들이 자동으로 모인다. 개념이 수백 개로 늘어나도 "작업기억을 재는 과제 모음" 같은 분류는 손으로 관리할 필요가 없다.

실험 2 — 오류를 모순으로 바꾸는 서로소

이제 2-5에서 말한 안전장치를 시험한다. 같은 온톨로지에 입력 실수를 일부러 넣는다 — 숫자폭과제를 기억의 하위 클래스로도 선언한다(과제와 개념을 뒤섞는, 실무에서 흔한 실수다). 기억과 측정과제는 서로소로 선언되어 있다.

with onto:
    숫자폭과제.is_a.append(기억)   # 실수 주입: 과제를 개념의 하위로
sync_reasoner([onto])

# 실행 결과
충족 불가능 클래스: [owl.Nothing, 숫자폭과제]

코드 2충족 가능성 검사의 실제 실행 결과. 숫자폭과제는 서로소인 두 클래스(기억, 측정과제)에 동시에 속해야 하므로, 어떤 사례도 가질 수 없는 클래스 — owl:Nothing과 동치 — 로 판정되었다.

용어를 구분해 둔다. 이 사례처럼 특정 클래스만 꼬인 상태가 충족 불가능(unsatisfiable)이다. 온톨로지는 아직 일관적이다 — 그 클래스에 사례가 없는 한 모순이 현실화되지 않기 때문이다. 만약 숫자폭과제의 인스턴스가 하나라도 있었다면 모순이 터져 온톨로지 전체가 비일관(inconsistent)으로 판정된다. 충족 불가능은 경보이고, 비일관은 사고다. 경보 단계에서 잡는 것이 검증(트랙 5의 7차시)의 목표다.

추론기의 한계

추론기는 적힌 공리의 논리적 귀결만 안다. 공리에 없는 지식을 지어내지 않고(환각이 없다), 공리 밖의 상식도 없다. "일화기억과 의미기억은 다르다"를 적지 않았으면 다른 줄 모른다(유일 이름 가정 없음, 2-5). 따라서 추론의 품질은 전적으로 공리의 품질이다 — 앞 차시들의 설계 규율이 여기서 회수된다. 비용의 한계도 있다. 표현력이 높은 공리를 쓸수록, 그리고 온톨로지가 클수록 추론은 느려진다(2-5의 거래). 3부에서 다룰 LLM과의 결합이 흥미로운 이유가 이 대비에 있다. LLM은 상식이 많지만 보장이 없고, 추론기는 아는 것이 적지만 아는 것은 보장한다.

판별 연습

적용: 실습의 검증 계획 구체화

판정 기준 3 — "추론기 일관성 검사와 역량 질문 테스트 통과" — 이 이 차시로 구체화된다. 실습의 검증은 세 단계로 돌린다. 첫째, 추론기 실행 후 충족 불가능 클래스 0개 확인(경보 단계 점검). 둘째, 도출된 분류를 눈으로 검토 — 추론기가 보탠 is_a가 의도와 맞는지. 셋째, 역량 질문의 SPARQL 테스트(완결성 점검은 질의 수준에서 — 2-5의 결론). 이 순서가 트랙 5의 7차시 절차가 된다.

용어 정리