⌂ eff0rtchung.kr

Ontology Wiki / docs / rule-shacl-critic-belief

Rule, SHACL, LLM Critic, Belief Management

규칙 검증과 LLM critic 반복을 belief 관리로 연결하는 구조입니다.

ruleSHACLcriticbelief

Rule에서 시작하기

Rule은 agent가 매번 새로 고민하지 않아도 되는 판단을 고정합니다. 예를 들어 출처 없는 claim은 확정 사실로 승격하지 않는다, destructive action은 승인 없이는 실행하지 않는다, 최신성이 필요한 정책은 공식 문서를 확인한다 같은 규칙입니다.

Rule은 hard rule과 soft rule로 나눌 수 있습니다. Hard rule은 위반 시 중단이고, soft rule은 confidence를 낮추거나 추가 검증을 요구합니다. 이 구분이 없으면 agent가 모든 문제를 같은 강도로 다루게 됩니다.

SHACL의 역할

SHACL은 Agent가 가진 Assertion에 대해 빡빡한 검문을 진행하는 계층입니다. 주장이 들어오면 메모리에 세세하게 기록된 시간, 출처, 권한, 실패 사례를 보고 조건을 만족하는지 확인합니다. 조건을 만족하지 못하면 그 assertion은 accepted belief로 올라가지 못하고 밀려납니다.

예를 들어 Action node는 target, risk, precondition을 가져야 하고, PolicyDecision node는 source, checkedAt, decision을 가져야 한다고 정할 수 있습니다. LLM이 만든 구조화 출력은 그럴듯하지만 빠진 필드가 생기기 쉽습니다. SHACL validator는 빠진 필드, 타입 오류, cardinality 오류를 잡아줍니다.

다만 SHACL은 strict합니다. 현실 세계의 모든 것을 strict하게 바라보면 너무 보수적인 agent가 나옵니다. 깊은 고민이 필요하거나 단조적이지 않은 inference를 과하게 때려잡을 수도 있습니다. 그래서 SHACL은 모든 판단의 대체물이 아니라, 빡빡하게 봐야 할 assertion과 action에 제한적으로 쓰는 편이 좋습니다.

LLM Critic 반복과 Belief

LLM critic은 rule이나 SHACL이 잡지 못한 모호함을 검토합니다. 이 action이 사용자 의도와 맞는지, 근거가 충분한지, category error가 있는지 묻습니다. 다만 critic도 모델이므로 최종 권한자가 아니라 검토자 중 하나로 둡니다.

반복은 Rule check, SHACL validation, LLM critic, belief update 순서로 돌 수 있습니다. Belief는 candidate, accepted, contradicted, deprecated, unresolved 상태를 가집니다. 충돌이 있으면 accepted로 올리지 않고 unresolved로 남기는 것이 더 정직합니다.

Ontology의 Disjointness도 여기서 중요합니다. Disjointness는 두 개념이 동시에 성립할 수 없음을 말합니다. 예를 들어 어떤 action이 동시에 'public release'이면서 'private-only operation'이라고 주장한다면, critic과 belief manager가 이 충돌을 잡아야 합니다. 아주 강하게 제한하고 싶은 것은 LLM critic에 맡기지 않고 Rule로 강제할 수도 있습니다.

OWL, Rule, SHACL, LLM Critic 반복과 이를 통한 Belief 개선은 agent의 품질을 결정합니다. 모델의 말솜씨보다 이 반복 구조가 더 오래 남습니다.

Belief의 관리

Critic의 말도 assertion입니다. 그래서 evidence와 분리해야 합니다. critic이 그럴듯하게 지적해도 실제 rule 위반인지, 단순 스타일 의견인지 나눠야 합니다. Belief manager는 이 차이를 상태로 남깁니다.

법적 규제 준수는 hard rule에 가깝습니다. 개인정보, 저작권, 광고 정책, 약관 위반 가능성은 critic의 감상으로 완화하면 안 됩니다. 공식 정책과 인간 승인으로 escalation해야 합니다.

Taxonomy

  • rule taxonomyhard rule, soft rule, policy rule, heuristic rule, temporary rule을 구분합니다.
  • SHACL taxonomyshape, target, property constraint, cardinality, datatype, severity를 검증 단위로 둡니다.
  • critic taxonomyLLM critic, deterministic validator, human reviewer, regression test를 서로 다른 비평자로 둡니다.
  • belief status taxonomycandidate, accepted, contradicted, deprecated, unresolved 상태를 관리합니다.
  • loop taxonomyrule check, SHACL validation, critic pass, belief update, retry decision을 반복 단계로 둡니다.
  • disjointness taxonomy동시에 참일 수 없는 class와 role을 선언해 모순을 찾습니다.
  • severity taxonomyinfo, warning, violation, blocking violation을 나눠 멈출지 묻고 갈지 정합니다.
  • belief transition taxonomycandidate에서 accepted, contradicted, deprecated, unresolved로 넘어가는 조건을 둡니다.
  • strictness taxonomy엄격 검증, 완화 검증, LLM 재검토, human escalation을 도메인별로 고릅니다.
  • overfeeding taxonomy작은 신호를 finding으로 과승격하는 문제를 막기 위해 threshold를 둡니다.