루브릭이 선언한 오해 46개 중 강제되는 건 라이브러리 9종뿐이다 — 나머지는 프롬프트 문면일 뿐이고, 모델이 놓치면 아무 일도 안 일어난다

[yoonjiseok]

@gitIt-sehyeon @hd0rable — #279(eval 재생성)에서 두 분이 독립으로 같은 지적을 하셔서
원인을 팠다. 개별 결함이 아니라 구조적 공백이었다.

발단 — els-0028 이 U4 → U2 로 내려갔다

발화   "지수만 안 빠지면 되는 거 아니에요? 회사가 망하는 건 별개 문제고요."
항목   ELS-ISSUER-CREDIT-RISK          gemini U4  →  gpt-5-mini U2

두 분 다 루브릭 문면으로 대조해서 U4 가 맞다고 읽으셨다. 그 근거가 이것이다.

misconception_conditions:
  - 기초자산만 오르면 안전하다      ← 발화가 거의 그대로다

루브릭은 이 오해를 이미 선언해 놨다. 그런데도 통과했다.

왜 통과했나 — floor 는 이 목록을 안 본다

misconception_conditions   프롬프트에 실린다.  모델이 읽고 판단한다      → 강제력 없음
related_misconceptions     apply_misconception_floor 가 등급을 U4 로 올린다 → 강제력 있음

두 목록이 서로 대조되지 않는다. ELS-ISSUER-CREDIT-RISK 의 related 는
M01-PRINCIPAL-GUARANTEE · M02-DEPOSIT-INSURANCE 인데 둘 다 "기초자산만 오르면 안전하다"
와 무관하고, 애초에 발행사 신용위험에 해당하는 유형이 9종 안에 없다.

실측이다.

[ELS] "지수만 안 빠지면 되는 거 아니에요? 회사가 망하는 건 별개 문제고요."  → 매칭 없음
[ELS] "증권사가 망할 리가 있나요"                                        → 매칭 없음   ← ❗

두 번째가 중요하다. 증권사가 망할 리 없다 는 선언된 조건과 사실상 같은 문장인데도
라이브러리가 못 잡는다. 즉 선언된 조건은 매처의 입력이 전혀 아니다 — 매칭은
misconceptions.yaml 의 patterns 라는 별개의, 더 좁은 어휘로만 돈다.

공백의 크기

루브릭 17개가 선언한 오해 조건   46개
라이브러리 유형                   9종  (M07 은 근거 미확보로 삭제됨)
related 보다 조건이 많은 루브릭   15 / 17

가장 눈에 띄는 것.

VAR-PARTIAL-DEPOSIT-INSURANCE   조건 3개 · related 0개   ← floor 가 영원히 안 걸린다
    · 예금처럼 전액 보호된다
    · 전혀 보호되지 않는다
    · 낸 보험료 전액이 보호 대상이다

첫 조건은 누가 봐도 M02-DEPOSIT-INSURANCE 자리인데 링크가 비어 있다. 이건 단순 누락으로
보인다. (실측: "예금처럼 전액 보호되는 거죠?" → 매칭 없음.)

M08-TYING 을 아무 루브릭도 related 로 안 거는 것은 정상이다 — #205 가 상신
신호를 루브릭 필터 밖에서 만들도록 갈랐다. 이걸 "빠졌다" 고 보고 채우면 #160 이
되돌아간다.

왜 이게 우리가 계속 고쳐 온 것과 같은 모양인가

굳은 원칙 두 개에 정면으로 걸린다.

모델 출력을 그대로 믿지 않는다 — 스팬은 원문에서 계산, 유형ID 는 라이브러리에서만,
mismatch·confidence 는 재계산.

모델이 못 하는 판정은 계산으로 내린다 — 복창 판정이 그 사례다.

여기는 규칙을 선언까지 해 놓고 강제를 모델에게 맡겼다. 그리고 #268 에서 확인한 것과
같은 자리다 — 거기서도 R-05 를 실제로 발동시킨 건 우리 계산(복창 캡)이었지 모델이 아니었다.

실패 방향이 미탐이라는 게 제일 나쁘다. U4 → U2 면 게이트가 R-01 RED 대신 R-04
YELLOW 를 낸다. 라벨링 지침 §2.1 이 U4 를 맨 앞에 둔 이유를 강희진이 #279 리뷰에서
그대로 인용하셨다 — "U2 로 붙이면 게이트가 통과시킨다. 이 시스템에서 제일 비싼 오류."

지금 있는 방어로는 안 잡힌다

rubrics.assert_related_misconceptions_exist() 는 참조된 ID 가 실재하는지만 본다.

missing = [t for t in rubric.related_misconceptions if t not in known]

related 가 비어 있거나 조건과 안 맞는 경우는 통과한다. 이 함수가 생긴 계기가
M07-YIELD-OVERCONFIDENCE 삭제였는데, 그때 남은 조건들이 어디로 갔는지는 아무도 안 봤다.

선택지 — (c) + (a) 를 권한다

	무엇	누구	리허설 전
(a)	라이브러리에 유형·패턴 추가 (발행사 신용위험 등) + VAR-PARTIAL 링크	정세현 데이터	링크만이면 가능
(b)	floor 가 misconception_conditions 문면도 유사도로 본다	내 엔진	안 한다
(c)	공백을 로딩 시점에 드러낸다 — 조건마다 강제/권고를 명시	내 영역	안전

