초기 온톨로지 빌드는 "무료 배송 조건은 무엇인가" 같은 역량 질문을 필수 입력으로 받았습니다. 질문을 먼저 정하고 답에 필요한 개념과 관계를 찾는 방식입니다. 문서가 늘자 그 질문 목록이 평가 기준을 넘어 무엇을 발견할지까지 정하고 있었습니다. 질문을 자동 생성하도록 바꿔봐도 같았습니다. 질문에 두 가지 역할이 섞여 있었다는 것을 확인하고 하나를 떼어낸 과정입니다.
질문이 좋은 동안에는 결과도 좋아 보였습니다
온톨로지는 업무 개념의 클래스와 속성, 관계, 그리고 실제 인스턴스를 함께 표현하는 지식 구조입니다.
초기 빌드는 역량 질문을 필수 입력으로 받았습니다. 답해야 할 질문을 먼저 정하고, 그 답에 필요한 개념과 관계를 원문에서 찾습니다.
질문 목록이 업무 범위를 충분히 덮는 동안에는 결과가 목표와 잘 맞았습니다. 물어본 것에 답하는 그래프가 나오니까요.
문서가 늘면서 어긋나기 시작했습니다. 배송과 반품을 묻는 질문만 있으면, 같은 원문에 적힌 판매자 귀책과 환불 책임, 예외 승인 절차는 그래프에 들어오지 않았습니다.
질문 목록이 평가 기준을 넘어 지식의 발견 범위까지 정하고 있었습니다.
질문을 자동 생성해도 병목은 같은 자리에 있었습니다
당시 저희가 먼저 시도한 것은 질문을 사람이 쓰지 않게 만드는 것이었습니다. 문서를 읽고 질문을 자동으로 만들면 목록이 넓어질 테니까요.
넓어지긴 했습니다. 그래도 한계는 그대로였습니다.
질문 생성 단계에서 놓친 내용은 뒤 단계에서 복구할 수 없습니다. 질문을 누가 쓰든 그 목록이 파이프라인의 첫 관문인 이상, 관문을 통과하지 못한 개념은 뒤에서 다시 나타나지 않습니다.
자동화한 것은 질문을 쓰는 노동이었고, 병목은 질문이 발견 범위를 결정한다는 구조 자체에 있었습니다.
여기까지 와서 질문이라는 입력을 다시 봤습니다. 질문 중심 빌드에는 두 역할이 섞여 있었습니다.
역할 1 어떤 지식을 찾을지 정한다 → 아직 모르는 것을 못 찾는다
역할 2 만든 그래프가 쓸모 있는지 본다 → 질문이 잘 맞는 일이다
첫 번째 역할까지 질문에 맡기면 모르는 것을 발견할 수 없습니다. 두 번째 역할에는 질문이 적합합니다. 특정 질문에 필요한 개념과 관계가 그래프에 있는지, 검색이 그 구조를 실제로 사용했는지 확인할 수 있으니까요.
3월 말 파이프라인을 다시 만들며 책임을 바꿨습니다. 빌드 입력은 원문으로 옮기고, 질문은 평가 쪽에 남겼습니다.
이 구분으로 그래프가 답해야 할 문제는 유지하면서도, 그래프에 들어갈 지식을 미리 만든 질문 목록으로 제한하지 않게 됐습니다.
자동화를 검토할 때 먼저 물어볼 것이 있습니다. 지금 자동화하려는 것이 병목인지, 아니면 병목 앞에 놓인 노동인지입니다. 둘은 자주 붙어 있어서 구분하지 않으면 노동만 줄이고 같은 벽을 다시 만납니다.
단계를 나눠뒀더니 뒤 단계가 앞 단계의 실수를 볼 수 없었습니다
질문을 빌드에서 빼자 다른 것도 같이 보였습니다.
당시 추출은 개념 추출, 개체명 인식, 관계 추출, 데이터 속성 추출을 각각 실행하는 구조였습니다. 단계를 나누면 각각을 개선하기 쉬울 것 같았습니다.
실제로는 앞 단계가 놓친 개념을 뒤 단계가 참조할 수 없었습니다. 개념 추출에서 빠진 것은 관계 추출에서 연결될 수 없습니다. 같은 문장을 여러 번 읽는 비용도 컸습니다.
질문이 첫 관문이었던 것과 같은 구조가 단계 사이에도 있었습니다. 앞이 놓치면 뒤가 복구하지 못합니다.
그래서 문서 청크 하나를 읽을 때 다음 결과를 함께 만들도록 추출 책임을 합쳤습니다.
문서 청크
├─ 클래스와 상하위 구조
├─ 인스턴스
├─ 인스턴스 간 관계
└─ 데이터 속성
이 구조에서는 관계가 어느 개념과 개체를 연결하는지 한 응답 안에서 맞출 수 있습니다. 추출 결과는 그래프 빌더가 RDF, 즉 주어와 술어와 목적어로 표현하는 그래프 형식으로 변환하고, 서로 다른 청크에서 나온 같은 개념은 후처리에서 합칩니다.
파이프라인을 잘게 나누는 것이 항상 좋은 것은 아니었습니다. 나눈 경계에서 정보가 떨어질 수 있다면, 그 경계는 개선 단위가 아니라 손실 지점입니다.
출처를 붙였지만 어느 청크가 어느 관계를 뒷받침하는지는 몰랐습니다
문서 중심으로 바꾸면 책임이 하나 더 생깁니다. 그래프의 각 사실이 어느 원문에서 왔는지 되돌아갈 수 있어야 합니다.
클래스와 인스턴스에 출처 청크를 연결했습니다. 검색기는 노드의 출처 식별자로 관련 원문 청크를 다시 가져올 수 있습니다.
그래프의 개념·관계 주어
↓ sourceChunk
원문 청크
↓
답변과 인용
중복 개념을 합칠 때도 출처 목록을 함께 합칩니다. 식별자만 하나로 만들고 먼저 처리한 청크의 출처만 남기면, 검색 결과는 맞아도 확인할 원문 범위가 줄어듭니다.
여기서 저희가 처음에 근거 추적이 됐다고 부른 것을 다시 봐야 했습니다.
관계를 추출한 청크는 관계 트리플 자체가 아니라 현재 그 관계의 주어 노드에 연결됩니다. 그러니까 이 모델로 할 수 있는 것은 노드가 등장한 원문으로 돌아가는 일이고, 어느 청크가 어느 술어를 직접 뒷받침하는지는 구분하지 못합니다.
관계 단위 근거가 필요하면 RDF-star나 reification, named graph처럼 트리플 자체에 출처를 붙이는 별도 provenance 모델이 필요합니다. 이 한계는 7편에서 화면의 근거 강조를 다룰 때 같은 모습으로 다시 나옵니다.
출처를 붙였다는 사실과 근거를 추적할 수 있다는 사실 사이에는 이런 간격이 자주 있습니다. 무엇에서 무엇으로 돌아갈 수 있는지를 한 문장으로 적어보면 그 간격이 보입니다.
빌드 성공과 질문 성공을 같은 숫자로 보지 않았습니다
새 파이프라인에서는 질문 정답성과 빌드 완료 상태를 분리했습니다.
입력, 추출, 스키마, RDF, 출처를 단계별 관측 대상으로 두고, 질문의 정답성은 같은 그래프를 대상으로 별도 평가합니다. 현재 완료 상태가 모든 출처와 품질 검사를 통과했다는 뜻은 아니므로 경고와 품질 보고서를 함께 봐야 합니다.
이 분리는 실패 원인도 선명하게 만듭니다.
답에 필요한 관계가 그래프에 없다 → 빌드 문제
관계는 있는데 가져오지 못했다 → 검색 문제
근거는 가져왔는데 답변에서 빠뜨렸다 → 합성 문제
하나의 정답률로 세 계층을 섞지 않아도 됩니다. 정답률이 떨어졌을 때 어디를 볼지가 그 숫자 안에 들어 있지 않으면, 그 숫자로는 다음 작업을 정할 수 없습니다.
질문을 뺀 것이 아니라 질문이 하던 두 일을 갈랐습니다
이 편에서 저희가 한 일을 "CQ를 제거했다"로 요약하면 절반만 맞습니다.
질문은 그대로 남아 있습니다. 자리가 바뀌었을 뿐입니다. 빌드의 입력이던 것이 평가의 기준이 됐습니다.
바꾼 것은 질문의 유무가 아니라 질문이 무엇을 결정하게 둘 것인가였습니다. 무엇을 찾을지는 원문이 정하고, 쓸모가 있는지는 질문이 봅니다.
과장하지 않고 말하면, 이 변경으로 확인한 것은 질문 목록 밖의 개념도 추출 대상으로 둘 수 있게 됐다는 것입니다. 그것이 실제로 더 나은 답으로 이어지는지는 별도 평가가 필요했고, 그 평가 자체가 4편의 주제가 됐습니다.
그리고 남은 한계가 있습니다. 그래프와 원문을 한 번 조회하는 것만으로 여러 단계의 관계를 따라갈 수 있는 것은 아닙니다. 다음 편에서는 한 번의 검색으로 끝내던 구조를, 모델이 도구를 골라가며 탐색하는 멀티턴 검색으로 넓힌 과정과 그 대가를 다룹니다.