# 지그재그 세미나 3회 - 12/12 장소: 그랑서울 타워2 15층 (서울 종로구 종로 33) 일시: 2025-12-12 오후 7시 # 진행 방식 1. 기술 세션과 토의 세션으로 구분하여 진행 1. 기술세션 주제 : AI에이전트와 지식표현 2. 토의세션 주제 : 온톨로지 기반 운영모델 ![Image](https://upload.cafenono.com/image/slashpageHome/20251202/131626_W0vo34H35jqDyYhPCa?q=80&s=1280x180&t=outside&f=webp) # 순서표 | 시간 | 내용 | 진행 | | | --- | --- | --- | --- | | 19:00 ~ 19:10 | 인사 및 소개 | | | | 19:10 ~ 19:30 | 오픈 소스로 구성하는 지식그래프 엔진 - 그 가능성에 대한 보고서 | 김정석 | [슬라이드 링크](https://docs.google.com/presentation/d/1gZ4BbJPLkQfeK04EKypld6_PF5uflMSpVDgf8mh2dmc/edit?usp=sharing) | | 19:30 ~ 19:50 | 대화형 검색에서 다양한 RAG기반 검색 방식 성능 비교 | 김수진 | soongtunes_공유용.pdf | | 19:50 ~ 20:00 | 휴식 | | | | 20:00 ~ 21:30 | 토의 - 온톨로지 기반 운영 모델 | | | # 내용 요약 ## 오픈 소스로 구성하는 지식그래프 엔진 --- 요약 발표자는 **지식 표현(온톨로지)**을 실제로 활용하려 했으나, 막상 바로 사용할 수 있는 엔진이나 기술이 거의 없다는 문제에 직면했고, 그 결과 직접 조사하고 프로토타입까지 제작한 과정을 공유하였다. 1. 문제 인식 - 온톨로지는 주목받고 있으나, 예산 없이 PoC를 수행할 수 있는 실용적 도구가 부족함 - 상용 솔루션은 초기 비용·절차 부담이 커서 배제하고, 오픈소스 중심으로 조사 진행 2. 온톨로지 저장소 조사 결과 - 레거시 / 표준 / 차세대 프로젝트로 분류 - 레거시 계열은 기술적으로 우수했으나 유지보수·최신 표준(SPARQL 1.1 등) 미지원 문제로 제외 Knowledge_Graphs_AI_Operating_System.pdf - 표준 계열(예: Apache Jena, Eclipse RDF4J)은 여전히 대체 불가하지만 Knowledge_Graphs_AI_Operating_System.pdf - Java 버전 의존성 - 메모리 사용량 - 로컬 PoC에 과도한 운영 부담이라는 한계 존재 - 차세대 후보 중 일부(예: Oxigraph)는 성능·라이선스·WASM 지원 등 장점이 있으나 - 메인테이너가 1인이라는 지속성 리스크 존재 3. 추론(Reasoning) 관점의 한계 - 기존 RDF 추론 엔진은 **증분 추론(incremental reasoning)**이 어려워 데이터 추가 시 전체 재계산이 필요한 구조적 문제 존재 - 이를 해결하기 위해 Datalog 기반 추론 엔진들이 등장 - 인메모리 고속 추론 - 신규 데이터에 대해서만 델타 추론 수행 - 온톨로지 + 벡터 DB 결합 시도 등 다양한 접근 확인 - 라이선스 검토 결과 상업적 사용에도 큰 제약은 없음 4. 중간 결론 - "엔진은 새로 만들 필요 없다. 쓸 만한 것은 이미 있다." - 그러나 가장 큰 공백은 '데이터 적재' 영역 - RDF/SPO 온톨로지는 받지만 PDF, 이미지, 이메일, 비정형·정형 파일을 어떻게 온톨로지로 변환할지에 대한 해법이 없음 5. 자체 프로토타이핑 - 이 공백을 해결하기 위해 비정형 데이터 → 온톨로지(SPO) 변환 파이프라인을 직접 구현 - 핵심 아이디어: - 이미지·텍스트 등 입력 데이터 타입 자동 판별 - OCR이 아닌 **"이미지를 설명하라"**는 방식으로 의미 추출 - 설명 결과를 중간 표현으로 삼아 온톨로지화 - 영수증, 생성형 이미지 등 다양한 사례에서 의미 있는 개체·관계가 온톨로지로 변환됨을 시연 6. 흥미로운 관찰 - LLM이 매번 동일하지 않은 온톨로지를 생성하지만 - → 온톨로지는 누적 구조이므로 오히려 정보 확장의 장점이 될 수 있음 7. 결과물 및 향후 계획 - Python 기반 프로토타입을 GitHub에 공개 - 빠른 실험을 위해 Python을 사용했으며, 아키텍처 확정 후 컴파일 언어로 재구현 예정 - 라이선스는 GPL + Commercial 이중 라이선스로 설정하여 커뮤니티 기여와 아이디어 환원을 유도 - 관심 있는 사람들의 컨트리뷰션을 요청하며 발표 마무리 --- ## 대화형 검색에서 다양한 RAG기반 검색 방식 성능 비교 > --- 요약 연구는 음악 검색·추천 RAG 시스템에서 그래프 기반 검색 방식들을 비교 평가하는 것이 목적이며, 특히 **대화 맥락(누적 조건)**을 얼마나 정확히 반영하는지가 핵심 쟁점이다. 1.배경: 기존 검색/추천의 한계 - 키워드 검색: 문자 매칭 중심이라 동의어/유의어 처리와 맥락 반영이 약하고, 정확한 곡명·아티스트명을 알아야 검색이 잘 됨. - 순수 벡터 검색: 의미 유사도 검색은 가능하지만 정보가 임베딩으로 "통합"되며, 아티스트/장르/조건을 구조적으로 제어하기 어렵고 조건이 많아질수록 추적이 힘듦. - 대화 길이(숏텀 메모리·질문 재작성): 대화가 길어지고 조건이 누적될수록 질문 재작성 과정에서 맥락 왜곡·조건 누락 위험이 커짐. 1. 연구 목표 - 단순 메모리 버퍼/질문 재작성 방식의 한계를 보완하기 위해, **구조화된 맥락 표현(그래프)**의 효과를 검증하고자 함. - 사용자 대화 흐름 속에서 의도와 누적 조건을 안정적으로 유지하는 검색·추천 방식을 구축하고 성능 비교. 2. 비교한 4가지 검색 방법 - (1) Contextual RAG(버추얼 노드 방식): 대화 맥락을 "가상 쿼리 노드"로 그래프에 저장하고, 누적 상태를 참조해 검색. - (2) Graph RAG: 그래프 구조 + 커뮤니티/연결 패턴(루뱅 알고리즘 기반 커뮤니티 등)을 활용한 검색/랭킹. - (3) Vector RAG: 임베딩 기반 벡터 검색. - (4) Keyword/Text-to-Cypher 기반: 자연어를 Cypher 쿼리로 변환해 조건 조합 검색(입력 불명확 시 실패 가능). 3. 시스템/데이터 구성 - 멜론 플레이리스트 데이터셋의 메타데이터를 활용해 음악 지식그래프 구축(노래-아티스트-앨범-장르(세부장르 포함)-태그(분위기 등)-플레이리스트 관계). - 모든 노드에 OpenAI 임베딩을 부여. - Graph RAG는 Neo4j 기능을 사용하고, 커뮤니티는 루뱅 알고리즘으로 생성. 4. 평가 설계 - 별도 정답 데이터가 없어 평가셋을 생성: - 인기곡 1,000곡을 샘플링 - 곡 메타데이터를 바탕으로 LLM이 자연어 질의·대화 시나리오를 생성 - 각 질의에 대한 기대 정답(곡 ID)을 그래프 쿼리로 생성해 정답 셋 구성 - 지표: MRR, nDCG, Recall, Precision, F1 등. - RAG 평가 라이브러리(예: RAGAS류)를 연동해 측정. 5. 결과 및 결론 - 버추얼 노드(맥락을 그래프에 구조화·영속 저장) 방식이 모든 지표에서 최고 성능. - Graph RAG는 기대보다 낮았는데, 커뮤니티 기반 확장 과정에서 사용자 조건과 무관한 곡이 섞일 가능성이 원인으로 해석. - 핵심 이점은 맥락의 구조화: 임베딩/질문 재작성 대신, 세션-조건-의도를 그래프로 남겨 복잡한 다중 조건(예: "이전 곡과 비슷하지만 빠른 템포, 2010년대")을 더 정확히 포착. 6. 향후 과제 - Graph RAG의 "다양성" 측면을 더 평가할 수 있도록 지표 확장. - 숏텀 메모리 누적을 **롱텀 메모리(사용자 프로필/취향)**로 확장. - 버추얼 쿼리 노드의 생명주기(세션 관리/만료/갱신) 설계 중요. --- ## 토론 내용 > --- 요약 1. 모임 목적과 오늘의 화두 - 지난달 "AI-Ready Data, 데이터웨어하우스/데이터레이크의 역할과 한계"를 논의하다가 온톨로지 기반 운영모델 주제로 확장되었고, 이를 오늘 공개 토의로 이어감. - 오늘의 큰 질문은 "에이전트 AI 시대(자동화 → 자율화)에서 온톨로지가 어떤 역할을 할 수 있는가", 더 구체히는 - "온톨로지는 지식표현 체계로서 운영모델/운영체제로 진화할 수 있는가". 2. "운영모델" 정의 정리 - 공학 관점: 데이터–모델(엔진)–애플리케이션의 3층 구조로 이해 가능. - 현업 관점: 문서화되지 않은 경험·노하우·해석이 발현되는 지점을 시스템화/정규화해 담는 체계를 운영모델로 인식. - 현실에서는 온톨로지/지식그래프/Graph RAG 등이 혼용되며, 개념 구분 자체가 높은 전문성을 요구한다는 공감대가 있음. 3. RDF/OWL로 "현실 비즈니스"를 충분히 표현할 수 있나? - 이론적으로 가능하더라도 현업에서의 핵심 병목은 '사람이 해야 하는 모델링 비용': - 심볼릭 AI가 과거 "예외 처리·지식 입력 비용" 때문에 벽을 겪었던 역사와 유사하다는 시각. - "사람이 전부 정의해야 하는데 도구/프로세스가 없다"는 문제 제기. - 추가 관점: 세상을 전부 표현하려는 전제가 위험할 수 있고(철학적 비유), 사람마다 의미 이해가 달라 공통 의미/언어 합의 자체가 난제라는 지적. - 대안적 합의: - 모든 데이터를 RDF로 만들 필요는 없고, "공리(axiom)/핵심 팩트" 수준은 RDF/OWL이, - 더 넓은 연결성/실무 유연성은 LPG(프로퍼티 그래프) 등 혼합이 현실적일 수 있음. - 결국 "문제(유스케이스)에 맞는 데이터/모델 적합성"이 선행되어야 한다는 결론으로 수렴. 4. 데이터는 '결과물'이 아니라 '트리거/브리지'인가? - 데이터는 단순 저장 대상이 아니라 **운영을 촉발(트리거)하거나 연결(브리지)**하는 매개가 될 수 있다는 논의. - 다만 트리거는 단독으로 의미가 없고, 관련 객체/관계 설계가 되어야 인사이트로 연결된다. - 의료 비유로, 사람은 "목적을 먼저 깔고" 데이터를 읽는다 → - 온톨로지화도 **목적성(무엇을 트리거로 삼고, 무엇을 하이라이트할지)**이 핵심이라는 정리. 5. 오픈월드/비단조 추론과 '운영체제화'의 난제 - 현실 세계는 예외가 많고(오픈월드), 온톨로지의 단조 추론만으로는 운영에서 생기는 충돌/변경/예외를 다루기 어렵다. - 컴퓨터 운영체제도 "오류 0"이 아니라 오류 허용/격리/우회 메커니즘으로 동작한다는 비유 제시. - 결론적으로: - "온톨로지/지식그래프만으로 운영을 완결"하기보다, - 어떤 데이터는 고정(팩트)으로 두고, **의사결정 경로/프로토콜(볼 순서·판단 로직)**을 조정하는 접근이 더 현실적일 수 있다는 관점이 나옴. - LLM은 온톨로지 결과가 부족해도 유사도 기반으로 보완 생성하는 등 "혼합 사용"이 오히려 실용적이라는 평가도 있음. 6. 자율화(Agentic AI)는 어디까지 가능하나 - "완전 자율(인간 개입 0)"은 비현실적이며 Human-in-the-loop는 필수라는 견해. - 반면 업무 단축/효율화 수준의 자율은 비교적 단기간(수년) 내 가능할 수 있음. - 그러나 "데이터는 그대로인데, 프레임 자체를 바꿔 재해석하는 수준의 자율(관점 전환)"은 더 먼 이야기. - 실제 기업 업무는 수천~수만 단위 태스크로 쪼개지고 협업·우선순위·스케줄링이 필요해, "운영체제처럼" 만들기엔 아직 갈 길이 멀다는 정리. 7. 마무리 - 충분히 결론을 내기보다는, 온톨로지 운영체제화 논의가 결국 "유스케이스 적합성, 모델링 비용, 검증, 예외 처리, 프로토콜/운영 메커니즘"으로 귀결된다는 점을 확인하고 토의를 종료. --- # 정리 영상 [Video](https://vz-127031db-d43.b-cdn.net/0dacc461-31e3-47df-91e0-519d27ddcd18/playlist.m3u8) Knowledge_Graphs_AI_Operating_System.pdf --- # 준비 > 토의 세션 # 주제 > 온톨로지 기반 운영 모델 온톨로지는 지식 표현 체계로서 운영모델 또는 운영체제로 진화할 수 있을까? ## 질문들 **온톨로지의 본질과 역할에 대한 질문** 1. RDF/OWL 기반 온톨로지가 현실 세계의 복잡한 비즈니스 운영을 충분히 표현할 수 있는가? 2. 온톨로지의 범위는 어디까지 확장 가능한가? (데이터 → 프로세스 → 행동 → 의사결정) **운영 모델/운영 체제와 온톨로지의 접점에 대한 질문** 1. 운영체제(Operating System)를 구성하는 핵심 요소는 무엇이며, 온톨로지는 그 요소들을 어떤 방식으로 대체할 수 있을까? 2. 온톨로지가 운영모델이 되는 순간, “데이터”는 어떤 형태로 역할이 변하는가? **자동화에서 자율화로의 전환 관점** “무엇을 할지 사람이 정하고, 어떻게 할지는 기계가 스스로 찾는다.” 1. 자동화와 자율화의 본질적 차이는 무엇이며, 온톨로지는 어느 지점에서 자율화를 가능하게 하는가? 2. 온톨로지는 계획(Planning)과 의사결정(Decision-making)이 가능한가? **기술적/ 조직적 관점의 질문** 1. 현실 시스템에 필요한 비단조 의사결정은 어떻게 처리가 가능할 것인가? 2. 온톨로지가 운영체제화될 때 조직의 역할 체계(업무 역할/자원 역할)는 어떻게 재편되는가? **마무리** 10년 후 기업 운영에서 온톨로지는 어떤 위치에 있을까? For the site tree, see the [root Markdown](https://slashpage.com/zigzag.md).