#분산된 문서 증거를 어떻게 조립하는가 — 본문·각주·부록

← 전체 목차 · 이전: Rerank 모델은 언제 반드시 필요한가 · 다음: 신구 제도가 동시에 존재하면 어떻게 처리하는가

전형적인 오답: 본문·각주·부록을 전부 펼쳐서 하나의 초장문으로 이어 붙인 뒤 평범하게 청킹하고 인덱스를 만들면 "모델이 자연히 모든 정보를 보게 된다".

틀린 이유: 평탄한 접합은 문서의 구조 계층을 잃는다.

본문·부록·각주는 출처 등급과 신뢰도가 완전히 다르므로, 한 덩어리로 이어 붙이면 "부록의 세부 조항을 본문과 동급의 강제 약정으로 취급"하기 쉽다.

핵심 답변: 문서에 평탄화 청킹이 아니라 계층화 청킹을 하고, 각 조각이 원문서에서의 위치 경로를 지니게 하며, 생성 단계에서 출처 계층에 따라 가중 융합해 부록 조항이 본문 주간을 슬그머니 대체하지 못하게 한다.

#1층: 계층화 청킹과 위치 앵커링

구매 계약을 예로 들면 명확한 구조가 있다: 서명 당사자 / 본문 조항 / 페이지 각주 / 부록A.

청킹 시 이 계층 관계를 반드시 보존해야 한다. 각 조각에 세 개의 메타데이터 라벨을 붙여 벡터와 함께 인덱스에 저장한다.

1. 블록 유형(본문 / 부록 / 각주)
2. 문서 트리 경로
3. 동급 순번

경로의 형태:

본문 제7조 제5항 제3목  →  "본문/제7조/제5항/제3목"
부록A 위약 책임 제1조    →  "부록A/제1조"

효과: 모델이 답을 생성할 때 내용이 본문에서 왔는지 부록에서 왔는지 각주에서 왔는지 볼 수 있으므로, 서로 다른 출처에 서로 다른 가중치를 자연스럽게 부여한다.

#2층: 구조 인지 리콜

청킹에 라벨을 붙이는 것만이 아니라 검색 자체도 구조 정보를 활용해야 한다.

사용자 질문: "이 계약의 위약금은 어떻게 계산하나요?"

문제: 본문의 그 "부록A 참조"는 답 자체가 아니라 답의 위치를 가리킬 뿐인데 리콜 자리를 하나 차지하면서 정보를 담고 있지 않다.

#구조 인지 리콜의 두 동작

동작 1: 엔티티에 따라 계층 선택
  「위약금」이라는 엔티티를 식별
  → 본문이 아니라 【부록 블록】을 우선 검색
  이유: 위약 책임의 상세 조항은 부록에 나타나는 경향이 있다

동작 2: 인용 연동
  검색 결과에 「부록X 참조」 같은 인용 문장이 나타나면
  → 인용된 【부록 블록】을 자동 추적
  → 연동 리콜하여 「인용 대상」과 「출처」를 동시에 반환

#3층: 출처 가중 융합

모든 관련 조각이 계층 경로를 지닌 채 리콜된 뒤, 답을 생성할 때의 출처 가중 전략이다.

본문 신뢰도  >  부록  >  각주

왜 반대가 아닌가:

• 부록이 아무리 상세해도 본문 틀 아래의 전개이고,
• 각주는 해석적 설명일 뿐이다.

#Prompt에 출처 계층을 명시적으로 주입

이렇게 해야 모델이 생성 시 어떤 문장에 힘을 실을지, 어떤 문장에 "부록A에 따르면"이라는 접두를 붙일지를 안다.

#4단 링크

1. 적재 시 계층화 파싱 — 본문·부록·각주 블록을 식별하고 경로 라벨을 생성한다.
2. 청킹 시 경로 메타데이터를 보존해 내용과 함께 인덱스에 저장한다.
3. 검색 시 구조 인지 전략을 지원한다 — 증거 유형에 따라 검색 계획을 우선 생성하고, 인용 문장에 대해 연동 리콜을 자동 발동한다.
4. 생성 시 출처 계층에 따라 신뢰도 가중치를 부여한다 — 본문은 고신뢰, 부록은 중상, 각주는 참고급.

#가점 요소와 나쁜 경로

가점 요소 — "계층이 너무 많으면 어떻게 수렴시키나?"라는 추가 질문에 대해:

• 일반적인 계약은 3단계면 충분하다: 본문 주조항 / 부록 세칙 / 각주 주석.
• 5~6단계까지 복잡하다면 계층 접기 전략으로 인접한 세부 계층을 병합한다.

나쁜 경로 — 정규식으로 「부록」「각주」 키워드를 하드 매칭해 계층을 식별하는 것:

• 영문 계약에서는 Schedule, Exhibit, Footnote 세 단어를 쓴다.
• 정규식이 전부 누락되고 시스템이 무력화된다.

#핵심 통찰

