지식그래프 설계 · 8/10
열 개 CSV 테이블을 빌드한 직후에는 클래스도 열 개였습니다. 후처리가 끝난 그래프에는 네 개만 남았습니다. 의미가 비슷하다는 이유로 서로 다른 테이블 클래스가 같은 URI에 합쳐진 것입니다. 문서에서 추출한 유사 개념을 정리하는 규칙이 정형 스키마의 식별자까지 바꾸고 있었습니다.
문서 증분 빌드에서도 비슷한 문제가 나타났습니다. 새 문서를 추가한 뒤 ‘이어서 빌드’를 실행해도 이전 청크 전체를 다시 처리했습니다. 완료된 청크 집합이 빌드가 끝난 뒤 남아 있지 않아, 다음 실행이 무엇을 건너뛸지 알 수 없었기 때문입니다.
두 문제의 공통 원인은 다음 실행에 필요한 맥락이 영속 데이터로 남지 않았다는 점이었습니다. 클래스가 CSV 스키마에서 왔는지 문서 추출에서 왔는지, 어느 청크가 최근 정상 빌드에 포함됐는지를 저장하고 다음 빌드의 보호·처리 범위를 계산하도록 바꿨습니다.
정형 클래스는 의미가 아니라 스키마 식별자입니다
CSV 빌드가 처음 만든 클래스는 입력 테이블과 일대일로 대응했습니다. 그런데 후처리가 끝난 그래프에서는 10개 클래스가 4개로 줄어 있었습니다. Orders 노드에 ProductVariants와 VariantSales 라벨이 함께 붙어 있어, 의미 유사도 병합이 서로 다른 테이블을 하나의 URI로 합쳤다는 것을 확인할 수 있었습니다.
문서에서 모델이 만든 고객과 회원은 같은 개념일 수 있습니다. 반면 Orders, ProductVariants, VariantSales는 이름이 비슷해도 서로 다른 테이블 역할입니다. 정형 클래스의 이름은 자연어 개념 후보가 아니라 외래키가 참조하는 스키마 식별자입니다.
순수 정형 빌드에서는 개념 중복 병합을 실행하지 않도록 했습니다. 그러나 CSV와 문서가 함께 들어오는 하이브리드 빌드에서는 문서 개념의 중복 정리가 여전히 필요합니다. 전체 후처리를 끄는 것만으로는 해결되지 않습니다.
생성 출처를 스키마와 함께 저장했습니다
CSV에서 만든 클래스에 source=csv를 저장하고 중복 정리의 보호 집합으로 사용했습니다. 보호된 클래스는 삭제 대상 URI가 될 수 없습니다. 문서에서 추출한 개념이 정형 클래스와 같은 대상을 가리키면 정형 URI 쪽으로 합칠 수 있지만, 정형 URI를 문서 개념 쪽으로 없애지는 않습니다.
CSV 클래스 → CSV 클래스 병합하지 않음
CSV 클래스 → 문서 개념 허용하지 않음
문서 개념 → CSV 클래스 기존 중복 규칙이 같은 개념으로 판정한 경우 허용
문서 개념 → 문서 개념 기존 중복 정리 적용
출처는 파이프라인의 임시 플래그가 아니라 스키마 레코드에 저장합니다. 프로세스가 재시작되거나 다음 증분 빌드가 시작돼도 같은 보호 규칙을 적용하기 위해서입니다. 보호 여부를 설명문 형식이나 URI 이름에서 추측하지 않습니다.
이어서 빌드는 최근 완료 청크를 기준으로 삼습니다
기존 이어서 빌드는 그래프를 지우지 않았지만 문서 그룹은 처음부터 다시 모델에 보냈습니다. RDF INSERT는 멱등이어도 LLM 추출은 실행마다 달라질 수 있어 비용과 개념 수가 함께 늘어날 수 있습니다.
완료된 작업에 built_chunk_ids를 저장하고 현재 청크 집합과 차집합을 계산했습니다.
이번에 추출할 청크
= 현재 컬렉션의 청크 ID
- 최근 완료 빌드의 built_chunk_ids
실패하거나 취소된 작업의 일부 처리 목록은 기준으로 사용하지 않습니다. 그래프에 반영됐는지 확정되지 않은 청크를 다음 실행이 건너뛰는 일을 막기 위해서입니다. 재빌드는 기준을 초기화하고 모든 입력을 다시 처리합니다.
최근 완료 작업의 기준 목록을 읽지 못하면 일부 청크를 추측으로 건너뛰지 않고 전체 처리로 돌아갑니다. 증분 최적화가 실패했을 때 비용은 늘어도 데이터 누락 쪽으로 실패하지 않게 한 선택입니다.
전체 청크 개수만 비교하지도 않습니다. 문서 하나가 삭제되고 다른 문서가 추가되면 개수는 같아도 입력 집합은 달라집니다. 진행률에는 개수를 사용할 수 있지만 변경 판정에는 식별자 집합이 필요합니다.
문서 청크와 정형 파일은 증분 단위가 다릅니다
문서는 모델에 들어가는 청크가 독립된 추출 단위입니다. 새 청크만 보내도 기존 청크를 다시 해석할 필요가 없습니다. 반면 CSV의 한 행은 전체 컬럼 타입과 기본키 후보, 다른 테이블의 외래키 구조 안에서 의미가 정해집니다.
정형 파일은 청크 필터를 적용하기 전에 별도 경로로 보내 파일 전체를 다시 처리했습니다. 행 단위 증분을 하려면 안정적인 PK, 삭제 추적, FK 갱신 계약이 먼저 필요합니다. 이 계약은 10편의 DB 색인에서 별도로 설계합니다.
11개 청크 중 8개가 완료 기준에 있고 3개가 새로 추가된 조건에서 전체 빌드는 LLM 6회와 25,755토큰을 사용했습니다. 이어서 빌드는 새 청크만 2회 호출해 7,789토큰을 사용했습니다. 특정 문서와 모델의 결과이므로 일반적인 절감률은 아닙니다. 확인한 것은 기존 8개가 호출 입력에서 빠지고, 완료 뒤 기준 집합이 11개로 갱신됐다는 점입니다.
생성 출처는 후처리가 바꿔도 되는 대상을 정하고, 완료 청크 집합은 다시 처리해야 할 입력을 정합니다. 반복 빌드가 안전하려면 이런 판단 근거가 실행이 끝난 뒤에도 남아 있어야 합니다.
현재 문서 증분은 새 청크를 다시 추출하지 않는 데까지 보장합니다. 수정·삭제된 청크가 과거에 만든 트리플을 자동으로 무효화하려면 출처별 결과와 다른 출처의 지지 여부를 더 계산해야 합니다. 다음 편에서는 먼저 모델마다 다른 컨텍스트와 출력 한도 때문에 생기는 추출 실패를 배치 분할과 재시도로 다룹니다.
이전 편 → 답변에 언급된 그래프 노드만 강조하기 다음 편 → 모델 한도에 맞춰 추출 배치를 조절하는 방법