트리플은 사실이 아니라 주장이다 Image: AI generated

위키데이터의 침묵


위키데이터에 이런 트리플이 있다.

(tomato, instance_of, vegetable) — rank: preferred
(tomato, instance_of, fruit)     — rank: normal

누가 preferred를 결정했는가. 왜 preferred인가. 어떤 맥락에서 preferred인가.

위키데이터는 이 질문에 침묵한다. 편집자가 결정하고, 시스템은 결정을 저장할 뿐이다.

그런데 토마토가 채소인지 과일인지는 물리 상수가 아니다. 요리사에게 물으면 채소다. 식물학자에게 물으면 과일이다. 미국 대법원에게 물으면 채소다 (1893년, Nix v. Hedden). 같은 질문에 세 개의 답이 있고, 세 개 모두 틀리지 않았다.

지식 그래프의 트리플은 사실이 아니다. 주장이다.


주장에는 논증이 필요하다

주장을 저장하려면 구조가 필요하다. Toulmin의 논증 모델이 그 구조를 제공한다.

요소역할토마토 예시
Claim주장“토마토는 채소다”
Ground직접 근거“요리 분류 체계에서 채소로 취급”
Backing출처/권위“Le Guide Culinaire (1903)”
Qualifier적용 범위“요리 맥락에서” (확신도 0.8)
Rebuttal반박 조건“식물학적 맥락에서는 과일 — 씨방 구조”
Warrant연결 논리“전통적 식재료 분류는 조리 용도 기준”

하나의 트리플에 하나의 truth value를 강제하는 대신, 트리플을 논증의 대상으로 올려놓는다. 주장이 있고, 근거가 있고, 반박 조건이 있고, 출처가 있다. 그리고 판정은 — 저장 시점이 아니라 질의 시점에 일어난다.

이 아이디어 자체는 새롭지 않다. 학계에서는 Dung의 추상 논증 프레임워크(1995), ASPIC+(2010), nanopublication 등이 지식 그래프 위의 논증을 다뤄왔다. 차이는 하나다 — 우리는 논문이 아니라 실행 가능한 코드로 제공한다. go install로 설치하고, 규칙을 Go 함수로 쓰고, 지금 당장 돌린다.


맥락이 진실을 결정한다

저장은 논증 구조. 판정은 런타임.

ctx.Set("domain", "cooking")
results, _ := g.Evaluate(ctx)
// verdict: +0.8 → 채소

ctx.Set("domain", "botany")
results, _ = g.Evaluate(ctx)
// verdict: -0.9 → 채소 아님 (과일)

같은 그래프, 같은 논증 구조, 같은 코드. 맥락만 바꿨다. 요리 맥락에서 질의하면 +0.8(채소), 식물학 맥락에서 질의하면 -0.9(과일). 판정이 맥락을 따라간다.

이것이 위키데이터의 정적 rank와 결정적으로 다른 점이다. 편집자가 preferred를 정하는 것이 아니라, 질의자의 맥락이 판정을 만든다.


명왕성은 행성인가

트리플: (Pluto, instance_of, planet)

주장:
  근거: "태양 궤도, 구형, 충분한 질량"
  출처: IAU 1930 분류 결의

반박:
  근거: "궤도 주변 천체 청소 미충족"
  출처: IAU 2006 Resolution 5A

반박의 예외:
  근거: "교육 과정에서 여전히 행성으로 교육"
  출처: NASA Education Resources 2024
ctx.Set("domain", "astronomy_formal")
// verdict: -0.8 (행성 아님)

ctx.Set("domain", "education")
// verdict: +0.3 (맥락에 따라 행성으로 취급 가능)

2006년 이전에 초등학교를 다닌 사람에게 명왕성은 행성이다. IAU에게 명왕성은 왜소행성이다. 둘 다 근거가 있고, 둘 다 출처가 있다. 시스템이 해야 할 일은 하나를 선택하는 것이 아니라, 둘 다 저장하고 맥락에 따라 판정하는 것이다.


출처가 공격당할 때

학술 논쟁에서는 출처 자체가 공격받는 일이 흔하다.

// 주장: 약물 X는 효과가 있다
claim := g.Rule(drugXEffective).
    With(&TripleSpec{
        Ground:  "임상시험 3상에서 유의미한 효과",
        Backing: "Smith et al. (2020), NEJM",
    })

// 반박: 독립 재현 실패
counter := g.Counter(replicationFailed).
    With(&TripleSpec{
        Ground:  "독립 재현 실험에서 효과 미확인",
        Backing: "Jones et al. (2022), Lancet",
    })
counter.Attacks(claim)

// 주장의 근거를 약화: 이해충돌
undercutter := g.Counter(conflictOfInterest).
    With(&TripleSpec{
        Ground:  "Smith의 연구비가 제약사에서 출처",
        Backing: "Retraction Watch (2023)",
    })
undercutter.Attacks(claim)

Smith의 논문은 NEJM에 실렸다. 권위 있는 출처다. 그러나 연구비 출처가 밝혀지면 그 논문에 기반한 주장 전체가 약해진다. counter는 주장을 정면으로 반박하고, undercutter는 주장의 근거 자체를 약화시킨다. 둘 다 주장을 공격하지만 방식이 다르다. h-Categoriser는 이 공격들의 강도를 종합하여 최종 verdict를 계산한다.

