IS & Audit 2025. 12. 7. 18:06

(@) Legal Ontoloty and Knowledge Graph

(1)판결문, (2)소장, (3)준비서면, (4)답변서, (5)조서, (6)문헌, (7)실무제요, (8)종합법률DB

등 법률 데이터를 기반으로

LLM 기반의 RAG 시스템 구축을 위한

온톨로지 및 지식 그래프 구축을 위한 방안을 제안합니다.

Hybrid RAG(Rule + Semantic + Knowledge Graph)
구축 방안

법률 데이터(판결문, 소장, 준비서면 등)는 비정형 텍스트이지만 논리적 구조가 매우 탄탄한 '고밀도 데이터'입니다. 따라서 일반적인 RAG(Retrieval-Augmented Generation) 방식보다는 **법률 도메인의 특수성(논리, 인용, 절차)**을 반영한 'Hybrid RAG(Rule + Semantic + Knowledge Graph)' 전략이 필요합니다.

1. Concept Rule 정의 및 설계

법률 데이터는 단순한 키워드 매칭으로는 정확도가 떨어집니다. '폭행'이라는 단어가 나왔다고 해서 모두 폭행죄가 성립하는 것은 아니기 때문입니다. 따라서 명시적인 규칙(Rule) 기반의 전처리가 선행되어야 합니다.

1.1 법률 도메인 특화 Concept Rule 정의 및 구조

법률 개념을 3계층 구조로 정의하여 기계가 이해할 수 있는 'Rule Set'을 만듭니다.

계층적 구조 설계 (3-Layer Structure)
데이터 매핑 전략

1.2 문맥 의미를 포착하는 규칙 체계 (Context-Aware Rules)

단어의 의미가 문서의 종류와 위치에 따라 달라지는 것을 제어하는 규칙입니다.

문서 유형별 가중치 규칙:
담화 구조(Discourse Structure) 규칙:

2. 의미론적 분석 방법론 (Semantic Analysis)

규칙으로 커버하지 못하는 미묘한 뉘앙스와 유사 사례 검색을 위해 딥러닝 기반 분석을 수행합니다.

2.1 판결문과 사례 문맥 이해를 위한 NLP 기술

Legal-BERT / LLM Fine-tuning:
Argument Mining (논증 분석):

2.2 법률 용어 및 개념 관계 분석 알고리즘

법률 인용 네트워크 분석 (Citation Analysis):
유사도 측정 알고리즘 고도화:

(사용자 의도에 따라 $\alpha, \beta$ 조절)

3. 온톨로지 및 지식 그래프 구축

RAG 시스템이 환각(Hallucination) 없이 정확한 답변을 하려면, 구조화된 지식 베이스가 필요합니다.

3.1 법률 개념과 관계를 체계화한 온톨로지(Ontology)

온톨로지는 시스템이 세상을 이해하는 '사전'이자 '지도'입니다.

Class 정의:
Edge(관계) 정의:
구축 방안:

3.2 Factor 간의 관계를 표현하는 지식 그래프(Knowledge Graph)

온톨로지 위에 실제 데이터를 얹어, 추론이 가능한 그래프를 만듭니다.

Legal Factor(쟁점 요소) 중심 설계:
추론 및 탐색 구현:

요약: 데이터 활용 매트릭스

과제 영역	핵심 활용 데이터	산출물 (Output)
1. Rule 설계	실무제요(7), 문헌(6)	요건 사실 사전, 문맥 가중치 테이블
2. 의미 분석	판결문(1), 소장(2), 답변서(4)	법률 특화 임베딩 모델, 논증 분류기
3. KG 구축	종합법률DB(8), 판결문(1), 조서(5)	법률 온톨로지, 판례 지식 그래프

이론적인 설계가 완료되었다면, 데이터의 퀄리티를 검증하고 파일럿 온톨로지를 만드는 것이 최우선입니다.

