[LLM] Graph Schema 설계, 벡터 검색&Text-to-Cypher 조회

1. LLM 이용한 그래프 스키마 설계(GraphRAG 관점)

 : 비정형 텍스트 문서를 LLM에 넣어 Neo4j에 적재 가능한 노드/관계/속성 스키마&Cypher 쿼리 자동 생성

❗️ LLM 산출물 : 항상 초안. 데이터 중복·관계 방향·네이밍 규칙·고유 식별자·검색 목적 등은 사람이 검토

 

1-1. 노드(Label) 설계 원칙

 • 문서에서 독립적으로 식별, 다른 개체가 참조 가능. 탐색의 시작점이 될 수 있는 개체로 만듦

 • 후보 : 사람, 조직, 장소, 상품, 문서, 사건, 개념, 기술, 프로젝트 등

 • 명명 규칙 : Pascal(ex. Person, Company, Product)

 • 동의어 : 하나의 Label로 통합(ex. 기업/회사/업체 → Company)

 • 각 노드는 최소 하나의 식별 속성(name, id, code 등) 가져야 함

 

1-2. 관계(Relationship) 설계 원칙

 •  두 노드 사이 방향성 있는 행위/역할/연관 관계로 만듦(단순히 같은 문장에 등장했다는 이유 X)

 • 명명 규칙 : 대문자 SNAKE_CASE, 동사/동사구(WORKS_FOR, LOCATED_IN 등)

 • 관계 속성 : 관계 자체에 의미 있는 정보(ex. since, role 등)

 

1-3. 속성(Property) 설계 원칙

 • String, Integer, Float, Boolean, Date, List

 • 명명 규칙 : camelCase

 • 값은 문서에 있는 것만 사용(없는 정보 임의 생성 X)

 • 구조화 가능한 정보는 가능한 한 별도 속성으로 분리(ex. 날짜/금액/수량/상태/역할)

 

1-4. 제약조건/인덱스 설계

 • 주요 노드의 고유 식별 속성 : UNIQUE 제약조건

 • 자주 검색될 속성 : 인덱스(ex. 이름·제목·코드·날짜·상태·카테고리 등)

  - UNIQUE 제약 속성에는 중복으로 일반 인덱스 생성 X

 

1-5. 생성 전략 

 • 문서 분량 적음 : 하나의 프롬프트로 스키마+쿼리+명세서 생성 가능

 • 문서 분량 많음 : 단계적 체인으로 나누는 것이 품질에 좋음

 

1-6. 설계 근거(Rationale) 작성 필요한 이유

 - LLM이 생성한 스키마를 사람이 검토 시 함께 제시되어야 신뢰 가능

 • 왜 이 개체를 노드로, 왜 저 연결을 관계로 삼았는지

 • 어떤 속성을 식별자/검색 대상으로 판단했는지

 • 문서에 정보가 부족해 확정하기 어려운 부분

 

2. 의미기반 검색(Semantic Search) 위한 벡터 임베딩

2-1. 필요성

 : Neo4j는 키워드 기반 검색으로, 의미 기반 질의는 처리할 수 없어 노드에 임베딩 필드 추가

 - 필드 생성 시 필요한 3가지

 ➀ 임베딩 대상 텍스트 : 기존 속성 또는 새 텍스트 

 ➁ 임베딩 모델 : Neo4j는 벡터 직접 생성 X → OpenAI 등 외부 임베딩 API 호출 필요(모델에 따라 출력 벡처 차원 수 결정)

 ➂ 벡터 저장할 노드 속성 : 이 속성에 벡터 인덱스를 걸어야 유사도 검색 가능

 

2-2. 벡터 인덱스

 : 고차원 벡터 공간에서 유사 벡터 빠르게 찾기 위한 특수 인덱스(ANN 알고리즘)

 - 인덱스 없이는 모든 노드를 순차 비교(비효율적)

 

2-3. 벡터 값 저장

 - 노드의 임베딩 속성에 임베딩 벡터 저장 : db.create.setNodeVectorProperty() 함수(프로시저) 사용

 

2-4. SEARCH절(신규 문법)

 : MATCH / OPTIONAL MATCH에 종속된 서브절(독립절 X)

[OPTIONAL] MATCH (조회할 노드)
SEARCH 노드 IN(
    VECTOR INDEX vector_index_name
    FOR embedding_vector  // 질의 벡터
    [WHERE 필터조건]        // 인덱스 내 필터링(선택)
    LIMIT 조회개수          // 필수 : top_k
)
[SCORE AS 별칭]            // 유사도 점수(선택)

 

3. Text-to-Cypher

 : 자연어 질의를 Neo4j의 Cypher로 변환 → 그래프를 자연어로 조회

3-1. GraphCypherQAChain 동작 구조

 사용자 자연어 질문
             ↓ [1단계 LLM] 그래프 스키마 참고
Cypher 쿼리 생성
             ↓ Neo4j 실행
쿼리 결과(컨텍스트)
             ↓ [2단계 LLM] 컨텍스트 + 원래 질문
최종 자연어 답변

 - 객체 : 생성자 대신 from_llm() 클래스 메소드로 생성

 

3-2. 주요 파라미터

 • 필수

graph	연결할 Neo4jGraph 객체
allow_dangerous_requests	True 명시 필수(DB 변경 쿼리 허용에 대한 동의)

 

 • LLM 분리

llm	Cypher 생성 + 답변 생성에 동일 LLM 사용
cypher_llm	Cypher 생성 전용 LLM
qa_llm	답변 생성 전용 LLM

 

 • 프롬프트 / 스키마 제어

cypher_prompt	Cypher 생성용 커스텀 프롬프트 ({schema}, {question} 변수 포함)
qa_prompt	답변 생성용 커스텀 프롬프트
include_types / exclude_types	LLM에 노출 / 제외할 노드•관계 타입 지정

 

 • 결과 제어

top_k	LLM에 전달할 최대 쿼리 결과 건수(기본값 10)
return_intermediate_steps	True시 생성된 Cypher와 조회 결과도 함께 반환(기본값 False)
return_direct	True시 2단계(자연어 답변 생성) 생략, DB 조회 결과를 그대로 반환(기본값 False)
validate_cypher	True시 관계 방향 오류 등 자동 교정(기본값 False)
use_function_response	True시 DB 결과를 tool/function 응답 형식으로 전달 → 정확도 향상(기본값 False)
verbose	중간 과정(Cypher, 컨텍스트) 출력(기본값 False)

 

3-3. 주요 속성

graph_schema	LLM에 전달되는 현재 그래프 스키마 문자열
input_key	입력 키(기본값 "query")
output_key	출력 키(기본값 "result")