
목차
제조 현장 LLM 환각은 모델을 바꾸기보다, AI가 근거로 읽는 공장 데이터의 이름과 관계를 먼저 정리하고, 답마다 근거를 붙이고, 확인할 수 없는 답은 보류하게 해서 줄입니다. 온톨로지는 품목·설비·공정·불량 같은 대상의 이름과 관계를 정한 약속이고, 지식그래프는 그 약속대로 실제 데이터를 연결한 기록이며, 그래프 RAG는 질문을 받았을 때 그 연결을 따라 근거를 찾아 답을 만드는 검색 방식입니다. 셋을 갖춰도 틀린 답이 0이 되지는 않습니다. 틀린 답이 줄고, 틀렸을 때 어디서 틀렸는지 찾을 수 있습니다.
제조 AI 운영체제 VEXPLOR를 만드는 웨이스가 이 글에서 다루는 질문은 4가지입니다. 제조 AI는 왜 틀린 답을 자신 있게 내는가, 온톨로지·지식그래프·그래프 RAG는 각각 무엇을 하는가, 지식그래프를 쓰면 답이 얼마나 정확해지는가, 공장 데이터 온톨로지는 어떻게 구축하는가. 질문마다 더 깊이 다룬 글을 달아 둡니다.
제조 AI는 왜 틀린 답을 자신 있게 내나요
제조 AI의 틀린 답은 대개 모델이 몰라서가 아니라, 근거로 받은 데이터가 끊겨 있거나 질문에 맞지 않는 근거를 받았을 때 생깁니다. 공장에서 자주 보이는 원인은 4가지입니다.
원인 | 공장에서 보이는 모습 | 먼저 할 일 |
|---|---|---|
이름이 시스템마다 다름 | 같은 부품이 세 코드 | 코드 대응표 정리 |
관계를 묻는 질문 | 여러 표를 건너야 답함 | 관계를 미리 정의 |
드문 사례 | 기록이 적은 불량 | 보류하고 사람에게 |
근거 없는 생성 | 출처 없는 숫자 | 답마다 근거 표시 |
제조 AI의 틀린 답을 줄이는 일은 틀린 답의 종류를 나누는 데서 시작합니다. 맞는 근거를 못 찾은 검색 실패, 근거는 맞는데 답을 잘못 만든 생성 실패, 질문을 다르게 알아들은 이해 실패는 고치는 방법이 서로 다릅니다. 그래프 검색이 고치는 것은 그중 검색 실패입니다. 실패 사례 100건을 손으로 분류해 보면 어디에 먼저 투자할지가 대개 분명해집니다. 드문 불량에서 AI가 높은 확신으로 틀리는 이유와 확인할 4가지는 AI는 왜 드문 불량에서 자신 있게 틀리는가 — 공장이 AI의 불량 판정을 쓰기 전에 확인할 4가지에 정리했습니다.
온톨로지·지식그래프·그래프 RAG는 각각 무엇을 하나요
세 낱말은 함께 쓰이지만 하는 일이 다릅니다. 온톨로지가 규칙이고, 지식그래프가 그 규칙으로 쌓인 데이터이며, 그래프 RAG가 그 데이터를 찾아 쓰는 방법입니다.
이름 | 하는 일 | 공장 예 |
|---|---|---|
온톨로지 | 대상·관계의 약속 | 공정이 품목을 소비 |
지식그래프 | 약속대로 연결된 기록 | 이 로트가 이 설비를 지남 |
그래프 RAG | 연결을 따라 근거 검색 | 불량 로트의 원자재 추적 |
온톨로지는 AI가 지켜야 할 공장의 약속이고, 지식그래프는 그 약속대로 연결된 공장의 기록입니다. 웨이스는 공장 운영을 자원·품목·공정·약속·사건·기준 6가지 대상으로 나눠 봅니다. 관계에는 방향이 있고, 방향은 곧 금지입니다. 공정이 품목을 소비하지 품목이 공정을 소비하지 않고, 기준이 사건을 판정하지 사건이 기준을 판정하지 않습니다. 방향을 정해 두면, AI가 만든 질의가 관계를 거꾸로 읽었는지 그 규칙으로 검사해 걸러 낼 수 있습니다. 6가지 대상과 시간 규칙은 공장 온톨로지의 대상과 시간 규칙을 다룬 글에 적었습니다.