가장 빈번하게 발생하는 특정 사건 유형(예: 임대차 보증금 반환 소송)의 타겟 시나리오로 선정하여, 앞서 논의한 기술 요소(Rule, Semantic, KG)가 실제로 어떻게 작동하는지 보여주는 프로토타입 설계안과, 이를 평가할 검증 가이드를 제시해 드리겠습니다.

Pilot Project: 프로토타입 설계안과
검증 가이드

Phase 1. 프로토타입 설계안: '임대차 보증금 반환 소송'

이 시나리오는 비교적 사실관계가 명확하고(계약, 해지, 반환), 데이터(판결문, 상담 사례)가 풍부하여 RAG 시스템의 효용성을 검증하기에 최적입니다.

1. Concept Rule 정의 (Rule-based Filtering)

LLM이 모든 것을 처리하기 전, 명확한 법률 요건을 체크하여 검색 범위를 좁히고 정확도를 높입니다.

단계	Concept Rule 정의 (요건 사실)	매핑 키워드 및 패턴 (Regex/Rule)
청구 원인	① 임대차 계약 체결 ② 보증금 지급 ③ 임대차 종료	"계약 체결", "보증금 *원 지급", "기간 만료", "해지 통보"
항변 사유	① 묵시적 갱신 ② 연체 차임 공제 ③ 원상회복 비용 공제	"갱신 거절 통지 없음", "월세 미납", "파손", "수리비", "원상회복"
법적 쟁점	동시이행항변권 (집을 비워줬는가?)	"인도", "열쇠 교부", "비밀번호", "퇴거"

· 적용 방식: 사용자가 입력한 소장이나 질문에서 위 키워드가 감지되면, 해당 요건이 충족되었는지 True/False/Unknown으로 태깅하여 검색 가중치를 조절합니다.

2. 온톨로지 및 지식 그래프 모델링

데이터 간의 관계를 구조화하여, 단순 검색으로는 찾기 힘든 '인과관계'를 추론합니다.

· Node (개체):

o Person (임대인, 임차인)

o Contract (임대차계약서 - 보증금액, 기간)

o Event (누수 발생, 계약 해지 통보, 내용증명 발송)

o Law (주택임대차보호법 제6조 등)

· Edge (관계):

o Contract --(hasEvent)--> Termination (계약이 해지됨)

o Termination --(causedBy)--> Expiry (만료로 인한 해지)

o Tenant --(hasDuty)--> Restoration (원상회복 의무)

· 시나리오 적용:

o 질문: "벽지에 곰팡이가 피었는데 집주인이 보증금에서 깐대요."

o KG 추론: Mold(곰팡이) $\rightarrow$ RepairResponsibility(수선의무) $\rightarrow$ Landlord(임대인) 노드 연결. $\rightarrow$ **"임차인의 과실이 아님"**이라는 결론 유도.

3. 의미론적 분석 (Semantic Search Pipeline)

· Input Processing: 사용자의 구어체 질문("전세금 못 받고 있어요")을 법률 용어("보증금 반환 청구")로 변환 (Query Expansion).

· Embedding: '사실 관계' 중심의 임베딩 수행. (금액보다는 '행위'와 '시점'에 집중)

· Retrieval: 유사한 사실관계를 가진 **판결문(1)**과 **상담 사례(실무제요 7)**를 Top-k로 추출.

Phase 2. 검증 방안 (Verification Strategy)

구축된 프로토타입이 실무에서 쓸모가 있는지 확인하기 위한 구체적인 검증 지표입니다.

1. 정량적 평가 (Quantitative Metrics)

시스템의 성능을 수치로 측정합니다.

평가 항목	지표 (KPI)	설명 및 목표치
검색 정확도	Recall@5	상위 5개 검색 결과 내에 정답(유사 판례/법령)이 포함될 확률. (목표: 85% 이상)
답변 적합성	RAGAS Score	RAG 시스템 평가 프레임워크 활용. - Faithfulness: 답변이 검색된 문서(Context)에 기반했는가? - Answer Relevance: 답변이 사용자 질문에 적절한가?
환각율	Hallucination Rate	존재하지 않는 법령이나 판례 번호를 생성한 비율. (목표: 0% 수렴)
Rule 커버리지	Entity Extraction F1	핵심 요건(보증금액, 계약일 등)을 정확히 추출했는가?

