AI VIDEO BRIEFING

RAG 청킹 전략 정리: 오버랩 재귀 분할과 시맨틱 청킹, 법령·표 문서 처리 방법까지

RAG 답변이 엉뚱해지는 원인은 검색 성능보다 문서를 자르는 방식에 있다. 오버랩을 둔 재귀 분할, 표와 법령처럼 구조가 있는 문서의 처리 방법, 시맨틱 청킹의 장단점과 한계까지 실무 관점에서 정리했다.

RAG 답변 품질은 '자르기'에서 갈린다, 실무형 청킹 전략 정리 영상 대표 이미지

핵심 메시지

  • 청킹은 RAG에서 새로 생긴 개념이 아니라 검색 엔진의 정보 검색 분야에서 문서를 버킷과 청크로 나누던 방식에서 이어져 왔다.
  • 청크가 너무 크면 불필요한 내용까지 담겨 환각과 유사도 저하로 이어지고, 너무 작으면 의미 자체가 사라진다.
  • 고정 길이로 자르면 문맥이 끊기기 때문에, 앞뒤 청크가 일부 겹치도록 오버랩을 둔 재귀적 분할이 사실상 표준처럼 쓰인다.
  • 표·법령·지침처럼 구조가 있는 문서는 자동 분할만으로는 안 되고, 헤더 기준 논리 분할과 메타데이터 주입, 표의 마크다운 변환 같은 수작업이 필요하다.
  • 문장 임베딩 유사도로 자르는 시맨틱 청킹은 줄글에는 잘 맞지만 구두점이 불분명하거나 표·조항이 섞인 문서에는 적합하지 않다.

쉽게 이해하기

발표자는 스스로를 빅스터 이현종 대표로 소개하며, RAG 시스템을 만들 때 가장 먼저 부딪히는 단계인 청킹을 정리한다. 청킹이라는 말 자체가 낯선 이유는 이 개념이 LLM에서 나온 것이 아니라 검색 엔진의 정보 검색 분야에서 왔기 때문이다. 웹 문서를 관리하던 시절에도 문서를 버킷 단위로 나눈 뒤 다시 잘게 쪼갠 것을 청크라 불렀고, 대략 한 문단 정도가 하나의 청크에 해당했다.

청크 크기는 크다고도 작다고도 좋지 않다. 청크가 너무 크면 한 덩어리에 너무 많은 내용이 담겨 환각의 원인이 되고 코사인 유사도 기반 검색 정확도도 떨어진다. 반대로 너무 작으면 문장은 남아도 의미가 남지 않는다. 발표자는 문서마다 적정 길이와 오버랩 값이 다르기 때문에, 실무에서는 여러 차례 테스트를 거쳐 문서별 최적값을 찾는다고 말한다.

고정 길이 분할의 약점은 문맥이 잘리는 지점에서 드러난다. 예를 들어 같은 길이로 계속 자르면 A 청크와 B 청크의 경계에 걸친 내용이 어느 쪽에서도 온전히 검색되지 않는다. 그래서 앞뒤 청크가 일정 부분 겹치도록 오버랩을 두는 재귀적 분할이 쓰인다. 1000바이트 단위로 자를 때 100바이트 정도를 겹치게 하면, 한쪽 청크만 검색되더라도 끊긴 문맥을 어느 정도 이어서 답할 수 있다.

진짜 문제는 그다음이다. 금융·제조·의료의 매뉴얼과 기술 문서, 지침과 공문서에는 표와 조항이 섞여 있어서 자동 분할이 문맥을 끊어 버린다. 발표자는 헤더를 기준으로 논리 단위를 나누고 메타데이터를 주입하며, 표는 LLM이 읽을 수 있도록 마크다운 형태로 바꿔 주는 방식을 제시한다. 법령이라면 최소 독립 단위인 '항'을 기준으로 자르되, 각 항마다 어떤 법 몇 조에 속하는지를 반드시 함께 넣어 줘야 한다. 다른 조문을 근거로 삼는 관계는 지식 그래프로 연결해 함께 제공하는 방향을 제안한다.

마지막으로 자동화 여지로 시맨틱 청킹이 소개된다. 문장 단위로 자른 뒤 임베딩해 앞 문장과의 유사도를 재고, 임계치 아래로 뚝 떨어지는 지점을 화제 전환으로 보고 청크를 끊는 방식이다. 오버랩 없이도 깔끔하게 나뉘지만, 구두점이 분명하지 않으면 문장 경계를 알기 어렵고 표나 조항이 있는 규정·지침에는 쓰기 어렵다. 결론은 데이터 유형별로 전략을 달리하고, 필요하면 지식 그래프까지 섞은 하이브리드로 가야 한다는 것이다.

주요 인사이트

  • RAG 품질이 나쁠 때 사람들은 검색이나 모델을 먼저 의심하지만, 발표자는 원인의 상당 부분이 문서를 자르는 단계에 있다고 본다. 답변이 이상한 것은 LLM이 말을 못해서가 아니라 잘못 잘린 조각을 받았기 때문일 수 있다.
  • 의미가 비슷해도 구조가 다르면 답이 틀린다. 5페이지의 조항과 1000페이지의 조항이 문장으로는 유사해 일반 벡터 검색에서 함께 끌려오지만, 사용자가 원한 것은 한쪽뿐이다. 체계와 위계 정보를 청크에 심어 두지 않으면 이 혼선을 막을 수 없다.
  • 완전 자동화에 대한 기대를 낮추는 것이 오히려 실무적이다. 자동 분할만으로는 프로토타입까지는 가지만 제품 수준은 어렵고, 표와 조항이 있는 문서일수록 사람이 한 번씩 눈으로 확인하는 과정이 필요하다.
  • 청킹은 단일 정답이 아니라 데이터 유형별 선택의 문제다. 줄글과 기사에는 시맨틱 청킹이, 규정·법령에는 구조 기반 분할과 메타데이터 주입이, 그 사이에는 하이브리드가 맞는다는 식으로 접근해야 한다.

자주 묻는 질문

청크에 오버랩을 두는 이유는 무엇인가요?

같은 길이로 문서를 자르면 경계에 걸친 내용의 문맥이 끊어져, 한쪽 청크만 검색됐을 때 LLM이 잘린 의미로 답하게 됩니다. 앞뒤 청크가 일부 겹치도록 오버랩을 두면(예: 1000바이트 청크에 100바이트 정도) 한쪽만 검색돼도 끊긴 문맥을 어느 정도 이어서 답할 수 있습니다.

법령 문서는 어떻게 나누는 것이 좋다고 하나요?

조 단위는 너무 커서, 최소 독립 단위인 '항'을 기준으로 자르는 방식을 제안합니다. 다만 항만 떼어 두면 어떤 법 몇 조에 속한 항인지 알 수 없으므로 상위의 법령명과 조 정보를 반드시 함께 넣어 주고, 다른 조문을 근거로 삼는 관계는 지식 그래프로 연결해 함께 제공하는 것이 좋다고 설명합니다.

시맨틱 청킹은 어떤 방식이며 한계는 무엇인가요?

문장 단위로 자른 뒤 임베딩해 앞 문장과의 유사도를 계산하고, 유사도가 임계치 아래로 크게 떨어지는 지점에서 청크를 끊는 방식입니다. 오버랩 없이도 깔끔하게 나눌 수 있지만, 구두점이 분명하지 않아 문장 경계를 알기 어려운 경우나 표·조항이 포함된 규정·지침 문서에는 적합하지 않습니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식