260908

1. 자연어 → 트리플
   ㄴ 사실을 (주어, 관계, 목적어)로 구조화
   ㄴ 트리플 → 그래프의 노드-관계-노드로 연결

2. 온톨로지 설계
   ㄴ 어떤 노드 타입과 관계를 사용할지 결정
   ㄴ 관계 시그니처 정의
   (주어 타입, 목적어 타입, 판정 기준)
   ㄴ 노드의 키는 이름이 아니라 id

   • 온톨로지에서 구분하지 않은 정보는 나중에 복구하기 어려움

3. 구조화 출력 규격 정하기
   ㄴ 온톨로지 → 허용 타입·관계 정의
   ㄴ Triple 서식 → subject, subject_type, relation,
   object, object_type, evidence
   ㄴ Pydantic / JSON Schema로 출력 형식 강제

   • 구조화 출력은 '형식'을 보장하지만
     관계의 타입·방향까지 올바른지는 보장하지 않음

4. 추출 프롬프트 설계
   ㄴ 온톨로지를 프롬프트에 주입

   [추출 프롬프트 4부분]

   • 역할
   • 온톨로지 블록
   • 규칙
     · 허용 관계만 사용 + 방향 지키기
     · 맞는 관계가 없으면 넣지 않기
     · 서술문이 아닌 개체 이름만 추출
     · evidence는 원문 문장 그대로
   • 추출할 텍스트

   ㄴ 필요하면 CoT로 추출 과정을 단계화

   • CoT가 항상 성능을 높이는 것은 아님

5. 추출 결과 검증 → 그래프 쌓기
   ① 후처리
   ㄴ evidence가 실제 트리플을 뒷받침하는지 → 근거 미달 제거

   ② 시그니처 검사
   ㄴ 관계 + 주어 타입 → 목적어 타입 확인 → 위반 시 기각

   ③ 이름 해소(Entity Resolution)
   ㄴ 이름 → 그래프의 id 연결
   ㄴ 못 찾거나 애매하면 :Candidate로 격리

   ④ 중복 제거
   ㄴ 같은 (주어, 관계, 목적어) 제거

   ⑤ 적재
   ㄴ 트리플 → Cypher MERGE
   ㄴ Neo4j Knowledge Graph에 적재
   

---

LLM 트리플 추출

(1) 온톨로지 설계

• 허용가능한 레이블
• 관계 시그니처 정의

(2) 구조화된 출력을 위한 스키마 설계
(3) 프롬프트 설계
- 온톨로지도 context로 주입
- 주의사항
- 지침
- CoT, FewShot
(4) LLM 호출 -> 트리플 추출
(5) 후처리
- 추출한 트리플이 온톨로지에 합당한지
- LLM이 추출한 트리플의 근거가 원문에 있는지

---> 평가 --> 추출이 얼마나 잘됐는지 수치 도출 !
---> 평가 결과가 나오고 --> 뭘 개선? 어떻게 개선? -> 평가 기준과 평가 결과에 따라서 달라짐

• LLM이 도출한 트리플의 evidence 증거원문이 실제 원문에 일치하지않는게 많다 --> 원문 준수율 80/100 ---> 원문에 해당하는 evidence 잘 도출

(6) 적재