문서는 많은데 '구조'가 없다는 문제
사내 문서로 RAG(검색 증강 생성) 챗봇을 만들어 봤다면 이런 경험이 있을 거예요. '이 계약서의 위약금 조항이 뭐야?' 같은 질문엔 꽤 잘 답해요. 그런데 'A 협력사와 맺은 계약 중에서 B 부품과 관련된 것들의 공통 리스크는?'처럼 여러 단계를 거쳐야 하는 질문엔 엉뚱한 답을 내놓죠. 벡터 검색은 '비슷한 문장'을 찾는 데는 강하지만, 개념과 개념 사이의 관계를 따라가는 데는 약하거든요.
NVIDIA가 깃허브에 공개한 auto-ontology는 이름 그대로 온톨로지를 자동으로 만들어주는 오픈소스 프로젝트예요. 온톨로지는 이 문제를 풀기 위한 출발점이고요. 온톨로지가 뭔지부터 시작해서, GPU 회사로 알려진 NVIDIA가 왜 이런 걸 내놓는지까지 하나씩 풀어볼게요.
온톨로지가 뭐냐면
온톨로지는 어떤 분야에 어떤 개념들이 있고, 그 개념들이 서로 어떤 관계인지를 정리한 설계도예요. 데이터베이스로 치면 테이블 스키마 같은 거죠. 의료 분야를 예로 들면 '질병', '증상', '약물'이라는 개념이 있어요. 그리고 '약물은 질병을 치료한다', '질병은 증상을 일으킨다' 같은 관계가 정의돼요.
자주 헷갈리는 게 지식 그래프와의 차이예요. 온톨로지는 '사람은 회사에 다닌다' 같은 규칙(스키마)이고, 지식 그래프는 '김철수는 A사에 다닌다' 같은 실제 데이터예요. 도서관으로 비유하면 온톨로지는 분류 체계이고, 지식 그래프는 그 체계에 따라 꽂혀 있는 실제 책들이에요.
왜 '자동'이 중요할까
2024년 마이크로소프트가 GraphRAG를 공개하면서, 문서를 그래프로 바꿔서 검색하는 방식이 RAG의 다음 단계로 떠올랐어요. 그런데 현장에서는 여기서 막혔어요. 좋은 그래프를 만들려면 좋은 온톨로지가 먼저 있어야 하는데, 온톨로지를 만드는 데 비용이 너무 많이 들거든요. 보통은 도메인 전문가와 온톨로지 엔지니어가 몇 달씩 붙어서 개념을 정의하고 관계를 다듬어야 했어요. 그렇다고 스키마 없이 LLM에게 '알아서 엔티티랑 관계 뽑아줘'라고 하면 문제가 생겨요. 같은 개념이 '고객', '클라이언트', '거래처'로 제각각 쪼개진 지저분한 그래프가 나오거든요.
온톨로지 자동 생성 도구는 대체로 이런 순서로 동작해요.
1. 문서를 적당한 크기로 나눠요.
2. LLM으로 문서에 나오는 개념과 관계 후보를 뽑아요.
3. 임베딩 유사도 같은 걸로 동의어와 중복을 합쳐요.
4. 상위·하위 개념 계층을 정리해요.
5. OWL이나 RDF 같은 표준 형식, 또는 그래프 DB 스키마로 내보내요.
auto-ontology도 이 과정을 자동화해서, 사람이 백지에서 시작하지 않아도 되게 만드는 데 초점을 둔 프로젝트로 보여요.
업계 흐름 속에서
이 분야엔 이미 여러 도구가 있어요. 마이크로소프트 GraphRAG는 문서에서 그래프를 만들고 커뮤니티 단위로 요약하는 데 강해요. Neo4j의 LLM Graph Builder는 그래프 DB와 잘 연결된다는 게 장점이고요. LangChain이나 LlamaIndex에도 LLM으로 그래프를 뽑아내는 모듈이 들어 있어요. 그런데 이 도구들은 대부분 '그래프 만들기'에 집중해요. 그 앞 단계인 '스키마 설계'는 사용자에게 맡기는 경우가 많아요. 온톨로지 자체를 자동화하는 건 바로 이 빈 곳을 채우는 시도예요.
NVIDIA 입장에서도 이해가 되는 행보예요. NVIDIA는 cuGraph 같은 GPU 가속 그래프 분석 라이브러리와 NIM 같은 추론 마이크로서비스를 꾸준히 내놓았어요. 그러면서 'GPU를 파는 회사'에서 '엔터프라이즈 AI 파이프라인 전체를 제공하는 회사'로 영역을 넓혀 왔죠. 지식 그래프 구축은 LLM 호출과 대규모 연산이 많이 필요한 작업이에요. 그러니 이 생태계를 키우는 게 곧 자기 플랫폼을 키우는 일이기도 해요.
한국 개발자에게는
사내 규정집, 제품 매뉴얼, 계약서처럼 관계가 복잡한 문서로 RAG를 운영하면서 정확도에 한계를 느끼고 있다면 한번 살펴볼 만해요. 금융, 제조, 공공처럼 용어 체계가 중요한 분야라면 효과가 더 클 수 있어요.
한국어 문서에 쓸 때는 주의할 점이 있어요. 한국어는 같은 개념을 한자어, 외래어, 줄임말로 다양하게 부르는 경우가 많아요. '고객사', '클라이언트', '거래처'처럼요. 그래서 동의어를 합치는 단계의 품질이 결과를 크게 좌우해요. 그리고 자동으로 나온 온톨로지는 어디까지나 잘 만든 초안으로 봐야 해요. 손으로 처음부터 만드는 것보다 훨씬 빠르지만, 검토 없이 쓰면 잘못된 관계가 그대로 답변에 섞여 나올 수 있어요. 도메인 담당자가 검토하는 단계를 꼭 넣는 게 좋아요.
마무리
한 줄 정리: GraphRAG를 도입할 때 진짜 병목은 '스키마 설계'였고, auto-ontology는 그 병목을 자동화하려는 시도예요.
여러분 팀의 RAG는 벡터 검색만으로 충분한가요, 아니면 관계를 따라가야 하는 질문에서 막히고 있나요? 그래프 기반 접근을 도입해 보셨다면 경험담도 들려주세요.
🔗 출처: Hacker News