#신구 제도가 동시에 존재하면 어떻게 처리하는가 — 버전 재정의 전치

← 전체 목차 · 이전: 분산된 문서 증거를 어떻게 조립하는가 · 다음: 대량 제로 리콜은 어떻게 트러블슈팅하는가

기업 지식베이스에서 신구 제도가 병존할 때 의미 유사도로만 리콜하면 반드시 구 제도를 현행 규칙으로 설명하게 된다. 두 버전 모두 관련 있고 모두 권위 있게 쓰여 있기 때문이다.

피해야 할 답변: "최신 문서를 리콜한다"만 답하는 것. 이유: 최신 ≠ 적용, 최신 ≠ 이미 발효.

#진짜 쟁점: 메타데이터 거버넌스 + 답변 재정

핵심 판단: 기업 지식베이스에서 문서는 애초에 평등하지 않다.

#총론: 버전 재정을 검색층과 증거층으로 전치

1. 버전 정보를 텍스트에서 뽑아내 필터 가능·비교 가능·설명 가능한 메타데이터로 만든다.
2. 검색 시 사용자 시나리오로 적용 범위를 먼저 필터링한다.
3. 그다음 발효 시간 + 권위 계층으로 증거를 선택한다.
4. 충돌 시 버전 차이를 보여주고, 모델의 자유로운 추측을 금지한다.

#1단계: 적재 시 메타데이터 추출

추출해서 적재해야 할 9개 필드:

1. 제도 명칭
2. 버전 번호
3. 발행 일자
4. 발효 일자
5. 폐지 일자
6. 사용 조직
7. 주관 부서
8. 초안 여부
9. 날인 여부

전형적 장애 근인: 시스템이 본문만 저장하고 이 통제 필드들을 저장하지 않았다.

예 — 사용자가 "지금 경비 정산이 가능한가요?"라고 물을 때

#2단계: 검색 시 먼저 필터링하고 나서 재정렬

반면 사례: 사용자가 화남 지사 직원인데 본사 구 제도와 지사 신 제도를 모두 모델에 던져 스스로 판단하게 한다.

1단계: 메타데이터 필터   [조직] [시간] [문서 상태]
            ↓
2단계: 재정렬 모델        관련성 비교

핵심 정렬 원칙: 고위험 제도 문답에서 메타데이터 필터의 우선순위는 흔히 의미 유사도보다 높다.

#3단계: 충돌과 경과 기간 처리

실제 제도에서 흔한 경과 규정 형태:

• 특정 일자 이전은 구 규칙, 이후는 신 규칙.
• 기존 주문은 구 규칙, 신규 주문은 신 규칙.

피해야 할 답변: "최신 버전을 고른다"만 답하는 것. 적용성 판단을 말해야 한다.

#표준 답안

저는 적재 단계에서 발효 일자, 폐지 일자, 버전 번호, 조직 범위, 발행 상태를 추출하고, 검색 시 사용자 신원·시간·시나리오에 따라 먼저 필터링하며, 리콜·재정렬·생성 시 현행 유효 버전을 인용합니다. 경과 기간이나 충돌을 만나면 조건을 설명하고 추가 질문을 합니다. 이렇게 해야 RAG가 구 제도를 신 규칙으로 답하지 않습니다.

한 단계 위의 정리: 버전 문제는 Prompt로 완전히 해결할 수 있는 것이 아니라 지식베이스 거버넌스 문제다. 메타데이터 필터 / 권위 계층 / 경과 기간 / 충돌 처리 네 가지를 설명할 수 있어야 **"기업 RAG는 검색 엔진이 아니라 업무 기준을 지닌 문답 시스템"**임을 이해한 것이다.

#검수 방식과 프로덕션 모니터링

검수셋 구성: 동명 제도의 신 버전 vs 구 버전 / 부서별 버전 / 초안판 vs 정식판.

판정 규칙: 시스템이 답할 때 반드시 적용 시간과 적용 대상을 설명해야 한다. 다음 중 하나라도 나타나면 실패다.

• 구 버전을 인용해 현재 질문에 답함
• 초안을 정식 제도로 취급함

프로덕션 모니터링: 적중 문서의 버전 분포. 구 버전이 자주 리콜되면 → 필터 규칙과 문서 상태 라벨을 점검할 것.

#출시 점검과 회귀 테스트

모든 방안에는 세 가지 부속물이 필요하다: 관측 가능 지표 + 실패 샘플 + 롤백 동작.

아래 네 종류의 변경은 전부 같은 회귀 샘플 묶음으로 다시 돌려야 한다.

핵심 관측 지표 5종: 정확률 / 경로 안전 / 인용 품질 / 비용 / 지연.

프로덕션 클로즈드 루프: 실제 Trace 샘플링 → 실패 샘플 추출 → 평가셋에 환류. 단일 최종 답변이 보기 좋은지만 보지 말고 동종 작업이 전체적으로 더 안정적인지를 볼 것.