1. 청킹의 단위는 문자가 아니라 "문자 + 문서 트리에서의 위치"다 — 평탄 접합은 주종이 있는 트리를 하나의 목록으로 눌러 버린다. 정보량은 줄지 않은 것처럼 보이지만 실제로 잃는 것은 **"누가 누구를 구속하는가"**다. 위치 경로(본문/제7조/제5항/제3목)가 바로 그 눌린 차원을 인덱스에 되돌려 저장하는 것이다.
2. 문서 구조 자체가 신뢰도 신호다 — 본문은 핵심 약정, 부록은 보충 세칙, 각주는 해석 설명 — 이 우선순위는 문서 작성 관행이 자체적으로 갖고 있으므로 모델이 추측할 필요가 없다. 메타데이터로 만들면 한 겹의 증거 등급을 공짜로 얻는 셈이다.
3. "부록이 아무리 상세해도 본문 틀 아래의 전개"가 가중 정렬의 공리다 — 디테일의 풍부함 ≠ 구속력의 강도. 많은 사람이 직관적으로 "더 구체적인 조항이 더 권위 있다"고 여기는데 순서가 정확히 뒤집힌 것이다.
4. 일부 리콜 결과는 "답"이 아니라 "포인터"다 — 본문의 "위약 책임은 부록A 참조"는 벡터 공간에서 질문과 고도로 관련되지만 정보량은 0이다. 시스템이 포인터 계열 문장을 식별하고 그것을 따라가 진짜 내용을 가져올 수 있어야 하며, 그렇지 않으면 유사도가 높을수록 답이 비어 간다.
5. 엔티티 유형이 검색이 어느 계층으로 가야 하는지를 결정할 수 있다 — 「위약금」 같은 엔티티의 상세 조항은 부록에 떨어지는 경향이 있으므로, 엔티티를 식별한 뒤 부록 블록을 먼저 검색한다. 검색 계획이 증거 유형에 의해 구동되어야지 전 라이브러리에 일률적으로 점수를 매기는 것이 아니다.
6. 구조 정보는 생성 단계에서 "말로 표현되어야" 모델이 쓴다 — 출처 계층을 메타데이터에만 저장해 두는 것은 소용없고, Prompt에 "주요 증거 / 보충 증거 / 보조 참고"로 명시해야 가중치가 실제로 어투에 작용한다 — 힘을 싣거나, "부록A에 따르면"이라는 접두를 붙이거나.
7. 계층은 많을수록 좋은 것이 아니라 수렴할 수 있어야 한다 — 3단계(본문 주조항 / 부록 세칙 / 각주 주석)면 충분하고, 5~6단계를 넘으면 인접한 세부 계층을 접어 병합한다. 계층 설계의 목표는 판정 가능성이지 복원 가능성이 아니다.
8. 키워드 정규식으로 구조를 식별하는 것은 취약한 설계다 — 영문 계약으로 바꾸면 Schedule / Exhibit / Footnote가 하나도 매칭되지 않아 계층 식별 전체가 조용히 실효하며, 이런 실패는 에러도 내지 않고 답만 서서히 틀려지게 만든다.

#엔지니어링 실전 Tips

• 경로는 사람이 읽을 수 있는 문자열로 쓸 것: 본문/제7조/제5항/제3목, 부록A/제1조. 메타데이터 필터 조건이면서 최종 답변에 그대로 인용할 수 있는 출처이기도 하다.
• 동급 순번을 생략하지 말 것: 블록 유형이 "무엇인지", 문서 트리 경로가 "어디인지", 동급 순번이 "몇 번째인지"를 주므로 셋이 갖춰져야 같은 계층 안에서 위치를 특정하고 정렬할 수 있다.
• "포인터 문장"을 탐지 가능한 패턴으로 취급할 것: 부록X 참조 같은 인용 문장이 연동 리콜을 발동시키고, 반환 시 인용 대상과 출처를 함께 모델에 주어야 모델이 "부록A에 따르면…" 같은 출처가 담긴 문장을 말할 수 있다.
• 우선순위 라벨을 Prompt 본문에 쓸 것(메타데이터에만 남기지 말 것): 주요 증거 / 보충 증거 / 보조 참고 3등급이 생성 시 어투의 강도를 직접 결정한다.
• 가중 정렬의 이유를 한 문장으로 말할 수 있어야 한다: 부록은 본문 틀 아래의 전개, 각주는 해석적 설명. 설계 리뷰에서 순서를 외우는 것보다 이유를 말할 수 있는 편이 값지다.
• 정규식으로 구조 키워드를 매칭하지 말 것: 계층 식별은 문자열 매칭이 아니라 파싱으로 가야 한다.
• 계층 접기는 타협이 아니라 운영 수단이다: 문서가 본래 5~6단계일 때 인접한 세부 계층을 병합해 계층 수를 판정 가능한 3단계 수준으로 되돌린다.
• 더 파고들 방향: 구조 파서 자체의 구현(PDF/DOCX 블록 식별과 다국어 적응), 검색 계획 라우팅 규칙의 유지 관리(「위약금 → 부록 우선」 같은 엔티티-계층 매핑을 규칙 표로 할지 학습형 라우팅으로 할지), 연동 리콜의 예산 통제(다단계 인용 시 깊이와 중복 제거), 신뢰도 가중치의 정량화와 검증.