지식그래프를 쓰면 AI 답이 얼마나 정확해지나요
지식그래프는 정확도를 올리지만, 그 효과는 질문의 종류에 따라 크게 다릅니다. 지식그래프 기반 데이터 카탈로그 회사 data.world의 연구진(Sequeda·Allemang·Jacob, 2023)은 arXiv 기술 보고서 「A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases」(동료 심사 전)에서, 보험 표준 데이터 모델 가운데 13개 테이블로 만든 데이터베이스에 자연어 질문 43개를 GPT-4에 예시 없이(zero-shot) 묻는 실험을 했습니다. SQL 데이터베이스에 바로 물었을 때 정확도는 16.7%였고, 같은 데이터를 온톨로지와 지식그래프로 표현해 물었을 때는 54.2%였습니다. 테이블 구조가 복잡한 질문에서는 SQL 직접 질의가 하나도 맞히지 못했고(답 하나에 테이블이 5개 넘게 필요하면 정확도가 0이 됐습니다), 지식그래프를 거쳐도 35~38%였습니다.
이 결과는 두 가지를 함께 보여 줍니다. 테이블을 많이 건너야 하는 질문에서는 SQL 직접 질의가 아예 답을 내지 못했고 지식그래프를 거친 쪽만 일부 맞혔다는 것, 그리고 그 경우에도 지식그래프 쪽 정확도가 35~38%로 낮아졌다는 것입니다. 전체로 봐도 지식그래프를 쓴 쪽이 절반 가까이 틀렸습니다. 연구진은 결론에서 지식그래프 기반 데이터 카탈로그 플랫폼에 투자하라고 권하는데, 연구진이 바로 그런 플랫폼을 파는 data.world 소속이라는 점도 밝혀 둡니다.
그래프 RAG가 언제 효과가 있는지는 ICLR 2026에 실린 연구(Xiang 외, 「When to use Graphs in RAG: A Comprehensive Analysis for Graph Retrieval-Augmented Generation」)가 정리했습니다. 연구진은 단순한 사실을 찾는 질문에서는 일반 RAG가 그래프 RAG와 비슷하거나 더 낫고, 여러 개념 사이의 관계를 거쳐야 하는 복잡한 추론과 요약에서는 그래프 RAG가 분명히 앞선다고 보고했습니다. 그래프 RAG는 답이 여러 기록 사이의 관계에 있을 때 효과가 있습니다. 공장에서 자주 나오는 질문 가운데에는 이런 질문이 많습니다. 「이 설비가 멈추면 어느 고객의 어느 주문이 며칠 밀리나」는 설비·공정·품목·재고·작업지시·주문을 차례로 지나야 답이 나옵니다. 연구별 결과와 한계는 그래프RAG는 정말 지고 있을까에, 그래프 검색으로 옮기기 전에 확인할 6문항은 Graph RAG가 벡터 RAG보다 나은 순간과 아닌 순간에 있습니다.
공장은 데이터 온톨로지를 어떻게 구축하나요
공장 데이터 온톨로지는 모델링 도구보다 공장이 실제로 묻는 질문 목록에서 시작합니다. 질문에 나오지 않는 대상과 관계는 만들어도 쓰이지 않고, 질문에 나오는 대상의 이름이 정리되지 않으면 그래프가 중간에 끊깁니다. 아래 5단계로 진행합니다.
단계 | 정할 것 | 빠지면 생기는 일 |
|---|---|---|
1 질문 목록 | 자주 묻는 질문 20개 | 안 쓰이는 관계가 쌓임 |
2 식별자 | 대상마다 번호 하나 | 같은 설비가 4개로 |
3 관계와 방향 | 관계 이름·방향 | 같은 뜻 관계가 중복 |
4 시간 규칙 | 계획·사건·기준 구분 | 과거 판정을 재현 못 함 |
5 생성 시점 | 저장할 때 함께 생성 | 만들 때마다 다른 그래프 |
가장 오래 걸리는 단계는 2번입니다. 같은 설비가 시스템마다 다른 번호로 등록돼 있으면, 온톨로지는 서로 다른 설비로 봅니다. 설비 한 대가 ERP·MES·설비보전·에너지 시스템에 각각 다른 번호로 올라 있으면 온톨로지에는 설비가 넷으로 남습니다. 나중에 합치려면 어느 번호가 같은 실물인지 아는 사람이 하나씩 짝지어 줘야 합니다. 시스템마다 다른 코드를 맞추는 순서는 MES·ERP·WMS·QMS·PLM 역할과 도입 순서, 공장은 어느 시스템부터 도입하고 데이터는 어떻게 맞추나 글의 「어느 시스템부터 도입하나요」 절에 적었습니다.