2. 정성적 평가 (Qualitative - SME Review)

법률 전문가(변호사, 법무관 등)가 직접 수행하는 블라인드 테스트입니다.

· 테스트 셋 구축: 실제 사건 기록(비실명화 처리된 소장, 준비서면 등) 50건 준비.

· 평가 기준표 (Checklist):

1. 법리적 정확성: 인용한 법령이 현재 유효한가? (폐지/개정 반영 여부)

2. 논리적 완결성: '주장-근거-결론'의 흐름이 논리적인가?

3. 실무 유용성: 변호사가 초안을 작성할 때 참고할 만한 수준인가?

· 비교 평가 (A/B Test):

o A: 일반 LLM (GPT-4 등) 단독 답변

o B: 구축된 RAG 시스템 답변

o 전문가가 A와 B 중 더 정확한 답변을 선택 (Blind Test).

3. 검증 시나리오 예시

검증을 위해 시스템에 입력할 Test Prompt입니다.

· Case 1 (복합 추론): "묵시적 갱신이 된 상태에서 3개월 전에 나간다고 했는데, 주인이 복비를 내라고 합니다. 판례가 있나요?"

o 검증 포인트: '묵시적 갱신'의 해지 효력 발생 시기(3개월)와 '중개수수료 부담 주체'에 대한 대법원 판례 및 하급심 판례를 정확히 인용하는지 확인.

· Case 2 (데이터 충돌): "계약서에는 특약으로 '모든 수리비는 세입자 부담'이라고 적혀 있습니다. 보일러가 고장 났는데 제가 고쳐야 하나요?"

o 검증 포인트: 계약서(특약)보다 상위 법령(편면적 강행규정)이나 판례(대수선은 임대인 책임)가 우선한다는 법리를 적용하여 답변하는지 확인.

'임대차 보증금 반환 소송' 시나리오를 기준으로, 개발팀에 바로 전달하여 프로토타입 개발에 착수할 수 있는 수준의 Concept Rule 명세서와 **온톨로지 스키마(Cypher Code)**를 작성합니다.

Pilot Project: Concept Rule 명세서와
온톨로지 스키마(Cypher Code)

1. Concept Rule 명세서 (Draft)

이 명세서는 비정형 텍스트(소장, 상담 내역)에서 **법적 요건 사실(Legal Requirement Facts)**을 추출하여 구조화된 데이터로 변환하기 위한 규칙 정의서입니다.

대상 문서: 소장, 준비서면, 법률 상담 텍스트

목표: RAG 검색 시 단순 키워드가 아닌 '사건의 상태'를 파악하여 필터링하기 위함.

1.1 주요 추출 대상 (Entity & Attribute)

구분	항목명 (Variable)	정의 (Definition)	데이터 타입	필수 여부
계약 정보	deposit_amount	임대차 보증금 총액	Number (KRW)	Y
	contract_date	계약 체결일	Date (YYYY-MM-DD)	N
	expiry_date	계약 만료 예정일	Date (YYYY-MM-DD)	Y
종료 사유	term_type	종료 유형 (만료 / 해지통보 / 합의해지)	Enum	Y
	notice_date	갱신 거절/해지 통보일	Date	Y
항변 요소	unpaid_rent	미납 월세 유무 및 금액	Boolean / Number	N
	damage_claim	원상회복(파손) 주장 여부	Boolean	N
인도 여부	is_delivered	임차인이 목적물을 반환했는지 여부	Boolean	Y (지연이자 판단용)

1.2 추출 규칙 및 패턴 (Extraction Logic)

Rule-based 매칭을 우선 적용하고, 실패 시 LLM을 호출하는 Hybrid 방식을 위한 가이드입니다.