진실은 빛의 속도로 사라지고 주장만 남는다. 시스템은 주장을 관리하는 것이지, 진실을 선언하는 것이 아니다.


모든 트리플에 논증이 필요한가

아니다.

(water, chemical_formula, H2O)   — 확정. 논증 불필요.
(tomato, instance_of, ?)         — 논쟁적. 논증 부착.
(Pluto, instance_of, ?)          — 논쟁적. 논증 부착.
(Jerusalem, capital_of, ?)       — 논쟁적. 논증 부착.

기준은 단순하다: 같은 subject + predicate에 대해 복수의 object가 존재하거나, rank가 갈리거나, reference가 충돌하면 — 논쟁적 트리플이다. 나머지는 그냥 트리플로 둔다.

물의 화학식에 논증을 붙이는 것은 낭비다. 예루살렘의 수도 지위에 논증을 붙이지 않는 것은 거짓말이다.


판정 엔진: h-Categoriser

논증 그래프의 판정은 Amgoud의 h-Categoriser가 수행한다. 각 노드에 [-1, +1] 스케일의 수용도를 계산하고, 공격자의 수용도가 높을수록 피공격자의 수용도가 떨어진다. 재귀적으로 수렴할 때까지 반복.

성능: 10만 개 논쟁적 트리플이 각각 논증 그래프를 가져도, 질의 시 해당 트리플의 그래프만 evaluate하면 된다. 전체 지식 그래프 크기에 독립적이다.

트리플 검색:       밀리초 (기존 인덱스)
논증 evaluate:    밀리초 (h-Categoriser)
판정 근거 추적:   밀리초 (그래프 순회)

모델을 키우지 않고, 논증을 키운다.


위키데이터 rank와의 대응

위키데이터toulmin 확장
preferred rankverdict > +0.5 (현재 맥락에서)
normal rank0 < verdict ≤ +0.5
deprecated rankverdict ≤ 0
referenceBacking
qualifierQualifier + 맥락 함수 조건

차이: 위키데이터의 rank는 정적이다. 편집자가 결정한다. toulmin의 verdict는 동적이다. 맥락과 논증 구조가 결정한다.


더 큰 그림

이 시스템은 특정 도메인에 종속되지 않는다.

AI전두엽 (feature 선택):
  트리플 = (feature, should_include_in, app_type)
  맥락 = 현재 프로젝트의 앱 태그
  verdict = 이 feature를 포함해야 하는가

지식 그래프 일반:
  트리플 = (subject, predicate, object)
  맥락 = 질의자의 도메인/관점
  verdict = 이 트리플이 현재 맥락에서 참인가

같은 엔진. 같은 구조. 다른 도메인. 규칙은 Go 함수, 예외는 defeats 그래프, 판정은 h-Categoriser. DSL 없음.


왜 이것이 필요한가

LLM은 지식을 가중치에 녹인다. 질문하면 답이 나온다. 그러나 그 답이 어떤 맥락에서 참인지, 어떤 출처에 기반하는지, 반박이 존재하는지 — 구조적으로 추적할 수 없다. 할루시네이션은 이 구조의 부재에서 온다.

이 시스템이 모든 할루시네이션을 막지는 못한다. LLM은 개방형 출력을 생성하고, 모든 가능한 주장을 미리 등록할 수는 없다. 그러나 이미 논증 그래프에 등록된 주장에 대해서는, LLM이 생성한 답을 대조하여 신뢰도를 평가할 수 있다. “이 주장의 Backing은 무엇인가. 그 Backing을 공격하는 Counter가 있는가. 현재 맥락에서 verdict는 양수인가.”

범용 진실 판정기가 아니다. 축적된 논증 위에서 작동하는 신뢰도 평가 시스템이다.

사실을 저장하는 시스템이 아니라, 주장을 관리하는 시스템. 진실을 선언하는 것이 아니라, 판정을 추적하는 시스템. 이것이 지식 그래프의 다음 단계다.


관련 글

코드: github.com/park-jun-woo/toulmin

go install github.com/park-jun-woo/toulmin@latest

이 글의 코드 예시는 toulmin 라이브러리의 현재 API를 기반으로 한 설계 비전이다. 지식 그래프 확장(TripleSpec, 맥락 기반 평가)은 구현 진행 중이다. 핵심 판정 엔진(h-Categoriser, defeats graph, Rule/Counter)은 지금 동작한다.


출처

  • Toulmin, S. (1958). The Uses of Argument. Cambridge University Press.
  • Dung, P.M. (1995). “On the Acceptability of Arguments and its Fundamental Role in Nonmonotonic Reasoning, Logic Programming and n-Person Games.” Artificial Intelligence, 77(2), 321–357.
  • Amgoud, L. & Ben-Naim, J. (2013). “Ranking-based semantics for argumentation frameworks.” SUM 2013, LNCS 8078, 134–147.
  • Modgil, S. & Prakken, H. (2014). “The ASPIC+ framework for structured argumentation: a tutorial.” Argument & Computation, 5(1), 31–62.
  • Groth, P. et al. (2010). “Anatomy of a Nanopublication.” Information Services & Use, 30(1-2), 51–56.
  • Nix v. Hedden, 149 U.S. 304 (1893). United States Supreme Court.