빌드가 안정적으로 끝나게 만든 다음, 좋은 그래프인지 재보려고 했습니다. 손에 있던 숫자는 트리플 수였습니다. 커머스 CSV는 25만 개가 넘게 나왔고 문서 컬렉션은 1천 개가 안 됐습니다. 둘 다 문제가 있었는데 문제의 방향이 정반대였습니다. 하나의 숫자로 볼 수 없다는 것을 확인하고 품질을 다섯 경계로 나눈 과정입니다.
같은 파이프라인이 25만 개와 1천 개를 만들었습니다
새 환경에서 성격이 다른 입력을 각각 빌드해봤습니다.
커머스 CSV 그래프는 25만 개가 넘는 트리플을 만들었습니다. 대부분이 사실 테이블의 행과 반복되는 관계였습니다.
문서 그래프는 1천 개도 되지 않는 트리플로 핵심 정책과 관련 원문을 표현했습니다.
두 데이터셋의 우열을 비교한 것이 아닙니다. 데이터 형태가 다르면 트리플 수를 공통 품질 점수로 쓸 수 없다는 반례였습니다.
빌드가 완료됐다는 상태도 품질 보증이 아니었습니다. 클래스가 관계 없이 평평하게 남을 수 있고, 출처가 끊길 수 있으며, 그래프에 필요한 구조가 있어도 검색이 가져오지 못할 수 있습니다.
정답률 하나만 보면 지식이 없어서 틀렸는지, 검색이 실패했는지, 근거를 찾고도 답변에서 빠뜨렸는지가 전부 섞입니다.
그래프를 얼마나 많이 만들었는지가 아니라 어느 경계에서 품질이 달라졌는지 알아야 후처리와 검색을 고칠 수 있었습니다.
같은 오답도 고칠 자리가 세 군데였습니다
질문 하나가 시스템을 통과하는 흐름을 세 단계로 나눴습니다.
빌드 답에 필요한 개념과 관계가 저장됐는가
검색 질문에 맞는 구조와 원문을 가져왔는가
답변 가져온 근거로 요구한 형식과 범위를 충족했는가
"모든 상품을 알려 달라"는 질문이 틀렸다고 해봅시다. 순서대로 확인합니다.
먼저 빌드 결과에 전체 상품 집합이 있는지 봅니다. 집합이 있다면 검색 기록에서 그래프 조회가 실제로 호출되고 전체 후보가 합성기까지 갔는지 봅니다. 거기까지 정상이라면 답변 모델이 출력 예산 때문에 목록을 잘랐는지 봅니다.
같은 오답인데 고칠 위치가 셋입니다. 정답률 하나만 보면 그 셋을 구분할 수 없고, 구분하지 못하면 다음 작업을 정할 수 없습니다.
단계마다 봐야 할 것도 달랐습니다. 빌드에서는 클래스와 인스턴스 수보다 구조를 봅니다. 존재하지 않는 식별자를 가리키는 관계가 없는지, 속성의 도메인과 레인지가 유효한지, 개념과 관계가 원문 출처로 이어지는지입니다.
답변에서는 정확성과 완전성과 근거성을 나눕니다. "해당 상품을 모두 알려 달라"에서 일부만 맞게 답했다면 정확한 항목은 있어도 완전한 답은 아닙니다. 인용 표시가 있어도 원문 식별자로 다시 조회할 수 없다면 근거가 연결됐다고 보기 어렵습니다.
품질 지표를 하나로 합치고 싶은 이유는 대체로 보고하기 쉬워서입니다. 그 하나가 나빠졌을 때 어디를 볼지 알려주지 않는다면, 보고에는 쓰이고 개선에는 쓰이지 않습니다.
옵션이 켜져 있는 것을 그래프를 쓴 증거로 보고 있었습니다
검색 단계를 재려다 걸린 것이 하나 있습니다.
당시 저희는 그래프 검색 옵션이 켜져 있으면 그 실행을 그래프 검색으로 분류하고 있었습니다.
설정은 의도이지 증거가 아닙니다. 대상 그래프에 데이터가 있고, 질의가 실제로 실행됐고, 그 결과가 최종 합성 입력까지 도달해야 그래프를 사용한 실행입니다.
이 셋 중 어디서든 끊길 수 있고, 끊겨도 답은 나옵니다. 벡터 검색이 대신 답을 만들기 때문입니다. 이 문제가 실제로 어떤 모습이었는지는 6편에서 그대로 드러납니다.
그래서 6월 비교를 시작하면서 무엇을 같은 실행으로 볼지 먼저 정의했습니다.
한 실행의 기록 단위
대상 컬렉션 · 그래프 식별자 · 준비된 색인
호출한 도구 · 검색 결과 수 · 시간 초과 상태
합성에 전달된 근거 항목
검색과 합성의 시간 예산, 전달할 근거 수와 길이도 비교 조건에 넣었습니다. 한쪽 검색기가 더 많은 시간과 컨텍스트를 쓰면 점수 차이에 검색 구조 외의 변수가 섞입니다.
기능이 켜졌는지를 사용 여부로 기록하는 계측은 흔합니다. 켜진 것과 쓰인 것과 결과에 반영된 것이 각각 다른 사건이라는 점을 계측 설계에 넣어두지 않으면, 나중에 그 데이터로는 아무것도 판정할 수 없습니다.
노드가 많다는 같은 증상이 정반대 문제였습니다
기존 그래프만 보면 현재 구조가 원래 의도인지 누적된 결과인지 구분하기 어렵습니다. 그래서 성격이 다른 문서형, 금융형, 정형 커머스형 컬렉션을 새로 빌드하고 같은 구조 감사를 적용했습니다.
문서형에서는 클래스가 많은데 상하위 관계가 거의 없는 평면 구조가 나왔습니다. 정형에서는 반대로 모든 행과 외래키 관계를 충실히 옮기면서 개체와 관계가 지나치게 커졌습니다.
문서형 클래스는 많은데 관계가 없다 → 관계와 출처의 완전성이 부족
정형 행과 관계를 전부 충실히 옮겼다 → 무엇을 개체로 남길지 기준이 없음
트리플 수만 보면 둘 다 풍부합니다. 필요한 처방은 정반대였습니다.
이 비교 덕분에 "노드가 많다"를 하나의 문제로 다루지 않게 됐습니다. 문서형 그래프에는 관계와 출처를 채우는 작업이 필요했고, 정형 그래프에는 어떤 행을 개체로 남길지 정하는 모델링이 필요했습니다.
증상이 같아 보이는 두 시스템에 같은 처방을 내리기 전에, 그 증상이 어느 경계에서 만들어졌는지 먼저 보는 편이 안전합니다.
출처가 연결됐다는 말의 범위도 좁혔습니다
출처 지표에도 경계를 다시 그었습니다.
현재 출처 청크는 클래스와 인스턴스, 그리고 관계의 주어 노드 수준에 연결됩니다. 관련 원문으로 돌아갈 수는 있지만 관계 트리플 하나의 근거를 직접 증명하지는 못합니다.
1편에서 이 모델을 만들 때 이미 적어둔 한계인데, 지표로 만들면서 다시 확인해야 했습니다. 출처 연결률이라는 숫자가 관계 단위 근거까지 보장하는 것처럼 읽히면 안 되기 때문입니다.
관계 단위 근거가 필요하면 별도 provenance 모델이 필요합니다. 지금 숫자가 보장하는 범위를 지표 이름 옆에 적어두는 편이 낫습니다.
좋은 지표는 다음에 무엇을 고칠지 가리킵니다
이 편에서 정리한 기준을 한 줄로 줄이면 이렇습니다. 지표는 상태를 설명하는 데서 끝나지 않고 고칠 위치를 알려줘야 합니다.
필요한 관계가 저장되지 않았다 → 추출과 모델링을 바꾼다
관계는 있는데 검색 결과에 없다 → 색인과 질의 계획을 바꾼다
근거는 충분한데 목록이 잘렸다 → 합성 입력과 출력 예산을 바꾼다
이 기준으로 정형 데이터의 대량 노드는 검색 튜닝 문제가 아니라 모델링 문제라는 결론이 나왔습니다. 사실 행 전체를 그래프에 복제하는 대신 스키마와 기준 개체를 남기고, 자동 정리도 입력 출처에 따라 제한해야 했습니다.
다음 편에서 그 결론을 정형 데이터에 적용합니다. 그런데 그래프를 줄이는 작업에서 저희는 반대 방향의 사고를 냈습니다. 정리하려다 정상 클래스를 대량으로 지웠습니다.