#핵심 통찰

1. 의미 유사도는 구조적으로 "유효성"을 표현할 수 없다 — 유사도가 재는 것은 "닮았는가"인데, 발효 여부는 불리언형 업무 사실이다. 답이 사실성 속성(시간, 조직, 상태)에 좌우되는 모든 문답은 벡터 거리가 아니라 구조화 필터로 해결해야 한다.
2. 문서는 애초에 평등하지 않다 — 이것이 기업 RAG와 개방 도메인 RAG의 분수령이다. 개방 도메인은 "관련되면 쓸 수 있다"고 가정할 수 있지만, 기업 도메인은 먼저 **"이 문서가 이 사람에게, 이 시각에 유효한가"**에 답해야 한다.
3. 재정은 전치해야지 모델에게 후치하면 안 된다 — 충돌을 LLM에게 던져 "스스로 판단"하게 하는 것이 가장 흔한 아키텍처 오류다. 검색층/증거층으로 전치해야 결과가 설명 가능하고, 감사 가능하고, 회귀 테스트 가능해진다.
4. "최신"은 서로 독립적인 세 개념의 혼동이다 — 최신(버전 번호가 큼), 적용(조직/시나리오 매칭), 발효(시간 창 안). 셋은 서로 독립적이며, 어느 하나의 차원으로만 정렬하는 모든 방안은 틀린다.
5. 메타데이터 추출의 실패점은 검색이 아니라 적재에 있다 — "본문만 저장하고 통제 필드를 버린 것"이 근인이다. 검색층을 아무리 최적화해도 적재 시 뽑지 않은 필드를 복원할 수는 없다.
6. 경과 기간 규정은 답이 확정값이 아니라 조건을 담을 것을 요구한다 — "특정 일자 이전은 구, 이후는 신"이란 정답 자체가 조건 표현식이라는 뜻이다. 시스템이 "X에 따라 다릅니다"를 출력하고 능동적으로 추가 질문하는 것을 허용하는 것은 체감 결함이 아니라 정확률의 일부다.
7. 재정할 수 없을 때 사람에게 인계하는 것도 정답의 한 형태다 — "충돌을 나열하고 사람에게 인계"를 시스템 능력 경계에 설계해 넣는 편이, 자신 있게 틀린 답을 억지로 주는 것보다 기업 컴플라이언스에 부합한다.
8. 평가는 단일 출력의 매끄러움이 아니라 동종 작업의 전체 안정성을 봐야 한다 — 단일 case의 인상은 오도되기 쉽고, 고정 회귀 샘플 + 5개 지표(정확률/경로 안전/인용 품질/비용/지연)라야 비교 가능한 기준이 된다.

#엔지니어링 실전 Tips

• 버전 통제 필드를 점수 특징이 아니라 하드 필터 조건으로 만들 것: 발효 일자·폐지 일자·조직 범위는 벡터 검색의 전치 filter로 써야지, 재정렬 모델이 그것들을 "저울질"해 주기를 기대하면 안 된다.
• 「초안 여부」「날인 여부」 같은 승인 상태 필드를 반드시 적재할 것: 초안이 정식 제도로 답변되는 것은 기업 시나리오에서 위해가 가장 큰 실패 유형이며, 본문 내용만으로는 전혀 식별할 수 없다.
• 변경(Prompt 수정 / 모델 교체 / 검색 전략 교체 / 도구 설명 교체)마다 같은 회귀 샘플을 돌릴 것: 그렇지 않으면 어느 변경이 퇴보를 유발했는지 귀인할 수 없다.
• 방안마다 3종 세트를 갖출 것: 관측 가능 지표, 실패 샘플, 롤백 동작. 하나라도 빠지면 출시하지 말 것.
• 5개 지표를 함께 볼 것: 정확률만 최적화하면 비용과 지연의 악화를 대가로 치르는 경우가 많다.
• Trace 샘플링 → 실패 샘플 → 평가셋 환류의 클로즈드 루프를 구축할 것: 프로덕션의 실제 실패가 오프라인 평가셋을 지속적으로 보충하게 한다.
• 「적중 문서 버전 분포」 모니터링은 저비용 고신호 프로덕션 지표다: 구 버전 비중의 이상 상승은 거의 반드시 필터 규칙이나 상태 라벨의 문제에 대응한다.
• 더 파고들 방향: 「권위 계층」을 비교 가능한 점수로 정량화(그룹 > 사업부 > 지사)해 일률적 사람 인계 대신 자동 재정 구현, 경과 기간 규정의 구조화 표현 설계(발효 구간 + 적용 대상 술어)로 조건식 답변 출력, 「구 버전 인용 / 초안을 정식으로 취급」 두 실패 유형을 자동화 레드팀 케이스로 만들어 CI에 연결.