Citation Needed: Provenance for LLM-Built Knowledge Graphs — Daniel Chalef, Zep AI

한 줄 핵심

LLM이 여러 소스에서 생성한 사실은 흔적이 쉽게 사라지므로, 사실의 출처·변경·삭제 가능성을 그래프 기반 lineage로 내장해야 신뢰성, 컴플라이언스, 디버깅을 동시에 해결할 수 있다.

시간별 요약

1. 0:01
   LLM은 여러 출처를 종합해 사실이나 구조화된 기록을 만들지만, 그 과정이 비결정적이라 원문에 없는 결과가 생기고 생성 경로가 사라지기 쉽다. 그래서 provenance를 통해 어떤 산출물이 어떻게 만들어졌는지 추적하는 것이 중요하며, 이는 법적 준수뿐 아니라 디버깅과 신뢰성 판단에도 직접 도움이 된다.
2. 2:03
   의료 사례처럼 여러 문서와 사용자 입력이 합쳐진 사실은 출처를 명확히 표시하지 않으면 잘못된 판단을 낳을 수 있다. 단순한 source ID 방식은 정형 데이터에는 맞지만, LLM이 여러 소스를 섞어 요약·통합하는 컨텍스트 파이프라인에서는 엔티티 병합과 사실 갱신 때문에 lineage를 안정적으로 유지하기 어렵다.
3. 4:00
   해결 방식은 사실과 소스의 관계를 그래프로 모델링하는 것이다. 소스 episode에서 추출된 entity와 edge를 연결해 fact를 만들고, 엔티티가 병합되거나 사실이 새로운 데이터로 무효화될 때도 모든 소스 링크와 변경 이력을 유지하면, fact에서 source로의 추적은 그래프 탐색으로 단순해진다.
4. 6:06
   메타데이터를 그래프에 투영하면 출처 태그나 검증 여부 같은 속성을 여러 episode와 파생 사실에 전파할 수 있다. 다만 같은 구조의 fact라도 ‘어느 부모가 검증되어야 하는가’는 상황에 따라 다르므로, 그래프는 근거를 제공하고 실제 정책 적용은 에이전트가 비즈니스 규칙으로 수행해야 한다.
5. 9:01
   보존 정책이나 right to be forgotten 요청처럼 소스 데이터를 삭제해야 할 때도 lineage가 있으면 어떤 파생 사실이 함께 삭제되어야 하는지 결정할 수 있다. 모든 사실을 로그로 나중에 맞추는 방식보다, 소스와 파생 결과를 처음부터 그래프에 연결해 두는 방식이 삭제·검증·추적에 더 안전하고 실용적이다.
6. 12:01
   실무에서는 graph construction 비용과 지연이 크기 때문에, LLM만 쓰지 말고 엔트로피·sim hash 같은 전통적 NLP와 정보검색 기법을 섞어 중복 제거와 개체 정합성을 더 싸고 결정적으로 처리해야 한다. 또한 file-based memory나 markdown은 대규모 멀티에이전트·멀티유저 환경에서 provenance 유지가 어렵기 때문에, 엔터프라이즈 메모리에는 그래프 기반 구조가 더 적합하다.

실무 인사이트

• LLM 기반 지식 저장소는 '무엇이 맞는가'보다 '왜 맞는가'를 저장하는 구조로 설계해야 나중에 감사, 디버깅, 삭제가 가능하다.
• 사실의 출처를 한 개 ID로 고정하는 방식은 병합·갱신·상충이 잦은 에이전트 메모리에는 취약하므로, 사실-소스 관계를 다중 링크 그래프로 관리해야 한다.
• 검증 태그나 삭제 정책은 그래프가 아니라 애플리케이션 계층에서 해석해야 상황별 규칙을 유연하게 바꿀 수 있다.