GraphRAG: LLM에게 공장의 지식을 가르친다

기존 RAG의 한계: "문서는 찾았는데 맥락을 모른다"

[상황: 신입 기술자가 RAG 시스템에 질문]

질문: "알람 E-201이 떴는데 어떻게 해요?"

[기존 Vector RAG의 답변]
"매뉴얼 Section 14.3.2에 따르면 E-201은 스핀들 과열 알람입니다.
냉각수 레벨을 확인하고 베어링 상태를 점검하세요."

→ 문제점:
  1. "어떤 순서로?" → 모른다 (확률 정보 없음)
  2. "냉각수 어디서 확인?" → 모른다 (설비 구조 없음)
  3. "혼자 할 수 있나?" → 모른다 (스킬 매칭 없음)
  4. "이 설비만의 특이사항은?" → 모른다 (이력 없음)

[GraphRAG의 답변]
"CNC밀링 3호기의 알람 E-201(스핀들 과열) 대응 방법:

1순위: 냉각수 부족 확인 (확률 45%, 15분)
  - 위치: 장비 후면 하단 패널
  - 필요 스킬: 기본 정비 (이신입 님 수행 가능)
  - 이 장비는 최근 3개월간 냉각수 부족이 2회 발생

2순위: 베어링 마모 확인 (확률 35%, 4시간)
  - ⚠️ 현재 베어링 사용률 81.3% (교체 시기 임박)
  - 필요 스킬: 스핀들 정비 (김기술 님 호출 필요)

3순위: 과절삭 확인 (확률 20%, 30분)
  - NC 프로그램 이송속도(F값) 확인 필요"

→ 차이점: 구조화된 지식(KG)이 맥락을 제공!

GraphRAG란?

┌──────────────────────────────────────────────────────────┐
│                    GraphRAG 아키텍처                       │
├──────────────────────────────────────────────────────────┤
│                                                          │
│   [사용자 질문]                                           │
│   "알람 E-201이 떴는데 어떻게 해요?"                        │
│        │                                                 │
│        ▼                                                 │
│   ┌─────────────────────────────────┐                    │
│   │        Query Analyzer           │                    │
│   │   질문 의도 분석 + 엔티티 추출    │                    │
│   │   → 엔티티: "E-201"             │                    │
│   │   → 의도: 고장 대응 방법         │                    │
│   └───────────┬─────────────────────┘                    │
│               │                                          │
│        ┌──────┴──────┐                                   │
│        ▼             ▼                                   │
│   ┌────────┐   ┌──────────┐                              │
│   │ Vector │   │ Graph    │                              │
│   │  RAG   │   │  RAG     │                              │
│   │        │   │          │                              │
│   │ 매뉴얼 │   │ Neo4j    │                              │
│   │ 문서   │   │ KG 탐색  │                              │
│   │ 검색   │   │          │                              │
│   └───┬────┘   └────┬─────┘                              │
│       │             │                                    │
│       ▼             ▼                                    │
│   ┌─────────────────────────────────┐                    │
│   │        Context Merger           │                    │
│   │   문서 맥락 + 그래프 맥락 통합    │                    │
│   └───────────┬─────────────────────┘                    │
│               │                                          │
│               ▼                                          │
│   ┌─────────────────────────────────┐                    │
│   │        LLM (GPT-4 등)           │                    │
│   │   통합 맥락 기반 답변 생성        │                    │
│   └───────────┬─────────────────────┘                    │
│               │                                          │
│               ▼                                          │
│   [구조화된 답변 + 근거 + 조치 안내]                        │
│                                                          │
└──────────────────────────────────────────────────────────┘

Vector RAG vs GraphRAG

비교 항목	Vector RAG	GraphRAG
지식 소스	비정형 문서 (PDF, 텍스트)	구조화된 그래프 (Neo4j)
검색 방식	유사도 기반 (임베딩)	관계 기반 (Cypher)
맥락 품질	유사한 텍스트 청크	연결된 엔티티 + 관계
장점	자연어 문서 활용	정확한 관계 추론, 인과 추적
단점	관계 추론 불가	그래프 구축 비용
제조 활용	매뉴얼 검색	고장 원인 추적, 영향도 분석

