Neo4j LLM Graph Builder는 문서를 GraphRAG용 지식 그래프로 바꾸는 앱이다

RAG 시스템을 만들다 보면 벡터 검색만으로는 설명하기 어려운 지점이 생긴다.
문서 chunk는 “비슷한 문장”을 찾는 데는 좋지만, 여러 문서에 흩어진 사람·회사·제품·사건이 어떻게 연결되는지, 답변이 어떤 entity와 relationship을 따라 만들어졌는지, 사용자가 결과를 그래프로 검토할 수 있는지는 별도 구조가 필요하다.

neo4j-labs/llm-graph-builder는 이 문제를 Neo4j답게 푸는 오픈소스 웹 애플리케이션이다.
PDF, 문서, 웹 페이지, YouTube transcript, Wikipedia, S3/GCS 같은 비정형 소스를 넣으면 LLM과 LangChain 계열 로더/graph transformer를 통해 Neo4j 안에 lexical graph와 entity graph를 만든다.
이후 사용자는 그래프를 미리 보고, Neo4j Bloom/Workspace로 열고, chatbot에서 GraphRAG 방식으로 질의할 수 있다.

내가 보기에 이 저장소의 중심은 “LLM이 알아서 좋은 지식 그래프를 만들어 준다”가 아니다.
더 정확히는 문서 ingestion, schema-guided extraction, graph visualization, GraphRAG 질의, evaluation/post-processing을 한 화면의 실험실로 묶은 Neo4j용 그래프 구축 앱에 가깝다.
그래서 라이브러리라기보다는 GraphRAG 프로토타입과 내부 데이터 검토 workflow를 빠르게 시작하는 제품 표면으로 읽는 편이 맞다.

무엇을 해결하려는가

문서 기반 GraphRAG를 직접 만들려면 의외로 많은 주변 작업이 필요하다.
파일을 업로드하고, 웹 페이지와 YouTube transcript를 읽고, chunk를 만들고, embedding을 계산하고, vector index를 만들고, entity와 relationship을 뽑고, 원문 chunk와 entity를 다시 연결하고, 사용자가 그래프를 확인할 수 있는 UI까지 붙여야 한다.
여기에 schema를 직접 지정하거나, 기존 Neo4j database의 schema를 참고하거나, post-processing으로 duplicate entity를 정리하는 단계까지 들어가면 단순 RAG 샘플을 넘어선다.

LLM Graph Builder는 이 과정을 앱으로 낮춘다.
사용자는 Neo4j Aura 또는 접근 가능한 Neo4j instance에 연결하고, source를 올리고, 사용할 LLM과 embedding 설정을 고른 뒤, 필요한 경우 graph schema를 설정한다.
생성이 끝나면 file table에서 source별 node/relationship count와 상태를 보고, graph preview에서 lexical graph, entity graph, full knowledge graph를 확인한다.

Neo4j Labs 문서는 이 도구가 특히 long-form English text, PDF, text-heavy document, schema-guided knowledge graph extraction에 잘 맞고, Excel/CSV 같은 tabular data나 이미지·다이어그램·슬라이드 중심 자료에는 덜 적합하다고 적는다.
이 caveat가 중요하다.
Graph Builder는 OCR/문서 이해 만능 도구라기보다, 텍스트를 그래프 구조로 바꾸는 GraphRAG 준비 도구에 가깝다.

핵심 구조: lexical graph와 entity graph를 함께 만든다

Neo4j Labs 설명에서 가장 중요한 구분은 lexical graph와 entity graph다.

작동 방식은 대략 이렇다. source가 들어오면 LangChain loader가 문서를 읽고 chunk로 나눈다. chunk는 Neo4j에 저장되고 원본 Document와 연결된다. embedding은 chunk에 저장되고 vector index에 들어가며, 유사도가 높은 chunk끼리는 SIMILAR 관계로 묶인다.
그런 다음 llm-graph-transformer 또는 diffbot-graph-transformer가 텍스트에서 entity와 relationship을 추출하고, 그 결과를 chunk와 연결한다.

이 구조의 장점은 답변 근거를 “검색된 텍스트 조각”에만 묶지 않는다는 점이다.
검색은 vector/fulltext에서 시작할 수 있지만, entity relationship과 community summary를 따라가면 문서 밖의 구조적 맥락을 더할 수 있다.
Neo4j의 2025 release post도 이 방향을 강조한다. chunk만 보면 문맥이 약하지만, concept/entity를 뽑아 연결하면 여러 source에 흩어진 정보가 이어진다는 것이다.

