온톨로지 구현-전체적
온톨로지 구현 전체적
- 설계 (온톨로지)
- 정형화: CQ(질문)을 먼저 뽑아 거기서 역산을 해 최상위 클래스를 뽑는 설계 (14개 질문 -> 11개 최상위 클래스)
- 클래스(계약/당사자/계약상태/업무유형/신청채널/구비서류/규정조건/재무처리/통지유형/전달매체/계약구성요소)와 19개의 관계(domain->range)를 정함.
- schema에 Pydantic 코드로 고정시킴. 여기까지가 설계도. 아직 구현 안함
- 문서 쪼개기
- 간단하게 첫번째 시도니 페이지단위로 잘라서 청크 144개를 확보.
- 각 청크는 원문 텍스트를 그대로 담아 Chunk 노드로 저장.(지식이 아닌 원문 조각을 저장한 것)
- 청크에서 지식 확보
- 정형화: 144개 청크 각각을 llm한테 보내서 1단계에서 정한 11개 클래스/19개 관계 안에서만 골라 뽑게 시킴. LLM이 그 조각에서 발견한 엔티티(예: 업무유형=”감액(특약삭제)”)와 관계(예: 규정조건→계약상태)를 JSON으로 반환. Pydantic으로 검증해서 스키마 맞지 않으면 버림
- 그래프에 저장
- 정형화: 검증된 엔티티는 MERGE로 노드 생성/재사용 (같은 키값이면 새로 안 만들고 기존 노드 재사용). 관계도 MERGE로 연결. 그리고 Chunk-[:MENTIONS]->엔티티로 “이 지식이 어느 원문 조각에서 나왔는지” 출처를 남김.
- 정제/병합
- 정형화: 같은 개념이 표현만 다르게 쪼개졌는지 점검하고 병합. 지금까지 업무유형(33→29개), 계약상태(17→6개) 정리 완료. 규정조건(207개), 구비서류(129개)는 아직 점검 전. ex. 1번노드랑 2번 노드가 키값만 다르지 같은 노드인것을 확인하고 병합하는 작업
- 질문에 답하기
- 정형화: 자연어 질문 → LLM이 Cypher 쿼리 생성(generate_cypher) → 그래프에서 실행(run_cypher) → 결과를 근거로 LLM이 자연어 답변 생성(generate_answer). 그래프는 안 바꾸고 읽기만 함.
- 전체 품질 채점
- 정형화: 실제 업무매뉴얼 Q&A 134개를 5단계 파이프라인에 통과시키고, LLM judge로 CORRECT/PARTIAL/WRONG 채점. 지금 CORRECT 27.6%, WRONG 59%.
페이지 단위 vs 계층형(헤더) 청킹
청킹 방식별 비교표
| 비교 항목 | 페이지 단위 (예전) | 계층형/헤더 단위 (지금) |
|---|---|---|
| 청크 수 | 145개 | 444개 (3배) |
| API 호출 / 비용 / 시간 | 적음 | 3배 많음 |
| 청크당 사실 밀도 (관계 오부착 사고 위험) |
높음 (22~25개 뒤섞임) • 실제로 관찰됨 (증권재발행 사례) |
낮음 (보통 5~6개) • 확 줄어듦 (감액 사례에서 정확히 잡힘) |
| 표/헤더 구조 보존 | 자동으로 보존 (안 쪼개니까) | 헤더 경계로 쪼개도 표는 헤더와 붙어서 자연스럽게 유지됨 (확인함) |
| maxTokens 잘림 위험 | 큼 (출력이 길어서 relations가 통째로 잘림 — 실제로 겪음) | 작음 (출력이 짧음) |
| 문맥 손실 위험 (이 청크가 무슨 업무인지) |
낮음 (청크가 커서 맥락이 안에 다 들어있음) | 큼 → 문서명/섹션제목 메타데이터로 보완함 |
| 이름 병렬 충돌 위험 (새 업무유형/규정조건) |
낮음 (청크 수 적어 애초에 동시 처리될 확률 낮음) | 큼 — 방금 실제로 발견함 • (“직무직종/운전차종변경” vs “직종/직무 및 운전차종변경” 중복) |
| 문자열 글리치 비율 (entities가 배열 아닌 문자열로 반환) |
6.9% (145개 중 10건) | 3.7% (표본 82개 중 3건, 표본이 작아 확정적이지 않음) |
핵심 트레이드오프 요약
“하나의 실패 유형을 다른 실패 유형으로 맞바꾼 솔루션”
- 계층형 청킹의 이점: “한 번에 너무 많이 뭉쳐서 맥락이 헷갈리는” 기존의 치명적인 오류는 확실히 줄어든다.
- 새롭게 알게 된 점: 데이터를 너무 잘게 쪼개고 병렬 처리를 돌리다 보니, 새로 등장하는 엔티티 이름끼리 동시에 처리되며 충돌하는 부작용이 발생한다. (ex. 계층형 청킹을 도입하며 발견된 업무유형 중복 건)
이 두 방식 중 무엇이 좋다는 없지만 그래프db를 구축중 나온 문제(사실 뭉침)에 대해선 계층형이 더 좋다고 판단됨. -> 그치만 이름 증복 점검같은 사항이 추가로 필요하다고 보임.
문제점
1차 문제점
| 이슈 | 어느 단계 | 성격 | 상태 |
|---|---|---|---|
| 계약상태 노드 중복 | 3단계 (그래프 저장, 키값 설정) | 데이터 저장 방식 버그 | 오늘 해결 |
| Cypher 매칭 너무 좁음 | 5단계 (질문→쿼리 변환) | 질문 처리 로직 문제, 그래프는 그대로 | 대기 중 |
| 추출 시 일부만 뽑음 | 2단계 (청크→지식 추출) | 추출 프롬프트 문제, 고치면 4단계 재실행 필요 | 대기 중 |
