Week 8. 도메인 특화 프로젝트 (Case Study)
의료, 법률, 금융 도메인 지식 그래프 구축 실전
학습 목표
이 튜토리얼을 완료하면 다음을 할 수 있습니다:
- 도메인 특화 온톨로지 설계
- 실제 데이터로 지식 그래프 구축
- 도메인별 쿼리 및 추론 구현
- 프로젝트 구조화 및 문서화
"마천루(Skyscraper)" 비유
Week 1-7에서는 기초 공사(Foundation) 를 마쳤습니다 (온톨로지, Neo4j, GraphRAG). 이제 그 위에 마천루를 세울 차례입니다.
기초는 같지만, 지어질 건물의 용도는 다릅니다.
- 병원 (의료): 무균실과 응급실이 필요합니다 (엄격한 프라이버시, 복잡한 분류체계).
- 법원 (법률): 문서보관소와 재판정이 필요합니다 (인용 네트워크, 판례의 시간적 효력).
- 증권거래소 (금융): 초고속 통신망이 필요합니다 (실시간 데이터, 규제 준수).
같은 도구(벽돌, 철근)를 사용하지만, 설계도는 도메인마다 완전히 다릅니다.
Case Study 선택
의료 지식 그래프
목표: 질병-증상-치료법 관계 그래프 구축
온톨로지:
Disease → hasSymptom → Symptom
Disease → treatedBy → Treatment
Treatment → hasContraindication → Condition
Drug → interactsWith → Drug데이터소스:
- SNOMED CT (의료 용어)
- DrugBank (약물 정보)
- PubMed (논문)
프로젝트 구조
case-study/
├── ontology/
│ └── domain.owl # 도메인 온톨로지
├── data/
│ ├── raw/ # 원본 데이터
│ └── processed/ # 전처리된 데이터
├── extraction/
│ └── pipeline.py # 지식 추출 파이프라인
├── graph/
│ ├── schema.cypher # Neo4j 스키마
│ └── import.py # 데이터 임포트
├── query/
│ └── examples.cypher # 예제 쿼리
└── app/
└── demo.py # 데모 앱의료 도메인 예시
1. 온톨로지 설계
from owlready2 import *
onto = get_ontology("http://example.org/medical.owl")
with onto:
class Disease(Thing): pass
class Symptom(Thing): pass
class Treatment(Thing): pass
class Drug(Treatment): pass
class hasSymptom(ObjectProperty):
domain = [Disease]
range = [Symptom]
class treatedBy(ObjectProperty):
domain = [Disease]
range = [Treatment]
class contraindicatedFor(ObjectProperty):
domain = [Drug]
range = [Disease]2. 데이터 추출 및 적재
# 증상-질병 관계 추출
def extract_disease_symptoms(medical_text):
prompt = """
다음 의료 텍스트에서 (질병, 증상) 쌍을 추출하세요.
텍스트: {text}
JSON 형식: [{{"disease": "", "symptom": ""}}]
"""
return llm.invoke(prompt.format(text=medical_text))
# Neo4j 적재
def load_to_neo4j(disease, symptom):
session.run("""
MERGE (d:Disease {name: $disease})
MERGE (s:Symptom {name: $symptom})
MERGE (d)-[:HAS_SYMPTOM]->(s)
""", disease=disease, symptom=symptom)3. 진단 보조 쿼리
// 증상으로 가능한 질병 추론
MATCH (s:Symptom)<-[:HAS_SYMPTOM]-(d:Disease)
WHERE s.name IN $symptoms
WITH d, count(s) AS matchCount
ORDER BY matchCount DESC
RETURN d.name, matchCount
// 금기 약물 체크
MATCH (drug:Drug)-[:CONTRAINDICATED_FOR]->(condition:Disease)
WHERE condition.name IN $patient_conditions
RETURN drug.name, condition.name AS contraindication평가 기준
| 항목 | 배점 | 기준 |
|---|---|---|
| 온톨로지 설계 | 25% | 완성도, 확장성 |
| 데이터 품질 | 25% | 정확도, 커버리지 |
| 쿼리 기능 | 25% | 실용성, 성능 |
| 문서화 | 25% | 코드 설명, 사용법 |
면접 질문 맛보기
Q: 도메인 온톨로지 구축 시 가장 어려운 점은?
- 도메인 전문가 협업: 용어 이해 차이
- 데이터 품질: 비정형/불완전 데이터
- 스키마 진화: 요구사항 변경 대응
- 성능 최적화: 대규모 그래프 쿼리
더 많은 면접 질문은 Premium Interviews (opens in a new tab)에서 확인하세요.
🎬 프로젝트: 영화 추천 지식그래프
진행 현황
| Week | 주제 | 프로젝트 마일스톤 |
|---|---|---|
| 1 | 온톨로지 입문 | ✅ 영화 도메인 설계 완료 |
| 2 | RDF & RDFS | ✅ 영화 10편 RDF 변환 완료 |
| 3 | OWL & 추론 | ✅ 추론 규칙 적용 완료 |
| 4 | 지식 추출 | ✅ 영화 100편 자동 수집 완료 |
| 5 | Neo4j | ✅ 그래프 DB 구축 완료 |
| 6 | GraphRAG | ✅ 자연어 질의 시스템 완료 |
| 7 | 온톨로지 에이전트 | ✅ 자동 업데이트 에이전트 완료 |
| 8 | 도메인 확장 | 영화 → 다른 도메인으로 확장 |
| 9 | 서비스 배포 | API + 대시보드 |
Week 8 마일스톤: 다른 도메인으로 확장
영화 지식그래프에서 배운 패턴을 의료, 법률, 금융 도메인에 적용합니다.
도메인별 온톨로지 매핑:
| 영화 | 의료 | 법률 | 금융 |
|---|---|---|---|
| Movie | Disease | Case | Company |
| Director | Doctor | Lawyer | CEO |
| Actor | Patient | Client | Investor |
| Genre | Specialty | CaseType | Sector |
| directed | treats | represents | leads |
| actedIn | diagnosed | involved | invested |
의료 지식그래프 예시:
(:Disease {name: "당뇨병", icd10: "E11"})
(:Doctor {name: "김의사", specialty: "내분비내과"})
(:Treatment {name: "인슐린 요법"})
(:Doctor)-[:SPECIALIZES_IN]->(:Specialty)
(:Doctor)-[:TREATS]->(:Disease)
(:Disease)-[:TREATED_BY]->(:Treatment)재사용 가능한 패턴:
- Entity-Relation-Entity 트리플 구조
- 계층적 클래스 분류
- 추론 규칙 템플릿
- GraphRAG 쿼리 패턴
프로젝트 노트북에서 영화 패턴을 다른 도메인에 적용합니다.
프로젝트 노트북에서는 다음을 직접 구현합니다:
- 영화 온톨로지 → 의료 온톨로지 매핑 (Movie→Disease, Director→Doctor)
- 의료 데이터셋(SNOMED CT 샘플) 로딩
- "당뇨병 증상과 치료법" 쿼리 작성
- 재사용 가능한 지식그래프 템플릿 추출
9주 후 완성되는 것: "놀란 감독 스타일의 SF 영화 추천해줘"라고 물으면, 지식그래프에서 감독-장르-평점 관계를 추론하고 자연어로 답변하는 AI 에이전트
실습 노트북
이론을 더 깊이 탐구하고 싶다면:
실습 노트북에서는 추가로 다음 내용을 다룹니다:
- 의료/법률/금융 도메인 중 선택하여 완성
- 실제 공개 데이터셋 연동
- 도메인 전문가 협업 패턴
- 프로젝트 문서화 템플릿
다음: Week 9: 서비스 아키텍처