앱 표면: source ingestion, schema, graph preview, chatbot

LLM Graph Builder가 일반적인 extraction script와 다른 점은 UI가 작업 흐름 자체를 안내한다는 점이다.
공식 feature 문서와 frontend docs 기준으로 주요 표면은 다음과 같다.

Graph preview는 이 도구의 핵심 UX다.
파일별 또는 선택된 전체 source에 대해 graph를 열고, document/chunk 중심의 lexical graph, entity 중심 그래프, community graph를 나눠 볼 수 있다.
이는 실제 운영에서 중요하다.
LLM extraction은 언제든 누락, 중복, 잘못된 relation type을 만들 수 있기 때문에, 사람의 검토 화면 없이는 지식 그래프 품질을 통제하기 어렵다.

Chatbot도 단순한 “문서 QA”가 아니라 retrieval mode 비교 표면에 가깝다. frontend/src/utils/Constants.ts에는 vector, graph, graph+vector, fulltext, graph+vector+fulltext, entity search+vector, global search+vector+fulltext가 정의되어 있다. backend docs의 /chat_bot 설명은 embedding model, Neo4jGraph, chat history, retrieved chunks/entities/communities를 엮어 답변을 만든다고 적는다.
응답에는 source, retrieved node detail, token usage, response time, metric detail 같은 정보를 담을 수 있다.

LightRAG 기준으로 본 raw 문서 의미 추출 정확도

여기서 LightRAG와 비교해야 할 대상은 라이브러리 형태나 UI 기능이 아니라, raw 문서에서 의미 그래프를 뽑는 정확도다.
LightRAG의 graph construction prompt는 지정된 entity type을 기준으로 entity-relationship 정보를 추출하고, entity description, relationship description, strength, high-level keyword를 만든다.
Neo4j LLM Graph Builder도 결국 LangChain LLMGraphTransformer나 Diffbot transformer로 문서 chunk에서 entity와 relationship을 뽑는다.
따라서 핵심 질문은 “어느 앱이 더 편한가”가 아니라 “같은 원문을 줬을 때 어느 쪽이 더 사실에 맞는 graph를 만드는가”다.

이 글에 들어가야 하는 비교는 retrieval mode나 배포 구조가 아니라 extraction quality matrix다.
Graph Builder의 장점은 schema 설정과 graph preview가 있어 사람이 결과를 볼 수 있다는 점이지만, preview가 있다고 해서 extraction이 정확하다는 뜻은 아니다.
LightRAG의 장점도 answer-level 평가에서 좋은 win rate를 보인다는 점이지만, 그것 역시 entity/relation extraction accuracy를 직접 측정한 것은 아니다.
둘 다 별도의 gold annotation 기반 평가가 필요하다.

정량 지표도 이 수준으로 내려와야 한다.
LightRAG 논문의 Comprehensiveness, Diversity, Empowerment, Overall은 최종 답변을 LLM-as-judge로 비교한 지표라서 “GraphRAG 답변 품질”에는 유용하지만, raw 문서 의미 추출 정확도에는 간접 지표다.
Neo4j Graph Builder 글에서는 다음처럼 extraction-level metric을 제안하는 편이 더 맞다.

실험은 같은 corpus에서 해야 한다.
예를 들어 20~50개 raw 문서를 골라 사람이 entity, relation, attribute, evidence span을 annotation하고, Neo4j LLM Graph Builder와 LightRAG식 extraction을 동일 schema로 실행한다.
그런 다음 node/edge count나 retrieval answer win rate보다 entity F1, relation F1, evidence coverage, unsupported edge rate, schema violation rate를 먼저 본다.
여기에 최종 GraphRAG 답변 지표를 붙이면 “정확히 추출된 graph가 실제 답변 품질로 이어졌는가”까지 확인할 수 있다.

공개된 근거에서 확인되는 점

2026년 6월 26일 조회 기준 공개 표면은 다음과 같다.

릴리스 흐름도 읽을 만하다. v0.8.5는 embedding model 선택과 token usage tracking을 강조했고, v0.8.6은 최신 LLM model config와 안정성 수정을 강조한다.
Neo4j Developer Blog의 2025 release post는 community summaries, local/global retrievers, parallel retriever comparison, RAGAS evaluation, custom extraction instructions를 핵심 변화로 소개했다.
즉 최근의 방향은 단순 graph extraction에서 retrieval mode 비교와 graph quality/post-processing을 포함한 GraphRAG workbench로 넓어지고 있다.

