RAG 검색 경로를 두 개로 나눴더니, 넓은 질문에서도 답변이 나왔습니다

커뮤니티 요약까지 만들었는데, 언제 쓰라는 건지 모르겠습니다

이전 글에서 Leiden으로 클러스터를 찾고, LLM으로 요약을 만들고, Level 0→1→2 계층으로 쌓는 과정을 정리했거든요. 요약 노드가 Neo4j와 Qdrant에 들어가 있으니까, 기술적으로는 검색할 준비가 된 상태였습니다.

그런데 실제로 RAG 파이프라인에 연결하려니까 막히는 게 있었어요. "올해 인프라 이슈 전체 정리해줘"가 들어왔을 때는 커뮤니티 요약을 검색해야 하고, "물류서버 IP가 뭐야?"가 들어왔을 때는 개별 문서를 검색해야 하거든요. 두 질문이 같은 검색 경로를 타면 안 되는데, 기존 파이프라인에는 경로가 하나밖에 없었습니다.

Global Search와 Local Search, 역할이 다릅니다

Microsoft GraphRAG 논문에서는 이 두 경로를 Global Search와 Local Search로 구분합니다.

Local Search — 개별 문서를 대상으로 벡터 검색 + 그래프 탐색을 하는 경로입니다. "물류서버 IP가 뭐야?", "인증서 갱신 누가 했어?" 같은 좁은 질문에 맞아요. 관련 문서가 소수이기 때문에 top-K 안에 다 들어오고, 리랭크로 정확한 답을 뽑을 수 있습니다.

Global Search — 커뮤니티 요약을 대상으로 검색하는 경로입니다. "올해 인프라 이슈 전체 정리해줘", "2025년 물류시스템에 무슨 일이 있었어?" 같은 넓은 질문에 맞아요. 개별 문서 200건을 검색하는 대신, 요약 20~30장을 검색해서 전체를 커버합니다.

기존 파이프라인의 hybrid_search가 Local Search에 해당하고, 여기에 Global Search 경로를 추가하는 구조예요.

질문이 넓은지 좁은지를 어떻게 판단하는가

두 경로가 있으면, 질문이 들어왔을 때 어디로 보낼지 판단하는 로직이 필요합니다. 여기서 세 가지 방법을 검토했어요.

방법 1 — LLM이 판단한다. 의도분석 단계에서 "이 질문이 넓은 질문인지 좁은 질문인지"를 LLM한테 맡기는 거예요. 기존 라우팅에 판단 기준 하나를 추가하면 되니까 구현이 간단합니다. 다만 이전에 LLM 라우팅이 그래프 검색을 빠뜨리는 문제를 겪었거든요. 같은 한계가 여기서도 생길 수 있습니다.

방법 2 — 키워드 기반으로 판단한다. "전체", "정리", "요약", "기간" 같은 키워드가 있으면 Global로 보내는 규칙을 만드는 거예요. 확실하지만 커버하지 못하는 표현이 생깁니다. "물류시스템에 무슨 일이 있었어?"는 키워드가 없는데 넓은 질문이거든요.

방법 3 — 둘 다 돌리고 결과를 합친다. Local과 Global을 병렬로 돌리고, 결과를 합쳐서 리랭크하는 방식입니다. 판단 자체를 안 해도 되니까 라우팅 실패가 없어요. 비용이 2배지만, 커뮤니티 요약 검색은 요약 20~30장 대상이라 부하가 크지 않습니다.

둘 다 돌리는 게 가장 현실적이었습니다

결론부터 말하면 방법 3을 선택했어요. 이유가 몇 가지 있었습니다.

첫째, 라우팅 실패 리스크가 없습니다. LLM이든 키워드든, 판단이 들어가면 틀릴 수 있거든요. 넓은 질문을 Local로 보내면 답변에 빠지는 게 생기고, 좁은 질문을 Global로 보내면 구체적 팩트가 안 나와요. 둘 다 돌리면 이 문제가 구조적으로 사라집니다.

둘째, 비용이 생각보다 크지 않았습니다. Local Search는 기존 파이프라인 그대로이고, Global Search는 요약 20~30장에 대한 벡터 검색이라 시간이 거의 안 걸려요. 병렬로 실행하면 전체 시간도 크게 늘지 않았습니다.

셋째, 리랭크가 자연스럽게 경로를 선택해줍니다. 좁은 질문이 들어오면 Local Search 결과가 리랭크에서 높은 점수를 받고, Global Search 결과는 낮은 점수로 밀려나요. 넓은 질문이면 반대고요. 별도 라우팅 없이도 리랭크가 결과적으로 적절한 경로를 택하는 셈이에요.

전체 흐름을 정리하면 이렇습니다

커뮤니티 시리즈 3편의 내용을 합치면, 넓은 질문에서 RAG가 답변을 빠뜨리는 문제를 해결하는 전체 흐름이 나옵니다.

질문 입력
  → Local Search: 개별 문서 벡터 검색 + 그래프 탐색 (기존)
  → Global Search: 커뮤니티 요약 벡터 검색 (추가)
  → 두 결과 합산 + 리랭크
  → LLM 답변 생성

좁은 질문이면 Local 결과가 상위에 올라오고, 넓은 질문이면 Global 결과가 상위에 올라옵니다. 라우팅 로직이 없어도 리랭크가 자연스럽게 경로를 선택해주는 구조예요.

1편에서 top-K 한계를 발견하고 커뮤니티 탐지를 도입했고, 2편에서 클러스터를 LLM으로 요약해서 계층 구조를 만들었고, 3편에서 Global Search와 Local Search를 병렬로 돌려서 합치는 것까지 왔습니다.

라우팅을 고민하기 전에 리랭크를 믿어봤습니다

Global vs Local을 어떻게 나눌지 고민하면서, 처음에는 LLM 판단이나 키워드 규칙을 만들어야 한다고 생각했거든요. 그런데 이전에 검색 라우팅에서 LLM이 자꾸 틀리는 경험을 했잖아요. 같은 함정에 빠지고 싶지 않았습니다.

둘 다 돌리고 리랭크에 맡기는 방식은 "판단을 안 하는 것"이 오히려 정답인 케이스였어요. 라우팅을 정교하게 만드는 데 시간을 쓰는 것보다, 검색 결과의 품질로 경로가 결정되게 하는 게 더 안정적이었습니다.

검색 경로를 나눠야 할 때, 라우팅 로직부터 만들기보다 "둘 다 돌리고 리랭크로 합칠 수 있는지"를 먼저 검토해보는 걸 추천합니다.