관계를 그리고, 미리 정리하기
그래프 검색이 이기는 질문과 지는 질문, 비용이 다른 변종들, 그리고 넣을 때 위키로 정리하는 방식의 한계.
On This Page
조각 검색은 ‘답이 한곳에 있는’ 질문에 강합니다. 사실을 연결하거나 자료 전체를 요약해야 하면, 관계를 저장하거나 지식을 미리 글로 정리하는 층이 필요합니다.
그래프 검색이란
마이크로소프트 리서치가 2024년 제안한 방식입니다. 저장 단계에서 모델이 문서에서 대상과 관계 — 제공한다, 소속된다, 썼다 — 를 뽑아 지식 그래프를 만들고, 서로 가깝게 연결된 묶음마다 요약을 미리 써 둡니다.
질문에 답하는 길은 네 가지입니다.
- 지역 검색. 특정 대상 주변을 봅니다. ‘A 프로젝트의 책임자는?’
- 전역 검색. 묶음 요약을 나눠 읽고 합쳐 전체 질문에 답합니다. ‘전체 프로젝트의 공통 문제는?’
- 드리프트 검색. 전체 맥락에서 시작해 점점 구체적인 후속 검색으로 좁힙니다.
- 기본 검색. 일반 조각 검색으로 대신합니다.
다중 홉과 전체 요약에서 평면적인 조각 검색과 격차가 벌어지고, 경로를 따라가므로 근거의 구조를 추적할 수 있습니다. 대가도 분명합니다. 그래프를 만드는 비용이 기본 방식의 3~5배이고, ‘Microsoft’와 ‘Microsoft Corporation’, ‘삼성전자’와 ‘Samsung’을 한 점으로 합치는 일의 품질이 전체를 좌우합니다. 사실 찾기가 대부분인 시스템에 넣으면 비용만 늘어납니다.
같은 이름, 다른 비용
| 변종 | 핵심 | 강점 | 주의 |
|---|---|---|---|
| Microsoft GraphRAG | 대상·관계를 뽑고 묶음별 요약을 미리 생성 | 전역 질문의 포괄성 | 저장 때 호출이 많고, 질문당 글이 매우 길어짐. 자료가 바뀌면 다시 만드는 부담 |
| LazyGraphRAG | 요약 만들기를 질문 시점으로 미룸 | 저장 비용이 의미 검색과 비슷하고 기존 그래프 RAG의 약 0.1%. 전역 질문 비용을 크게 줄이면서 품질은 비슷하다고 보고됨 | 질문 시점 계산이 늘어남 |
| LightRAG | 구체 수준과 주제 수준의 이중 검색 | 새 자료를 덧붙이기 쉬움 | 질문당 문맥이 약 1만 토큰으로 큼 |
| HippoRAG / HippoRAG 2 | 연상처럼 관련도를 퍼뜨려 한 번에 여러 홉을 탐색 | 다중 홉에 강하고 문맥이 짧음. 자료가 커져도 비교적 안정 | 대상 연결이 잘못되면 엉뚱한 방향으로 퍼짐 |
| RAPTOR | 조각을 묶어 요약하기를 반복해 아래에서 위로 나무를 만듦 | 세부와 개요를 여러 수준에서 검색 | 나무를 다시 만드는 비용, 요약 과정의 정보 손실 |
그래프가 이기는 곳과 지는 곳
ICLR 2026에 발표된 GraphRAG-Bench의 관찰은 셋입니다.
- 단순한 사실 찾기는 기본 방식이 같거나 더 낫습니다. 그래프가 관련은 있지만 필요 없는 정보까지 끌어옵니다. 앞선 연구에서는 일반 질의응답 정확도가 기본 방식보다 13.4% 낮았습니다.
- 복잡한 추론과 맥락 요약에서는 그래프가 앞섭니다. 멀리 떨어진 조각을 연결할수록 차이가 커집니다.
- 가져오는 글의 양을 관리해야 합니다. 기본 방식의 질문당 문맥이 약 900토큰일 때, 마이크로소프트 그래프의 전역 검색은 수만 토큰까지 커졌습니다. 많이 가져오는 것이 곧 잡음입니다.
자료를 약 5만 6천 토큰에서 113만 토큰으로 키우자 기본 방식의 복잡 추론 정확도는 58.6%에서 43.2%로 떨어졌지만, HippoRAG 2는 거의 그대로였습니다. 자료가 커질수록 ‘비슷하지만 틀린’ 조각이 늘어나는 의미 검색의 약점을, 그래프의 명시적인 대상 일치가 걸러 준다는 해석입니다.
실무 조언은 네 가지입니다.
- 조직도, 고객-계약-담당자처럼 이미 구조가 있는 자료는 모델로 뽑지 말고 직접 넣습니다. 말로 된 질문을 그래프 질의로 바꾸는 방식이 더 정확하고 쌉니다. 모델로 뽑는 도구는 구조 없는 글에서 관계를 발견해야 할 때 씁니다.
- 관계에도 출처와 유효 기간이 필요합니다. 없으면 ‘과거에 담당했던 프로젝트를 지금도 담당한다’고 답합니다.
- 한곳에서 찾는 질문은 하이브리드 검색으로, 연결·전역 질문만 그래프 길로 보냅니다.
- 연구 구조를 참고하는 것과, 그 구현을 장기 제품의 핵심 의존성으로 삼는 것은 구분합니다. 공개 저장소의 유지 상태를 확인하세요.
넣을 때 정리하는 위키
안드레이 카르파티가 2026년 4월 제안한 LLM 위키는 방향이 반대입니다. 질문이 올 때마다 원본 조각을 뒤지는 대신, 자료를 넣는 시점에 모델이 원본을 읽고 사람이 읽을 수 있는 마크다운 위키로 미리 합성합니다.
원본은 소스, 모델은 컴파일러, 위키는 번역 결과, 정기 점검은 시험, 질문에 답하는 일은 실행에 해당합니다.
| 구성 | 역할 | 규칙 |
|---|---|---|
원본 층 raw/ | 논문, 기사, 메모, PDF | 모델은 읽기만 함. 모든 주장의 근거 |
위키 층 wiki/ | 출처 요약, 개념·대상 페이지, 비교 | 모든 페이지에 원본 출처 |
목차 wiki/index.md | 페이지 목록과 한 줄 요약 | 질문이 오면 가장 먼저 읽는 지도 |
기록 log.md | 수집, 질의, 점검 기록 | 지우지 않고 덧붙임 |
| 규칙 파일 | 폴더, 양식, 이름, 절차 | 모호하면 위키도 엉망 |
세 작업이 순환합니다. 수집은 새 자료를 읽고 관련 페이지 10~15개를 고치며 연결을 갱신합니다. 질의는 목차를 먼저 읽고 필요한 페이지만 엽니다. 좋은 답은 다시 위키에 남아 질문할수록 지식이 쌓입니다. 점검은 페이지끼리 어긋나는 내용, 낡은 주장, 고립된 페이지, 자주 언급되는데 페이지가 없는 개념을 찾습니다.
카르파티의 사례는 약 100개 문서, 40만 단어에서 목차가 문맥 안에 들어가 벡터 저장소 없이 동작했습니다. 기본 검색은 질문할 때마다 다시 종합하고, 위키는 넣을 때 한 번 깊게 읽습니다. 그래서 여러 문서를 종합하는 미묘한 질문에 강하고, 나누기 문제 자체가 줄어듭니다. 원본이 자주 바뀌면 필요할 때 찾기가, 지식이 쌓여 재사용될수록 미리 정리가 유리합니다.
한계도 분명합니다.
- 실무 보고로는 단일 주제 100~400개 문서, 약 40만 단어가 상한에 가깝습니다. 그 이상이면 목차만으로 부족해 검색이 다시 필요합니다. 마크다운용 지역 하이브리드 검색인 qmd가 그 확장으로 언급됩니다.
- 잘못 연결한 관계가 위키에 남으면 이후 모든 답에 영향을 줍니다. 원본은 고치지 않기, 출처 연결, 판본 기록, 정기 점검이 안전장치입니다.
- 사람이 쓴 글과 모델이 정리한 글을 같은 공간에 섞지 않습니다.
- 역할별 권한, 동시 편집, 감사 기록이 없어 기업 전체 지식 저장소로는 맞지 않습니다.
위키와 그래프는 유용한 ‘미리 만들어 둔 지식 보기’이지만 원본의 권위를 자동으로 물려받지 않습니다. 모델이 쓴 위키를 다시 모델이 검증 없이 사실로 쓰는 순환은 특히 위험합니다. 자주 바뀌는 뜨거운 지식은 위키로, 거의 안 바뀌는 대량 보관 자료는 검색으로 나누는 조합이 현실적입니다.