다만 문서 간 시점 차이는 있다.
Neo4j Labs feature page는 공개 hosted version에서 사용할 수 있는 model이 제한적이라고 설명하는 반면, 현재 README와 example env는 GPT-5.x, Gemini 3.5, Claude 4.x, Fireworks, DeepSeek, Bedrock, Ollama 등 더 넓은 model config를 노출한다.
따라서 “지원 model”은 hosted app에서 바로 보이는 목록과 self-hosted/dev config로 열 수 있는 목록을 분리해서 이해해야 한다.

실무 관점에서의 해석

LLM Graph Builder가 잘 맞는 상황은 명확하다.
Neo4j를 이미 쓰고 있거나, GraphRAG를 검토하는 팀이 내부 문서 몇 묶음을 빠르게 그래프로 바꿔 보려는 경우다.
문서를 올리고 schema를 조정하고, 추출 결과를 그래프로 본 다음, 같은 데이터 위에서 vector-only, graph+vector, fulltext, entity_vector, global retrieval을 비교할 수 있다.
이건 notebook 샘플보다 훨씬 제품적인 검토 흐름이다.

특히 장점은 human-in-the-loop이다.
GraphRAG의 문제는 “그래프를 만들 수 있느냐”보다 “만든 그래프를 사람이 어떻게 검토하고 고치느냐”에 있다.
이 앱은 source table, graph preview, duplicate merge, disconnected node deletion, schema settings, retrieved context display를 한 UX에 묶는다.
잘 쓰면 LLM extraction을 blind automation이 아니라 검토 가능한 data preparation 단계로 만들 수 있다.

반대로 production 지식 그래프 파이프라인으로 바로 간주하기에는 조심할 점이 있다.
첫째, source와 provider credential이 많다.
README와 env 예시는 OpenAI, Diffbot, GCS, S3, Neo4j, token tracker DB, Auth0/Okta 등 많은 환경 변수를 다룬다.
민감한 문서를 다룬다면 hosted app보다 self-hosted deployment와 provider/data egress policy를 먼저 검토해야 한다.

둘째, LLM extraction 품질은 schema와 source 성격에 크게 좌우된다.
Neo4j Labs 문서가 직접 말하듯 long-form text에는 강하지만 표/이미지/슬라이드 중심 자료에는 덜 맞는다. entity와 relationship이 잘못 추출되면 GraphRAG가 더 “설명 가능해지는” 것이 아니라, 잘못된 관계를 더 자신 있게 따라갈 수 있다.
따라서 sampling review, schema validation, duplicate/entity cleanup, source citation 확인이 필수다.

셋째, 이 저장소는 installable SDK라기보다 앱이다. backend는 requirements.txt 기반 FastAPI service이고, frontend는 private Vite package다.
GitHub Releases도 별도 binary/package asset보다는 source release 중심이다.
따라서 “라이브러리로 pip install해서 붙이는 도구”를 찾는 팀보다는, Neo4j-backed GraphRAG workbench를 띄워서 실험하고 내부 workflow로 확장하려는 팀에 더 잘 맞는다.

정리

Neo4j LLM Graph Builder는 문서와 웹 소스를 Neo4j 지식 그래프로 바꾸고, 그 결과를 GraphRAG 질의와 시각화로 이어 주는 Labs 앱이다.
기술적으로는 LangChain loader/graph transformer, embedding/vector index, entity graph extraction, Neo4j graph visualization, retriever 비교, RAGAS evaluation이 결합되어 있다.

핵심은 자동화보다 검토 가능한 workflow다.
문서를 넣으면 chunk와 entity graph가 만들어지고, 사용자는 schema를 조정하고, 그래프를 보고, duplicate/disconnected entity를 정리하고, 여러 retrieval mode로 답변을 비교한다.
GraphRAG를 “논문/블로그 개념”이 아니라 실제 Neo4j 데이터베이스 위에서 시험해 보려는 팀에게는 꽤 실용적인 출발점이다.
다만 production 도입 전에는 self-hosting, credential/data policy, Neo4j version, LLM provider별 extraction 품질, schema review 절차를 반드시 함께 설계해야 한다.