1편 · RAG — LLM에 기억이 아니라 근거를 붙이는 기술
대규모 언어모델은 학습이 끝나는 순간 지식이 굳어버립니다. 여기서 세 가지 결함이 동시에 발생합니다. 학습 이후의 사실을 알지 못하고, 모르는 것을 그럴듯하게 지어내며, 사내 문서나 계약서 같은 비공개 자료는 애초에 접근 대상이 아닙니다. 파인튜닝으로 메우려는 시도는 비용과 갱신 주기 양쪽에서 불리합니다. 문서 한 건 수정될 때마다 모델을 다시 학습시킬 수는 없기 때문입니다.
RAG는 문제를 다르게 풉니다. 지식을 파라미터 안에 넣는 대신 외부 저장소에 두고, 질문이 들어온 그 순간 검색해서 프롬프트에 주입합니다. 모델은 기억하는 존재가 아니라 주어진 근거를 읽고 답하는 존재로 역할이 바뀝니다. 문서를 갱신하면 즉시 반영되고, 답변에 출처를 붙일 수 있으며, 검색 단계에서 권한을 걸어 문서별 보안까지 구현됩니다.
구조는 두 단계입니다. 오프라인 인덱싱에서 문서를 파싱하고, 청크로 자르고, 임베딩해 벡터 인덱스에 넣습니다. 온라인 질의에서는 질문을 변환하고, 검색하고, 재순위화한 뒤 프롬프트를 조립해 생성합니다.
품질을 좌우하는 지점은 정해져 있습니다. 첫째, 파싱. 2단 조판 PDF의 컬럼 순서가 뒤섞이거나 표가 줄바꿈으로 뭉개지면 뒤 단계가 아무리 정교해도 복구되지 않습니다. 둘째, 청킹. 청크가 작을수록 검색 정밀도는 오르고 답변 충실도는 떨어집니다. 이 상충은 작은 청크로 검색하고 큰 부모 청크를 전달하는 방식으로 해소합니다. 셋째, 하이브리드 검색. 임베딩은 의미를 잡지만 조항번호·모델명 같은 고유명사에 약하고, BM25는 정확히 반대입니다. 두 결과를 융합하면 단일 방식을 거의 항상 상회합니다. 넷째, 리랭커. 검색기가 재현율 확보를 위해 넉넉히 가져오면 크로스 인코더가 질의-문서 쌍을 직접 채점해 상위 몇 건으로 압축합니다. 투입 노력 대비 개선 폭이 가장 큰 지점입니다.
평가는 검색과 생성을 분리해야 원인 진단이 됩니다. 검색은 Hit Rate와 문맥 정밀도·재현율로, 생성은 충실도(제공 문맥이 답변을 지지하는 비율)로 봅니다. 여기서 실무 원칙 하나. 골든 평가셋 50문항을 먼저 만들고 시작하십시오. 평가셋 없이 튜닝하면 개선인지 퇴행인지 판별조차 불가능합니다.
개선 효과가 큰 순서는 평가셋 → 파싱 → 청킹 → 하이브리드 → 리랭커 → 질의 변환입니다. 거꾸로 접근하는 조직이 많습니다. Self-RAG나 에이전트 루프를 먼저 붙이고도 성능이 안 오르는 사례 대부분은, 실은 PDF 파싱에서 표가 이미 깨져 있던 경우입니다.
그리고 RAG에는 원리적 한계가 둘 있습니다. 여러 문서를 이어붙여야 답이 나오는 다중 홉 질문, 그리고 "이 자료 전체의 핵심 쟁점은?" 같은 전역 요약 질문입니다. 후자에 대응하는 청크는 애초에 존재하지 않습니다.
2편 · GraphRAG — 유사도가 아니라 관계로 검색하다
표준 RAG가 무너지는 지점에서 GraphRAG가 시작합니다.
"A사 공급업체 중 B규제 대상은 어디인가"라는 질문을 생각해 봅니다. A와 공급사의 관계, 공급사와 규제의 관계가 서로 다른 문서에 흩어져 있고, 어느 쪽도 질문과 직접 닮지 않았다면 유사도 검색은 실패합니다. "이 1만 건 문서를 관통하는 쟁점 다섯 가지"도 마찬가지입니다. 답이 코퍼스 전체에 분산되어 있으니 상위 k개 검색으로는 도달할 방법이 없습니다.
Microsoft가 2024년 내놓은 GraphRAG의 발상은 단순합니다. 검색하기 전에 문서를 읽어 "누가 무엇과 어떻게 연결되는지"를 미리 구조화해 둔다.
인덱싱은 이렇게 흘러갑니다. 문서를 텍스트 유닛으로 자르고, LLM이 각 유닛에서 엔티티와 관계를 추출합니다. 추출된 것들을 이어 그래프를 만들고, Leiden 알고리즘으로 밀접하게 얽힌 노드 군집(커뮤니티)을 계층적으로 찾아냅니다. 그리고 각 커뮤니티마다 LLM이 요약 보고서를 씁니다. 하위 요약을 재료로 상위 요약을 만드는 상향식 구조입니다. 이 보고서 집합이 곧 코퍼스 전체의 다층 지도이며, 표준 RAG에는 이런 산출물이 아예 없습니다.
여기서 두 가지가 결정적입니다. 하나는 도메인 스키마. 기본 프롬프트는 범용 엔티티를 가정하므로, 법률이면 조항·판례·의무, 부동산이면 필지·용도지역·거래 같은 유형을 명시해야 쓸 만한 그래프가 나옵니다. 다른 하나는 엔티티 해소. "서울대", "서울대학교", "SNU"가 세 노드로 남으면 그래프가 파편화되고 GraphRAG의 이점이 통째로 사라집니다. 실무 최다 실패 지점입니다.
질의는 세 갈래입니다. Local은 질문 속 엔티티를 찾아 그 이웃과 원문 청크를 모아 답합니다. Global은 모든 커뮤니티 보고서를 map-reduce로 훑어 전역 질문에 답하지만, 커뮤니티 수만큼 LLM을 호출하므로 비쌉니다. DRIFT는 커뮤니티 정보로 넓게 출발해 질문을 후속 질의로 쪼갠 뒤 그래프를 동적으로 순회하는 방식으로, 국소 검색의 재현율 부족과 전역 검색의 비용 과다 사이 중간해입니다. 실전에서 1순위로 검토할 모드입니다.
대가는 정직하게 비쌉니다. 문서 전량을 LLM으로 읽어야 하므로 인덱싱 비용이 표준 RAG의 수십에서 수백 배까지 갑니다. 증분 갱신도 어렵습니다. 그래서 통제 전략이 필요합니다. 추출은 저비용 모델, 요약과 생성은 고성능 모델로 이원화하고, 전역 검색은 상위 커뮤니티 레벨만 쓰며, 코퍼스 전체가 아니라 핵심 문서군만 그래프화합니다.
실무 정답은 양자택일이 아니라 질의 라우팅입니다. 단일 사실 조회는 표준 RAG로, 엔티티 상세는 Local로, 다중 홉은 DRIFT로, 전역 요약은 Global로 보냅니다. 통상 질의의 70~85%가 가장 싼 경로에서 끝납니다.
GraphRAG는 RAG의 상위 호환이 아니라 다른 질문을 푸는 도구입니다. 전자가 검색이라면 후자는 이해입니다. 그러므로 도입 판단의 출발점은 기술 사양이 아니라 한 줄의 실측입니다. 우리 질의 중 관계형 질문이 몇 퍼센트인가. 이 숫자 없이 시작하는 GraphRAG는 대체로 비싼 실험으로 끝납니다.