결론부터
“벡터 기반 엔티티 추출 → Text2Cypher” 조합이 별도 벡터 검색을 완전히 대체하지는 않는다. 프로덕션에서는 거의 예외 없이 vector + keyword + graph traversal(그래프 순회) 3중 하이브리드를 쓴다.
왜 대체가 안 되는가
헷갈렸던 원인: “벡터 검색”이라는 말이 두 가지를 동시에 가리켰다. 두 개를 분리하면 이해가 쉽다.
① 쿼리 시점 엔티티 매칭용 벡터 검색
사용자 질문에서 엔티티를 뽑고, 그래프 DB에 저장된 엔티티 임베딩(entity embedding)과 유사도 비교해서 “이 질문이 어떤 노드에 대한 건지” 찾는 과정. 이건 진입점(entry point) 찾기지, 답변 컨텍스트 수집이 아니다.
② 청크/문서 수준 벡터 검색
실제 텍스트 청크를 임베딩해서, 쿼리와 의미적으로 가까운 텍스트 조각을 가져오는 과정. 이건 컨텍스트 수집이다.
| ① 엔티티 매칭용 | ② 청크 매칭용 | |
|---|---|---|
| 무엇을 찾냐 | 그래프 노드 ID | 원본 텍스트 조각 |
| 쓰임 | 진입점 탐색 | 답변 근거 수집 |
| 대상 | 엔티티 임베딩 | 문서 청크 임베딩 |
①만 하고 Text2Cypher(LLM이 Cypher 쿼리를 생성하는 방식)로 그래프를 탐색하면, 그래프에 명시적으로 저장된 관계만 가져올 수 있다. Text2Cypher 패턴은 가장 유연하지만 가장 신뢰도가 낮다. GraphRAG
특히 사용자 질문에서 추출된 엔티티 별칭(alias, 별명/다른 표기)이 DB에 저장된 값과 정확히 일치하지 않으면 쿼리가 빈 결과를 반환하는 문제가 있다. Neo4j 그래서 별칭 불일치를 커버할 키워드 검색과 청크 벡터 검색이 실전에서는 같이 필요하다.
한마디 요약
① 진입점용 벡터 ≠ ② 컨텍스트용 벡터. 하나만 써서는 별칭 불일치와 암묵 지식을 못 건진다. 3중 하이브리드가 기본기다.