비정형 텍스트에서 구조화된 지식을 자동으로 추출하는 OneKE 시스템을 깊이 분석합니다. 규칙 기반부터 LLM 에이전트까지, 지식 추출 기술의 30년 역사와 함께 Schema·Extraction·Reflection 세 에이전트의 협력 메커니즘을 사례와 인터랙티브 데모로 쉽게 이해할 수 있습니다.
당신이 신약 개발 연구자라고 상상해 보자. 매일 쏟아지는 수천 편의 논문에서 "어떤 단백질이 어떤 질병과 관련되어 있고, 어떤 약물이 어떤 부작용을 일으키는지"를 파악해야 한다. 모든 정보가 자연어 텍스트 속에 묻혀 있다.
"BRCA1 유전자의 변이는 유방암 위험을 최대 72%까지 증가시키며, 최근 연구에서 PARP 억제제인 올라파립이 이 변이를 가진 환자에게 효과적임이 밝혀졌다."
이 한 문장 안에는 유전자(BRCA1), 질병(유방암), 약물(올라파립), 관계(변이→위험 증가, 약물→효과), 이벤트(연구 발표)가 모두 들어 있다. 사람이 이걸 하나하나 읽고 정리하려면 얼마나 걸릴까?
전 세계에서 매일 생산되는 비정형 데이터는 약 2.5엑사바이트(250경 바이트)에 달한다. 이메일, 뉴스, 논문, SNS, 보고서... 이 거대한 텍스트의 바다에서 의미 있는 지식을 건져 올리는 것 — 이것이 바로 지식 추출(Knowledge Extraction)이다.
그리고 2024년 12월, 저장대학교(Zhejiang University)의 천화쥔(Huajun Chen) 교수팀이 이 문제에 대한 획기적인 해법을 내놓았다. 세 명의 AI 에이전트가 협력하여 비정형 텍스트에서 구조화된 지식을 추출하는 시스템, 바로 OneKE다.
이 글에서는 지식 추출의 역사부터 OneKE의 핵심 아키텍처까지, 이 기술이 왜 중요하고 어떻게 작동하는지를 깊이 있게 살펴본다.
지식 추출 기술은 지난 30년간 극적인 변화를 겪었다. 각 시대를 살펴보자.
초기 지식 추출은 사람이 직접 규칙을 만드는 방식이었다.
문제는 명확했다. 규칙을 만들어도 만들어도 예외가 끝없이 나타났다. "Apple"은 과일인가, 회사인가? "Jordan"은 사람인가, 나라인가? 문맥을 이해하지 못하는 규칙으로는 한계가 분명했다.
은닉 마르코프 모델(HMM)과 조건부 랜덤 필드(CRF)가 등장하면서, 기계가 데이터에서 패턴을 스스로 학습할 수 있게 되었다. 대량의 태깅된 데이터를 학습하면, "이 위치에 이런 단어가 올 확률이 높다"는 것을 통계적으로 예측할 수 있었다.
하지만 여전히 특성 엔지니어링(feature engineering)이 필요했다. 사람이 "대문자 여부", "접미사", "품사 태그" 같은 특성을 수동으로 설계해야 했다.
BiLSTM-CRF 모델이 등장하면서 특성 엔지니어링이 불필요해졌다. 신경망이 텍스트의 앞뒤 문맥을 양방향으로 읽으면서 자동으로 특성을 추출했다. 하지만 장거리 의존성(long-range dependency)을 잘 잡지 못하는 한계가 있었다.
2018년 BERT가 등장하면서 패러다임이 완전히 바뀌었다. 대규모 텍스트로 사전 학습(pre-training)한 뒤, 소량의 태깅 데이터로 미세 조정(fine-tuning)하는 방식이다. 문맥 이해 능력이 비약적으로 향상되었다.
하지만 BERT 기반 접근법에도 한계가 있었다:
GPT-4, LLaMA, Qwen 같은 대형 언어 모델(LLM)이 등장하면서, 지식 추출의 패러다임이 다시 한번 완전히 바뀌었다. LLM은:
이것이 바로 OneKE가 태어난 배경이다.
OneKE를 이해하려면, 먼저 지식 추출의 핵심 과제 세 가지를 알아야 한다.
텍스트에서 사람, 장소, 조직, 날짜 등의 고유 명사를 찾아내는 것이다.
"이재용 회장이 2026년 3월 서울에서 삼성전자의 신제품을 발표했다."
여기서 NER은 이재용=인물, 2026년 3월=날짜, 서울=장소, 삼성전자=조직을 식별한다.
엔티티들 사이의 의미적 관계를 찾는 것이다.
NER이 "누가 있는지"를 찾는다면, RE는 "그들이 어떻게 연결되어 있는지"를 찾는다. 이 관계들이 모여 지식 그래프(Knowledge Graph)를 형성한다.
텍스트에서 무슨 일이 일어났는지, 그리고 그 일에 관련된 참여자, 시간, 장소 등을 구조화하는 것이다.
이벤트 추출은 NER과 RE보다 더 복잡하다. 하나의 문장에 여러 이벤트가 중첩될 수 있고, 이벤트의 인과관계까지 파악해야 하기 때문이다.
이 세 가지를 결합하면 비정형 텍스트를 구조화된 지식 그래프로 변환할 수 있다. 그리고 지식 그래프는 다시 검색, 추천, 의사결정 지원, 질의응답 시스템의 기반이 된다.
| NER (개체명 인식) | RE (관계 추출) | EE (이벤트 추출) |
|---|---|---|
| "누가/무엇이 있는가?" | "어떻게 연결되는가?" | "무슨 일이 일어났는가?" |
| 엔티티 식별 + 분류 | 엔티티 간 관계 파악 | 이벤트 트리거 + 논항 추출 |
| 지식 그래프의 노드 | 지식 그래프의 엣지 | 동적 지식의 핵심 |
아래 시뮬레이터에서 직접 체험해 보자. 다양한 텍스트에서 NER, RE, EE가 어떤 결과를 만들어내는지 확인할 수 있다.
2023년을 기점으로, 지식 추출 분야에 근본적인 변화가 일어났다. 대형 언어 모델(LLM)이 등장하면서, 기존의 "데이터 태깅 → 모델 학습 → 추론"이라는 파이프라인이 "프롬프트 작성 → LLM 호출 → 결과 획득"으로 단순화된 것이다.
| 기존 방식 (BERT 등) | LLM 방식 (OneKE 등) |
|---|---|
| 도메인별 수천~수만 건 태깅 데이터 필요 | 태깅 데이터 불필요 (Zero/Few-shot) |
| 스키마 변경 시 재학습 필수 | 스키마를 텍스트로 동적 변경 |
| GPU 클러스터에서 수시간~수일 학습 | API 호출로 즉시 사용 |
| 오류 수정 = 데이터 추가 + 재학습 | 프롬프트 수정 또는 사례 추가로 수정 |
| NER/RE/EE 별도 모델 필요 | 하나의 LLM이 모든 태스크 수행 |
LLM을 "그냥" 지식 추출에 쓰면 여러 문제가 발생한다:
이 다섯 가지 문제를 체계적으로 해결한 것이 바로 OneKE다.
OneKE의 핵심 아이디어는 간단하다: 하나의 LLM이 모든 걸 하지 않는다. 대신, 역할이 분명한 세 명의 전문 에이전트가 협력하여 더 정확한 결과를 만들어낸다.
역할: 입력 데이터 전처리 + 추출 스키마 결정
Schema Agent는 OneKE의 "기획자"다. 들어오는 데이터를 분석하고, 어떤 형태로 지식을 추출할지 결정한다.
예를 들어, 사용자가 "이 뉴스 기사에서 인물, 조직, 사건을 추출해줘"라고 요청하면, Schema Agent는:
역할: LLM을 활용한 실제 지식 추출
Extraction Agent는 OneKE의 "실행자"다. Schema Agent가 준비한 스키마에 따라 실제로 텍스트에서 지식을 추출한다.
이 에이전트의 핵심 무기는 Case Retrieval(사례 검색)이다:
# OneKE의 Few-shot 프롬프트 구성 (개념 예시)
prompt = f"""
[스키마]
엔티티 유형: {schema.entity_types}
관계 유형: {schema.relation_types}
[유사 사례 1]
입력: {similar_case_1.text}
출력: {similar_case_1.result}
[유사 사례 2]
입력: {similar_case_2.text}
출력: {similar_case_2.result}
[추출 대상]
입력: {target_text}
출력:
"""
그리고 결정적으로, Self-consistency(자기 일관성) 메커니즘으로 불확실한 예측을 필터링한다. 같은 입력에 대해 여러 번 추출을 수행하고, 결과가 일관되지 않으면 해당 항목을 "불확실"로 표시하여 Reflection Agent에게 넘긴다.
역할: 오류 진단 및 수정
Reflection Agent는 OneKE의 "품질 관리자"다. 이것이 OneKE의 가장 혁신적인 부분이다.
기존 시스템은 모델이 틀리면 재학습 외에 방법이 없었다. 하지만 Reflection Agent는:
이 메커니즘의 핵심은 재학습 없는 지속적 개선이다. 모델을 다시 학습시키지 않아도, Case Repository가 축적되면서 시스템이 점점 더 정확해진다.
아래 시뮬레이터에서 세 에이전트가 어떻게 순차적으로 협력하는지 직접 체험해 보자.
뉴스 기사 HTML 페이지를 OneKE에 입력한다고 하자.
논문에서 인상적인 사례 중 하나는, 해리 포터 1권 첫 번째 장(17페이지 분량의 PDF)에서 지식을 추출한 것이다.
Schema Agent가 긴 PDF를 자동으로 청크로 분할하고, Extraction Agent가 각 청크에서 등장인물(해리 포터, 덤블도어, 더즐리 부부...), 장소(프리벳 드라이브 4번지, 호그와트...), 관계(가족, 적대, 멘토...)를 추출한다.
{
"entities": [
{"text": "Harry Potter", "type": "인물"},
{"text": "Albus Dumbledore", "type": "인물"},
{"text": "Vernon Dursley", "type": "인물"},
{"text": "Privet Drive", "type": "장소"},
{"text": "Hogwarts", "type": "조직"}
],
"relations": [
{"subject": "Harry Potter", "relation": "거주지", "object": "Privet Drive"},
{"subject": "Vernon Dursley", "relation": "거주지", "object": "Privet Drive"},
{"subject": "Albus Dumbledore", "relation": "소속", "object": "Hogwarts"}
]
}
이렇게 추출된 결과는 Neo4j 같은 그래프 데이터베이스에 저장하여 시각화하고 질의할 수 있다.
OneKE의 또 다른 강점은 사전 정의된 스키마 없이도 추출이 가능하다는 것이다. "Base" 모드에서는 사용자가 자연어로 지시만 내리면 된다:
"이 텍스트에서 주요 기술과 그 기술을 개발한 기관, 그리고 관련 성과를 추출해줘."
Schema Agent가 이 지시를 분석하여 자동으로 스키마를 생성하고, 나머지 에이전트가 추출을 수행한다.
OneKE의 이름에서 눈에 띄는 단어가 있다: Dockerized. 왜 Docker가 중요한가?
AI 연구의 고질적인 문제 중 하나가 재현성(reproducibility)이다. "논문에서는 된다고 했는데 내 환경에서는 안 된다"는 경험, AI 개발자라면 누구나 있을 것이다.
OneKE는 시스템 전체를 Docker 컨테이너로 패키징하여 이 문제를 해결한다:
# OneKE를 단 두 줄로 실행
docker pull zjunlp/oneke:v4
docker run --gpus all -v ./OneKE:/app/OneKE -it oneke:v4 /bin/bash
Python 버전, CUDA 버전, 라이브러리 의존성 — 이 모든 것이 컨테이너 안에 고정되어 있어 어떤 환경에서든 동일하게 작동한다.
| Quick 모드 | Standard 모드 | Customized 모드 |
|---|---|---|
| 긴 텍스트 빠르게 처리 | 높은 정확도 추출 | 에이전트별 세부 설정 |
| Schema Agent만 사용 | 3개 에이전트 모두 사용 | 사용자가 각 에이전트 구성 |
| 속도 우선 | 정확도 우선 | 유연성 우선 |
OneKE는 특정 LLM에 종속되지 않는다:
모델을 교체해도 시스템을 재설계할 필요가 없다. YAML 설정 파일 하나만 바꾸면 된다.
OneKE 팀은 두 가지 벤치마크에서 시스템을 평가했다:
특히 Case Retrieval(사례 검색)이 가장 큰 성능 향상을 가져왔다. 유사한 과거 사례를 Few-shot으로 제공하는 것만으로도 추출 정확도가 크게 올라간 것이다. 그리고 Reflection Agent의 오류 수정이 추가되면서 최종 성능이 한 단계 더 올라갔다.
| 평가 항목 | LLaMA-3-8B | GPT-4-turbo |
|---|---|---|
| NER (CrossNER) | Case Retrieval에서 큰 향상 | 전반적으로 높은 기준 성능 |
| RE (NYT-11-HRL) | Reflection에서 큰 향상 | Case Retrieval에서 가장 큰 향상 |
| 에이전트 효과 | 모든 에이전트에서 일관된 향상 | 이미 높은 성능에서도 추가 향상 |
흥미로운 점은, 오픈소스 모델(LLaMA-3-8B)도 OneKE의 에이전트 시스템과 결합하면 상용 모델에 근접하는 성능을 보인다는 것이다. 이는 비용에 민감한 기업들에게 중요한 시사점이다.
2026년 현재, 지식 추출은 단순한 학술 연구를 넘어 산업 현장의 핵심 기술로 자리잡고 있다:
의료 분야: 환자 기록, 논문, 임상시험 데이터에서 약물-질병-유전자 관계를 자동 추출하여 신약 개발 가속화
금융 분야: 뉴스, 공시, SNS에서 기업 관계, 이벤트(인수합병, 경영진 변동, 규제 변화)를 실시간 추출하여 리스크 관리
법률 분야: 판례, 법률 조항, 계약서에서 법적 관계와 선례를 자동 추출하여 법률 자문 자동화
제조업: 기술 문서, 특허, 매뉴얼에서 부품-공정-불량 관계를 추출하여 품질 관리 자동화
OneKE 같은 지식 추출 시스템은 GraphRAG(Graph-based Retrieval Augmented Generation)와 결합될 때 진정한 힘을 발휘한다. 지식 추출 → 지식 그래프 구축 → GraphRAG로 질의응답 — 이 파이프라인이 2026년 엔터프라이즈 AI의 핵심 아키텍처가 되고 있다.
OneKE 논문이 보여준 가장 중요한 인사이트는 이것이다:
LLM 하나로 모든 것을 해결하려 하지 마라. 역할을 나누고, 피드백 루프를 만들어라.
이것은 지식 추출뿐 아니라, LLM 기반 시스템 설계의 일반 원칙이 되고 있다:
우리는 매일 엄청난 양의 텍스트를 만들어내지만, 그 안의 지식은 대부분 비정형 상태로 잠들어 있다. OneKE는 세 명의 AI 에이전트가 협력하여 이 잠든 지식을 깨우는 시스템이다.
30년 전 사람이 수작업으로 규칙을 만들던 시대에서, 이제 AI 에이전트가 스스로 스키마를 설계하고, 지식을 추출하고, 실수를 반성하며 개선하는 시대가 되었다. 그리고 이 모든 것이 Docker 컨테이너 안에 담겨, 누구나 docker run 한 줄로 실행할 수 있다.
기계가 세상을 읽는 법 — 그것은 더 이상 먼 미래의 이야기가 아니다. 지금, 여기서 일어나고 있다.
참고 자료