왜 둘 다 필요한가?

[예시 질문별 최적 방식]

"스핀들 과열 원인이 뭐야?"
  → GraphRAG ✅  (원인-결과 관계 탐색)
  → Vector RAG △ (매뉴얼에서 찾을 수는 있지만 불완전)

"CNC 밀링 정밀도 향상 팁 알려줘"
  → Vector RAG ✅  (기술 문서, 논문에서 검색)
  → GraphRAG △ (구조화된 팁 데이터가 필요)

"알람 E-201 대응하면서 이번 달 정비 이력도 알려줘"
  → Vector RAG + GraphRAG ✅  (하이브리드)
    GraphRAG: 원인-조치-인력 경로
    Vector RAG: 과거 정비 보고서 검색

GraphRAG의 핵심 컴포넌트

1. Entity Extraction (엔티티 추출)

# 질문에서 KG 엔티티 추출
def extract_entities(question: str) -> dict:
    """
    "CNC밀링 3호기의 알람 E-201 조치 방법"
    →
    {
        "equipment": "CNC밀링 3호기",
        "alarm_code": "E-201",
        "intent": "troubleshooting"
    }
    """
    # LLM 기반 추출 또는 규칙 기반 추출
    pass

2. Cypher Generation (쿼리 생성)

# 추출된 엔티티로 Cypher 쿼리 자동 생성
def generate_cypher(entities: dict) -> str:
    """
    entities = {"alarm_code": "E-201", "intent": "troubleshooting"}
    →
    MATCH (f:Fault {alarmCode: "E-201"})
          -[:CAUSED_BY]->(cause:RootCause)
          -[:RESOLVED_BY]->(action:MaintenanceAction)
    RETURN cause, action
    ORDER BY cause.probability DESC
    """
    pass

3. Context Building (맥락 구성)

# KG 결과를 LLM이 이해할 수 있는 맥락으로 변환
def build_context(kg_results: list, doc_results: list) -> str:
    """
    KG 결과 + 문서 검색 결과 → 통합 프롬프트
    """
    context = "## Knowledge Graph 정보\n"
    context += format_kg_results(kg_results)
    context += "\n## 관련 문서\n"
    context += format_doc_results(doc_results)
    return context

4. Answer Generation (답변 생성)

# 맥락 기반 LLM 답변 생성
def generate_answer(question: str, context: str) -> str:
    prompt = f"""
    당신은 제조 현장의 기술 지원 AI입니다.
    아래 Knowledge Graph 정보와 문서를 참고하여 답변하세요.

    질문: {question}

    {context}

    답변 시 다음을 포함하세요:
    1. 원인별 확률과 조치 방법 (높은 확률순)
    2. 각 조치의 난이도와 소요 시간
    3. 필요한 스킬과 가용 인력
    4. 주의사항
    """
    return call_llm(prompt)

Microsoft GraphRAG vs 우리의 접근

[Microsoft GraphRAG]
- 비정형 텍스트에서 자동으로 KG 생성
- 커뮤니티 감지 + 요약 생성
- 글로벌 질문에 강함 ("전반적인 추세는?")
- 범용적

[우리의 제조 GraphRAG]
- 도메인 전문가가 설계한 온톨로지 기반
- 설비-부품-고장-조치 구조화된 KG
- 구체적 질문에 강함 ("E-201 어떻게 해?")
- 제조 특화

→ 우리 접근이 제조 현장에 더 적합!
  (정확한 인과 관계와 조치 경로가 핵심)

GraphRAG: LLM + Knowledge Graph의 시너지

GraphRAG: LLM + Knowledge Graph의 시너지

GraphRAG: LLM에게 공장의 지식을 가르친다

기존 RAG의 한계: "문서는 찾았는데 맥락을 모른다"

GraphRAG란?

Vector RAG vs GraphRAG

왜 둘 다 필요한가?

GraphRAG의 핵심 컴포넌트

1. Entity Extraction (엔티티 추출)

2. Cypher Generation (쿼리 생성)

3. Context Building (맥락 구성)

4. Answer Generation (답변 생성)

Microsoft GraphRAG vs 우리의 접근

추가 자료