지식그래프 설계 · 1/10
초기 온톨로지 빌드는 역량 질문(Competency Question)을 필수 입력으로 받았습니다. 여기서 온톨로지는 업무 개념의 클래스·속성·관계와 실제 인스턴스를 함께 표현하는 지식 구조를 뜻합니다. “무료 배송 조건은 무엇인가” 같은 질문을 먼저 정하고, 답에 필요한 개념과 관계를 찾는 방식입니다. 질문 목록이 업무 범위를 충분히 덮는 동안에는 결과가 목표와 잘 맞아 보였습니다.
문서가 늘어나자 질문 목록이 평가 기준을 넘어 지식의 발견 범위까지 결정했습니다. 배송과 반품을 묻는 질문만 있으면 원문에 적힌 판매자 귀책, 환불 책임, 예외 승인 절차는 그래프에서 빠질 수 있었습니다. 질문을 자동 생성하도록 바꾼 뒤에도 한계는 같았습니다. 질문 생성 단계에서 놓친 내용은 뒤 단계에서 복구할 수 없었습니다.
3월 말 빌드 파이프라인을 다시 만들며 책임을 바꿨습니다. 원문이 클래스, 인스턴스, 관계, 속성의 발견 범위를 정하고, 질문은 완성된 그래프가 실제 요구를 충족하는지 평가하는 데 사용했습니다. 클래스와 인스턴스를 sourceChunk로 원문에 연결하고, 관계를 추출한 청크도 현재는 주어 노드의 출처 목록에 합쳤습니다. 질문에 포함되지 않은 지식도 저장하되, 나중에 관련 원문으로 돌아갈 수 있게 한 것입니다.
질문은 요구사항이고 원문은 발견의 경계입니다
질문 중심 빌드에는 두 역할이 섞여 있었습니다.
- 어떤 지식을 찾을지 정하는 역할
- 만들어진 그래프가 쓸모 있는지 확인하는 역할
첫 번째 역할까지 질문에 맡기면 아직 모르는 내용을 발견하기 어렵습니다. 반면 두 번째 역할에는 질문이 적합합니다. 특정 질문에 필요한 개념과 관계가 그래프에 있는지, 검색이 그 구조를 실제로 사용했는지 확인할 수 있기 때문입니다.
빌드 입력은 원문으로 옮기고 질문은 평가 쪽에 남겼습니다. 이 구분으로 그래프가 답해야 할 문제는 유지하면서도, 그래프에 들어갈 지식을 미리 만든 질문 목록으로 제한하지 않게 됐습니다.
단계별 추출을 하나의 문서 해석으로 합쳤습니다
질문을 빌드에서 빼자 개념 추출, 개체명 인식, 관계 추출, 데이터 속성 추출을 각각 실행할 이유도 줄었습니다. 단계가 분리돼 있을 때는 앞 단계가 놓친 개념을 뒤 단계가 참조할 수 없었고, 같은 문장을 여러 번 읽는 비용도 컸습니다.
문서 청크 하나를 읽을 때 다음 결과를 함께 만들도록 추출 책임을 합쳤습니다.
문서 청크
├─ 클래스와 상하위 구조
├─ 인스턴스
├─ 인스턴스 간 관계
└─ 데이터 속성
이 구조에서는 관계가 어느 개념과 개체를 연결하는지 한 응답 안에서 맞출 수 있습니다. 추출 결과는 그래프 빌더가 RDF(주어·술어·목적어로 표현하는 그래프 형식)로 변환하고, 서로 다른 청크에서 나온 같은 개념은 후처리 단계에서 합칩니다. 질문은 더 이상 이 흐름의 필수 입력이 아닙니다.
출처를 그래프의 일부로 저장했습니다
문서 중심으로 바꾸면 한 가지 책임이 더 생깁니다. 그래프의 각 사실이 어느 원문에서 왔는지 되돌아갈 수 있어야 합니다.
클래스와 인스턴스에 sourceChunk를 연결했습니다. 관계를 추출한 청크는 관계 트리플 자체가 아니라 현재 그 관계의 주어 노드에 연결됩니다. 검색기는 노드의 출처 식별자로 관련 원문 청크를 다시 가져올 수 있습니다. 그래프는 연결 구조를 제공하고, 원문은 답변을 확인할 재료를 제공합니다.
그래프의 개념·관계 주어
↓ sourceChunk
원문 청크
↓
답변과 인용
중복 개념을 합칠 때도 노드의 출처 목록은 함께 합칩니다. URI만 하나로 만들고 먼저 처리한 청크의 출처만 남기면, 검색 결과는 맞아도 확인할 원문 범위가 줄어들기 때문입니다.
이 모델은 노드가 등장한 원문으로 돌아가는 데는 쓸 수 있지만, 어느 청크가 어느 술어를 직접 뒷받침하는지는 구분하지 못합니다. 관계 단위 근거가 필요하면 RDF-star, reification, named graph처럼 트리플 자체에 출처를 붙이는 별도 provenance 모델이 필요합니다.
빌드 성공과 질문 성공을 분리했습니다
새 파이프라인에서는 질문 정답성과 빌드 완료 상태를 분리했습니다. 입력, 추출, 스키마, RDF, 출처를 단계별 관측 대상으로 두고, 질문의 정답성은 동일한 그래프를 대상으로 별도 평가합니다. 현재 completed 상태가 모든 출처와 품질 검사를 통과했다는 뜻은 아니므로 warning과 품질 보고서를 함께 봐야 합니다.
이 분리는 실패 원인도 선명하게 만듭니다. 답에 필요한 관계가 그래프에 없으면 빌드 문제이고, 관계는 있지만 가져오지 못하면 검색 문제입니다. 근거까지 가져왔는데 답변에서 빠뜨렸다면 합성 문제입니다. 하나의 정답률로 세 계층을 섞지 않아도 됩니다.
문서 중심 빌드로 발견 범위는 넓어졌습니다. 하지만 그래프와 원문을 한 번 조회하는 것만으로 여러 단계의 관계를 따라갈 수 있는 것은 아닙니다. 다음 편에서는 한 번의 검색으로 끝내던 구조를 도구를 선택하며 탐색하는 멀티턴 검색으로 확장한 과정을 다룹니다.