02. 보험 약관을 일정한 글자 수로 자르면 안 되는 이유

Posted Sep 17, 2026 Updated Sep 23, 2026

By figure.2

6 min read

“제3조”만 남은 chunk는 검색할 수 있어도 무슨 담보의 제3조인지 알기 어렵습니다. 자동차 보험 약관에는 보통약관, 특별약관, 담보, 조, 항이 겹쳐 있습니다. 표 안의 금액과 본문의 조건이 서로 연결되기도 합니다.

Insurance_PF에서는 글자 수를 기준으로 자르기 전에 약관의 제목 경로를 복구하는 데 시간을 썼습니다.

원문을 요약하지 않고 구조를 보존했다

전처리 입력은 Upstage Parser로 변환한 보험사별 JSON이었습니다. 요약문을 새로 만들지 않고 원문을 검색 단위로 사용했습니다.

보험 약관은 한 단어가 보상 여부를 바꿀 수 있습니다. 생성 모델로 미리 요약하면 제외 조건이나 예외 문장이 사라질 수 있습니다. 검색 단계에서는 원문을 유지하고, 사용자에게 설명할 때만 생성 모델을 사용하기로 했습니다.

Parser element의 heading 정보를 따라 breadcrumb를 만들었습니다. 각 chunk에는 source file, 보험사, 약관 유형, page range를 함께 저장했습니다.

보통약관 → 배상책임 → 대인배상 → 제3조

이 경로가 있으면 같은 “제3조”라도 어느 담보에 속하는지 구분할 수 있다. 보험사나 약관 유형을 기준으로 필터링할 때도 metadata를 사용할 수 있다.

초기 sample 검사에서는 breadcrumb 누락 28건과 초단문 chunk 33건이 발견됐다. Parser가 꺾쇠나 괄호로 시작하는 소제목을 heading이 아니라 paragraph로 분류하는 경우가 있었다.

세 가지 보정 규칙을 추가했다.

이 규칙은 특정 보험사 sample에서 breadcrumb 누락과 제목 파편화를 줄였다. 그러나 전체 corpus 검증에서는 길이 50자 미만 chunk가 107개 남았다. Sample에서 해결됐다는 결과를 전체 데이터의 0건으로 확대하지 않았다.

Parser가 반환한 HTML table을 단순 문자열로 펼치면 행과 열의 관계가 사라진다. 보장 등급과 금액을 연결해야 하는 질문에서는 이 손실이 계산 오류로 이어질 수 있다.

HTML table을 Markdown table로 변환해 chunk에 포함했다. 전체 6,402개 가운데 1,046개, 약 16.3%에 Markdown table 문법이 남았다.

이 처리가 표의 의미를 완전히 보존한다는 뜻은 아니다. 병합된 cell, 여러 페이지에 걸친 표, 각주는 별도 검사가 필요하다. 다만 행과 열을 무시한 일반 텍스트보다 생성 모델이 구조를 확인할 수 있는 입력을 제공했다.

11개 보험사 데이터를 처리한 전체 검증 결과는 다음과 같다.

반복 header와 footer는 정규식으로 제거했지만 일부 짧은 문장과 OCR 잔여물은 남았다. 로그에서는 전체 성능 영향이 작다고 판단해 수용했지만, 지금 다시 한다면 107개를 유형별로 분류하고 retrieval 평가에 미치는 영향을 따로 확인할 것이다.

구조를 보존했다고 검색이 자동으로 맞아지지는 않았다. Breadcrumb에 약관 용어가 들어 있어도 사용자가 다른 표현을 쓰면 BM25가 놓칠 수 있다. 표가 남아 있어도 생성 모델이 조건과 금액을 잘못 계산할 수 있다.

이 단계에서 확인한 것은 corpus의 구조와 metadata다. 검색 정확도와 답변 정확도는 이후 단계에서 별도로 평가했다. 세 검증을 한 문장으로 묶어 “약관 데이터 품질을 확보했다”고 쓰지 않는 이유다.

This post is licensed under CC BY 4.0 by the author.