실습: 정비 보고서 → Knowledge Graph 자동 적재

목표

자유 형식 정비 보고서를 LLM으로 구조화해서, Day 2에서 만든 그래프에 정비 이력을 붙입니다.

새 설비나 새 관계 타입을 만드는 실습이 아닙니다. 이미 있는 온톨로지에 이력을 얹는 실습입니다.

실습 환경

pip install pydantic neo4j langchain-openai langchain-core
export OPENAI_API_KEY="sk-..."      # 없으면 규칙 기반 대체 추출기로 돌아갑니다

이 실습이 막아야 하는 두 가지 사고

1. 온톨로지에 없는 관계를 만드는 것 (e:Equipment)-[:HAD_FAULT]->(f:Fault) 처럼 편한 이름을 붙이면 적재는 성공합니다. 그런데 이번 주의 모든 조회 쿼리는 (e:Equipment)-[:HAS_COMPONENT]->()-[:HAS_PART]->(p:Part)-[:CAN_CAUSE]->(f:Fault)를 따라가므로, 그렇게 넣은 데이터는 한 건도 매칭되지 않습니다. 적재는 성공하고 조회는 0행입니다. 이 KG에서 "언제 무슨 고장이 났는가"는 MaintenanceRecord가 담습니다.

2. 없는 값을 대표값으로 묶는 것 알람 코드가 없다고 alarmCode: "UNKNOWN"으로 MERGE하면 사출기 온도 센서 이상과 컨베이어 모터 과부하가 같은 노드가 됩니다. 샘플 보고서 넷 중 둘이 알람 코드가 없으므로 바로 일어나는 일입니다. 중복보다 과병합이 고치기 어렵습니다. 없는 값은 만들지 말고 검토 큐로 보내세요.

진행 순서

1. Pydantic 스키마로 추출 형식을 고정합니다.
2. 설비·알람·조치·작업자를 그래프에서 MATCH합니다. 하나라도 없으면 검토 큐로 보냅니다.
3. 통과한 건만 MaintenanceRecord로 적재합니다.
4. 검토 큐에 무엇이 왜 남았는지 출력합니다.

합격 기준

• 샘플 넷 중 그래프에 이름이 있는 둘만 적재되고, 나머지 둘은 사유와 함께 검토 큐에 남는다
• 같은 보고서를 두 번 넣어도 MaintenanceRecord 수가 늘지 않는다
• 적재 후 MATCH (r:MaintenanceRecord)-[:FOR_EQUIPMENT]->(e) RETURN e.name, r.date 에 새 행이 보인다

confidence는 LLM이 스스로 매긴 값이라 보정되어 있지 않습니다. 그 값을 자동 적재의 통과 기준으로 쓰지 말고, 그래프에 실제로 붙었는지로 판정하세요.