RAG 시스템 구축을 위한 청킹(Chunking) 전략 조언

오픈소스 LLM의 파인튜닝 없이, 알려진 LLM을 활용하여 법령 문서에 대한 RAG 시스템의 청킹(Chunking) 문제를 해결하는 것은 충분히 가능하며 효율적인 접근 방식입니다.

법령 문서는 일반 텍스트와 달리 강력한 계층적 구조를 가지고 있기 때문에, 단순한 고정 길이(Fixed-size) 청킹보다는 구조를 활용한 청킹 전략이 필수적입니다.

1. 법령 문서에 최적화된 청킹 전략: 구조 기반 청킹

법령 문서는 장(章) → 절(節) → 조(條) → 항(項) → 호(號)와 같은 명확한 계층을 따릅니다.

이 구조를 활용하여 정보의 독립된 단위를 기준으로 청크를 생성해야, 검색된 청크만으로도 LLM이 완전한 맥락을 파악하고 정확하게 답변할 수 있습니다.

청크 단위	특징 및 장점	활용 조언
조(條)	가장 이상적인 청킹 단위. 하나의 조항(예: ‘제45조 (벌칙)’)은 대체로 하나의 완성된 법적 의미를 담고 있습니다.	청크의 크기가 너무 크지 않다면, 조(條) 전체를 하나의 독립된 청크로 사용하는 것이 가장 좋습니다.
항(項)	조가 너무 긴 경우 (특히 복잡한 정의나 예외 조항), 항(項)을 단위로 분리합니다.	항을 분리할 때는 반드시 상위 조(條)의 제목과 번호를 메타데이터로 첨부해야 합니다.
재귀적 청킹	먼저 조 단위로 나눈 후, 조의 길이가 너무 길면 항 단위로 재귀적으로 나누는 방식입니다.	이 접근법이 법령 데이터에 가장 추천됩니다.

핵심: 단순히 텍스트를 자르는 것이 아니라, 법령의 의미적 경계를 따라 잘라야 합니다.

일반적인 청킹 라이브러리(예: LangChain의 Splitter) 외에, LLM의 능력을 활용하여 더 똑똑하게 청크를 나눌 수 있습니다.

파인튜닝 없이도, LLM은 구조 파악 능력과 문맥 이해 능력이 뛰어나기 때문입니다.

프롬프트 설계: 법령 원문 전체를 LLM에 입력합니다.
지시:

“위 법령 문서를 JSON 또는 XML 형식으로 파싱해 주세요. 각 조(條)를 독립된 객체로, 항(項)을 그 객체의 속성으로 구분해 주세요.”
결과 활용: LLM이 출력한 구조화된 JSON/XML 파일에서, 각 조(條) 또는 항(項) 블록을 추출하여 최종 청크로 사용합니다.

청크 분할 지점 파악: 법령 문서를 작은 단위(예: 문장)로 나눕니다.
LLM 판단: 인접한 두 문장이 서로 다른 주제를 다루기 시작하는 지점인지 LLM에게 판단하도록 합니다.

“이전 문장과 다음 문장이 다루는 법적 주제가 바뀌었는지 판단하고 ‘True’ 또는 ‘False’를 반환하시오.”
결과 활용: LLM이 ‘True’를 반환한 지점에서 청크를 나누어 의미적으로 응집력 있는 청크를 생성합니다.

청킹 후에는 각 데이터베이스에 다음 메타데이터를 필수적으로 저장하여 검색의 품질을 높여야 합니다.

데이터베이스	저장 항목	활용 목적
RDB (원본 관리)	청크 ID (PK), 법령 이름, 조/항/호 번호, 개정일자, 원본 텍스트	구조화된 필터링 및 원본 출처(Citation) 표시
Vector DB (Milvus)	임베딩 벡터, 청크 ID, 법령 이름, 조 번호	검색된 임베딩이 어떤 법령의 어느 조항인지 식별하여 RDB나 Graph DB 연동
Elasticsearch	원본 텍스트, 청크 ID, 조 번호	키워드 검색 후, 해당 조 번호를 통해 RDB 및 Vector DB와 상호 참조
Graph DB	노드: 법령명, 조 번호 / 엣지: ‘참조함’, ‘상위법이다’	검색된 청크와 관련된 다른 조항이나 법령의 맥락 정보 탐색