지식그래프 설계 · 4/10
새 환경에서 서로 다른 입력을 빌드해 보자 트리플 수가 품질을 거의 설명하지 못한다는 사실이 분명해졌습니다. 커머스 CSV 그래프는 25만 개가 넘는 트리플을 만들었지만 대부분이 사실 테이블의 행과 반복 관계였습니다. 반면 문서 그래프는 1천 개도 되지 않는 트리플로 핵심 정책과 관련 원문을 표현했습니다. 두 데이터셋의 우열을 비교한 수치가 아니라, 데이터 형태가 다르면 트리플 수를 공통 품질 점수로 쓸 수 없다는 반례였습니다.
빌드가 완료됐다는 상태도 품질 보증은 아니었습니다. 클래스가 관계 없이 평평하게 남을 수 있고, 출처가 끊길 수 있으며, 그래프에 필요한 구조가 있어도 검색이 가져오지 못할 수 있습니다. 정답률 하나만 보면 지식이 없어서 틀렸는지, 검색이 실패했는지, 근거를 찾고도 답변에서 빠뜨렸는지가 섞입니다.
그래프를 얼마나 많이 만들었는지가 아니라 어느 경계에서 품질이 달라졌는지 알아야 후처리와 검색을 고칠 수 있었습니다. 그래서 적재량, 구조 무결성, 출처, 검색, 답변을 분리해 측정하기 시작했습니다.
빌드, 검색, 답변은 서로 다른 실패를 만듭니다
질문 하나가 시스템을 통과하는 흐름은 세 단계로 볼 수 있습니다.
빌드: 답에 필요한 개념과 관계가 저장됐는가
검색: 질문에 맞는 구조와 원문을 가져왔는가
답변: 가져온 근거로 요구한 형식과 범위를 충족했는가
빌드 단계에서는 클래스와 인스턴스 수보다 구조를 봅니다. 존재하지 않는 URI를 가리키는 관계가 없는지, 속성의 도메인과 레인지가 유효한지, 개념과 관계가 원문 출처로 이어지는지 확인합니다.
검색 단계에서는 실제로 어떤 도구가 호출됐는지 봅니다. 그래프 검색 옵션이 켜져 있다는 설정만으로는 부족합니다. 대상 그래프에 데이터가 있고, 질의가 실행됐으며, 결과가 최종 합성 입력까지 도달해야 그래프 검색을 사용한 실행입니다.
답변 단계에서는 정확성, 완전성, 근거성을 나눕니다. “해당 상품을 모두 알려 달라”는 질문에서 일부 상품만 맞게 답했다면 정확한 항목은 있어도 완전한 답은 아닙니다. 인용 표시가 있더라도 원문 식별자로 다시 조회할 수 없다면 근거가 연결됐다고 보기 어렵습니다.
예를 들어 “모든 상품을 알려 달라”는 질문이 틀렸다면 순서대로 확인합니다. 먼저 빌드 결과에 전체 상품 집합이 있는지 봅니다. 집합이 있다면 검색 기록에서 그래프 조회가 실제로 호출되고 전체 후보가 합성기로 갔는지 확인합니다. 여기까지 정상이라면 마지막으로 답변 모델이 출력 예산 때문에 목록을 잘랐는지 봅니다. 같은 오답도 고칠 위치는 세 군데로 나뉩니다.
출처 지표의 범위도 구분했습니다. 현재 sourceChunk는 클래스·인스턴스와 관계의 주어 노드 수준에 연결되므로 관련 원문으로 돌아갈 수는 있지만, 관계 트리플 하나의 근거를 직접 증명하지는 않습니다. 관계 단위 grounding은 별도 provenance 모델이 필요합니다.
같은 입력을 새 그래프에서 다시 확인했습니다
기존 그래프만 보면 현재 구조가 원래 의도인지 누적된 결과인지 구분하기 어렵습니다. 성격이 다른 문서형, 금융형, 정형 커머스형 컬렉션을 새로 빌드하고 같은 구조 감사를 적용했습니다.
문서형 데이터에서는 클래스가 많아도 상하위 관계가 거의 없는 평면 구조가 나타났습니다. 정형 데이터에서는 반대로 모든 행과 외래키 관계를 충실히 옮기면서 개체와 관계가 지나치게 커졌습니다. 두 그래프는 트리플 수만 보면 모두 풍부했지만, 문제의 방향은 정반대였습니다.
이 비교로 “노드가 많다”를 하나의 문제로 다루지 않게 됐습니다. 문서형 그래프에는 관계와 출처의 완전성이 필요했고, 정형 그래프에는 어떤 행을 그래프 개체로 남길지 모델링 기준이 필요했습니다.
다음 비교를 시작하며 실행 계약을 고정했습니다
이 구조 감사에서 드러난 실패를 바탕으로 6월 A/B를 시작할 때 무엇을 같은 실행으로 볼지 정의했습니다. 질문과 최종 답변만 저장하면 그래프 검색이 실제로 실행됐는지, 벡터 폴백으로 답이 만들어졌는지 구분할 수 없기 때문입니다.
대상 컬렉션과 그래프 식별자, 준비된 색인, 호출한 도구, 검색 결과 수, 시간 초과 상태, 합성에 전달된 근거 항목을 한 실행의 기록 단위로 잡았습니다. 그래프 옵션이 켜져 있다는 설정은 실제 그래프 사용의 증거로 보지 않았습니다.
검색과 합성의 시간 예산, 전달할 근거 수와 길이도 비교 조건에 포함했습니다. 한쪽 검색기가 더 많은 시간과 컨텍스트를 사용하면 점수 차이에 검색 구조 외의 변수가 섞입니다. 이 계약을 실제 질문 세트에 적용한 결과는 6편에서 다룹니다.
품질 지표는 다음 수정을 가리켜야 합니다
좋은 지표는 상태를 설명하는 데서 끝나지 않고 고칠 위치를 알려 줍니다.
- 필요한 관계가 저장되지 않았다면 추출과 모델링을 바꿉니다.
- 관계는 있지만 검색 결과에 없다면 색인과 질의 계획을 바꿉니다.
- 근거는 충분한데 목록이 잘렸다면 합성 입력과 출력 예산을 바꿉니다.
이 기준으로 정형 데이터의 대량 노드는 검색 튜닝 문제가 아니라 모델링 문제라는 결론을 내렸습니다. 사실 행 전체를 그래프에 복제하는 대신 스키마와 기준 개체를 남기고, 자동 정리도 입력 출처에 따라 제한해야 했습니다.
다음 편에서는 이 품질 기준을 정형 데이터에 적용합니다. 어떤 테이블은 개체로 남기고 어떤 테이블은 구조만 남길지, 그리고 자동 병합과 고아 삭제가 정상 구조를 지우지 않게 만드는 조건을 다룹니다.
이전 편 → 몇 시간 걸리는 온톨로지 빌드를 작업으로 다루기 다음 편 → CSV 행은 줄이고 정상 클래스는 지키는 방법