EdgeQuake는 인물, 프로젝트, 사건 사이의 관계를 따라가야 하는 질문에는 유리할 수 있지만, 단순 문서 검색까지 모두 GraphRAG로 바꿀 이유는 없습니다.
벡터 검색은 질문과 의미가 가까운 청크를 찾는 데 효과적입니다. 그러나 “A가 B에 어떤 경로로 영향을 줬는가”처럼 여러 문서의 관계를 이어야 하면 관련 청크가 따로 검색되거나 연결 근거가 사라질 수 있습니다. EdgeQuake는 LightRAG 계열의 엔티티, 관계 그래프와 벡터 검색을 결합해 이 간극을 다룹니다.
원문이 설명한 기본 파이프라인은 세 단계입니다.
튜플은 엔티티의 주체, 유형, 설명과 관계의 출발지, 도착지, 키워드, 설명을 담습니다. 이 구조가 있어야 검색 시 벡터 유사도뿐 아니라 그래프 경로도 따라갈 수 있습니다. 다만 1,200과 100은 모든 문서에 맞는 법칙이 아니라 원문에 제시된 기본값입니다. 계약서 조항, 코드 함수, 짧은 FAQ처럼 구조가 다른 자료에서는 청크 경계부터 다시 평가해야 합니다.
첫 추출에서 빠진 엔티티를 선택적 두 번째 패스로 다시 찾는 Gleaning은 재현율을 약 18% 높인다는 프로젝트 설명이 있습니다. “Apple Inc.”, “apple”, “애플” 같은 표현을 합치는 정규화는 중복을 약 36~40% 줄인다는 수치도 제시됩니다.
두 수치는 가능성을 보여 주지만 자신의 문서에서 보장되는 결과는 아닙니다. Gleaning은 LLM 호출을 추가하고, 정규화는 이름이 같은 다른 대상을 잘못 합칠 수 있습니다. 다음 항목을 사람이 판정한 표본으로 측정해야 합니다.
그래프의 답은 추출 품질을 넘을 수 없습니다. 의미 없는 일반 명사가 노드로 쌓이면 탐색 경로가 늘어도 답은 더 나빠질 수 있습니다.
EdgeQuake는 PostgreSQL에 Apache AGE와 pgvector를 결합합니다. 그래프와 벡터를 별도 데이터베이스에 나눌 때보다 배포 지점과 데이터 동기화 문제를 줄일 수 있습니다. 익숙한 백업, 권한 관리 체계를 활용할 수 있다는 점도 실용적입니다.
반면 “PostgreSQL 하나”가 “운영 하나”를 뜻하지는 않습니다. AGE와 pgvector의 버전 호환, 그래프 쿼리 계획, 벡터 인덱스, 트랜잭션과 백업 복구를 함께 관리해야 합니다. 문서 갱신 때 기존 엔티티와 관계를 어떻게 삭제, 병합하는지도 시험해야 합니다. 인덱스 재생성 중 검색 결과가 섞이는 문제는 단일 DB를 쓴다고 자동 해결되지 않습니다.
Rust의 소유권과 비동기 처리는 많은 API 요청과 DB 작업을 안정적으로 병렬화하는 데 도움을 줄 수 있습니다. 하지만 원문에는 동일 데이터와 하드웨어에서 Python 구현과 비교한 처리량, 메모리 표가 없습니다. “초고속”이라는 이름보다 색인 문서당 시간, peak memory, 실패 재시도와 쿼리 지연을 직접 재는 편이 맞습니다.
4.0에서 언급된 embedded pdfium 기반 PDF Vision Pipeline은 표나 스캔 다이어그램을 VLM로 해석하는 선택지를 넓힙니다. MCP 서버도 에이전트가 그래프를 조회하는 연결점이 될 수 있습니다. 둘 다 추가 모델 호출과 권한 경계를 만들므로, 원본 PDF가 외부 모델로 전송되는지와 에이전트가 볼 수 있는 컬렉션을 먼저 정해야 합니다.
먼저 단일 청크로 답할 질문과 관계를 두세 번 건너야 할 질문을 분리합니다. 같은 문서로 벡터 전용과 EdgeQuake를 색인하고 정답률, 근거 경로, 색인 비용, 갱신 시간, 질의 지연을 비교합니다. 다단계 질문만 좋아지고 단순 질문이 느려진다면 라우터로 검색 방식을 나누는 편이 합리적입니다.
원문에 나온 make dev는 설치 전제를 설명하지 않는 한 줄짜리 시작 명령일 뿐입니다. Rust 도구체인, PostgreSQL 확장, 모델 자격 증명과 버전이 빠져 있으므로 완전한 실행 절차로 볼 수 없습니다. EdgeQuake의 도입 기준은 그래프가 화려하게 보이는지가 아니라, 관계형 질문의 근거를 추가 비용만큼 더 정확하게 되찾는가입니다.
먼저 질문을 답에 필요한 근거 수와 관계 이동 횟수로 나눌 수 있습니다. 제품 설명 한 문단을 찾는 질문은 단일 청크 검색으로 충분할 수 있습니다. 반면 한 사람이 참여한 프로젝트와 그 프로젝트가 영향을 준 후속 사건을 연결하려면 여러 엔티티와 관계를 따라야 합니다. GraphRAG는 두 번째 유형에서 후보가 됩니다.
평가 세트에는 그래프가 필요 없는 질문도 충분히 넣어야 합니다. 모든 질문을 관계 탐색으로 보내면 단순 질의의 지연과 비용이 커지고 관련 없는 경로가 답에 끼어들 수 있습니다. 질문 유형을 분류하는 라우터를 쓴다면 잘못 분류된 비율까지 재야 합니다. 그래프가 필요한 질문을 벡터로 보낸 실패와 단순 질문을 그래프로 보낸 낭비를 따로 기록하는 편이 좋습니다.
그래프의 노드와 간선마다 원문 문서, 청크, 문장 위치를 연결해야 합니다. 답이 A에서 B, B에서 C라는 경로를 사용했다면 각 관계가 실제 문장에서 지지되는지 확인할 수 있어야 합니다. LLM이 그럴듯한 관계 설명을 만들었지만 원문에는 없는 경우를 최종 답변 단계에서 걸러야 합니다.
엔티티 병합도 경로의 일부입니다. 이름이 같은 두 사람을 하나로 합치거나 한 회사의 이전 이름을 다른 회사로 분리하면 경로 전체가 잘못됩니다. 대표 표본에서 병합 전후 노드와 근거 문장을 비교하고, 확신이 낮은 병합은 자동 확정하지 않는 규칙을 둘 수 있습니다. 근거가 끊긴 답은 자신 있게 완성하기보다 부족한 관계를 표시해야 합니다.
새 문서 추가보다 수정과 삭제가 어렵습니다. 한 청크가 바뀌었을 때 그 청크에서 만든 엔티티 설명과 관계만 다시 계산할지, 병합된 노드 전체를 재평가할지 정해야 합니다. 삭제된 문서가 어떤 관계의 유일한 근거였다면 간선도 제거되어야 합니다. 남은 다른 문서가 같은 관계를 지지한다면 출처 목록만 갱신할 수 있습니다.
증분 인덱싱 테스트에서는 문서 추가, 이름 변경, 사실 정정, 완전 삭제를 각각 실행합니다. 검색 중 이전 버전과 새 버전이 섞이는지, 실패한 갱신을 되돌릴 수 있는지 확인합니다. 원본 문서 버전과 그래프, 벡터 인덱스 버전을 연결해야 오래된 답이 나온 원인을 찾을 수 있습니다.
비용은 최초 엔티티 추출에만 있지 않습니다. Gleaning 재호출, 임베딩, 정규화와 병합, 그래프 저장, 문서 갱신, 질의 시 경로 탐색과 답 생성에 각각 시간이 듭니다. 문서당 LLM 호출량, 인덱스 크기, 일일 갱신량, 질문당 조회 지연을 따로 재면 어느 단계가 병목인지 보입니다.
PDF Vision Pipeline을 사용한다면 스캔 페이지 처리와 시각 모델 호출도 별도 비용입니다. 표와 그림에서 얻은 텍스트가 정확한지 표본 검사를 하고, 원본이 외부 모델로 전송되는지 확인해야 합니다. MCP 연결에서는 에이전트가 조회할 수 있는 컬렉션과 쿼리 범위를 제한하고 민감 문서가 관계 경로를 통해 노출되지 않는지 시험합니다.
대표 문서 집합에서 사람이 엔티티와 관계를 표시한 작은 정답 세트를 만듭니다. 같은 문서를 벡터 전용과 EdgeQuake로 색인하고 단일 근거, 두 단계 관계, 이름이 겹치는 질문, 답이 없는 질문을 반복합니다. 정답률과 함께 인용 근거의 정확성, 답을 만들 수 없을 때 멈추는 능력을 평가합니다.
GraphRAG의 개선이 확인되면 전체 문서가 아니라 관계형 질문이 많은 컬렉션부터 확대합니다. 운영 중에는 추출 모델이나 정규화 규칙이 바뀔 때 기존 정답 세트를 다시 실행합니다. 품질 이득이 색인과 갱신 비용을 넘지 못한다면 벡터 검색과 라우팅하는 혼합 구성이 더 적합할 수 있습니다.
아닙니다. 한 청크에서 답을 찾는 질문은 벡터 검색이 더 단순할 수 있고, 여러 문서의 엔티티와 관계를 따라야 하는 질문에서 GraphRAG의 추가 가치가 있는지 비교해야 합니다.
항상 그렇지는 않습니다. 누락 엔티티를 더 찾을 수 있지만 LLM 호출 비용과 오추출도 늘 수 있으므로 사람 판정 표본에서 재현율 증가와 잘못된 관계 증가를 함께 측정해야 합니다.
최종 문장만 보지 말고 사용한 노드와 관계를 원문 청크와 연결해야 합니다. 관계 방향, 엔티티 병합, 문서 버전이 맞는지 재계산할 수 있어야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.