5번은 환각과 직접 닿아 있습니다. 문서에서 언어 모델로 개체와 관계를 뽑아 그래프를 만들면 같은 입력에서도 실행마다 다른 그래프가 나올 수 있고, 원문에 없는 관계가 생기기도 합니다. 공장 데이터는 대부분 이미 데이터베이스에 표와 관계로 정리돼 있으므로, 거래 한 건이 저장되는 순간 정해 둔 규칙으로 그래프도 함께 만들면 같은 데이터에서 언제나 같은 그래프가 나옵니다. 이 방식은 같은 데이터로 지식그래프를 두 번 만들면, 다른 그래프가 나옵니다에 자세히 적었습니다.
공장은 AI 답을 현장에서 쓰기 전에 무엇을 확인하나요
구조를 갖춘 뒤에도 운영 규칙이 있어야 환각이 현장 결정으로 넘어가지 않습니다. 확인할 것은 4가지입니다.
답마다 근거가 붙는가 — 어느 기록의 어느 값에서 나온 답인지 화면에서 바로 열어 볼 수 있어야 합니다. 근거가 없는 숫자는 쓰지 않습니다.
질의를 AI가 자유롭게 만드는가 — 자연어를 그래프 질의로 바꾸는 일을 모델에게 다 맡기면 문법은 맞고 의미는 다른 질의가 나옵니다. 검증된 질의 틀을 만들어 두고 모델은 틀과 값만 고르게 하면 조용한 오답이 줄어듭니다.
AI가 보류할 수 있는가 — 확신이 기준에 못 미치는 답은 사람에게 넘기는 출구가 있어야 합니다. 보류가 없는 AI는 처음 보는 경우에도 아는 답 하나를 고릅니다.
검증을 AI 밖에서 하는가 — 여러 AI가 같은 답을 냈다는 것은 그 답이 맞다는 근거가 되지 않습니다. 같은 계열의 모델은 같은 방향으로 틀리기 쉽습니다. 검증은 실측 데이터와 대조하고 사람이 승인하는 일입니다.
검증을 시스템 밖에 두는 이유는 에이전트 스무 개가 만장일치로 틀리는 법 — 합의는 검증이 아니다에 적었습니다.
공장은 AI에게 공장 데이터를 맡기기 전에 5가지를 확인합니다
확인할 것 | 확인하는 방법 | 「아니오」면 먼저 할 일 |
|---|---|---|
대상마다 번호가 하나인가 | 시스템별 코드 대조 | 코드 대응표 정리 |
자주 묻는 질문이 있는가 | 질문 20개 목록 | 현장 질문 모으기 |
관계에 방향이 있는가 | 관계 목록 검토 | 관계 이름·방향 정리 |
답에 근거가 붙는가 | 답 하나 골라 추적 | 근거 표시 요구 |
보류 기준이 있는가 | 보류 비율 확인 | 사람 확인 단계 추가 |
다섯 가지 가운데 첫째와 둘째는 AI를 고르기 전에 공장이 스스로 할 수 있는 일입니다. 번호가 하나로 정리되고 질문 목록이 있으면, 어떤 AI를 쓰든 그 AI가 맞았는지 같은 질문으로 확인할 수 있습니다. 기록부터 시작하는 전체 순서는 제조 AI 도입 순서, 중소 제조기업은 무엇부터 기록하고 투자 회수는 어떻게 계산하나에 있습니다.
VEXPLOR는 온톨로지와 그래프 검색을 한 구조로 설계했습니다
웨이스는 VEXPLOR에 AI를 얹기 전에 데이터 구조와 관계를 먼저 표준으로 정하는 방식을 택했습니다. VEXPLOR는 솔루션 사이의 관계를 관계 타입 22종과 사전 정의 관계 456건으로 설계해 두었고, AI는 그래프·벡터·SQL·문서 4가지를 동시에 검색하고 여러 단계를 건너는 추론을 더한 5가지 검색의 결과가 서로 일치하는지 보도록 설계했습니다. 여러 검색이 같은 답을 내도 그것을 검증으로 보지 않고, 현장 결정 전 확인은 실측 데이터 대조와 사람 승인으로 합니다. 거래가 저장되는 순간 정해 둔 규칙으로 지식그래프를 함께 만드는 방식은 웨이스의 등록 특허 제10-3003470호(태그 기반 메타모델을 이용한 실시간 그래프 검색 증강 생성 시스템, 2026년 8월 등록)에 담겨 있습니다. 웨이스는 중소벤처기업부의 2026년 제조데이터 표준화 참조모델 개발기관으로 선정돼 컨소시엄 주관으로 수행하고 있습니다.

제조 AI 환각은 모델 하나로 막히지 않습니다. 공장 데이터의 이름과 관계를 온톨로지로 정하고, 그 약속대로 연결된 지식그래프에서 근거를 찾고, 근거 없는 답은 보류하게 할 때 줄어듭니다. 그 출발점은 공장이 실제로 묻는 질문 목록과 대상마다 하나로 정리된 번호입니다.
WACE(웨이스)는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만드는 회사다.
함께 읽어보세요
이 글이 도움이 되셨다면 공유해 주세요
태그
작성자
새 글이 올라오면 메일로 알려드립니다
제조 현장에서 확인한 것들을 기록합니다. 새 글이 올라오면 보내 드리고, 언제든 해지할 수 있습니다.
우리 공장은 지금 어느 단계일까요?
제조 AI 성숙도 자가진단 — 회사 정보 없이 10문항이면 됩니다.
이 문제를 실제 현장에서 풀고 있습니다
표준 테이블과 온톨로지 관계 위에 시스템을 올리는 이유를 정리해 두었습니다.