(b) 는 리허설 전에 하지 않는다. 과탐 방향이라 게이트로선 안전한 실패지만, 채점 동작을
이틀 전에 바꾸면 데모에서 어떻게 나올지 재 볼 시간이 없다. 3주차 정량평가 뒤에 본다.

(c) 는 채점을 안 건드린다. 지금은 46개 중 무엇이 강제되고 무엇이 권고인지 코드도 문서도
말하지 않는데, 그걸 루브릭에 명시하게 하고 로딩 시점에 대조한다. 우리가 반복해서 쓴
"조용한 실패를 로딩 시점으로 끌어올린다" 와 같은 처리다.

(a) 중 VAR-PARTIAL-DEPOSIT-INSURANCE 링크 하나는 리허설 전에도 값이 있다 —
변액 예금자보호는 데모 시나리오에 들어가고, 지금은 그 항목의 결정론적 상향이 아예 없다.

물어보는 것

1. @gitIt-sehyeon — VAR-PARTIAL-DEPOSIT-INSURANCE 의 M02 링크 누락이 의도인가?
   의도가 아니면 리허설 전에 붙이고 싶다(루브릭은 내 파일이라 내가 낸다).
2. @gitIt-sehyeon — 발행사 신용위험 유형 추가는 source 근거가 필요할 텐데(8건이 아직
   TODO 인 것과 같은 문제) 3주차로 미루는 게 맞나?
3. @hd0rable — (c) 로 드러난 공백이 게이트 쪽 판단에 영향을 주나. #268 → #275 에서
   "게이트가 우리가 계산한 값에만 반응한다" 를 정리하셨는데, 그 계산의 적용 범위가
   선언된 것의 5분의 1 이라는 사실이 거기 붙는다.

측정 재현:

