어느 제약회사 품질(Quality) 팀이 6개월 치의 표준작업지침서(SOP), 일탈(Deviation), 시정 및 예방조치(CAPA) 문서를 LLM 기반 추출 파이프라인에 입력했습니다. 일주일 뒤, 수천 개의 노드와 깔끔한 엣지로 구성된 아름다운 지식 그래프가 완성되었습니다. 그런데 감사관(Auditor)이 특정 CAPA 엣지에 대해 단순한 질문 하나를 던집니다. “이 관계는 왜 여기에 있습니까? 어떤 문서에 나와 있는 내용인가요?”
아무도 대답하지 못합니다. 엣지에는 출처(Source)가 없습니다. 이를 생성한 파이프라인 역시 어디서 유래했는지에 대한 기록을 갖고 있지 않습니다. 답할 수 없는 이 단 하나의 질문으로 인해 전체 지식 그래프는 자산에서 부채로 전락합니다. GxP 환경에서 추적할 수 없는 지식은 결코 방어(Defend)할 수 없는 지식이기 때문입니다.
이것이 바로 모든 “텍스트 → 지식 그래프(Text → Knowledge Graph)” 프로젝트 이면에 숨겨진 진짜 문제입니다. 핵심은 추출(Extraction)이 아니라 신뢰(Trust)입니다. 그리고 신뢰는 프롬프트 엔지니어링의 문제가 아닌, 아키텍처의 속성입니다.
순진한 추출(Naive Extraction) 방식이 실패하는 이유
“이 텍스트에서 모든 개체(Entity)와 관계(Relationship)를 JSON으로 추출하라”는 식의 순진한 접근법은 모든 모델과 모든 도메인에 걸쳐 예측 가능하고 구조적으로 동일한 방식으로 실패합니다. 이러한 실패 사례들을 감사해보면, 완전히 무(無)에서 유를 창조하는 노골적인 날조는 의외로 드뭅니다. 지식 그래프를 오염시키는 것은 훨씬 더 미묘한 요인들입니다:
- 스키마 표류(Schema drift). LLM이 정의된 온톨로지(Ontology)에서 선택하는 대신 임의의 술어(Predicate)를 만들어냅니다 (
is_partner_with대collaborates_with). 이렇게 임의로 생성된 술어는 그래프를 파편화하고 순회(Traversal) 로직을 무너뜨립니다. - 동일시/혼동(Conflation). 관계 자체는 사실이지만 잘못된 개체에 연결됩니다. 마이크로소프트에 관한 텍스트 청크에서 추출된 “사티아 나델라(Satya Nadella) — CEO of — 마이크로소프트”가 ‘마이크로소프트 아일랜드(Microsoft Ireland)’ 노드에 연결되는 식입니다. 이는 환각의 가면을 쓴 개체명 해소(Entity Resolution) 실패이며, 실무에서 잘못된 엣지가 발생하는 제1의 원인입니다.
- 양태 오독(Modality misreads). 부정문(“X는 Y를 유발하지 않음”), 가정법(“일탈이 중대한 경우 조사가 필요함”), 간접화법(“분석가들은 …라고 믿는다”) 등이 모두 단정적인 사실(Asserted facts)로 평탄화되어 버립니다. 모델은 텍스트 스팬(Span)에 충실했을지 몰라도, 해당 스팬은 애초에 엣지로 생성되어서는 안 되는 내용이었습니다.
- 시점적 진부화(Temporal staleness). SOP v4에서 추출된 “QA가 일탈을 승인한다”는 내용이 영구적인 사실로 굳어져, SOP v5와 조용히 모순을 일으킵니다.
- 이행적 과잉 추론(Transitive over-inference). 어떤 문서에도 명시되지 않았음에도, 모델이 A→B와 B→C로부터 A→C를 임의로 추론해 냅니다.
복리 효과(Compounding problem)는 상황을 더욱 악화시킵니다. 그래프 구축은 파이프라인으로 이루어집니다. 3-홉(Three-hop) 경로에서 단계별 정밀도(Precision)가 95%라면 경로 전체의 충실도(Fidelity)는 약 86%로 떨어집니다. 또한 오류 분포는 지독할 정도로 롱테일(Long-tailed) 형태를 띱니다. 트리플(Triple)의 90%는 단순하며 어떤 모델이든 쉽게 맞힙니다. 하지만 나머지 10%(암시적 관계, 청크 간 상호참조, 희귀 개체)에 오류의 80%와 엔지니어링 시간의 95%가 집중되어 있습니다.
단 몇 퍼센트의 환각 엣지로 오염된 지식 그래프는 GraphRAG 검색, 영향 분석(Impact analysis), 컴플라이언스 보고서 등 모든 다운스트림 소비 프로세스의 품질을 조용히 저하시킵니다. 정밀도가 곧 제품입니다.
절대 원칙: LLM이 제안하고, 결정론적 인프라가 처분한다
실제 프로덕션 환경에서 제대로 작동하는 모든 아키텍처는 예외 없이 동일한 책임의 역전(Inversion of responsibility)으로 귀결됩니다:
LLM이 그래프 엣지를 직접 작성하도록 내버려 두지 마십시오. LLM은 증거 기반의 클레임(Claim)을 생성하도록 하고, 어떤 클레임이 엣지로 승격될 수 있는지는 결정론적(Deterministic) 시스템이 결정하도록 해야 합니다.
LLM은 가설 생성기(Hypothesis generator)입니다. 강력하고 유창하지만, 진실을 가리는 최종 판정관으로서는 신뢰할 수 없습니다. 그래프의 무결성은 LLM을 둘러싼 결정론적이고 검증 가능한 계층에서 나와야 합니다. 그리고 전체 아키텍처에서 가장 효과적인 단 하나의 메커니즘은 지극히 단순합니다:
스팬(Span)이 없으면 엣지도 없습니다 (No span, no edge). 추출된 모든 트리플은 원본 텍스트에서 파생된 정확한 문자 오프셋(Character-offset) 스팬을 반드시 포함해야 합니다. 자유 텍스트 형태의 변명이 아니라, 검증 가능한 포인터여야 합니다. 모델이 정확한 텍스트 스팬을 인용할 수 없다면, 그 엣지는 존재하지 않는 것입니다. 이를 통해 작화증(Confabulation, 환각)은 소리 없는 침묵의 실패에서 기계적인 실패로 전환됩니다. 그럴듯한 관계를 지어내는 것보다 구체적인 문자 오프셋을 조작해 내는 것이 훨씬 더 어렵기 때문입니다.
파이프라인 아키텍처
프로덕션 수준의 추출 파이프라인은 LLM을 독립된 만능 해결사가 아니라, 저렴한 결정론적 필터에서 점진적으로 고비용의 검증 계층으로 이어지는 단계별 퍼널(Staged funnel)의 한 구성 요소로 다룹니다:
원시 문서 (SOP, 일탈, CAPA, URS/FRS, 테스트 스크립트)
│
▼
[1] 구조 인식 수집(Structure-aware Ingestion) ── 시맨틱 청크, 스팬 오프셋,
│ 문서 ID + 버전 유지
▼
[2] 온톨로지 레지스트리(Ontology Registry) ── 닫힌 개체/술어 집합, 도메인/범위,
│ 카디널리티, 위험 계층 (버전 관리된 아티팩트)
▼
[3] 2단계 제약 추출(Two-Pass Constrained Extraction)
├─ Pass A: 개체 + 타입 지정 (엄격한 스키마, 구조화된 출력)
└─ Pass B: 검증된 쌍에 대한 관계만 추출 (허용된 술어 집합)
│
▼
[4] 접지 게이트(Grounding Gate)
├─ 스팬 검증 (원문 그대로의 부분문자열 일치)
└─ NLI 함의 검증 (전제 = 청크, 가설 = 트리플)
│
▼
[5] 개체명 해소(Entity Resolution) ── 블로킹 → 임베딩 → LLM 판정
│ → 정규 ID (멘션→개체 매핑)
▼
[6] 어셈블리(Assembly) ── 모순 탐색, 시점 범위 지정, 카디널리티 검사
│
▼
[7] 위험 기반 인간 검토(Risk-Based Human Review) ── 자동 승격 / 샘플링 / 심의
│
▼
[8] 클레임 원장(Claim Ledger) ── 이중 시간(Bitemporal), 출처 도장이 찍힌 커밋
│
▼
프로덕션 그래프 (Neo4j / RDF + SHACL)
│
▼
에이전트 · GraphRAG · 감사관 (모든 엣지에 대한 설명 가능성 확보)
1. 수집(Ingestion): 문서의 구조를 파괴하지 말 것
단 하나의 토큰을 처리하기 전에, 문서의 구조를 파괴하지 않고 파싱해야 합니다. 고정된 토큰 수가 아니라 섹션, 표, 마크다운 헤더 등 의미론적 경계(Semantic boundaries)를 따라 청킹(Chunking)을 수행합니다. 모든 청크는 doc_id, doc_version, section_path, 페이지 번호, 그리고 안정적인 문자 오프셋(Character offset)을 포함해야 합니다. 상호참조 해결(Coreference resolution) 사전 패스(FastCoref 등)를 적용하여 대명사를 명시적인 명사 멘션으로 치환함으로써 각 청크가 자체 완결성(Self-contained)을 갖도록 합니다.
이는 생각보다 훨씬 중요합니다. SOP의 규제 권위(Regulatory authority)는 해당 문서의 버전과 효력 발생일(Effective date)에서 나옵니다. “SOP-00123 v7, 2026-06-01 발효”라는 정보를 버린 지식 그래프는 규제 환경에서 가장 중요한 유일한 질문, 즉 *“특정 일자에 유효했던 규정은 무엇이었는가?”*에 답할 수 있는 능력을 상실한 것입니다.
2. 온톨로지가 진정한 제품이다
고객들은 자신이 정보 추출 기술을 구매한다고 생각하지만, 실제로는 스키마 결정(Schema decision)을 구매하는 것입니다. 온톨로지가 조금만 어긋나도 99% 정밀도의 추출기는 무용지물이 됩니다.
- 온톨로지를 코드로 정의하십시오 (Ontology as code). 개체 타입, 닫힌 술어 집합(Closed predicate set), 그리고 모든 관계에 대한 도메인/범위(Domain/Range) 제약조건(
WORKS_FOR: 도메인 Person, 범위 Organization)을 명시합니다. Git으로 버전을 관리하고 코드처럼 코드 리뷰를 진행하십시오. - 제약 디코딩(Constrained decoding)(Outlines, XGrammar, vLLM/SGLang structured output, Instructor/Pydantic)을 사용하여, 모델이 온톨로지에 존재하지 않는 술어를 방출하는 것이 물리적으로 불가능하도록 만듭니다. 스키마 표류는 단순히 ’지양’되는 것이 아니라 ’불가능’해집니다.
- 정규화 결정을 스키마에 인코딩하십시오. “works_at”과 “employed_by” 중 무엇을 사용할지는 여기서 단 한 번 결정되며, 청크마다 매번 판정할 필요가 없습니다.
- 모든 술어에 위험 계층(Risk tier)을 부여하십시오.
low(자동 수용 가능),medium(검증 필요),high(절대 LLM이 추론할 수 없으며 규칙이나 인간만이 부여 가능, 예:is_regulated_by). - 암묵적 스키마 확장을 그 자체로 환각의 한 벡터로 취급하십시오. 파이프라인이 새롭게 제안하고자 하는 술어가 있다면 온톨로지에 즉시 반영되지 않고 거버넌스 큐(Governance queue)로 라우팅되어야 합니다.
# 온톨로지를 코드로 정의 — LLM은 검증을 통과한 내용만 출력할 수 있음
class WorksFor(BaseModel):
source_type: Literal["Person"]
target_type: Literal["Company"]
relation: Literal["WORKS_FOR"]
evidence_span: str # 원본 소스의 글자 그대로 일치하는 부분문자열이어야 함
confidence: float
3. 2단계 추출: 개체 추출 후 관계 추출
단 한 번의 생성 단계에서 개체와 관계를 동시에 추출하지 마십시오. 인지적 부하(Cognitive load)가 바로 혼란을 초래하는 원인입니다.
- Pass A — 개체 멘션 및 타입 지정 (Entity mention and typing). 온톨로지와 일치하는 타입의 개체를 표면형(Surface form) 및 문자 오프셋과 함께 추출합니다. 높은 정밀도가 요구되는 타입은 결정론적 NER(spaCy, GLiNER)이 병렬로 처리하고, 모호한 멘션과 상호참조는 LLM이 처리합니다.
- Pass B — 검증된 개체 쌍에 대한 관계 추출 (Relation extraction over verified entity pairs). Pass A에서 확보된 개체들이 주어졌을 때, 모델은 온톨로지의 술어 매트릭스(Predicate matrix)에 정의된 관계만을 예측합니다. 만약 온톨로지에서 PERSON과 REGULATION 사이에 정의된 관계가 없다면, 모델은 해당 엣지를 평가하거나 출력할 수 없습니다.
이러한 순서는 가장 흔한 실패 유형인 ’관계를 추출하면서 연결할 개체까지 함께 지어내는 현상’을 원천 차단합니다.
4. 접지 게이트(Grounding Gate): 환각 방지 방화벽
살아남은 모든 후보 트리플은 지식 그래프 근처에 도달하기 전 반드시 세 가지 계층을 통과해야 합니다:
- 구문론적 접지(Syntactic grounding).
evidence_span은 명시된 오프셋 위치에서 원본 텍스트와 대소문자까지 글자 그대로 일치(Verbatim substring match)해야 합니다. 어설픈 의역(Paraphrasing)은 허용되지 않습니다. 유효성 검사기(Validator)가 해당 오프셋이 실제로 일치하는지 확인하며, 일치하지 않으면 즉시 폐기(Drop)합니다. 이 단 하나의 규칙만으로도 대부분의 날조를 제거할 수 있습니다. - 의미론적 함의(Semantic entailment). 원본 청크를 전제(Premise)로, 언어화된 트리플(Verbalized triple)을 가설(Hypothesis)로 설정하여 경량 NLI 모델(DeBERTa-v3-large, 자체 호스팅 가능하며 LLM 판정관보다 자릿수 단위로 저렴함)을 실행합니다. 임계값(0.85~0.90) 이상의 함의(Entailment) 점수를 반환하지 못하는 모든 항목을 기각합니다. 이는 스팬 매칭이 놓치는 의역 왜곡(Paraphrase drift)을 잡아냅니다. 여기에는 부정과 양태도 포함됩니다. 예를 들어 “QA가 MasterControl 도입을 검토 중이다”라는 문장은 “QA가 MasterControl을 사용한다”를 함의하지 않습니다. NLI 모델은 경계가 명확한 분류기(Bounded classifier)이므로, 생성형 검증기처럼 자체적인 환각을 일으키지 않습니다.
- 온톨로지 검증(Ontological validation). 도메인/범위 검사, 카디널리티(한 개인은 현재 하나의 고용주만 가짐), 비즈니스 규칙(계약 체결일이 계약 해지일보다 늦을 수 없음) 등을 검증합니다. 이는 Neo4j 제약조건(Constraints)이나 SHACL 셰이프(Shapes)를 통해 강제됩니다.
오직 이 세 가지 계층을 모두 통과한 트리플만이 그래프에 기록됩니다. 임계값에 미치지 못하는 항목은 클레임(Claim) 상태로 보존될 뿐, 결코 엣지로 승격되지 않습니다.
5. 개체명 해소(Entity Resolution): 순진한 파이프라인이 좌초하는 지점
개체명 해소에는 **전역적 일관성(Global consistency)**이 필요하지만, LLM은 말뭉치 전체가 아닌 제한된 컨텍스트 윈도우(Window)만을 처리합니다. 따라서 아키텍처가 이를 보완해야 합니다:
- 블로킹(Blocking) — 저비용 후보 생성(정규화된 키, 임베딩 ANN). 모든 개체를 쌍으로 전수 비교(Pairwise comparison)해서는 안 됩니다.
- 임베딩 유사도(Embedding similarity) — 명확한 케이스 처리 (
e5-mistral-7b,text-embedding-3-large). - LLM 판정(LLM adjudication) — 모호한 중간 구간에 대해 증거 스팬을 제공하여 판정. 이때 개체 타입의 경계를 넘어서는 병합(Merge)은 절대 허용하지 않습니다.
- 인간 검토 구간(Human review band) — 불확실한 병합 건을 선별. 프로젝트 전체의 경제성은 주로 “문서 1,000건당 인간 검토 시간 최소화”에 달려 있습니다.
- 원래 위치에서 직접 병합하지 말 것 (Never merge in place). 정규 ID(
ent_person_123) 및 별칭 테이블(Alias table)을 갖춘멘션 → 개체(mention → entity)매핑 레이어를 유지하십시오. 이렇게 하면 잘못된 병합이 발생해도 전체 데이터를 다시 추출할 필요 없이 단 한 줄의 병합 취소(Unmerge) 작업으로 해결할 수 있습니다.
6. 어셈블리(Assembly): 시간, 모순, 그리고 단언 모델(Assertion Model)
RDF의 단순한 주어-술어-목적어(Subject-Predicate-Object) 구조는 규제 대상 지식을 담기에 충분히 풍부하지 못합니다. 추출된 모든 진술에는 단언 모델(Assertion Model)이 필요합니다:
단언 (Assertion)
├── 주어 / 술어 / 목적어 (subject / predicate / object)
├── 극성 (polarity: 긍정 / 부정)
├── 양태 (modality: 단언 / 필수 / 허용 / 금지 / 가정)
├── 시점 범위 (temporal_scope: valid_from, valid_to — 문서 메타데이터에서 전파)
├── 조건부 범위 (conditional_scope)
├── 증거 (evidence: span, doc_id, doc_version, page, section)
└── 출처 (provenance: extractor, prompt version, timestamp)
이 구조가 바로 지식 그래프로 하여금 시간에 따른 변화를 표현할 수 있게 만듭니다. SOP v4에는 “QA가 일탈을 승인한다”고 되어 있고, SOP v5에는 “품질 부서(Quality Unit)가 일탈을 승인한다”고 되어 있을 수 있습니다. 시계열 그래프(Temporal graph)는 이를 소리 없는 모순으로 덮어쓰는 대신 유효 기간이 지정된 버전별 단언으로 두 내용을 모두 보존합니다. 이를 통해 일반적인 GraphRAG는 답할 수 없는 질문, 즉 단순히 “무엇이 사실인가?“를 넘어 “2025년 6월 15일 당시 권위를 가졌던 규정은 무엇인가?“에 답할 수 있게 됩니다.
모순 탐색(Contradiction mining)은 전용 패스로 수행됩니다. 충돌하는 엣지가 발견되면 시간적 선후 관계나 소스 가중치에 따라 해결하거나 인간 검토로 라우팅합니다. 모순은 *덮어써서 조용히 무마하는 것이 아니라 유지(Held)*되어야 합니다. 기존 내용을 덮어쓰지 않고 타임스탬프와 함께 두 진술을 모두 저장합니다.
7. 인간 검토: 위험 기반 계층화, 결코 전수 검사가 아니다
그 누구도 500만 개의 엣지를 일일이 수작업으로 검토할 수는 없으며, 그런 방식을 요구하는 시스템은 경제적으로 성립할 수 없습니다. 위험도에 따라 라우팅해야 합니다:
저위험 (LOW RISK) → 자동 승격
중위험 (MEDIUM RISK) → 샘플링 검사 / 2차 검증
고위험 (HIGH RISK) → 인간 전문가 심의
모든 클레임은 CANDIDATE(후보)로 시작하여 GROUNDED(접지 완료) → ONTOLOGY_VALID(온톨로지 유효) → ENTITY_RESOLVED(개체 해소 완료) → CONTRADICTION_CHECKED(모순 검사 완료) → RISK_SCORED(위험 점수 부여) → APPROVED(승인) → GRAPH(그래프 반영) 단계를 거칩니다. 프로덕션 그래프에 담기는 것은 LLM이 마음대로 생성한 결과물이 아니라, **승인된 지식(Approved knowledge)**입니다.
능동 학습(Active learning)은 성과를 복리로 증폭시킵니다. 인간 전문가는 무작위 엣지가 아니라, 불확실성이 높으면서도 정보 가치가 가장 큰 엣지를 심의합니다. 전문가들의 판정 결과는 골드 데이터셋(Gold dataset)이 되며, 이 골드 데이터셋은 추출기를 재학습시키고 검증기를 캘리브레이션하는 데 활용됩니다. 목표는 루프가 반복됨에 따라 수 주에 걸쳐 인간 검토 비율을 전체 물량의 약 40%에서 5% 미만으로 낮추는 것입니다.
8. 클레임 원장과 데이터 출처(Provenance): 진정한 최종 결과물
그래프 내의 모든 엣지는 자신의 전체 이력(Full biography)을 저장합니다: (subject, predicate, object, evidence_span, doc_id, doc_version, extractor_version, confidence, valid_from, valid_to). 이를 **클레임 원장(Claim ledger)**으로 생각할 수 있습니다. 모든 엣지는 출처 불명의 익명 단언이 아니라, 서명된 분개 항목(Signed entry)입니다.
여기서 가장 결정적인 킬러 기능이 자연스럽게 도출됩니다. 모든 엣지는 **“이 엣지는 왜 여기에 존재하는가?”**라는 질문에 답할 수 있습니다. 즉 문서, 버전, 섹션, 페이지 번호, 원문 그대로의 증거 텍스트, 추출 모델, 검증기 결과, 인간 승인 상태를 즉각 반환합니다. 나아가 이 시스템은 누락된(Missing) 엣지에 대해서도 설명할 수 있습니다: “SOP-123 v7의 8.2절에 조건부 관계가 명시되어 있으므로, 무조건적인 Deviation → CAPA 관계는 생성되지 않았습니다.”
또한 데이터 출처(Provenance)가 확보되면 엣지를 **철회(Retractable)**할 수 있습니다. 원본 문서가 업데이트될 때, 해당 문서에서 비롯된 엣지만을 정밀하게 외과 수술하듯 철회하고 다시 도출해 낼 수 있습니다. 이는 지속적으로 데이터를 수집하는 장기 운영 프로덕션 그래프에서 필수적인 요건입니다.
평가 체계: 당신이 실제로 판매하는 것
측정할 수 없는 지식 그래프는 보증할 수도 없습니다. 평가 하네스(Evaluation harness)는 10주 차가 아니라 2주 차에 구축되어야 합니다:
- 인간이 어노테이션한 500~1,000개의 트리플로 구성된 골드 세트(Gold set). 트리플 단위의 정밀도/재현율(Precision/Recall)이야말로 가장 정직한 핵심 지표입니다. 특히 이는 전체 평균이 아니라 **술어 유형별(Per predicate type)**로 추적되어야 합니다. 어떤 술어는 다른 술어보다 훨씬 더 환각을 일으키기 쉽기 때문입니다.
- 적대적 테스트 세트(Adversarial test set). 부정문, 가정문, 간접화법 등 순진한 추출기를 무너뜨리는 까다로운 케이스들을 포함합니다.
- 재현율과 분리하여 독립 지표로 추적하는 환각률(Hallucination rate). F1 점수는 훌륭해 보이지만 치명적인 결과를 초래하는 소수의 거짓 엣지를 지속적으로 생성하는 파이프라인이 존재할 수 있습니다.
- ~100%에 근접해야 하는 대리 지표(Proxy metrics): 스팬 검증 가능 비율(Span-verifiability rate), 스키마 위반율(0%에 수렴), NLI 통과율.
- 오류 분류 체계(Error taxonomy). 동일시(Conflation) / 양태(Modality) / 시점(Temporal) / 스키마(Schema) / 파편화(Fragmentation) 등으로 분류하며, 각 오류 클래스는 상류(Upstream)의 구체적인 해결책과 직접 매핑됩니다. 이를 통해 디버깅은 단순한 ’감(Vibes)’이 아니라 체계적인 체크리스트로 전환됩니다.
잘 구축된 파이프라인은 접지된 트리플에서 95% 이상의 정밀도를 달성하고 환각률을 5% 미만으로 유지하며, 제약 조건이 명확한 도메인에서는 1% 미만까지 떨어뜨립니다. 물론 “완벽한 환각 엣지 0%“는 점근선일 뿐 실제로 도달할 수는 없습니다. 여러분이 판매하는 것은 알려져 있고, 계층화되어 있으며, 측정이 가능한 정밀도입니다. 즉 오류율의 특성이 명확히 파악되고, 통제 범위 내에 있으며, 지속적으로 개선되는 지식 그래프입니다.
파인튜닝: 상류가 아닌 하류에서 수행할 것
처음 마주하는 본능은 언제나 “추출을 더 잘하도록 모델을 파인튜닝(Fine-tuning)하자”는 것입니다. 하지만 이는 대개 틀렸거나, 적어도 시기상조입니다. 끊임없이 변화하는 스키마를 대상으로 모델을 파인튜닝하는 것은 수억 원의 예산을 태우고 프로젝트를 원점으로 되돌리는 지름길입니다.
실제로 작동하는 올바른 순서는 다음과 같습니다:
- 제약 프롬프팅 + 스팬 접지 + 인간 검토를 통한 부트스트랩. 파인튜닝은 하지 않습니다. 온톨로지를 먼저 안정화하십시오.
- 인간 검토 루프에서 판정된 골드 데이터를 축적하십시오.
- 그다음 검증된 추출 데이터를 소형 고속 모델(8B급, Llama-3-8B 또는 Qwen-2.5-14B)로 증류(Distill)하십시오 (LoRA 활용). 선호(Chosen) = 엄격하게 접지된 추출 결과(재현율이 다소 낮아지더라도 높은 정밀도 보장), 거부(Rejected) = 접지되지 않았으나 그럴듯해 보이는 엣지로 구성된 선호도 데이터셋으로 DPO(Direct Preference Optimization)를 수행합니다. 이를 통해 모델이 유효한 관계가 없을 때 억지로 추측하는 대신
[]를 출력하도록 훈련시킵니다. - 도메인 특화 함의 데이터 쌍으로 NLI 검증기를 파인튜닝하십시오.
여기서 파인튜닝의 목적은 품질 향상이 아닙니다. 고객사의 지속적인 대규모 수집 파이프라인에서 단위 경제학(Unit economics)을 확보하고, 규제 대상 데이터 처리를 위한 온프레미스/VPC 배포를 지원하기 위함입니다. 프론티어 플래그십 모델은 아키텍처 전체를 장악하는 것이 아니라, 난이도 높은 검증을 처리하는 예외 핸들러(Exception handler)로 남겨둡니다.
생명과학 품질 조직에 주는 시사점
이 아키텍처는 막연한 일반론이 아닙니다. 규제 대상 품질 조직들이 이미 구축하고 있는 계층 스택(Layer stack)과 정확히 일치합니다:
- 계층 1 — 마스터 데이터 패브릭 (Master Data Fabric): 정규 시스템, 공급업체, 인력, 문서, 요구사항, 테스트.
- 계층 1.5 — 지식 증거 패브릭 (Knowledge Evidence Fabric, 누락되었던 핵심 고리): 멘션, 후보 개체, 후보 클레임, 증거 스팬, NLI 검증, 모순 탐지, 인간 검토. 이 계층은 확률론적 AI와 권위 있는 지식 사이를 가르는 보안 경계선(Security boundary) 역할을 합니다.
- 계층 2 — 시맨틱 지식 그래프 (Semantic Knowledge Graph): 온톨로지, 정규 개체, 검증된 관계, 시계열 그래프, 데이터 출처, SHACL 제약조건.
- 계층 3 — AI 에이전트 (AI Agents): 변경 영향 분석, 밸리데이션, 정기 검토, 감사 추적(Audit trail) — 계층 2의 신뢰할 수 있는 컨텍스트를 소비하며, 그래프에 직접 쓰기 작업을 수행하지 않습니다. 에이전트는 변경안(Mutations)을 제안할 뿐이며, 정책 엔진이 이를 검증하고 승인해야만 그래프에 반영됩니다.
이 모든 구조의 가치를 입증하는 명확한 MVP는 바로 **밸리데이션 지식 추출기(Validation Knowledge Extractor)**입니다. 사용자 요구사항 명세서(URS) → 기능 명세서(FRS) → 위험 평가 → 테스트 스크립트 → SOP → 밸리데이션 요약 보고서에 이르는 문서를 입력받아, 요구사항 → 위험 → 통제 → 테스트 → 증거 → 시스템으로 이어지는 추적성 체인(Traceability chain)을 출력합니다. 이때 모든 관계는 출처, 페이지, 섹션, 텍스트 스팬, 문서 버전, 밸리데이션 상태를 수반합니다. 그러면 제품이 던지는 질문은 다음과 같이 구체화됩니다: “모든 요구사항-테스트 관계를 보여주고, 이를 뒷받침하는 증거를 입증하십시오.”
이는 실질적이고 즉각적인 사업 가치를 갖는 역량입니다. 단순히 “문서를 읽어주는 AI”가 아니라, **“내 시스템, 프로세스, 요구사항, 위험, 통제, 문서, 테스트, 일탈, 공급업체, 변경 간의 권위 있는 관계를 제시하고, 그 모든 관계의 출처를 입증하라”**는 비즈니스적 요구에 부응하는 것입니다.
실제 공수가 투입되는 영역
최종 결과물은 단순한 스크립트가 아닙니다. SLA를 보장하는 실행 가능한 파이프라인입니다. 실제 프로젝트의 현실적인 공수 배분은 다음과 같습니다:
| 단계 | 공수 비중 | 비고 |
|---|---|---|
| 온톨로지 발굴 워크숍 | 15–25% | 도메인 전문가(SME) 시간, 합의 형성, 스키마 버전 관리 |
| 골드 데이터셋 구축 | 15–20% | 심의 인건비 — 동시에 가장 강력한 해자(Moat) |
| 파이프라인 엔지니어링 | 25–35% | 수집, 추출, 접지, 개체명 해소 |
| HITL 튜닝 + 임계값 캘리브레이션 | 15–20% | 능동 학습 루프, 목표 정밀도 달성 |
| 평가 하네스 구축 + 인계 | 10–15% | 단순 데모와 프로덕션 등급을 가르는 기준 |
진정한 해자는 모델이 아닙니다. GPT → Claude → Qwen 전환은 반나절이면 누구나 할 수 있습니다. 경쟁사가 쉽게 모방할 수 없는 자산은 온톨로지, 정규 개체 레지스트리, 증거 모델, 클레임 원장, 유효성 검증 규칙, 데이터 출처 계층, 인간 검토 이력, 골드 추출 데이터셋, 그리고 규제 시맨틱입니다. 인간 검토는 골드 데이터셋을 살찌우고, 이는 더 뛰어난 추출 성능으로 이어져 인간 검토의 필요성을 줄입니다. 이 플라이휠이 회전하면서 그 누구도 갖지 못한 도메인 특화 평가 데이터셋이라는 복리 자산이 구축됩니다.
요약 및 결론
LLM에 텍스트를 넣어 트리플을 추출하고 Neo4j에 밀어 넣는 식의 순진한 파이프라인은 10분 동안 감탄을 자아내지만 감사관의 첫 번째 질문 앞에서 무너져 내리는 데모를 만들어낼 뿐입니다. 반면 프로덕션 파이프라인은 LLM을 본연의 모습대로 대우합니다. 즉 강력하지만 신뢰할 수 없는 ’제안자’로 두고, 모든 클레임이 지식으로 승격되기 전에 이를 접지하고 검증하며 해소하고 감사하는 결정론적 인프라로 그 주변을 철저히 둘러싸는 것입니다.
파이프라인의 모든 계층은 단 하나의 질문에 답하기 위해 존재합니다: “이 엣지는 왜 여기에 존재하는가?” 만약 그 답이 “모델의 확신도(Confidence)가 높았기 때문”이라면, 그 시스템은 부채입니다. 반면 그 답이 명확한 문서, 버전, 섹션, 원문 그대로의 증거 텍스트, 그리고 검증 체인이라면, 그 지식 그래프는 시간이 흐를수록 복리로 가치가 커지는 진정한 자산이 됩니다.
학습 연구 문헌들 역시 정확히 이 방향으로 수렴하고 있습니다. 가공되지 않은 LLM 생성 트리플을 신뢰하는 대신 제약 추출, 정규화, 생성 후 사후 검증을 도입하는 것입니다 (EMNLP 2024의 Extract-Define-Canonicalize 프레임워크, ICCSC 2026의 DOPKG-SHACL 결정론적 IRI 발행 및 검증 등). 엔터프라이즈 지식 그래프 분야의 최종 승자는 정보 추출을 엄밀한 엔지니어링 학문으로 다루는 조직이 될 것이며, 패자는 이를 단순한 프롬프트 문제로 취급했던 조직이 될 것입니다.
관련 글: GraphRAG: 벡터 검색만으로는 부족할 때 · 하이브리드 GraphRAG: 세 개의 데이터베이스, 하나의 진실 · 그래프 데이터베이스 심층 분석
출처: Zhang & Soh, “Extract, Define, Canonicalize: An LLM-based Framework for Knowledge Graph Construction,” EMNLP 2024 (aclanthology.org/2024.emnlp-main.548); Uwasomba et al., “Deterministic and Trustworthy LLM-Driven Semantic Knowledge Graph Construction,” ICCSC 2026 (research.edgehill.ac.uk); W3C SHACL; W3C PROV-O.
Saram Consulting