기업의 지식그래프를 구축할 때 생성형 LLM은 반드시 필요할까요? 문서를 넣는 단계에서 LLM을 걷어내고, 같은 문서에서 같은 그래프가 만들어지는지 해시로 검증했습니다. 그 과정에서 확인한 가능성과 한계, 그리고 결국 LLM을 어디에 남겨야 하는지를 정리합니다.
기업에서 지식그래프를 운영하려면 정확도 외에도 확인할 것이 있습니다
기업이 생성형 AI를 실제 업무에 적용하면서 사내 문서를 어떻게 AI가 이해할 수 있는 지식으로 만들 것인가가 중요한 문제가 됐습니다.
일반적인 RAG가 질문과 관련된 문서를 찾아주는 데 강점이 있다면, 지식그래프는 문서에 등장하는 개체와 개체 사이의 관계를 구조화합니다.
예를 들어 수많은 사내 규정과 업무 문서에서 특정 조직, 사람, 제도, 업무가 서로 어떤 관계를 갖는지 미리 구조화해두면 단순한 유사 문서 검색을 넘어 전체 문서를 대상으로 관계를 탐색하거나 집계하는 것이 가능해집니다.
하지만 기업 환경에서는 결과의 정확도만큼 중요한 문제가 있습니다.
같은 문서를 다시 처리했을 때 같은 결과가 나오는가?
그리고 금융·공공·제조처럼 데이터 통제가 중요한 환경이라면 한 가지 질문이 더 추가됩니다.
문서를 처리하는 과정에서 기업 데이터가 외부로 나가지 않았다는 것을 설명할 수 있는가?
이번 실험은 이 두 질문에서 시작했습니다.
지식그래프 빌드 파이프라인은 대체로 생성형 LLM을 전제합니다. 문서를 넣으면 모델이 개체와 관계를 읽어내고, 그 결과를 그래프로 옮기는 구조입니다. 저희 파이프라인도 그렇게 만들어져 있었습니다.
빼기로 한 이유는 비용이 아니었습니다. 문서당 추출 비용은 이미 충분히 내려왔고, 로컬 모델로 돌리면 더 내려갑니다. "LLM은 비싸다"만으로는 더 이상 설계를 정당화할 수 없습니다.
남은 이유는 두 가지였습니다. 하나는 매번 같은 결과가 나오는가입니다. 같은 문서를 같은 설정으로 두 번 넣었을 때 같은 그래프가 나온다고 생성 모델이 약속해주지는 않습니다. 그래프가 조금씩 달라지면 어제와 다른 답이 나왔을 때 무엇 때문인지 짚기 어려워집니다.
다른 하나는 문서가 밖으로 안 나갔다는 걸 보여줄 수 있는가입니다. 규제가 있는 곳에서는 이걸 성능보다 먼저 묻는 경우가 많습니다.
LLM-free는 model-free가 아닙니다
먼저 하나 짚고 가겠습니다. 저희가 뺀 것은 문서를 넣을 때 생성형 LLM을 부르는 부분입니다. 모델을 전부 뺀 것은 아닙니다.
파이프라인에는 여전히 모델이 돌아갑니다. 형태소 분석기(Kiwi), 개체 이름을 찾는 인코더, 관계를 분류하는 인코더가 사내 장비에서 실행됩니다. 밖으로 나가는 호출은 없지만, 학습된 모델인 것은 맞습니다.
빌드 파이프라인
├─ 형태소 분석 Kiwi 로컬
├─ 개체명 인식(NER) 인코더 모델 로컬
├─ 관계 분류 인코더 모델 로컬
├─ 계층 유도 결정적 규칙 로컬
└─ 생성형 LLM 호출 없음
"LLM 없이 만들었다"를 "모델 없이 만들었다"로 읽으시면 이 글의 나머지가 전부 어긋납니다.
저희가 얻은 것은 밖으로 나가는 호출이 없다는 점과 같은 것을 넣으면 같은 것이 나온다는 점이지, 학습된 모델을 사용하지 않았다는 뜻이 아닙니다.
기업 관점에서 보면 이 차이는 중요합니다. AI 기술을 사용하지 않는 것이 목표가 아니라, 어떤 처리를 내부에서 수행하고 어떤 부분에 생성형 LLM을 사용할 것인지 명확하게 구분할 수 있기 때문입니다.
두 번 빌드해서 해시를 맞춰봤습니다
재현성이 목표라면 재현성 자체를 재봐야 합니다. "결정적으로 만들었다"는 말은 확인하기 전까지 의도일 뿐입니다.
그래서 그래프를 여러 층위로 나눠 각각 해시를 뜨는 도구를 만들었습니다. 같은 문서를 같은 설정으로 다시 빌드하고 해시를 비교합니다.
빌드 1 ─┐
├─→ 해시 5종 비교 ─→ 전부 일치하면 결정성 유지
빌드 2 ─┘ 하나라도 다르면 원인 추적
연속으로 빌드했을 때 해시가 모두 같았습니다. 개체에 붙는 주소까지 매번 똑같이 만들어진다는 뜻입니다.
한 가지는 짚어둘 만합니다. 처음에 비교하던 항목에서 관계 일부가 빠져 있었습니다. 그 부분은 값이 달라져도 비교에 걸리지 않으니, 해시가 같다고 해서 전부 같다고 말할 수 없는 상태였습니다.
빠진 항목을 찾아 비교 대상에 넣고 나서야 지금 형태가 됐습니다. 무엇을 비교할지 정하는 일 자체가 한 번에 끝나지 않았습니다.
지금은 이 해시 값들을 파일에 적어두고 기준값으로 씁니다. 파이프라인을 고칠 때마다 두 번 빌드해서 이 값과 대조하면, 고치려던 것 말고 무엇이 같이 움직였는지가 바로 드러납니다.
결과가 좋아지는 것보다 바뀐 것이 있으면 반드시 눈에 띈다는 쪽이 실제로 더 쓸모 있었습니다.
기업에서 운영되는 AI 시스템도 마찬가지입니다. 성능 개선뿐 아니라 변경 전후에 무엇이 달라졌는지 확인할 수 있는 구조가 있어야 업데이트와 장애의 원인을 추적할 수 있습니다.
생명보험업은 잡았지만 강아지는 못 잡았습니다
계층을 만드는 데는 한국어의 성질 하나를 썼습니다. 복합명사는 뒤쪽이 상위 개념이라는 것입니다.
생명보험업은 보험업으로 끝나니 생명보험업 ⊂ 보험업입니다.
단어의 끝을 비교하는 것만으로 판정되니 모델이 필요 없고, 왜 그렇게 묶었는지도 그대로 보입니다.
법령이나 규정처럼 복합명사가 많은 문서에서는 이 방법 하나로 계층이 꽤 나왔습니다. 처음에는 계층 추출이 잘 되고 있다고 봤습니다.
그런데 강아지 ⊂ 동물은 나오지 않았습니다. 두 단어에 겹치는 글자가 없기 때문입니다. 사과 ⊂ 과일도, 서울 ⊂ 도시도 마찬가지였습니다.
정확도가 떨어져서 놓친 것이 아니라, 이 방법으로는 볼 수조차 없는 종류였습니다.
생명보험업 ⊂ 보험업 끝이 겹침 → 판정됨
강아지 ⊂ 동물 겹침 없음 → 판정 자체가 불가
그러니까 이건 계층을 찾는 기능이 아니라 한 단어가 다른 단어로 끝나는지 보는 기능이었습니다.
법령 문서에서 성적이 좋았던 것도 방법이 뛰어나서가 아니라, 그런 문서가 상위 개념을 단어 끝에 드러내는 문체였기 때문입니다. 문체가 다른 문서로 옮기면 같은 성적이 나오지 않습니다.
글자가 겹치지 않는 계층을 잡으려고 채널을 하나 더 두고 있었습니다. "A는 B의 일종이다" 같은 정의문에서 상위 개념을 뽑는 방식입니다. 이쪽은 글자 겹침과 무관하니 강아지 ⊂ 동물에 닿을 수 있는 경로였습니다.
그래서 이 채널이 실제로 무엇을 만들어내고 있는지부터 셌습니다. 결과가 예상과 반대였습니다.
정의문 채널을 껐을 때 사라지는 계층 66건
├─ 거짓 54건 ← 전량 소멸
├─ 판단 불가 5건
└─ 참 4건
남는 계층 198건 중 의미 기반 3건은 전부 참
이 채널이 만들어낸 계층의 88.5%가 틀린 것이었습니다.
뉴스 문체에서 "A는 B이다" 형태가 계층이 아닌 문장에서도 계속 발화하고 있었습니다. 켜두면 맞는 것 몇 개를 얻는 대신 틀린 것을 훨씬 많이 얻는 구조였습니다.
그래서 이 채널을 기본값 꺼짐으로 바꿨습니다. 정의문이 실제로 계층을 뜻하는 백과사전 문체에서는 켤 수 있도록 선택 항목으로 남겼습니다.
이 조치로 잃은 참 계층은 2~3건이고, 의미 기반 계층의 오류율은 88.5%에서 0%가 됐습니다.
여기서 확인한 것은 모든 기업 문서에 동일한 지식 추출 방식을 적용할 수는 없다는 점입니다. 법령·규정처럼 일정한 문장 구조를 가진 문서와 뉴스·보고서처럼 자유로운 문장은 같은 규칙으로 처리했을 때 결과가 달라집니다.
지표가 좋아 보였을 때가 가장 위험했습니다
초기 프로토타입에서 검색 품질을 비교해봤습니다.
LLM으로 만든 그래프와 LLM 없이 만든 그래프를 각각 붙여놓고, 같은 질문들을 던져 점수를 냈습니다.
결과는 소수점까지 똑같았습니다.
처음에는 품질 손실 없이 LLM을 뺐다는 증거로 읽었습니다.
그런데 실험 조건을 다시 살펴보니, LLM 없이 만든 쪽은 개체 이름을 찾는 기능을 아예 꺼둔 상태였습니다. 그래프에 개체가 하나도 안 들어 있었다는 뜻입니다.
그런데도 개체가 가득 들어 있는 쪽과 점수가 같았습니다.
같은 점수가 나온 게 아니라, 애초에 그래프를 보고 매기는 점수가 아니었던 겁니다.
이 질문들의 답은 전부 벡터 검색이 찾아내고 있었습니다. 그래프를 어떻게 만들든 이 숫자는 꿈쩍도 안 했을 겁니다.
그래서 점수 하나로 전체를 판단하는 방식을 그만뒀습니다. 그래프가 하는 일이 여러 가지인데 점수는 하나뿐이니, 하나가 좋아지고 다른 하나가 나빠져도 숫자는 그대로일 수 있습니다.
그래서 하는 일을 나누고, 각각 따로 채점하기로 했습니다.
계층 상위-하위 관계가 맞는가
관계 누가 무엇을 했는지가 맞는가
동의어 같은 것을 같다고 묶는가
클래스 개념으로 쓸 만한 말인가
분류 개체를 옳은 종류에 넣는가
이렇게 나눠놓으니 하나가 좋아질 때 다른 하나가 나빠지는 것도 같이 보였습니다.
AI 시스템의 품질을 하나의 정확도나 검색 점수만으로 판단하기 어려운 이유도 여기에 있습니다. 실제 업무에서 AI가 수행해야 하는 역할을 나누고 각 역할에 맞는 지표를 확인해야 합니다.
전부 나열해보라고 하면 벡터는 답을 못 합니다
지표를 바꾸자 그래프가 실제로 기여하는 자리가 드러났습니다.
뉴스 기사 100건으로 만든 문서 묶음에서, 같은 시스템 프롬프트를 두고 검색 도구만 바꿔 비교했습니다.
한 기사 안에서 답이 나오는 질문은 양쪽이 같았습니다. 관계를 묻는 사실 질문 세 건 모두 두 쪽 다 만점이었습니다.
벡터로 충분한 질문은 벡터로 충분했고, 그래프를 붙여도 나아지는 것이 없었습니다.
차이는 문서 전체를 훑어야 하는 질문에서 났습니다.
"등장한 인물을 모두 나열하라"
벡터 → 검색을 반복하다 끝내 목록을 만들지 못함
그래프 → 총 178명이라는 개수와 이름 목록을 함께 제시
"뉴스에서 언급한 지역은 총 몇 군데인가"
벡터 → "전수 집계는 기술적으로 불가능하다"고 답변
그래프 → 142곳을 세어 전부 나열
벡터 검색은 질문할 때마다 상위 몇 건만 꺼내 봅니다. 전체를 세어야 하는 질문은 몇 건만 봐서 답할 수 있는 종류가 아닙니다.
반면 문서를 넣는 시점에 개체를 그래프로 만들어두면, 세는 일은 질문할 때 할 일이 아니게 됩니다.
여기서 갈리는 것은 검색을 잘하고 못하고가 아니라 정확한 답이 어디에서 나오느냐입니다.
개수와 명단이 맞는 이유는 검색을 잘해서가 아니라, 문서를 넣을 때 이미 세어둘 수 있게 정리해뒀기 때문입니다. 답을 만들 때 LLM이 하는 일은 찾아온 것을 문장으로 다듬는 정도입니다.
없는 사실을 지어낸 경우는 양쪽 다 없었습니다. 다만 이건 그래프 덕분이라기보다 프롬프트로 제약을 걸어둔 결과로 보는 편이 맞습니다.
이 실험은 기업에서 Vector RAG와 Knowledge Graph를 왜 함께 고려하는지를 보여줍니다.
지식그래프가 모든 검색을 더 잘하는 것은 아닙니다. 특정 문서에서 관련 내용을 찾는 업무라면 Vector Search만으로 충분할 수 있습니다.
반면 여러 문서에 흩어진 개체와 관계를 빠짐없이 파악하거나 전체 현황을 집계해야 한다면 그래프 구조가 다른 역할을 할 수 있습니다.
둘은 경쟁 관계라기보다 서로 다른 종류의 질문을 담당하는 구조에 가깝습니다.
넘지 못한 벽은 동의어였습니다
개체 통합은 끝내 기준을 통과하지 못했습니다.
형태소 기반 정규화는 삼성전자,와 삼성전자는을 같은 것으로 묶습니다. 조사와 활용을 걷어내는 일은 규칙으로 잘 됩니다.
하지만 금융위와 금융위원회, 취득과 획득, 뉴욕과 New York은 묶지 못합니다. 문자열이 다르고 의미가 같은 경우입니다.
임베딩 유사도로 풀어보려 했지만 여기서 원리적인 벽을 만났습니다.
인공지능 ~ 머신러닝 0.714 주제가 가까울 뿐, 같은 개념이 아님
전자상거래 ~ 이커머스 0.690 같은 개념
동의어 쌍이 단순히 주제가 가까운 쌍보다 낮은 점수를 받습니다.
코사인 유사도는 주제 근접성과 동의성을 분리하도록 만들어진 척도가 아니므로, 임계값을 어디에 두어도 한쪽을 포기해야 합니다.
판정 성능은 AUC 0.81 부근에서 천장을 쳤고, 기준을 완화해도 통과하지 못했습니다.
전통 사전으로 보완하려던 경로도 막혔습니다. 국내 어휘 자원 몇 곳의 도메인이 이미 죽어 있었고, 살아 있는 자원에는 현대 고유명사가 실려 있지 않았습니다.
그래서 동의어 묶기는 더 손대지 않기로 하고 마무리했습니다.
시간이 없어 미룬 것이 아닙니다. 글자로도 안 되고 임베딩으로도 안 되는데, 저희가 쓸 수 있는 방법이 그 둘뿐이었습니다.
금융위와 금융위원회가 같다는 것은 두 단어를 아무리 들여다봐도 나오지 않고, 그 기관이 무엇인지 알아야 나옵니다. 그건 지금 파이프라인에 없는 지식입니다.
그래서 이 부분은 못 한다고 적어두고 넘어갔습니다.
동의어를 반드시 묶어야 하는 곳에서는 사전을 직접 만들어 넣거나, 이 대목에만 LLM을 쓰는 편이 낫습니다.
LLM을 빼는 것이 아니라, 어디에 남길지를 정하는 문제였습니다
이 작업으로 확인한 것은 세 가지입니다.
첫째, 빌드에서 생성형 LLM을 빼니 재현성을 눈으로 확인할 수 있었습니다. 같은 문서를 넣으면 같은 그래프가 나오고, 그것을 해시로 대조해 보일 수 있습니다. 뭔가 바뀌면 반드시 눈에 띕니다. 문서가 외부로 나가지도 않습니다. 규제 산업에서는 이 두 가지가 성능과 별개로 요구되는 경우가 많습니다.
둘째, 규칙과 인코더가 닿는 범위에는 뚜렷한 선이 있습니다. 문서가 문장 구조로 드러낸 것은 잘 옮깁니다. 복합명사의 끝이 상위 개념을 알려주는 경우가 그 예입니다. 반대로 글자가 다르고 뜻이 같은 것은 이 방법으로 볼 수 없습니다. 동의어를 여기서 마무리한 이유가 그것입니다.
셋째, 그래프가 도움이 되는 자리는 좁고 분명합니다. 문서 하나 안에서 답이 나오는 질문은 벡터로 충분하고, 그래프를 붙여도 나아지지 않습니다. 전체를 세거나 빠짐없이 훑어야 하는 질문에서만 갈립니다. 그래프는 벡터를 대신하는 것이 아니라, 벡터가 원래 못 하는 종류의 질문을 맡습니다.
그래서 저희가 얻은 결론은 "LLM이 필요 없다"가 아닙니다.
LLM 없이 되는 일과 안 되는 일이 재보니 갈렸다는 것입니다.
되는 쪽을 규칙으로 처리해두면 그 부분은 매번 같은 결과가 나오고, 왜 그렇게 나왔는지도 설명할 수 있습니다.
LLM은 안 되는 쪽에만 쓰면 됩니다.
기업 AI 관점에서 우리가 얻은 것
이번 실험의 의미는 생성형 LLM을 제거했다는 데 있지 않습니다.
오히려 LLM이 잘하는 일과 반드시 LLM이 필요하지 않은 일을 분리할 수 있었다는 것에 있습니다.
기업의 AI 시스템은 모든 문제를 하나의 모델로 해결할 필요가 없습니다.
결과의 재현성과 변경 추적이 중요한 영역은 결정적인 규칙과 로컬 모델을 활용하고, 의미적 판단이 필요한 영역에서는 LLM을 선택적으로 사용할 수 있습니다. 관련 문서를 빠르게 찾는 업무에는 Vector Search를, 문서 전체의 개체와 관계를 구조적으로 탐색해야 하는 업무에는 Knowledge Graph를 활용할 수 있습니다.
중요한 것은 어떤 기술이 더 우수한가가 아니라 기업의 데이터와 업무 특성에 따라 각각의 기술을 어디에 배치할 것인가입니다.
이번 실험은 그 경계를 직접 확인해본 과정이었습니다.