검색을 다시 만든 뒤 화면에서 답을 검증하려고 그래프를 열었습니다. 붉게 칠해진 노드가 실제 근거보다 훨씬 많았습니다. 강조 범위를 답변에 실제로 등장한 라벨로 줄였고, 그 과정에서 저희가 만든 기능의 이름도 다시 붙여야 했습니다. 그것은 근거 추적이 아니라 문자열 대조였습니다.
답을 검증하려고 그래프를 열었는데 온통 붉었습니다
6편에서 검색 구조를 정리하고 나서, 답이 맞는지 화면에서 확인하려고 그래프 뷰를 열었습니다.
붉게 강조된 노드가 실제 근거보다 훨씬 많았습니다.
키워드가 일치한 후보와 그 주변 노드까지 모두 같은 색으로 표시되고 있었습니다. 답변에 실제로 쓰인 개체와 검색 중 잠시 거쳐간 개체를 구분할 수 없었습니다.
강조는 정보를 주려고 만든 기능인데, 이 상태에서는 화면을 봐도 답의 근거를 좁힐 수 없었습니다. 오히려 전부 관련 있어 보이게 만들어서, 확인하려던 사람의 판단을 흐리고 있었습니다.
원인은 검색 응답에 있었습니다. 키워드 부분 일치와 이웃 전체를 근거로 간주하는 보조 경로가 남아 있었습니다. 근거를 넉넉히 보여주려던 설계였는데, 넉넉함이 곧 무의미함이 됐습니다.
답변에 이름이 나온 후보만 남겼습니다
강조 범위를 줄이는 기준이 필요했습니다.
검색기가 그래프 트리플과 클래스 결과에서 후보 노드 라벨을 모은 뒤, 정규화한 최종 답변에 이름이 포함된 후보만 근거 노드로 반환하게 했습니다. 프론트엔드는 그 목록만 강조합니다.
검색 후보와 탐색 경로
↓ 답변 문자열에 이름이 등장했는가
최종 답변에 언급된 후보
↓
근거 노드 목록
↓
그래프 강조
검색 후보와 중간 경로는 디버깅이나 탐색 정보로 남길 수 있지만 근거 색상에는 섞지 않습니다.
강조 범위가 줄면서 화면이 실제로 답을 검증하는 데 쓰일 수 있게 됐습니다.
보여줄 것을 정할 때 많이 보여주는 쪽이 안전해 보입니다. 사용자가 그중에서 고를 수 있으니까요. 실제로는 선별 책임을 화면에서 사용자에게 넘긴 것이고, 선별에 필요한 정보를 우리가 이미 갖고 있었다면 넘기지 않는 편이 맞습니다.
우리가 만든 것은 근거 추적이 아니라 문자열 대조였습니다
여기서 이 기능의 이름을 다시 붙여야 했습니다.
이 계약은 안정적인 노드 식별자나 관계 단위 출처가 아니라 라벨 문자열을 기반으로 합니다. 그래서 두 가지가 따라옵니다.
같은 라벨을 가진 노드가 여러 개면 전부 함께 강조됩니다. 어느 것이 답에 쓰인 노드인지 화면은 구분하지 못합니다.
그리고 더 중요한 쪽입니다. 답변에 이름이 등장했다는 사실만으로 그 노드가 실제 추론 근거였다고 증명할 수는 없습니다. 모델이 그 노드를 보고 답을 만들었는지, 다른 경로로 나온 답에 우연히 같은 이름이 들어갔는지 이 계약은 구분하지 못합니다.
저희가 확인한 것 키워드 보조 경로보다 강조 범위를 줄였다
저희가 못 한 것 강조된 노드가 답의 근거였음을 증명한다
그래서 이 변경을 '정확한 근거 추적'이라고 부르지 않았습니다. 과도한 후보 강조를 줄인 화면 개선이고, 실제 추론 근거를 증명하는 데이터 계약은 아직 없습니다.
1편에서 출처가 관계 트리플이 아니라 주어 노드에 붙는다고 적었고, 2편에서 방문 노드가 안정적인 식별자가 아니라 라벨이라고 적었습니다. 같은 간격이 세 번째로 여기서 나온 것입니다. 화면에서 설명 가능성을 높이려면 무엇을 덜 칠할지뿐 아니라, 어떤 관계와 원문이 답을 지지했는지를 식별자로 보존해야 합니다.
정확한 인용 연결에는 안정 URI와 인용에서 트리플로, 트리플에서 원문 청크로 이어지는 매핑이 필요합니다.
기능에 이름을 붙일 때 그 이름이 약속하는 범위를 함께 적어두면, 나중에 그 이름 때문에 검증되지 않은 신뢰가 쌓이는 일을 줄일 수 있습니다. 설명 가능성을 다루는 기능일수록 그렇습니다. 잘못된 근거 표시는 근거가 없는 것보다 나쁩니다.
같은 그래프인데 두 화면이 다른 일을 하고 있었습니다
그래프가 커지면서 3D 화면이 또 다른 병목이 됐습니다.
전체 구조를 둘러보는 데는 유용했습니다. 밀집된 그래프에서 특정 답의 근거를 읽고 노드를 선택하는 작업은 느리고 불안정했습니다.
처음에는 3D를 개선할 문제로 봤습니다. 성능을 올리고 선택 정확도를 높이면 될 것 같았습니다.
두 작업의 요구가 서로 반대라는 것이 나중에 보였습니다.
3D 전체 구조 탐색 · 주변 확장 · 큰 그래프의 공간적 분리
→ 깊이와 회전이 도움이 된다
2D 답변 근거 확인 · 관계 라벨 비교 · 선택 범위 고정
→ 원근과 겹침이 방해가 된다
모든 그래프 화면이 같은 목적을 가질 필요는 없었습니다. 3D의 깊이는 탐색에 필요한 것이지 근거 확인에는 방해가 됩니다.
그래서 2D 보기를 추가해 근거 확인에 쓰고, 3D는 전체 구조와 군집 탐색에 남겼습니다. 물리 계산은 별도 워커로 넘겨 메인 화면의 부하를 줄였습니다.
어느 한쪽을 기본 정답으로 두지 않고 사용자가 지금 하려는 일에 맞춰 전환합니다. 화면이 달라져도 근거 노드 목록은 같은 상태를 공유합니다.
다만 이것으로 앞의 동명 노드 문제까지 해결되지는 않습니다. 두 화면의 강조를 서로 맞출 수 있게 됐을 뿐입니다.
하나의 화면이 잘 안 된다는 신고를 받으면 그 화면을 개선하는 쪽으로 갑니다. 그 앞에 물어볼 것은 그 화면이 지금 몇 가지 일을 동시에 하고 있는가입니다. 둘 이상이면 개선이 아니라 분리가 답일 수 있습니다.
검증도 필드 존재가 아니라 화면 동작까지 봤습니다
검증을 백엔드 필드가 존재하는지에서 끝내지 않았습니다.
답변에 없는 키워드 후보가 더 이상 강조되지 않는지, 반환된 라벨이 2D와 3D에서 같은 방식으로 표시되는지, 빈 그래프와 근거가 없는 답변에서 이전 강조가 남지 않는지를 확인했습니다.
마지막 조건이 실제로 걸렸습니다. 이전 질문의 강조가 남아 있으면 사용자는 새 답의 근거로 읽습니다. 상태를 지우는 경로가 표시하는 경로만큼 중요했습니다.
덜 칠하기로 한 것까지가 이번에 한 일입니다
이 편에서 저희가 한 일을 정확히 적으면 이렇습니다. 강조 범위를 줄였고, 화면의 역할을 나눴고, 기능의 이름을 실제 동작에 맞게 고쳤습니다.
설명 가능성을 높인 것이 아니라 잘못된 설명을 줄인 것입니다. 둘은 다릅니다. 후자는 전자의 전제이지만 전자를 대신하지 못합니다.
근거 화면을 정리한 다음 작업은 반복 빌드의 무결성이었습니다. 정형 클래스가 후처리에서 합쳐지지 않게 생성 출처를 남기고, 문서는 이미 처리한 청크를 다시 추출하지 않도록 완료 기준을 저장해야 했습니다.