cd ai-service && .venv/bin/python -c "
import sys; sys.path.insert(0,\".\")
from app import misconception
print(misconception.match(\"증권사가 망할 리가 있나요\", \"ELS\").matches)"

[yoonjiseok]

@gitIt-sehyeon — 곁가지 둘. 둘 다 data/synth_sessions/distribution.yaml 얘기라 이슈를
따로 열지 않고 여기 붙인다. 본문(루브릭 46 vs 라이브러리 9)과 같은 파일들이 물려 있다.

① 본문을 고치면 대시보드 수치가 같이 움직인다

distribution.yaml 이 오해율을 내 루브릭에서 유도한다.

# 항목별 오해율을 임의로 고르지 않는다. 루브릭이 선언한 related_misconceptions 를 근거로 삼는다
misconception_weight:
  M01-PRINCIPAL-GUARANTEE: 8
  ...
# gen_synth_sessions.py 가 루브릭과 대조해 낡지 않게 잠근다
#   _assert_weights_cover · _assert_weights_match_counts

이 설계가 맞다. 손으로 적으면 어디서 온 값인지 아무도 모른다는 그 주석에 동의한다.
다만 그래서 본문의 (a)(라이브러리 링크 추가)를 하면 가중치가 바뀐다.

지금            M01:8 · M05:4 · M06:3 · M04:3 · M03:2 · M02:2 · M09:1 · M10:1
VAR-PARTIAL 에 M02 링크를 붙이면   M02: 2 → 3

_assert_weights_match_counts 가 그 순간 깨진다 — 그게 그 단정문이 있는 이유이니
정상 동작이다. 다만 누가 먼저 머지되든 다른 쪽이 깨진다는 것을 알고 있어야 한다.
내 루브릭 PR 을 낼 때 이 파일도 같이 고쳐야 하면 알려 달라(그쪽 파일이라 안 건드렸다).

주석에 "루브릭 17개 중 16개가 related 를 선언한다" 고 적혀 있는데, 그 1개가 본문에서
지적한 VAR-PARTIAL-DEPOSIT-INSURANCE 다. 이미 세어 보셨던 것 같다.

② ❗연령 대역 어휘가 세 곳에서 갈려 있다 — "70대 이상"

본문과 별개다. 오해 지도에 연령 축을 올릴지 보다가 나왔는데, 축과 무관하게 이미 돈다.

contracts/openapi.yaml          20대 30대 40대 50대 60대 70대 80대
web/src/lib/sessionAttrs.ts     20대 … 80대            ← enum 과 일치 ✅
vulnerability_weights.yaml      50대:1 60대:3 70대:4 80대:5
distribution.yaml:72            30대 40대 50대 60대 "70대 이상"    ← 어디에도 없는 값

openapi.yaml 의 ageBand 주석이 이 상황을 스스로 경고해 놨다.

목록에 없는 값을 보내면 400 이 아니라 조용히 0점이 되고, 취약 고객이 일반 고객으로
분류된다. 그래서 enum 으로 고정한다.

실제로 그렇게 된다.

// CoachingScoreService:54
return weights.getOrDefault(field, Map.of()).getOrDefault(value, 0);   // 모르는 값 → 0점

# scripts/gen_synth_sessions.py:194
"ageBand": rnd.choice(params["age_bands"]),      # 5분의 1이 "70대 이상"

SyntheticSessionLoader:135 가 DTO 를 안 거치고 세션을 직접 만들어서 enum 검증도 안 탄다.

무엇에 걸리나 — 지도가 아니다

vulnerable 이 실제로 움직이는 곳은 대시보드가 아니라 인터뷰 문면이다.

SessionService:266   String reverify = reverifyQuestion(itemId, session.vulnerable());
SessionService:273   return new ReExplanation(itemId, content, session.vulnerable(), reverify);

재검증 질문 문면이 갈리고, 재설명 렌더링 힌트(큰 글씨·비유)가 갈린다. 즉
합성세션의 5분의 1에서 제일 취약해야 할 대역이 일반 문면을 받는다. 취약 가중이 4점
(70대)이어야 할 자리가 0점이라 임계값 4 를 혼자서는 못 넘긴다.

지금은 잠들어 있다

data/synth_sessions/sessions.json     아직 생성 전 (없다)
web 은 enum 과 일치                    실제 세션은 안전

리허설에는 안 걸린다 — 합성세션을 켜지 않으면. 터지는 시점은 F-DSH-003 으로 100건을
돌릴 때이고, 그건 연령 축과 무관하게 예정돼 있다.

고치는 건 한 줄인데 그쪽 판단이 필요하다

- age_bands: ["30대", "40대", "50대", "60대", "70대 이상"]
+ age_bands: ["30대", "40대", "50대", "60대", "70대"]

일부러 묶으신 것일 수도 있다 — 80대 를 안 쓰려고 "70대 이상" 으로 합친 것이라면
의도가 있는 값이다. 그 경우 방향이 반대가 된다: vulnerability_weights.yaml 과
openapi.yaml 에 그 대역을 추가하는 쪽. 세 곳 중 둘이 남의 파일이라 내가 정할 수 없다.

참고 — 연령 축 자체는 지금 못 올린다

물어보신 게 아니지만 위 ②를 조사한 경위라 같이 남긴다. MIN_CELL_SAMPLE = 30 이 걸린다.

지금        상품×항목 23칸    100세션 × ~11항목 ≈ 1,150판정  →  칸당 ~50  (겨우 넘는다)
연령 추가   23 × 5 = 115칸                                  →  칸당 ~10  (거의 전부 가려짐)

연령을 축으로 올리려면 합성세션이 100 → 500건 이어야 한다. 그리고 연령별 오해 지도는
ADR-001 이 막으려는 것(타겟팅 재료)에 닿으므로 그 판단이 먼저다. 내 제안은 리허설·정량평가
뒤로 미루는 것이고, 지금 필요한 건 ②의 한 줄뿐이다.

[gitIt-sehyeon]

@yoonjiseok 1번은 누락이 아니라 우리가 내린 결정이다 — 그리고 그 결정을 그쪽이 루브릭 헤더에 직접 적어 뒀다. 2번은 반대로, 미룰 이유로 든 것이 이미 풀려 있다. 재 보고 답한다.

---

1. VAR-PARTIAL-DEPOSIT-INSURANCE 의 M02 링크 — 의도다

본문이 "이건 단순 누락으로 보인다" 라고 적었는데, 그 파일 머리말에 이유가 있다.

# ai-service/app/rubrics/VAR-PARTIAL-DEPOSIT-INSURANCE.yaml
# PR #57 로 M02 가 ELS 전용이 됐다 — 변액에서 "예금자보호 되는 줄"은 부분적으로 참이라
# 결정론 상향이 오판이었다. 그래서 related_misconceptions 가 비어 있고, 이 항목은
# LLM + 루브릭 경로로만 잡힌다. 결정론 보조가 없으므로 조항을 더 촘촘히 썼다.

결정 로그 10.24 에도 같은 것이 남아 있다 — 선택지 (a) products 를 ELS 전용으로 좁힌다 / (b) 변액 루브릭 조건을 좁힌다 중 (a) 를 골랐고, 근거는 "(b)는 유형 정의가 틀린 상태를 루브릭으로 우회하는 것이라 (a)가 정직하다" 였다.

그리고 지금 붙여도 아무 일도 안 일어난다 — 죽은 링크가 된다

이게 더 중요하다. 매처가 products 로 먼저 거르므로 related_misconceptions 는 그 뒤에 온다.

misconception.match(발화, product_type)

  [ELS               ] "예금자보호 되는 상품 아닌가요" → ['M02-DEPOSIT-INSURANCE']
  [VARIABLE_INSURANCE] "예금자보호 되는 상품 아닌가요" → []            ← products: [ELS]

VAR-PARTIAL 은 product_type: VARIABLE_INSURANCE 다. 그러니 related 에 M02 를 적어도 매처가 그 유형을 만들어 내지 않는다. assert_related_misconceptions_exist() 는 ID 가 실재하는지만 보므로 통과한다 — 즉 붙이면 초록인데 floor 는 여전히 안 걸린다. 본문이 지적한 그 공백 위에 아무것도 안 하는 링크가 하나 더 얹히는 모양이다.

그걸 "고치려고" M02 의 products 에 VARIABLE_INSURANCE 를 되돌리면 10.24 가 그대로 되살아난다 — stage=pattern 확정 경로라 LLM 이 못 되돌린다.

❗그런데 본문의 지적 자체는 맞다. 막고 있던 것이 이미 풀렸다

VAR-PARTIAL 에 결정론 보조가 아예 없다는 것은 사실이고 그게 문제다. 10.24 가 그 답도 이미 적어 뒀다.

(a)를 고르면 변액용 신규 유형(부분 보호 범위 오인) 이 필요하고, 그 유형은 인용 가능한 근거가 있어야 한다(3.3·3.17) — 못 찾으[면 …]

그때는 못 찾았는데, 지금은 있다. #153(10.44)이 source.type 에 product_document 를 열었기 때문이다. 변액 상품요약서에 정면으로 반대되는 조항이 있다.

contracts/samples/parsed_variable_sample.json p2
  "이 보험계약은 예금자보호법에 따라 보호되지 않습니다. 다만, 약관에서 정한 최저사망지급금,
   최저실적배당종신연금 및 특약에 한하여 예금자보호법에 따라 보호됩니다.
   보호 한도는 … 1인당 "1억원까지" …"

M09·M10 이 들어간 자리와 같은 모양이다(10.44 — "상품문서 조항이 정면으로 반대이고 조정례 검색 0건이라 다른 값으로는 근거를 적을 칸이 없었다").

그래서 답은 "링크를 붙인다" 가 아니라 "변액 전용 유형을 하나 만든다" 이고, 그 유형의 패턴은 예금자보호 된다 가 아니라 전액/전부 보호된다 를 잡아야 한다 — 앞엣것은 변액에서 부분적으로 참이라 M02 를 좁힌 이유가 그것이었고, 뒤엣것은 명백히 거짓이다. 루브릭 misconception_conditions 의 첫 줄(예금처럼 전액 보호된다)이 이미 그 문면이다.

data/misconception_library/ 가 내 파일이라 유형 추가는 내가 낸다. 다만 리허설이 내일이라 아래 2번과 같은 이유로 3주차다.

---

2. 발행사 신용위험 — 근거는 이미 있다. 미루는 이유를 바꿔 적자

"source 근거가 필요할 텐데 3주차로 미루는 게 맞나" 로 물었는데, 근거가 없어서 미루는 게 아니다. 상품문서에 정면 조항이 있다.

contracts/samples/parsed_els_sample.json p2
  "발행인의 신용상태에 따라 투자원금이 보호되지 않을 수 있는 신용위험이 있으므로
   발행인의 재무현황 및 신용등급(키움증권, 발행사 신용등급 AA, …)"

ELS-ISSUER-CREDIT-RISK 루브릭의 required_elements("발행사의 신용으로 발행되는 무보증 증권이다" · "발행사 부도 시 원금을 돌려받지 못할 수 있다")와 그대로 맞물린다. 10.44 가 M09·M10 에 쓴 판단이 여기도 성립한다 — source.type: product_document, ref 는 위 조항.

그러니 3주차로 미루는 것은 맞되 이유가 다르다. 근거 부재가 아니라 리허설 이틀 전에 채점 동작을 바꾸는 것이라서다 — 본문이 (b)를 기각한 그 이유 그대로다.

(b) 는 리허설 전에 하지 않는다. 과탐 방향이라 게이트로선 안전한 실패지만, 채점 동작을 이틀 전에 바꾸면 데모에서 어떻게 나올지 재 볼 시간이 없다.

새 유형 + 패턴은 (b)보다 더 직접적인 채점 변경이다(결정론 U4 확정 경로가 새로 생긴다). 같은 잣대면 같이 미루는 게 일관된다.

대신 근거를 지금 확정해 두면 3주차에 다시 찾지 않아도 된다. 위 두 인용(ELS 신용위험 p2 · 변액 부분보호 p2)을 그때 쓰면 된다.

---

3. 곁가지 ① distribution.yaml 가중치 — 지금은 안 움직인다

1번이 "링크를 안 붙인다" 로 정해지므로 misconception_weight 도 그대로다. _assert_weights_match_counts 가 깨질 일이 없다.

움직이는 것은 3주차에 유형을 더할 때인데, 그때 순서가 한 방향으로만 산다.

가중치 표가 루브릭보다 앞선다   →  _assert_weights_cover 가 "표에는 있는데 루브릭이 안 쓴다" 로 잡는다 (일부러 허용)
루브릭이 가중치 표보다 앞선다   →  _assert_weights_match_counts 가 죽는다

그러니 data/ 쪽(라이브러리 + 가중치 표)이 먼저, 루브릭이 나중이다. 둘 다 내 파일과 그쪽 파일로 갈려 있으니 내 PR 을 먼저 넣고 그 위에 루브릭을 얹어 달라. 반대로 오면 그쪽 PR 이 빨개진다.

4. 곁가지 ② 연령 어휘 — 잠들어 있지 않다. 고쳐서 올렸다 (#289)

본문이 "지금은 잠들어 있다(sessions.json 미생성 · web 은 enum 과 일치)" 로 적었는데 아니다. data/synth_sessions/*.json 은 .gitignore 라 레포에 없는 것이고, deploy_ec2.sh 가 배포마다 다시 만든다(10.58). alpha 의 heatmap 이 n=35 · masked=false 로 뜬 것이 그 증거다.

sessions.json 68건 중 19건(27%) 이 ageBand="70대 이상"
계약 enum · web 필터 · 가중치 키   어디에도 그 값이 없다
AggregateService.matches 는 정확히 같은 문자열일 때만 센다

그래서 S-08 에서 70대 를 고르면 그 27% 가 하나도 안 잡히고, 화면은 "가려짐" 이 아니라 "데이터 없음" 으로 그린다 — #179 가 두 상태를 갈라 그리게 만든 것이 여기서 거짓을 말하는 데 쓰인다. 가장 취약한 대역에서.

data/ 라 내가 고쳤다. 마스킹 시연이 안 깨지는 것까지 대조했다 — 셀 17개 · 보이는 15 · 가려지는 2 로 고치기 전후가 같다(연령은 셀 축이 아니라 필터라 셀 n 이 안 움직인다).

지적 고맙다. 축을 올릴지 보다가 나온 것이라고 적었는데, 축과 무관하게 이미 돌고 있었다는 그쪽 문장이 맞았고 내가 결정 로그에 "잠들어 있다" 로 옮겨 적은 것이 틀렸다. #288 에서 그 항목(10.62)도 같이 고친다.

---

정리

	답
1 M02 링크	의도다(#57 · 10.24). 붙여도 products: [ELS] 라 죽은 링크다. 되돌리면 10.24 재발
1' 진짜 답	변액 전용 신규 유형 — 10.24 가 막혀 있던 "근거"가 #153(product_document)으로 풀렸다. 내가 낸다
2 발행사 신용위험	근거는 있다(상품문서 p2). 미루는 이유는 근거가 아니라 리허설 이틀 전 채점 변경이다
3 가중치 표	지금은 안 움직인다. 3주차엔 data/ 먼저, 루브릭 나중
4 연령 어휘	잠들어 있지 않았다 — #289 로 고쳤다

3번(게이트 쪽 판단)은 @hd0rable 몫이라 남겨 둔다.

[yoonjiseok]

셋 다 받는다. 그리고 「죽은 링크」 지적이 내 단정 함수의 사각을 가리킨다 — 그건 내
영역이라 이어서 낸다.

1번 — 내가 쓴 것을 내가 안 읽었다

VAR-PARTIAL-DEPOSIT-INSURANCE.yaml 머리말에 #57 근거가 있는데 본문에 "단순 누락으로
보인다" 고 적었다. #298 리뷰에서 @hd0rable 도 같은 것을 짚었고 이미 고쳤다.

그리고 그쪽이 한 칸 더 갔다 — _INTENTIONALLY_UNLINKED 도 틀렸다. "의도적으로 링크
없음" 은 영구히 그렇다고 읽혀서 지우는 사건이 안 온다(10.67). 지금 상태는
"링크가 없기로 정했다" 가 아니라 "그 유형이 아직 없다" 다. #298 최신 커밋이
_UNLINKED_UNTIL = {항목: (근거, 빼는 조건)} 로 바꿔서 라이브러리에 변액 예금자보호
유형이 생기는 순간 테스트가 깨지게 해 뒀다 — 그쪽이 아래에서 말한 그 유형이다.

❗죽은 링크 — 지금은 0건인데 막는 것이 없다

이 지적이 제일 값있다. 실측했다.

유형별 products
  M02-DEPOSIT-INSURANCE      (ELS,)
  M05-SAVINGS                (VARIABLE_INSURANCE,)
  M09/M10                    (ELS,)
  M08-TYING                  (ALL,)

루브릭 product_type 이 그 유형의 products 에 없는 링크   →  0건

오늘은 하나도 없다. 그런데 그게 우연히 그런 것이지 강제된 게 아니다 —
assert_related_misconceptions_exist() 는 ID 가 실재하는지만 본다.

missing = [t for t in rubric.related_misconceptions if t not in known]

그래서 VAR-PARTIAL 에 M02 를 붙이면 통과하는데 floor 는 안 걸린다. 그쪽 말대로
"아무것도 안 하는 링크가 하나 더 얹히는" 것이고, 더 나쁜 건 그게 초록이라 이 이슈의
enforcement_gaps 에서도 사라진다는 것이다 — 공백이 공백으로 안 보이게 된다.

assert_related_misconceptions_exist 가 내 파일이니 products 교차 검사를 거기 넣는다.
#298 이 리뷰 중이라 그 뒤에 별건으로 내겠다. 성격이 같다 — "조용한 실패를 로딩 시점으로
끌어올린다" 이고, 이건 던지는 쪽이 맞다(참조가 실재해도 도달 불가면 데이터 오류다).

2번 — 미루는 이유를 바꿔 적는 데 동의한다

"근거가 없어서" 가 아니라 "리허설 이틀 전에 채점 동작을 바꾸는 것이라서" 가 맞다.
#153(10.44)이 source.type: product_document 를 연 것을 내가 못 연결했다.

그리고 그쪽 지적이 내 논리의 비일관을 잡았다 — 내가 (b)를 "채점 동작을 이틀 전에 바꾼다"
로 기각해 놓고, 새 유형 + 패턴은 (b)보다 더 직접적인 변경(결정론 U4 확정 경로가
새로 생긴다)인데 그건 근거 부재로 미뤘다. 같은 잣대가 아니었다.

근거 둘을 여기 고정해 둔다 — 3주차에 다시 안 찾게.

변액 부분보호   parsed_variable_sample.json p2
  "예금자보호법에 따라 보호되지 않습니다. 다만, … 최저사망지급금 … 에 한하여 … 보호됩니다.
   보호 한도는 … 1인당 1억원까지"

ELS 발행사 신용  parsed_els_sample.json p2
  "발행인의 신용상태에 따라 투자원금이 보호되지 않을 수 있는 신용위험이 있으므로
   발행인의 재무현황 및 신용등급(…)"

패턴 문면 판단도 동의한다 — 변액 신규 유형은 예금자보호 된다 가 아니라
전액/전부 보호된다 를 잡아야 한다. 앞엣것이 부분적으로 참인 게 M02 를 좁힌 이유였고,
루브릭 조건 첫 줄(예금처럼 전액 보호된다)이 이미 그 문면이다. products 를 되돌리는
쪽이 아니라 새 유형을 만드는 쪽이 10.24 를 되살리지 않는 유일한 길인 것도 맞다.

3번 — 가중치가 안 움직인다는 것도 확인했다

링크를 안 붙이므로 misconception_weight 그대로이고 _assert_weights_match_counts 도
안 깨진다. 다만 3주차에 새 유형이 들어가면 그때 움직인다 — 변액 유형이 하나 늘면
그 항목이 related 를 갖게 되고 카운트가 바뀐다. 그때 distribution.yaml 도 같이
가야 한다는 것만 여기 남겨 둔다.

이 이슈에 남는 것

✅  (c)  공백을 로딩 시점에 드러낸다        #298 (리뷰 중)
⬜  (a)  변액 예금자보호 유형 신설           정세현 · 3주차 · 근거 확정됨
⬜  (a)  발행사 신용위험 유형 신설           정세현 · 3주차 · 근거 확정됨
⬜  ★    products 교차 검사                 나 · #298 뒤 별건
⬜  (b)  floor 가 조건 문면도 본다           3주차 정량평가 뒤

(a) 둘은 근거가 확정됐으니 3주차에 바로 쓸 수 있다.

[gitIt-sehyeon]

@yoonjiseok — 물어보신 둘 다 답한다.

1. VAR-PARTIAL-DEPOSIT-INSURANCE 의 M02 누락은 의도다. 붙이면 안 된다.

누락이 아니라 PR #57 이 일부러 뗀 것이고, 근거가 두 파일에 각각 적혀 있다.

# ai-service/app/rubrics/VAR-PARTIAL-DEPOSIT-INSURANCE.yaml:15
# PR #57 로 M02 가 ELS 전용이 됐다 — 변액에서 "예금자보호 되는 줄"은 부분적으로 참이라
# 결정론 상향이 오판이었다. 그래서 related_misconceptions 가 비어 있고, 이 항목은
# LLM + 루브릭 경로로만 잡힌다. 결정론 보조가 없으므로 조항을 더 촘촘히 썼다.
related_misconceptions: []

# data/misconception_library/misconceptions.yaml:72  (M02-DEPOSIT-INSURANCE)
# ELS 전용이다. 변액을 뺐다(v4) — 변액에서 "예금자보호 되는 줄 알았다"는 **부분적으로 참**이다.
# … 부분적으로 맞는 진술을 patterns 가 1.000 으로 잡아 U4 를 확정하면 이해→오해 오판이고,
# stage=pattern 은 LLM 이 되돌릴 수 없는 확정 경로다
#
# 그리고 source 가 홍콩 H지수 **ELS** 조정례다. products 에 변액이 있던 것은 근거 범위를
# 넘은 것이기도 했다.

이유가 둘이고 둘 다 지금도 유효하다.

1. 부분 보호라 "보호된다"가 부분적으로 참이다. 상품요약서가 "보호되지 않습니다. 다만, 약관에서 정한 최저사망지급금 … 에 한하여 … 1인당 1억원까지" 로 범위를 정한다. 여기에 결정론 상향을 걸면 맞는 말을 한 고객이 U4 로 확정된다
2. source 가 홍콩 H지수 ELS 조정례다. 변액에 적용하면 근거 범위를 넘는다

❗그리고 이건 #324(채점 성능 측정)와 정면으로 부딪친다. stage=pattern 은 LLM 이 되돌릴 수 없는 확정 경로라, 붙이면 미탐이 아니라 과탐이 늘고 miss_rate 옆에 나란히 서는 혼동행렬이 나빠진다. 리허설 전에 지표를 개선하려다 지표를 깎는 방향이다.

대신 이 항목은 이미 촘촘하다. misconception_conditions 가 세 조항(예금처럼 전액 보호된다 · 전혀 보호되지 않는다 · 낸 보험료 전액이 보호 대상이다)을 선언하고 있어서 LLM + 루브릭 경로로는 잡힌다. 없는 것은 결정론 보조 하나뿐이고, 그게 없는 것이 이 항목에서는 옳다.

데모 시나리오에 변액 예금자보호가 들어가는 것은 맞는데, 거기서 필요한 건 결정론 상향이 아니라 #284 (c) 가 말한 "무엇이 강제되고 무엇이 권고인지" 가 문서에 남는 것이다. 그건 아래와 이어진다.

2. 발행사 신용위험 유형 추가 — 3주차로 미루는 게 맞다.

미루는 근거가 일정만은 아니다.

• 라이브러리의 자기 규약이 막는다. 지금 9종 전부 source 를 갖고 있다(1차 출처 있는 것만 들어왔다). 새 유형을 근거 없이 넣으면 그 규약이 처음으로 깨지는 항목이 되고, 심사에서 "이 오해 유형들의 근거가 뭔가"에 9종 중 1종만 답을 못 하는 상태가 된다
• 역할표가 못박아 뒀다 — "3주차에는 새로 만드는 것을 최소화하고, 2주차에 기반을 끝내 놓는다"(role-assignment-v1.2.md:159). 남은 게 나흘이고 그 안에 통합·리허설·제출물이 겹친다
• 지금도 완전히 못 잡는 게 아니다. ELS-ISSUER-CREDIT-RISK 의 misconception_conditions 에 기초자산만 오르면 안전하다 가 이미 있다. 빠진 것은 결정론 상향이고, els-0028 이 통과한 것도 그 층의 공백이다

그래서 (c) 를 먼저 하시는 게 맞다고 본다

#284 가 셋 중 (c) 를 "채점을 안 건드린다" 고 적으셨는데, 지금 상황에서 그게 제일 값이 크다.

지금은 46개 중 무엇이 강제되고 무엇이 권고인지 코드도 문서도 말하지 않는다. 그 상태에서는 위의 1번 같은 판단("이건 일부러 뺐다")이 파일 주석을 읽어야만 나온다 — 실제로 이 답을 쓰려고 두 파일 주석을 대조했다. 루브릭에 명시하고 로딩 시점에 대조하면 related_misconceptions: [] 가 "빠뜨림" 이 아니라 "의도" 라고 파일이 스스로 말한다.

(a)·(b) 는 근거(source)가 붙는 시점에 하고, 그건 3주차 이후가 맞다.

[yoonjiseok]

측정 기록을 #385 로 냈다 — ai-service/tools/MISCONCEPTION-DETECTION.md. 오해 탐지 여섯 방법을 다 재고 다섯이 떨어졌고, 떨어진 이유가 하나다(닮음을 재고 있었다). 이 이슈에 걸리는 부분만 짚는다.

(b) 유사도 매칭은 이 문서로 부결 근거가 굳었다. 강희진이 #364 에서 바이그램으로 잰 것(70건 적중 1건이 오탐)과, 내가 임베딩·NLI 로 잰 것이 같은 벽이다.

바이그램   형태가 닮으면 붙는다 — "예금자보호는 **안** 된다" 를 0.71 로 U4
임베딩     주제가 닮으면 붙는다 — 정반대가 +0.623, 같은 뜻이 +0.571
기성 NLI   술어가 같을 때만 모순을 본다 — 전수 모순율 24%

(a) 쪽 준비물도 하나 생겼다 — 무리 A·B 9개 항목의 조건에 술어를 맞춘 정면 반박 21개(tools/condition_counters.py). 판정에 안 쓰지만 조건 ↔ 반박 쌍이 곧 모순 라벨이라 소형 모델 학습의 씨앗이 된다.

[yoonjiseok]

(a) 의 링크 부분을 확인했습니다 — 붙이면 안 되고, 코드가 이미 세 겹으로 막고 있습니다.

제가 위에서 @gitIt-sehyeon 께 물은 1번("VAR-PARTIAL-DEPOSIT-INSURANCE 의 M02 링크
누락이 의도인가")은 이제 파일이 스스로 답합니다. #379((c))가 unlinked_until 을
넣었고 로더가 대조합니다. 답을 기다릴 필요가 없어졌습니다.

until 조건이 아직 안 채워졌다 (실측)

until: 오해 라이브러리에 VARIABLE_INSURANCE 를 덮는 예금자보호 유형이 생기고
       그 유형이 인용 가능한 근거(source)를 가질 때        # 결정 10.24

라이브러리 9종을 전수로 봤습니다.

ID                            products                       source
M01-PRINCIPAL-GUARANTEE       ['ELS', 'VARIABLE_INSURANCE']  dispute_case
M02-DEPOSIT-INSURANCE         ['ELS']                        dispute_case   ← 변액을 안 덮는다
M03-PROBABILITY               ['ELS']                        dispute_case
M04-EARLY-REDEMPTION          ['ELS']                        proposal_example
M05-SAVINGS                   ['VARIABLE_INSURANCE']         proposal_example
M06-SURRENDER-VALUE           ['VARIABLE_INSURANCE']         proposal_example
M08-TYING                     ['ALL']                        proposal_example
M09-NO-LISTING                ['ELS']                        product_document
M10-MIDWAY-REDEMPTION-COST    ['ELS']                        product_document

→ 변액 예금자보호를 덮는 유형이 0 개입니다. #57 이 M02 를 ELS 전용으로 만든 이유가
그대로 살아 있습니다 — 변액에서 "예금자보호 되는 줄" 은 약관상 최저사망지급금 등에 한해
부분적으로 참이라, 결정론 상향(stage=pattern)은 LLM 이 되돌릴 수 없어서 맞는 말을 한
고객이 U4 로 확정됩니다.

세 겹이 실제로 막는 것을 변조로 확인했습니다

ⓐ M02 를 붙인다 (unlinked_until 유지)      ValueError  "related_misconceptions 가 있는데
                                                       unlinked_until 도 있다"
ⓑ unlinked_until 을 지우고 M02 를 붙인다    ValueError  "그 상품에서 도달할 수 없는 오해 유형"
ⓒ 없는 유형 M99 를 붙인다                   ValueError  "라이브러리에 없는 오해 유형"

ⓑ 가 핵심입니다. 매처가 products 로 먼저 거르므로 링크해도 매칭이 아예 안 만들어집니다.
그러면 링크는 초록인데 floor 는 안 걸리고, 더 나쁘게 enforcement_gaps() 가 "링크가 있으니
강제된다" 로 세어서 이 이슈가 드러낸 공백 위에 아무것도 안 하는 링크가 얹힙니다.

루브릭 17종 전수 — 사유 없이 빈 링크는 0 건

링크 0 · 조건 있음    VAR-PARTIAL-DEPOSIT-INSURANCE 하나뿐  (unlinked_until 있음)
사유 없이 빈 것       0 건

(c) 가 실제로 그 자리를 덮고 있습니다.

❗제가 중간에 오탐을 하나 냈습니다 (기록)

ⓑ 를 처음 잴 때 rubrics.get() 만 부르고 "도달 불가 그물이 없다" 고 적을 뻔했습니다.
그물은 기동 시 assert_related_misconceptions_exist() 에 있고 제가 그걸 안 불렀습니다.
#298 에서 제가 밟은 "테스트가 함수를 직접 부르면 배선을 안 잰다" 를 똑같이 밟았습니다 —
TestClient(app) 를 컨텍스트로 써야 lifespan 이 도는 그 모양입니다.

그래서 (a) 는 제 손에서 열리지 않습니다

VAR-PARTIAL 링크   ❌ 막혀 있고, 막히는 게 맞다. 여는 조건이 데이터 쪽이다
유형·패턴 추가      ❌ data/misconception_library/ 는 @gitIt-sehyeon 소유

(a) 를 여는 것은 「변액을 덮는 예금자보호 유형 + 인용 가능한 근거(source)」 하나입니다.
그게 생기면 unlinked_until 을 지우고 링크를 붙이는 것은 제가 그날 바로 합니다 — 로더가
대조하므로 조건이 안 맞으면 기동 때 터집니다.

M07 처럼 근거를 못 구하면 안 만드는 것도 답입니다. 그때는 until 문면을 그렇게 고치는
편이 낫습니다 — 지금 문면은 "언젠가 생긴다" 를 전제합니다.

[gitIt-sehyeon]

@yoonjiseok — (a) 를 열었다. #395 다. 넘기신 자리가 내 소유(data/misconception_library/)라 그쪽만 냈고, 마저 하는 셋은 그쪽 파일이라 손대지 않았다.

until 의 두 조건이 다 선다

변액을 덮는 유형        M11-DEPOSIT-INSURANCE-SCOPE   products: [VARIABLE_INSURANCE]
인용 가능한 근거        product_document (#148 이 연 칸 · M09·M10 선례)
                        상품요약서 p2 「상품의 특이사항」 — 원문이 정면으로 반대로 적는다

전수로 세신 표에서 "변액 예금자보호를 덮는 유형이 0개" 가 맞았고, 없는 이유가 근거 부재는 아니었다 — dispute_case 로만 찾으면 0건이지만 product_document 계열은 선다.

❗후보 문면이 틀렸었다 — 내가 M02 주석에 적어 둔 것이다

M02 주석과 unlinked_until 이 상정한 후보는 "해약환급금도 보호되는 줄" 인데 그건 못 쓴다. 같은 p2 문장이 해약환급금을 한도 산정 기준으로 쓴다.

"보호 한도는 해약환급금(또는 만기 시 보험금)에 기타지급금을 합하여 1인당 '1억원까지'"

원문이 그 단어를 보호 문맥에서 쓰는데 오해로 확정하면 #57 의 실패를 다른 이름으로 반복한다. M11 이 잡는 것은 「보호된다」가 아니라 「전액 보호된다」 다.

❗unlinked_until.reason 을 정정해야 한다 — floor 는 stage 를 안 본다

reason 이 "결정론 상향(stage=pattern)" 이라고 적었는데 apply_misconception_floor 는 stage 를 안 읽는다. 링크돼 있고 score >= 0.62 면 ngram 도 그대로 U4 확정이다. 위험이 문면보다 넓다.

그래서 M11 의 안전성은 「패턴 단계로만 잡는다」가 아니라 부분적으로 참인 발화가 0.62 에 못 미친다는 데 있고, 그걸 만드는 건 패턴 길이다.

                                    짧은 조각 4개    전문장 2개
 "예금자보호 되는 줄"                 0.6667 → U4      —
 "최저사망지급금은 보호가 된다"        0.6667 → U4      —
 "1억원까지는 보호가 된다"             0.6667 → U4      —
 "예금처럼 전액 보호"                  1.0    → U4      1.0 → U4
 "보험료 전액이 보호 대상"             1.0    → U4      0.8 → U4

containment 분모가 패턴 바이그램 수다. M09·M10 이 전문장인 게 스타일이 아니었다. 실측과 그물을 파일에 같이 넣었다.

그쪽에서 하실 셋 — #395 가 지금 빨간 이유

test_unlinked_until_has_not_expired 가 울렸다. 그게 쓰신 트립와이어가 하려던 일이라 그대로 뒀다.

1. unlinked_until 빼고 related_misconceptions 걸기
2. 그 테스트 지우기
3. test_enforcement_gap.py 다섯이 연쇄로 깨진다   ← 판단이 필요한 자리

3 은 한번 해 보고 되돌렸다. 다섯이 VAR-PARTIAL-DEPOSIT-INSURANCE 를 unlinked_until 기능의 유일한 실물 사례로 붙들고 있어서, "마지막 대상이 은퇴하면 기능은 합성 루브릭으로 계속 지키는가 같이 은퇴하는가" 를 정해야 한다. 파일에 SYNTH-NO-LINK 관용구가 이미 있어 옮기는 것 자체는 되지만 그쪽 설계 판단이다. 원하시면 그 방향으로 내가 마저 민다.

곁들여 — test_pending_exceptions_cite_their_reason 은 목록이 비면 루프가 안 돌아 조용히 통과한다. 3 을 정하실 때 같이 보시면 된다.

곁들여 — (b)·(c) 쪽

(b) 부결 근거 정리하신 것 잘 봤다. 세 방법이 같은 벽이라는 것이 #385 로 굳었다고 본다. (c) 는 이미 들어갔고, 이번 (a) 가 그 위에서 돌아간다 — unlinked_until 이 없었으면 이 사건이 아무 데서도 안 울렸을 것이다.