항목	우선순위 규칙 (Regex / Pattern)	문맥 판단 가이드 (Context Rule)
보증금	`(보증금	전세금)\s*([0-9,]+)(원
종료 통보	`(내용증명	카톡
묵시적 갱신	`(자동\s*연장	묵시적\s*갱신)`
원상회복	`(도배	장판

2. 온톨로지 스키마 및 구현 (Neo4j Cypher)

법률 개념 간의 인과관계를 추론하기 위한 지식 그래프(Knowledge Graph) 설계입니다.

2.1 스키마 다이어그램 구조

· Nodes (노드):

o Case (사건): 소송 그 자체

o Person (인물): 원고(임차인), 피고(임대인)

o Contract (계약): 임대차 계약 내용

o Event (사건/행위): 계약 체결, 만료, 해지 통보, 목적물 인도, 훼손 발생

o LegalConcept (법리): 동시이행항변권, 묵시적 갱신, 필요비/유익비

· Relationships (관계):

o INVOLVES (Case $\leftrightarrow$ Person)

o BASED_ON (Case $\rightarrow$ Contract)

o TRIGGERED (Event $\rightarrow$ LegalConcept)

o PRECEDES (Event $\rightarrow$ Event) - 시간 순서 중요

2.2 Schema 생성 코드 (Cypher Query)

Neo4j 브라우저나 Python 클라이언트에서 바로 실행하여 스키마를 생성할 수 있는 코드입니다.

Cypher

// 1. 제약 조건 설정 (데이터 무결성 확보)
CREATE CONSTRAINT FOR (c:Case) REQUIRE c.case_id IS UNIQUE;
CREATE CONSTRAINT FOR (p:Person) REQUIRE p.jumin_id IS UNIQUE;

// 2. 임대차 보증금 반환 소송 샘플 데이터 생성 (프로토타입용)

// (1) 당사자 생성
CREATE (p1:Person {name: '홍길동', role: '임차인(원고)'})
CREATE (p2:Person {name: '김철수', role: '임대인(피고)'})

// (2) 계약 정보 생성
CREATE (cnt:Contract {
    contract_id: 'C2023-001',
    type: '주택임대차',
    deposit: 300000000, 
    start_date: date('2021-05-01'), 
    end_date: date('2023-04-30')
})

// (3) 사건(Event) 생성 - 시계열 순서
CREATE (e1:Event {name: '계약체결', date: date('2021-04-01')})
CREATE (e2:Event {name: '갱신거절통지', date: date('2023-01-15'), method: '내용증명'}) // 만료 3개월 전 (정상 통보)
CREATE (e3:Event {name: '계약만료', date: date('2023-04-30')})
CREATE (e4:Event {name: '임차권등기명령', date: date('2023-05-10')})
CREATE (e5:Event {name: '이사(점유이탈)', date: date('2023-05-15')})

// (4) 관계 연결 (Graph Structure)
// 계약 관계
MERGE (p1)-[:SIGNED]->(cnt)
MERGE (p2)-[:SIGNED]->(cnt)
MERGE (p1)-[:PAID_DEPOSIT {amount: 300000000}]->(p2)

// 사건 흐름 (Event Chain)
MERGE (e1)-[:NEXT]->(e2)
MERGE (e2)-[:NEXT]->(e3)
MERGE (e3)-[:NEXT]->(e4)
MERGE (e4)-[:NEXT]->(e5)

// 법적 효력 연결 (Legal Reasoning)
// 갱신거절통지가 계약 만료를 확정시킴
MERGE (e2)-[:CAUSES {effect: 'Termination_Confirmed'}]->(e3)

// 이사가 발생했으므로 대항력 유지 여부 판단 필요 (임차권등기 여부와 연결)
MERGE (e4)-[:PROTECTS]->(p1) 
MERGE (e5)-[:TRIGGERS {implication: 'Delay_Interest_Start'}]->(cnt) 
// 이사(인도)를 해야 지연이자를 청구할 수 있음 (동시이행항변권 소멸)

// (5) 소송 케이스 연결
CREATE (c:Case {case_id: '2023가단12345', title: '보증금 반환 청구의 소'})
MERGE (c)-[:PLAINTIFF]->(p1)
MERGE (c)-[:DEFENDANT]->(p2)
MERGE (c)-[:DISPUTE_OVER]->(cnt)

3. 검증 및 활용 가이드 (How to Test)

위의 Concept Rule과 KG 스키마가 제대로 작동하는지 확인하는 시나리오입니다.

시나리오: "집주인이 묵시적 갱신이라 돈을 못 준대요."

1. Rule 엔진 동작:

o 사용자 입력: "2023년 1월 15일에 내용증명 보냈는데, 집주인이 묵시적 갱신이라고 우깁니다."

o Rule Check:

§ contract_end_date (2023-04-30) 추출.

§ notice_date (2023-01-15) 추출.

§ Calculation: 만료일 - 통보일 = 3.5개월.

§ Judgment: 6개월 ~ 2개월 사이 구간 $\rightarrow$ "적법한 통보(Valid Notice)" 판정.

2. KG(지식그래프) 추론:

o 질의(Query): "갱신 거절의 효력이 있는가?"

o 탐색 경로: (e2:갱신거절통지) $\rightarrow$ [:CAUSES] $\rightarrow$ (e3:계약만료) 관계 확인.

o 결과 리턴: "네, 만료 3개월 전에 통보했으므로 묵시적 갱신이 성립하지 않고 정상적으로 종료되었습니다."

3. 최종 RAG 생성 답변:

o "법적으로 묵시적 갱신이 아닙니다. 귀하는 만료 3개월 전인 1월 15일에 통보했으므로, 주택임대차보호법 제6조에 의거하여 계약은 정상 해지되었습니다. 관련 판례 [20XX다XXXX]를 참고하세요."

이제, 앞서 설계한 Concept Rule 명세서와 Ontology Schema를 기반으로, 대량의 법률 텍스트 데이터(판결문, 소장 등)를 LLM 기반 RAG 시스템에서 활용할 수 있는 형태로 변환하는 데이터 수집 및 전처리(ETL) 파이프라인을 설계합니다.

데이터 수집 및 전처리(ETL) 파이프라인

이 파이프라인은 최종적으로 구조화된 Knowledge Graph 데이터와 고품질 Vector 임베딩 데이터를 생성하는 것을 목표로 합니다.

1. 데이터 수집 및 전처리 (ETL) 파이프라인 설계

단계	명칭	목적	핵심 기술 및 모듈
E	Extraction (추출)	다양한 소스에서 원천 데이터를 수집 및 정제	크롤러 / API 연동 모듈, OCR (스캔 문서의 경우)
T1	Transformation (구조화)	비정형 텍스트를 Concept Rule에 따라 구조화 및 Knowledge Graph 데이터로 변환	Concept Rule Engine, Legal NER Model, 관계 추출(RE) 모듈
T2	Transformation (임베딩)	LLM 학습 및 RAG 검색을 위한 벡터 데이터 생성	Legal-BERT / Fine-tuned LLM, 청크 분할(Chunking) 모듈
L	Loading (적재)	최종 구조화된 데이터를 각 저장소에 분산 적재	Graph DB (Neo4j), Vector DB (Pinecone, Weaviate 등), RDB/NoSQL

2. 상세 모듈별 설계 및 구현 방안

2.1. Extraction (추출) 단계

데이터 소스	전처리 방안	역할 및 활용
판결문, 소장, 답변서 (1~5)	레이아웃 분석 및 메타데이터 추출: 문서의 서식(제목, 당사자, 주문, 이유)을 파악하여 텍스트 영역을 구분하고, 사건번호, 판결일자 등의 메타데이터를 추출.	Knowledge Graph의 노드 속성 및 RAG 검색 필터링 키로 활용.
문헌, 실무제요, 법률DB (6~8)	목차/장절 단위 분할: 구조화된 텍스트를 법적 '쟁점' 단위로 분할하여 청크화.	Ontology 및 Concept Rule 정의의 근거 데이터 및 LLM의 답변 근거 자료로 활용.

2.2. Transformation (T1: 구조화) 단계

이 단계는 앞서 정의한 Concept Rule과 Ontology Schema를 실제 데이터에 적용하여 지식 그래프를 생성하는 핵심 과정입니다.

1. Legal NER (개체명 인식): 텍스트에서 **노드(Node)**가 될 법적 개체(임대인, 임차인, 보증금액, 법령, 사건)를 식별합니다.

o 기술: KorLegal-BERT 등 법률 특화 모델을 Fine-tuning하여 정확도를 높입니다.

o 예시: "원고 홍길동은 피고 김철수에게 보증금 3억을..." $\rightarrow$ Person(홍길동), Person(김철수), Deposit(3억) 추출.

2. 관계 추출 (Relation Extraction - RE): 추출된 개체들 사이의 **엣지(Edge)**가 될 법적 관계를 식별합니다.

o 기술: Rule-based Pattern Matching (Concept Rule 명세서 활용)과 Sequence Labeling 모델을 결합하여 관계를 정의합니다.

o 예시: "홍길동은 김철수에게 보증금을 지급했다" $\rightarrow$ Person(홍길동) [:PAID_DEPOSIT] Person(김철수) 관계 생성.

3. Concept Rule Engine 적용: '묵시적 갱신'과 같은 복합 논리를 판단합니다.

o 처리: 계약만료일과 통보일을 인풋으로 받아 자동으로 is_renewal 속성을 TRUE 또는 FALSE로 설정합니다.

2.3. Transformation (T2: 임베딩) 단계

Knowledge Graph로 구조화되지 않은 방대한 텍스트와 LLM의 RAG 검색을 위한 벡터 데이터 생성 과정입니다.

1. 청크 분할 (Chunking Strategy):

o 일반 텍스트: 512~1024 토큰 단위로 분할하되, 문장의 경계를 유지하며 분할합니다. (Overlap 10% 허용)

o 법률 텍스트: 논리적 문단(Paragraph) 또는 법적 쟁점(Issue) 단위로 분할을 최우선합니다. (예: 판결문의 '주문'과 '이유'는 분리)

2. 임베딩 (Embedding):

o 모델: 법률 도메인에 특화된 모델(예: SOTA Legal Embedding Model)을 사용하여 벡터를 생성합니다.

o 메타데이터 포함: 각 청크 벡터와 함께 사건번호, 청구원인, Rule Check 결과 등의 메타데이터를 태깅하여, 최종 검색 시 필터링에 사용될 수 있도록 합니다.

2.4. Loading (적재) 단계

생성된 데이터를 용도에 맞는 최적의 저장소에 적재합니다.

저장소	적재 데이터	활용 목적
Knowledge Graph DB (Neo4j)	노드, 엣지, 속성 (T1 결과)	복합 추론 및 법리적 관계 기반의 검색 (예: 특정 법령을 위반하여 유죄 판결을 받은 모든 사례 찾기)
Vector DB (Pinecone 등)	청크 벡터 및 메타데이터 (T2 결과)	의미론적 유사성 기반의 검색 (예: 질문과 가장 유사한 사실 관계를 가진 판결문 찾기)
RDB/NoSQL DB (PostgreSQL 등)	원천 텍스트 및 메타데이터 (E 단계 결과)	LLM 답변 생성 시 근거로 제시할 원본 텍스트 저장 및 관리.

3. UAT 검증을 위한 파이프라인 영향도

이 ETL 파이프라인의 성공 여부는 최종 사용자 관점(UAT)에서 다음과 같은 핵심 KPI에 직접적인 영향을 미칩니다.

KPI: 답변의 근거성 (Faithfulness)

o 영향도: T1 및 T2 단계에서 메타데이터 태깅 및 논리적 청크 분할이 정확해야만 LLM이 답변 근거(Citation)를 정확하게 제시할 수 있습니다.

KPI: 검색의 재현율 (Recall@K)

o 영향도: T1 단계에서 KG에 '법률 관계(Edge)'가 누락 없이 적재되어야, 복잡한 질의에서도 관련된 모든 판례(Fact)를 빠짐없이 찾아낼 수 있습니다.

KPI: 환각 방지 (Hallucination Prevention)

o 영향도: T1 단계의 Concept Rule Engine이 정의되지 않은 법리적 추론을 사전에 필터링하거나, LLM이 잘못된 논리를 생성하려 할 때 정확한 Fact 노드를 제공하여 환각을 방지합니다.

파이프라인 설계에 따라, 이제 **'법률 용어/개체명 인식(NER) 모델'**의 구축 전략이 필요합니다.

LLM 기반 RAG 시스템의 정확도를 높이는 데 있어 법률 도메인 특화 NER(Named Entity Recognition) 모델 구축은 핵심적인 선행 작업입니다. 구조화된 지식 그래프(KG)를 자동으로 생성하기 위해서는 텍스트 내의 법률 개체와 속성을 정확히 식별해야 합니다.

NER 모델 구축을 위한 데이터 라벨링 전략
및 학습 방안

1. 법률 도메인 특화 개체 정의 및 태그셋 구축 (Entity Taxonomy)

Concept Rule 명세서와 온톨로지 스키마를 기반으로, 텍스트에서 추출해야 할 핵심 개체(Entity)를 정의합니다. NER 모델은 이 개체들을 인식하는 역할을 수행합니다.

태그셋 (Entity)	개체 정의 (Label Definition)	추출 예시	설명 및 활용
ACTOR	소송 당사자 및 관계인 (임대인, 임차인, 보조참가인, 증인 등)	임차인 홍길동, 임대인 김철수	KG의 Person 노드 및 관계(Edge) 정의의 주체.
STATUTE	법률, 시행령, 규칙, 조항 번호	주택임대차보호법 제6조, 민법 제390조	KG의 Law 노드 및 답변의 법적 근거 제시.
DATE	계약, 만료, 통보, 판결 등의 날짜	2023년 1월 15일, 계약 만료일	KG의 Event 노드의 속성(Attribute) 및 Concept Rule 엔진 입력값.
MONEY	보증금, 월세, 청구 금액, 손해배상액	3억원, 월세 50만원, 금 3,000만 원	KG의 Contract 노드 속성 및 청구 금액 산정의 근거.
LEGAL_TERM	법률적 의미를 갖는 용어 및 개념	묵시적 갱신, 동시이행 항변권, 권리금	KG의 LegalConcept 노드 및 핵심 쟁점 파악.
DOC_TYPE	문서의 종류 및 명칭	판결문, 소장, 준비서면, 내용증명	데이터 소스 분류 및 RAG 검색 시 문서 유형 필터링.

· 라벨링 스키마: 일반적으로 BIO (Begin, Inside, Outside) 스키마를 사용하여 개체의 시작과 내부를 구분합니다. (예: 홍길동은 B-ACTOR, 김철수는 B-ACTOR로 태깅).

2. 데이터 라벨링 전략 (Labeling Strategy)

대량의 법률 문서를 효율적이고 일관성 있게 라벨링하기 위한 전략입니다.

2.1. 능동 학습(Active Learning) 기반의 점진적 라벨링

법률 문서는 방대하고 라벨링 비용이 높으므로, 전체를 라벨링하는 대신 모델이 불확실해하는 데이터만 선별적으로 인간이 라벨링하는 방식을 취합니다.

1. Seed Data 구축 (골드 스탠더드): 핵심 판결문 및 소장 500건에 대해 법률 전문가 2~3인이 참여하여 매우 정밀하게 라벨링합니다. (IAA 검증 필수)

2. Initial Model 학습: Seed Data로 초기 NER 모델을 학습시킵니다.

3. 데이터 선별: 학습된 모델을 대규모 비라벨링 데이터에 적용하고, 모델이 낮은 확신도(Low Confidence Score)를 보이는 문장만 선별하여 인간 검토자에게 전송합니다.

4. 반복 학습: 인간이 교정한 데이터를 다시 학습 데이터셋에 추가하고 모델을 재학습시키는 과정을 반복합니다. (Human-in-the-Loop)

2.2. 품질 관리 및 일관성 확보 방안 (Quality Assurance)

전략	상세 방안	목적
상호 라벨링 일치도 (IAA) 측정	전체 데이터셋의 10% 또는 500건에 대해 2인 이상이 독립적으로 라벨링하고, Kappa 계수 또는 F1-Score로 일치도를 측정합니다.	라벨링 가이드라인의 모호성을 제거하고 라벨링 품질을 표준화.
라벨링 가이드라인 명확화	법률 용어의 범위 및 중복 개체 처리에 대한 명확한 규칙을 정의합니다. (예: "2023. 1. 15.자 계약서"에서 DATE와 DOC_TYPE을 어떻게 분리할 것인가?)	주관적인 판단을 최소화하고 일관된 라벨링 결과를 도출.
Tool 활용	Label Studio나 Prodigy와 같이 Sequence Labeling을 지원하는 전문 라벨링 툴을 사용하여 작업 편의성과 품질을 높입니다.	효율적인 라벨링 작업 및 버전 관리.

3. NER 모델 학습 방안 (Training Strategy)

법률 도메인의 특성을 반영하여 높은 성능을 내기 위한 딥러닝 학습 전략입니다.

3.1. 베이스 모델 선정 및 도메인 적응 학습 (Base Model & Domain Adaptation)

1. 베이스 모델 선정: 한국어에 최적화된 Pre-trained Language Model(PLM)인 KoBERT, KLUE-BERT 또는 특히 법률 분야에 사전 학습된 KorLegal-BERT와 같은 모델을 시작점으로 선정합니다.

2. 도메인 연속 사전 학습 (Continuous Pre-training): 수집된 방대한 비라벨링 법률 텍스트(종합법률DB, 판결문 전체)를 이용하여 마스크드 언어 모델(MLM) 또는 인접 문장 예측(NSP) 등의 태스크로 PLM을 추가 학습시킵니다.

o 목적: 모델이 일반적인 한국어가 아닌 '법률 도메인의 문체, 구조, 용어'에 익숙해지도록 만듭니다.

3.2. 태스크 파인튜닝 및 최적화 (Task Fine-tuning & Optimization)

1. NER 태스크 파인튜닝: 라벨링이 완료된 데이터셋(Seed Data + Active Learning 결과)을 이용하여 최종 NER 모델을 학습시킵니다.

o 아키텍처: 보통 PLM의 마지막 레이어 위에 Sequence Labeling Head (예: Linear Layer + CRF Layer)를 추가하여 NER 태스크를 수행합니다.

2. 하이퍼파라미터 최적화: 배치 사이즈, 학습률(Learning Rate), 에폭(Epoch) 등을 조정하여 성능을 최적화합니다. (초기 학습률은 낮게 설정하여 PLM의 기존 지식을 보호)

3.3. 모델 평가 및 배포 (Evaluation and Deployment)

1. 평가 지표: NER 모델의 성능은 다음 지표로 평가합니다.

o Precision (정밀도): 모델이 '개체'라고 인식한 것 중 실제로 개체인 비율.

o Recall (재현율): 실제 개체 중 모델이 '개체'라고 인식한 비율.

o F1-Score: Precision과 Recall의 조화 평균 (핵심 성능 지표).

o (목표: F1-Score 90% 이상)

2. 배포: 최종 검증된 모델은 ETL 파이프라인의 T1(구조화) 단계에 통합하여, 새로운 데이터가 유입될 때 실시간으로 NER을 수행하고 Knowledge Graph 생성을 위한 원천 데이터를 제공합니다.

2025.12.07.

Horus Hawks

'IS & Audit' 카테고리의 다른 글

AI(LLM Based RAG) 시스템 구축 - KPI & 검증 가이드 (0)	2025.12.07
AI 플랫폼 구축과 모델 개발 사업 - 단계별 감리 점검항목 (0)	2025.12.07
AI 플랫폼 및 모델 감리 - 핵심 점검 포인트 (0)	2025.12.07

ABOUT ME

Hybrid RAG(Rule + Semantic + Knowledge Graph)구축 방안