[개인 노트 · 리뷰 불필요] 작업 인계 — 조용함. #625 에 내 파일 두 줄이 걸려 있다 (46회차) - #283
yoonjiseok wants to merge 1 commit into
Conversation
파일 변경 없는 빈 커밋이다. 다른 세션·랩탑에서 이어가기 위한 인계용이고 내용은 PR 본문에 있다. #196 과 같은 형태.
9/2 오후 — 리뷰 사이클 기록본문은 상태 스냅샷이라 매번 갈아 썼는데, 오늘 값이 있었던 건 대부분 리뷰에서 나왔고 ★ 오준서 정체가 풀렸다 (08:57)
내가 오늘 한 것❗리뷰에서 잡은 것 — 여섯. 대부분 변이를 걸어서 나왔다읽어서 찾은 건 하나뿐이다. 나머지는 되돌려 보고 테스트가 안 깨지는 것을 본 것이다.
오늘 배운 것 — 셋1. 결정로그를 먼저 읽는다
그리고 정세현이 2. 같은 규약을 적은 필드가 둘이면 그물도 둘이어야 한다
문면이 둘을 말하면 변이도 둘을 걸어 본다. 3.
|
`pr-review-guard.yml` · `pr-reviewer-label.yml` · `pr-author-assignee.yml` → `pr-review.yml` 한 파일 · 한 잡. ## 왜 — 분보다 결함 쪽이 크다 ① 셋 다 실측 4초짜리인데 잡 단위 올림 과금이라 각각 1분씩 나갔다. 실측 12.9분에 **과금 119분**. 합치면 약 40분이다. ② ❗**같은 판정을 두 파일이 각자 구현하면 어긋난다.** CLAUDE.md 가 두 번 경고하고 실제로 네 번 났다(#90·#91 · #135/#140 · #180). 다섯 번째가 이미 와 있었다 — 가드가 `reviewRequests` 로 판정하면서 그 값이 바뀌는 `review_requested`·`review_request_removed` 를 **안 들었다.** 초록인 PR 에 리뷰어를 새로 붙이면 라벨만 바뀌고 **가드는 낡은 초록으로 남았다.** 이제 「판정」 스텝이 사실을 한 번만 만들고, 커밋 상태와 라벨이 그 하나를 각자 표현한다. **두 표현이 갈릴 자리가 없다.** ## 지키기로 한 것 둘 (#276 코멘트) — 둘 다 지켰다 1. **트리거는 라벨 쪽 8종 합집합.** 가드 쪽 4종으로 좁히면 ②가 돌아오고 라벨이 눌어붙는다(#135/#140). 2. **`#180` 의 스텝 분리 유지.** 판정은 `continue-on-error`, 커밋 상태는 `always()` 로 **라벨보다 먼저** 쓴다 — 라벨이 죽어도 줄은 이미 갱신돼 있다. ## 라벨 쪽에 하나 보탰다 — 판정이 죽으면 라벨을 안 건드린다 라벨에는 가드의 `error` 같은 세 번째 값이 없다. 판정이 중간에 죽은 채로 목표가 비어 있으면 **라벨을 다 떼게 되고 그건 "전원 승인했다" 로 읽힌다** — 정확히 반대 뜻이다. 판정 끝에 찍는 표식(`verdict_ok`)이 없으면 물러난다. ## 실측 — 열린 PR 8건에 판정 로직을 그대로 돌려 현재 라벨과 대조했다 PR 상태 라벨(계산) 라벨(실제) 일치 #305 승인 0건 리뷰어 미배정 〃 ✅ #300 승인 0건 리뷰대기×2 · 리뷰중×1 〃 ✅ #299 미승인 yoonjiseok 리뷰중: 윤지석 〃 ✅ #298 변경요청 hd0rable 리뷰중: 강희진·정세현 〃 ✅ #287 전원 승인 (없음) 〃 ✅ #303 전원 승인 (없음) 〃 ✅ #283 초안 (없음) 〃 ✅ #270 머지됨 (없음) · 상태 안 씀 〃 ✅ `bash -n` 으로 네 스텝의 셸 블록을 전부 문법 검사했고 YAML 파싱도 확인했다. ## 곁들여 `소유자 승인 여부` 커밋 상태 context 는 **그대로 뒀다** — 바꾸면 기존 PR 에 줄이 하나 더 생긴다. 팀 리뷰 요청은 판정할 수 없어 경고로 드러낸다(이 레포는 CODEOWNERS 가 전부 개인 로그인이고 팀 요청 이력 0건이라 지금은 안 걸린다). CLAUDE.md · infra/README.md 의 옛 파일명 참조를 같이 고쳤다. Claude-Session: https://claude.ai/code/session_01Korhp5asdqxA4bJ5h8jFgw Co-authored-by: 오준서 <26485905+junseo2323@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
9/3 오전 — 리허설 당일. 밤새 들어온 것과 내가 본 것★ 밤새 머지 (9/2 오후~밤)
❗다른 랩탑 세션이 내 PR 을 이미 고쳤다 — 중복 작업을 했다
그리고 원격이 내 접근보다 한 칸 더 갔다.
내 로컬 커밋을 버리고 원격으로 리셋했다. 교훈 — 다른 랩탑에서 세션이 돌고 있으면 작업 전에 오늘 본 것 — 리뷰 넷 + 회신 둘❗원본이 들어오자 넷이 갈렸다 — 하나는 성격이 다르다④가 심사에서 제일 위험하다. 명세 3절이 "실패 시 U2(황색)로 보수 확정" 을 요구하는데 내가 근거를 한 절 잘못 알고 있었다메모에 "confidence < 0.7 → 황색 강등, 단 U4 는 예외(P5)" 로 적고 그걸 P5 조항으로 심사에서 P5 를 물으면 0.2절과 3절을 같이 인용해야 한다. 앞만 들면 우리가 위반으로 보인다. 오늘 배운 것
지금 열린 것내 차례는 없다. 다음에 할 것 |
9/3 오전 (계속) — 리허설 전. 내 PR 셋이 전부 리뷰 대기★ 정정 — 어제 인계 노트가 틀렸다앞 코멘트에서 이슈
열린 내 PR 셋❗
|
| # | 무엇 | 상태 |
|---|---|---|
| 1 | #341·#338·#308 머지 |
전부 리뷰 대기 |
| 2 | #308 머지 후 P5 절 표기 가드를 그 파일에 얹는다 |
같은 파일이라 순서가 있다 |
| 3 | #183 후속 — 짧은 조각 오탐 |
내 코드 · #324 로 시점이 가까워졌다 |
| 4 | #284 (a) 루브릭 쪽 |
근거 확정됨 · 라이브러리는 정세현 |
| 5 | F-DET-001 3단계(임베딩) · #234 ② |
3주차 |
내 담당 열린 이슈는 #284 하나고, 오늘 난 17건 중 내 담당은 0건이다.
9/3 05:30 — 리허설 전. 내 PR 셋 대기 · 라벨링이 움직이기 시작했다내 PR 셋 — 전부 리뷰 대기
❗F-CMN-003 라벨링이 시작됐다 — 내가 배제된 구간이다
그리고 강희진이 자기 자격 상실을 스스로 적었다.
내 배제와 같은 논리다. 나는 프롬프트 당사자라 처음부터 라벨러가 아니고, 강희진은 내가 이 구간에 낸 것은 파이프라인과 모델 예측 40건뿐이다( ❗리허설 전 마지막 미확인 — 그대로다
다음에 할 것
내 담당 열린 이슈는 |
9/3 오후 —
|
9/3 (리허설 당일) — 오늘 한 것 전수시각은 KST. 조회로 모았다(기억으로 적지 않는다 — 오늘 날짜·사건을 추론으로 이어서 한 번 틀렸다). 시간순머지된 내 것 — 넷열린 내 것 — 셋닫은 것 — 셋
남의 것 리뷰 — 아홉오늘 실제로 배운 것★ 1. 원본 명세가 들어오자 내 근거가 한 절 틀린 것이 나왔다
❗심사에서 P5 를 물으면 두 절을 같이 인용한다. 0.2절만 들면 "무조건 강등" 이라고 ★ 2. 안내 문면도 그 자리를 열어 보고 써야 한다 —
|
9/4 아침에 볼 것 — 내 R 셋의 품질 층 (개인 메모)어제 판단: 세 기능이 다 「돈다」인데 깊이가 MVP 선에 걸려 있다. 배선·계약은 다 아래 셋은 내 파일 안에서 끝난다 — 남의 승인·배선을 안 기다린다. ① F-EXT-002 추출 — 지금이 왜 MVP 선인가후처리가 프롬프트보다 13배 크다. 그게 옳은 설계였고(모델 출력을 그대로 안 믿는다) 그 무엇이 얕은가 — 셋(a) 조건이 여러 문장에 걸치면 못 담는다. 프롬프트 규칙 5 가 "한 문장, 최대 80자" 다. 지금은 루브릭을 촘촘히 써서 그 위험을 상쇄한다(그 파일 머리말). 즉 추출의 얕음을 → 후속 인용( (b) (c) 표는 구제하되 해석하지 않는다. 오늘 할 수 있는 것 (순서)2 번을 먼저 하는 게 맞다 — 계약을 안 건드리고, 지금 있는 위험(뜻 뒤집힌 인용)을 ② F-INT-002 되말하기 질문 — 단순한 이유가 구조에 있다단순한 것이 검사 때문이 아니다 — 유형이 셋뿐이고 항목당 질문이 하나다. 무엇이 얕은가 — 셋(a) 항목당 한 질문이라 유형이 안 돈다. (b) 난이도가 없다. 같은 항목을 (c) 폴백이 템플릿 고정문항이다. 26% 가 폴백이면 그 26% 는 F-INT-002 가 사실상 안 돈 오늘 할 수 있는 것2 번이 값이 크다. 지금 고정문항이 역이용 방지의 구멍이고, 그걸 메우는 문면은 내 몫이다. ③ F-INT-004 재설명 — 확인할 것
확인 순서
둘째 줄이 제일 나올 만하다. 재설명 프롬프트가 "비유를 쓴다. 다만 비유에 숫자를 넣지 그리고 확인해야 하는 것 하나 더
→ 관통해 보고 순서 제안③ 을 먼저 두는 이유는 재설명이 실제로 어떤 문면을 내는지 모르는 상태에서 ①②를 세 건 다 내 파일 안에서 끝나고, 계약 변경이 필요한 것은 ① 1번 하나다(강희진 승인). |
F-DET-001 3단계 임베딩 — 적용 방안 (실측 기반, 2026-09-03)결론부터: 내 메모의 원안이 틀렸다. "오해 8종 패턴을 미리 임베딩 → 코사인 + 임계값" ① 원안 반증 — 임베딩도 부정을 못 가른다
M09 는 임계값이 존재할 수 없다. 어미변형2(0.560)를 잡는 임계값은 정답(0.621)을 먼저 이유가 구조적이다 — 임베딩은 주제 를 잡고 입장 을 못 잡는다. 부정은 주제를 안 → 내 메모의 "2차는 LLM 보다 임베딩" 항목에 이 반증을 적어야 한다. 그대로 두면 ② 되는 것 — 대조 앵커 (pro/anti margin)절대 유사도를 버리고 어느 쪽에 더 가까운가를 본다. 부호가 정확히 갈린다. 오해·변형 전부 양수(+0.088 ~ +0.607), 정답·무관 전부 음수 ❗여유가 좁다. 최소 양수 +0.088, 최대 음수 -0.016 → 간격 0.104. 표본 11건이라 ③ 필요한 데이터 — 이해 발화(anti)가 없다지금 - id: M09-NO-LISTING
patterns: ["주식처럼 팔고 싶을 때 팔면 되는 거 아닌가요"]
counter_patterns: # ← 새 필드
- "주식처럼 팔 수 없다고 들었어요"
- "상장이 안 돼서 못 판다고 하셨죠"데이터는 정세현 소유다. 그리고 요청 근거가 좋다 — 위 표가 "이게 없으면 3단계가 대안: ④ 배선 설계1·2 를 안 건드린다. 그 둘이 결정론이고 감사에서 셀 수 있는 것이라, 임베딩은 def match(text, product_type="ELS"):
... # 1·2 단계 그대로
if not matches and _embedding_enabled():
matches = _embedding_stage(norm, product_type) # stage="embedding"재현성 (P2)
폐쇄망 (
|
F-EXT-002 에 검색 스택(청킹 · 하이브리드 · RRF · 리랭킹) 적용 방안전제부터 — 이 스택은 재현율을 올리는 게 아니라 내릴 수 있다. 즉 이 변경의 이득은 재현율이 아니라 정밀도·설명가능성·비용이다. 그걸 먼저 못 박아야 ① 지금 무엇이 아픈가 — 검색으로 풀리는 것만 골라낸다
아픈 것 셋이 정확히 이 스택의 자리다. 그리고 셋이 한 뿌리다 — "어느 문면이 이 항목의 ② 청킹 — 페이지가 아니라 조항·표 단위파서가 페이지 단위로 준다( ❗스팬 항등식을 깨면 안 된다. ③ 하이브리드 — 두 검색기가 서로의 사각을 받는다표 셀이 이 조합의 존재 이유다. 주석이 적은 그대로 "표 셀은 순수 수치라 자연어 cue 와 ④ RRF — 여기서는 융합이 실제로 값을 한다
점수 정규화가 필요 없는 게 요점이다. containment(0 ⑤ 리랭킹 —
|
RRF 까지는 순위 융합이고, *"이 문면이 이 항목의 조건인가"* 는 짝을 함께 보는 모델만 한다.
F-DET-001 실측이 그 근거다 — 임베딩이 오해 문장과 그 부정을 **0.560 vs 0.621 로 뒤집어
놨다**(주제는 같고 입장만 다르다).
## ★ 실측 — 리랭킹이 recall@1 을 두 배 이상 올린다
ELS 계약 정답 13건 · 청크 55개.
RRF 만 recall@1 4/13 recall@3 11/13
RRF+리랭킹 recall@1 9/13 recall@3 12/13
**앞 커밋에서 이득이 작다고 적은 것이 이 단계가 없어서였다.** 융합은 후보를 모으고
리랭커가 고른다.
## ❗그런데 게이트를 못 넘었다 — 그리고 지표가 흔들린다
`#283` 방안에 *"`recall@k` 가 26/26 이 안 되면 추출 프롬프트를 top-k 로 바꾸지 않는다"* 고
적어 뒀다. **12/13 이므로 안 바꾼다.** 그리고 재실행하니 11/13 이었다 — 리랭커가
비결정적이라(`#281`) **지표 자체가 회차마다 다르다.**
놓친 둘을 보니 **둘 다 청킹 경계 문제**이고 순위 문제가 아니다.
ELS-EARLY-REDEMPTION-CONDITION 정답 청크 30, 가져온 것 31·32·33 ← 인접 청크
ELS-ISSUER-CREDIT-RISK 정답 청크 45 가 문장 중간에서 시작한다
("따른 위험 파생상품적 성격을…" — 앞이 잘렸다)
→ 다음 할 일은 리랭커 튜닝이 아니라 **청킹 경계와 이웃 청크 포함**이다. 인접 청크를
같이 넘기면 첫째는 그대로 구제된다.
## 설계에서 지킨 것 넷
**① 순위만 받는다 — 점수를 안 받는다.** 점수를 받으면 그 숫자가 임계값이 되고
*"0.7 은 어떻게 정했나"* 를 답해야 한다. RRF 를 순위 융합으로 둔 것과 같은 이유다.
**② 후보가 `top_n` 이하면 안 부른다.** 순위를 바꿀 여지가 없는데 부르면 **비결정성만
들인다.** 호출 절약이 아니라 그게 이유다.
**③ 모델이 낸 번호를 그대로 안 믿는다.** 범위 밖·중복을 걸러낸다 —
`_pin_item_id`·`_drop_llm_misconception_type`(F-SCR-001)과 같은 층이다.
**④ 리랭커가 죽으면 RRF 순위로 되돌아가고 로그를 남긴다.** 이 단계는 순위를 *개선* 하는
것이라 검색이 같이 죽으면 안 된다. 그리고 **조용히 폴백하지 않는다** — 로그가 없으면
리랭킹이 꺼진 채로 도는 것을 아무도 모른다(`#238` 과 같은 이유).
`client=None` 이면 RRF 까지만 돈다 — `recall@k` 측정과 테스트가 LLM 없이 돌아야 하고,
리랭커가 정책·쿼터에 걸리는 날에도 검색은 돌아야 한다.
## 비결정성을 문면에 박았다
`rerank` docstring 이 쓰는 자리를 셋으로 가른다.
루브릭 생성 · 커버리지 검사 ✅ 사람이 승인한다. 흔들려도 사람이 본다
F-EXT-002 추출 프롬프트 입력 ⚠️ 실행마다 top-k 가 달라진다 → #280 이 그 자리다
F-SCR-001 채점 ❌ 쓰지 않는다
## 변조 검증
| 변조 | 잡히나 |
|---|---|
| 범위 검사 제거 (모델 출력을 그대로 믿음) | ✅ |
| 폴백 로그 제거 (조용히 꺼짐) | ✅ |
| 후보 적을 때도 리랭커 호출 | ✅ |
| `client=None` 인데 리랭커 호출 | ✅ 2건 |
457 passed (+6).
## ❗먼저 — 내가 "증상을 덮는 것" 이라고 한 판단이 틀렸다
`Chunk` 는 페이지 하나 + 오프셋을 든다. `pages[page].text[start:end] == text` 가 P6 ·
1절 F-EXT-002 의 근거이므로 **여러 페이지를 걸친 청크는 그 항등식을 만족할 수 없다.**
그런데 공시문서는 문장이 페이지를 걸친다.
페이지 첫 청크 15개 중 **10개가 문장 중간에서 시작한다** (계약 샘플 실측)
항등식이 크로스 페이지를 금지하는 이상 **이웃 포함이 그 제약 안에서의 정답**이다.
## 그런데 실측이 절반만 맞았다 — 그것도 적는다
top-3 만 recall 12/13
top-3 + 이웃1 recall 12/13 ← 안 올랐다
거리를 재니 이유가 명확했다.
ELS-EARLY-REDEMPTION 정답 30, 가져온 것 31·32·33 거리 1 → 구제한다 ✅
ELS-ISSUER-CREDIT-RISK 정답 45, 가져온 것 6 거리 39 → 원리상 못 닿는다 ❌
뒤엣것은 **적중 근처에 정답이 없다** — 검색이 아예 다른 데를 짚었다. 정답 청크가 문장
중간에서 시작해서(`"따른 위험 파생상품적 성격을…"`) 질의와 어휘·주제가 둘 다 안 맞는다.
**즉 이웃 포함은 순위 밀림을 구제하고 페이지 경계 문제는 구제하지 못한다.**
반경을 늘려 39 를 덮으려면 청크 79개를 넣는 것이고 그러면 문서 전체와 같다 — 이 모듈이
존재하는 이유가 없어진다. 그래서 **한계를 늘리는 것으로 풀지 않고 테스트로 못 박았다.**
남은 길은 둘이다. 청크가 스팬 목록을 들거나(항등식을 조각별로 만족), 파서가 페이지 경계
문장을 이어 주거나(`parsing.py` · 정세현). `#283` 에 남긴다.
## ❗그물이 런타임 값을 안 재고 있었다
`test_neighbors_cannot_reach_a_far_answer` 를 처음에 `span=1` 로 명시해서 썼더니
**`NEIGHBOR_SPAN = 40` 변조가 그 테스트를 안 지나갔다**(다른 테스트가 우연히 잡았다).
→ 기본 상수를 읽게 고쳤다. **그물은 런타임이 쓰는 값을 재야 한다** — 오늘 `#304`
정규식·`#352` 예외에서 내가 지적한 것과 같은 모양이고, 이번엔 내 테스트가 그랬다.
## 변조 검증
| 변조 | 잡히나 |
|---|---|
| 이웃을 안 냄 | ✅ 2건 |
| 중복을 안 지움 | ✅ |
| `NEIGHBOR_SPAN = 40` (반경으로 덮으려 함) | ✅ (고친 뒤) |
461 passed (+4).
## ★ 게이트를 넘었다
청킹 v1 (page,start,end 하나) top-3 12/13 + 이웃 12/13
청킹 v2 (스팬 목록 · 이 커밋) top-3 11/13 + 이웃 **13/13**
`#283` 방안에 *"`recall@k` 가 26/26 이 안 되면 추출 프롬프트를 top-k 로 바꾸지 않는다"* 고
적어 뒀다. ELS 13건 전건이 되었고, **3회 반복에서 다 13/13 이다** — 리랭커가 한 번 실패해
RRF 로 폴백한 회차에도 유지됐다(비결정성 아래서도 선다).
## 무엇이 문제였나
공시문서는 문장이 페이지를 걸친다. 계약 샘플 실측:
페이지 첫 청크 15개 중 **10개가 문장 중간에서 시작**
`Chunk` 가 `(page, start, end)` 하나였으므로 그 문장은 **어느 청크에도 온전히 없었다** —
검색을 어떻게 고쳐도 못 찾는다. `ELS-ISSUER-CREDIT-RISK` 가 그 실물이었고, 이웃
포함으로도 안 됐다(정답이 적중과 **거리 39**).
## 항등식을 조각별로 만족시킨다
"".join(pages[s.page].text[s.start:s.end] for s in spans) == chunk.text
**P6 · 1절 F-EXT-002 근거가 안 약해진다** — 조각마다 원문을 그대로 가리킨다. 페이지를
걸친 조건이 한 청크에 온전히 들어오고, 그 청크의 `spans` 가 둘이 된다.
`page`·`start`·`end` 는 **첫 조각**을 가리키는 유도 속성으로 남겼다. 대부분의 청크가
조각 하나라 호출부가 그대로 쓰고, 여러 조각을 다루려면 `spans` 를 명시적으로 봐야 한다.
## 병합 판정 — 조항머리를 함께 본다
앞 페이지가 문장 종결로 끝나지 않고 **뒤 페이지가 조항머리로 시작하지 않으면** 갈린 것으로
본다. 조항머리를 같이 보는 이유: 앞 페이지가 제목으로 끝나면(마침표가 없다) 종결 검사만
으로는 늘 "갈렸다" 가 된다 — **실측으로 그 오탐이 9건이었다.**
앞 페이지의 **끝** 청크와 뒤 페이지의 **첫** 청크만 합친다. 중간 청크를 합치면 조건이
아닌 것까지 끌어온다.
ELS 청크 55 → 45 · 페이지 걸친 것 10
VAR 청크 82 → 73 · 페이지 걸친 것 9
## 그물을 같이 고쳤다
항등식 테스트를 **조각별**로 바꿨다. 그리고 `test_some_chunks_cross_a_page_boundary` 를
새로 뒀다 — 이 단정이 없으면 **스팬 목록만 만들고 병합이 안 도는 상태가 전건 초록**이고,
그러면 이 커밋이 무의미하다.
463 passed (+2).
9/4 — 채점 품질로 넘어간 날오늘 한 것 — 채점 로직 세 겹❗임베딩을 재고 접었다 — 기록이 값이다
임베딩은 「무엇에 관한 말인가」를 재고 「참인가」는 안 잰다. 기록: ❗❗제일 큰 발견 — 표본이 종결어미로 라벨을 흘린다 (
|
9/4 저녁 — 채점 품질 구간 마감
오늘 머지된 내 것 — 여덟열린 것 — 둘★★ 본체 — 여섯 방법을 다 재고 다섯이 떨어졌다기록: 다섯이 떨어진 이유는 하나다 — 닮음을 재고 있었다. 오해는 닮음이 아니라 ❗하루에 같은 함정 네 번작은 표본 → 전수에서 조건이 바뀌면 무엇을 잰 건지 알 수 없다. ❗내가 낸 사고 — 283줄이 남의 리뷰 대상에 섞였다커밋 안 한 임베딩 작업이 다음공모전 관점 정리채점 정밀도는 이미 목표를 넘었다(QWK 0.884 vs 0.750 · U4→U1 0건). 남은 위험은 오늘 측정 작업의 실질 가치는 정밀도가 아니라 「왜 임베딩·NLI·유사도를 안 쓰나」에 몰랐던 근거 하나내 메모에는 "온프레미스 교체 가능하게 base_url 주입" 만 있고 왜 필요한지가 없었다. |
9/4 오후 ~ 9/5 — 승인 넷을 밀었고 F-DET-001 3단계가 났다머지한 넷 — 전부 로컬 시험 머지로 결과를 먼저 봤다
❗내가 낸 수치가 틀렸다 —
|
③(keep 방향)을 공식 코퍼스로 쟀는데 **측정이 안 된다** — 합의 U4 19건에서 1·2단계가 후보를 0건 만든다. 게이트가 탈 입력 자체가 없다. 그래서 dev set 의 30/30 keep 을 "미탐 0" 으로 읽으면 안 되고 「잴 자리가 없다」가 맞다. 표본이 10건이라는 것도 같이 적었다 — #283 에서 11건으로 방법을 확정했다가 M11 에서 무너진 전례가 있고, 그 자기 인용이 이 숫자의 무게를 재게 한다. 정세현 진단을 문면에 넣었다: 원인은 임계값이 아니라 **패턴의 화법 폭**이다. 패턴이 데모 대본 한 줄에서 나왔고 조정례의 화법 폭이 아니라서, 같은 오해를 한 겹 돌려 말하면 떨어진다. 데모 발화 "은행에서 파니까 원금은 보장되는 거죠" pattern 1.00 els-0004 "그래도 은행 창구에서 파는 건데, 최소한…" ngram 0.179 #377(표본의 화법 폭)과 같은 뿌리, 반대 방향이다. 임계값을 내리면 #203 이 잡은 오탐이 돌아오므로 답이 아니다 — 데이터는 정세현 소유이고 #284 로 갔다. ❗숫자를 한 번 틀렸다가 고쳤다. sample_id 로만 dict 를 만들어 67/18 로 읽었는데, 같은 sample_id 가 두 항목으로 채점돼 있어 3건이 덮였다. 키는 (sample_id, item_id) 다 — run_eval 과 같은 51/19 가 나온다. 그래서 build_polarity_sample.py 가 run_eval 의 aligned·load_labelers 를 그대로 부르는 설계가 맞다(정세현). Refs #397 · #284 · #377 · #283
* feat(F-DET-001): 3단계는 「더 잡는 층」이 아니라 「잘못 잡은 것을 빼는 층」이다 — 극성 게이트 docstring 이 3단계를 "임베딩 유사도로 붙일 예정" 이라 적어 뒀는데 실측으로 반증됐다. 같은 실패를 세 번 쟀다 — 한국어는 부정·양보가 어미에 붙어서 오해와 그 부정은 주제가 같고, 주제를 재는 수단은 전부 같은 곳에서 무너진다. #203 n-gram 어간까지만 자른 조각이 오해와 부정을 못 가른다 #283 임베딩 코사인 M09 에서 정답(0.621)이 어미변형(0.560)보다 높다 9/5 대조 앵커 M09 는 갈리는데(간격 +0.104) M11 은 겹친다(-0.006) 대조 앵커가 M09 에서 됐던 이유는 오해와 정답의 **내용**이 달라서였다. M11 은 같은 명제의 부정만 다르다 — pro·anti 앵커가 둘 다 같은 주제라 margin 이 잡음(±0.05)이 된다. 그래서 극성을 직접 묻는다. 1·2단계가 만든 후보만 검사하고, 후보를 만들지는 않는다. ❗두 필드가 합의할 때만 남긴다. holds 만 보면 비결정적이었다 — 같은 입력 3회 중 1회가 polarity="negative" 인데 holds=True 라는 자기모순으로 갈렸다. holds 만 1/9 · 0/9 · 0/9 holds AND polarity 0/9 · 0/9 · 0/9 덕분에 오해 문장을 데이터로 안 만들어도 된다 — 매칭된 패턴을 그대로 쓴다. 명제형 문장을 쓰면 holds 만으로도 3회 0/9 였지만 라이브러리에 새 필드가 필요하고 그 파일은 정세현 소유다. 게이트가 죽으면 후보를 남긴다(P5 0.2절 — 미탐이 과탐보다 비싸다). client=None 이면 3단계가 아예 안 돈다 — 기존 호출자 둘의 동작은 그대로다. 변조 넷으로 역검증: 합의 규칙 제거 2 failed · 실패 시 삭제 1 · 게이트 미호출 5 · 라벨을 오해 문장으로 1. Refs #284 · #283 · #203 · #395 * fix(F-DET-001): 극성 게이트 로그에서 고객 발화를 뺀다 — type_id 로 되짚는다 (#397 리뷰 ①) 정세현 지적. 로그 네 줄이 utterance[:40] 을 싣고 있었고, 실패 경로만이 아니라 **정상 경로도 후보마다 매번** INFO 로 남았다. 결정 4.8 이 폴백 로그에 누출 조각을 허용한 근거는 'QuestionRequest 에 고객 발화 필드가 아예 없고 조각의 출처가 상품문서·루브릭' 이었다. 여기는 그 근거가 통째로 없다 — 싣는 것이 고객 발화 자체다. P3 마스킹은 성명·주민번호를 지우는 것이지 발화를 지우는 게 아니고, 원문 보존 정책(F-GTE-004)은 evidence/ 에만 걸리므로 로그로 나가면 정책 밖에 사본이 하나 생긴다. type_id 로 바꿨다 — '어느 발화였나' 는 세션ID·항목ID 로 되짚는 것이 원래 경로다. Refs #397 * docs(F-DET-001): 3단계가 임계 경로를 지난다는 것을 문면에 적는다 — 약속을 낮추고 잰 값을 붙인다 (#397 리뷰 ②) docstring 이 "데모 발화가 2단계까지에서 잡혀야 한다. LLM 에 의존하면 임계 경로가 비결정적이 된다" 고 적어 뒀는데, 이 층이 생기면서 그 문장이 거짓이 됐다(정세현 지적). ngram 단계에만 걸어 결정론을 지키는 안을 냈다가 실측으로 철회했다 — 패턴을 축자로 담은 부정문이 pattern 1.00 으로 잡히고 게이트가 3/3 으로 뺀다. **부정하는 발화일수록 패턴을 축자로 담는다**(부정이 어미에 붙어 앞부분이 그대로 남는다). 그 자리를 빼면 이 층을 만든 이유가 없어진다. ❗공식 코퍼스에서는 이 층이 아예 안 돈다 — 합의 U4 19건에서 1·2단계 후보가 0건이다 (pattern 0 · ngram 0, 최고 점수 0.02~0.28 vs 임계 0.62). 그래서 dev set 의 30/30 keep 을 "미탐 0" 으로 읽으면 안 된다. **「잴 자리가 없다」이지 「안전하다」가 아니다** — dev set 은 패턴에서 유도된 표본이라 후보가 잘 생기는 쪽으로 치우친다. 그 0건은 이 파일보다 넓은 사실을 말한다: 강제되는 라이브러리 9종이 공식 코퍼스에서 한 번도 발동하지 않는다. 오해 판정은 지금 전적으로 LLM 이 하고 floor 는 패턴을 그대로 담은 발화에서만 운다 — #284 가 가리키는 공백이다. Refs #397 · #284 * docs(F-DET-001): 3단계가 실측 코퍼스에서 한 번도 안 돈다는 것을 문면에 적는다 (#397 리뷰 ③) ③(keep 방향)을 공식 코퍼스로 쟀는데 **측정이 안 된다** — 합의 U4 19건에서 1·2단계가 후보를 0건 만든다. 게이트가 탈 입력 자체가 없다. 그래서 dev set 의 30/30 keep 을 "미탐 0" 으로 읽으면 안 되고 「잴 자리가 없다」가 맞다. 표본이 10건이라는 것도 같이 적었다 — #283 에서 11건으로 방법을 확정했다가 M11 에서 무너진 전례가 있고, 그 자기 인용이 이 숫자의 무게를 재게 한다. 정세현 진단을 문면에 넣었다: 원인은 임계값이 아니라 **패턴의 화법 폭**이다. 패턴이 데모 대본 한 줄에서 나왔고 조정례의 화법 폭이 아니라서, 같은 오해를 한 겹 돌려 말하면 떨어진다. 데모 발화 "은행에서 파니까 원금은 보장되는 거죠" pattern 1.00 els-0004 "그래도 은행 창구에서 파는 건데, 최소한…" ngram 0.179 #377(표본의 화법 폭)과 같은 뿌리, 반대 방향이다. 임계값을 내리면 #203 이 잡은 오탐이 돌아오므로 답이 아니다 — 데이터는 정세현 소유이고 #284 로 갔다. ❗숫자를 한 번 틀렸다가 고쳤다. sample_id 로만 dict 를 만들어 67/18 로 읽었는데, 같은 sample_id 가 두 항목으로 채점돼 있어 3건이 덮였다. 키는 (sample_id, item_id) 다 — run_eval 과 같은 51/19 가 나온다. 그래서 build_polarity_sample.py 가 run_eval 의 aligned·load_labelers 를 그대로 부르는 설계가 맞다(정세현). Refs #397 · #284 · #377 · #283 * feat(F-DET-001): 극성 게이트가 무엇을 했는지 센다 — 0건과 「모른다」를 가른다 (#398 리뷰 ①②) 정세현 지적. #160 에서 내가 세운 규칙의 **반대 방향**이었다. > 조용히 등급만 바뀌면 감사 시점에 왜 U4 였는지 설명할 수 없다 U4 가 「안 된」 경우에도 똑같다. floor 가 울면 reason 에 상향 사실 · misconception_type → evidence 에 남는다 게이트가 빼면 평범한 U1~U3 · 필드 없음 · INFO 한 줄 → 아무 데도 안 남는다 로그는 evidence 가 아니다(ADR-003 — append-only · 해시 체인 · 정규화 직렬화). evidence 에 넣는 것은 계약 변경이라 이 PR 에서 안 한다 — 대신 계량기를 둔다. 집계·리포트는 #326·#327 에서 정세현이 붙인다(그쪽 몫이라 자리만 연다). ❗not_run 이 dropped == 0 과 다른 것이 요점이다. shadow.ShadowMeter.failed 와 같은 자리이고 결정 5.40("못 잰 값은 0 이 아니라 「모른다」로 적는다") 이다. 게이트가 조용히 영구히 안 도는 경로가 둘인데(LLM 예외 · 클라이언트가 model_cls 를 안 지킴) 둘 다 후보를 남기므로 판정만 보면 게이트가 없는 것과 구별되지 않는다 — ②가 지적한 그것이다. 자기모순(holds=True 인데 polarity 가 긍정이 아님)을 따로 센다. 실측에서 3회 중 1회 나왔고, 그 비율이 오르면 프롬프트가 흔들리는 신호다. 발화를 안 담는다 — #397 리뷰 ①에서 로그의 발화를 뺀 것과 같은 이유다(P3 · F-GTE-004 보존 정책 밖에 사본이 생긴다). 테스트가 by_type 키가 유형ID 인 것을 잠근다. 변조 셋: not_run 미기록 2 failed · 자기모순 미분리 1 failed · 계량기에 발화 담기 2 failed. Refs #398 · #397 · #160 · #326 · #327 · 결정 5.40 --------- Co-authored-by: 윤지석 <yunjiseok@yunjiseog-ui-MacBookPro.local>
* feat(F-DET-001): 3단계는 「더 잡는 층」이 아니라 「잘못 잡은 것을 빼는 층」이다 — 극성 게이트 docstring 이 3단계를 "임베딩 유사도로 붙일 예정" 이라 적어 뒀는데 실측으로 반증됐다. 같은 실패를 세 번 쟀다 — 한국어는 부정·양보가 어미에 붙어서 오해와 그 부정은 주제가 같고, 주제를 재는 수단은 전부 같은 곳에서 무너진다. #203 n-gram 어간까지만 자른 조각이 오해와 부정을 못 가른다 #283 임베딩 코사인 M09 에서 정답(0.621)이 어미변형(0.560)보다 높다 9/5 대조 앵커 M09 는 갈리는데(간격 +0.104) M11 은 겹친다(-0.006) 대조 앵커가 M09 에서 됐던 이유는 오해와 정답의 **내용**이 달라서였다. M11 은 같은 명제의 부정만 다르다 — pro·anti 앵커가 둘 다 같은 주제라 margin 이 잡음(±0.05)이 된다. 그래서 극성을 직접 묻는다. 1·2단계가 만든 후보만 검사하고, 후보를 만들지는 않는다. ❗두 필드가 합의할 때만 남긴다. holds 만 보면 비결정적이었다 — 같은 입력 3회 중 1회가 polarity="negative" 인데 holds=True 라는 자기모순으로 갈렸다. holds 만 1/9 · 0/9 · 0/9 holds AND polarity 0/9 · 0/9 · 0/9 덕분에 오해 문장을 데이터로 안 만들어도 된다 — 매칭된 패턴을 그대로 쓴다. 명제형 문장을 쓰면 holds 만으로도 3회 0/9 였지만 라이브러리에 새 필드가 필요하고 그 파일은 정세현 소유다. 게이트가 죽으면 후보를 남긴다(P5 0.2절 — 미탐이 과탐보다 비싸다). client=None 이면 3단계가 아예 안 돈다 — 기존 호출자 둘의 동작은 그대로다. 변조 넷으로 역검증: 합의 규칙 제거 2 failed · 실패 시 삭제 1 · 게이트 미호출 5 · 라벨을 오해 문장으로 1. Refs #284 · #283 · #203 · #395 * feat(F-DET-001): 극성 게이트를 판정 직전에 건다 — 배선 (#397 후속) 게이트를 `apply_misconception_floor` **바로 앞**에 건다. 자리가 여기인 이유가 둘이다. ① 채점 호출 **뒤**여야 한다 — 앞에 두면 게이트가 첫 LLM 호출이 되고 #281 이 고정한 "첫 시도는 설정 seed 그대로" 가 밀린다. 실제로 그렇게 짰다가 세 테스트가 갈렸다. ② floor **앞**이어야 한다 — 거기서 U4 가 확정되고 오탐의 값이 거기서 발생한다. `match()` 에서 게이트를 떼어 `apply_polarity_gate()` 로 갈랐다. `escalate` 를 다시 계산한다 — 게이트가 M08-TYING 후보를 빼면 그 신호도 같이 사라져야 한다. ❗**세 번 자리를 옮겼고 다 실측이 밀었다.** 1차 `match()` 안 · scoring 클라이언트 공유 30 failed — 스텁이 model_cls 를 안 지킨다 2차 라우트에서 주입 856 passed 인데 **4초 → 17초**. 라우트 테스트가 실제 LLM 을 불렀다 3차 판정 직전 · 같은 클라이언트 859 passed · 4.32초 응답 타입이 PolarityVerdict 가 아니면 게이트가 안 돈 것으로 보고 후보를 남긴다(P5 0.2절). 주입 스텁이 그 경로라 단위 테스트가 LLM 을 안 부른다. ❗`/internal/misconception` 은 게이트를 안 태운다. 그 엔드포인트가 답하는 질문은 "이 발화가 어느 패턴과 겹치는가" 라는 결정론적 측정이고, 기획서 5절이 재현성을 그 성질로 설명한다. 게이트는 판정 입력에만 건다. test_scoring.py 의 두 단정이 스텁 호출을 전부 세고 있었다 — schema_name 으로 채점 호출만 세게 고쳤다. 뜻이 "재판정 횟수" 이므로 그게 원래 의도다. 변조: 배선 끊기 2 failed · 게이트를 앞으로 1 failed(전체에서는 5). Refs #397 · #284 · #281 * fix(F-DET-001): 극성 게이트 로그에서 고객 발화를 뺀다 — type_id 로 되짚는다 (#397 리뷰 ①) 정세현 지적. 로그 네 줄이 utterance[:40] 을 싣고 있었고, 실패 경로만이 아니라 **정상 경로도 후보마다 매번** INFO 로 남았다. 결정 4.8 이 폴백 로그에 누출 조각을 허용한 근거는 'QuestionRequest 에 고객 발화 필드가 아예 없고 조각의 출처가 상품문서·루브릭' 이었다. 여기는 그 근거가 통째로 없다 — 싣는 것이 고객 발화 자체다. P3 마스킹은 성명·주민번호를 지우는 것이지 발화를 지우는 게 아니고, 원문 보존 정책(F-GTE-004)은 evidence/ 에만 걸리므로 로그로 나가면 정책 밖에 사본이 하나 생긴다. type_id 로 바꿨다 — '어느 발화였나' 는 세션ID·항목ID 로 되짚는 것이 원래 경로다. Refs #397 * docs(F-DET-001): 3단계가 임계 경로를 지난다는 것을 문면에 적는다 — 약속을 낮추고 잰 값을 붙인다 (#397 리뷰 ②) docstring 이 "데모 발화가 2단계까지에서 잡혀야 한다. LLM 에 의존하면 임계 경로가 비결정적이 된다" 고 적어 뒀는데, 이 층이 생기면서 그 문장이 거짓이 됐다(정세현 지적). ngram 단계에만 걸어 결정론을 지키는 안을 냈다가 실측으로 철회했다 — 패턴을 축자로 담은 부정문이 pattern 1.00 으로 잡히고 게이트가 3/3 으로 뺀다. **부정하는 발화일수록 패턴을 축자로 담는다**(부정이 어미에 붙어 앞부분이 그대로 남는다). 그 자리를 빼면 이 층을 만든 이유가 없어진다. ❗공식 코퍼스에서는 이 층이 아예 안 돈다 — 합의 U4 19건에서 1·2단계 후보가 0건이다 (pattern 0 · ngram 0, 최고 점수 0.02~0.28 vs 임계 0.62). 그래서 dev set 의 30/30 keep 을 "미탐 0" 으로 읽으면 안 된다. **「잴 자리가 없다」이지 「안전하다」가 아니다** — dev set 은 패턴에서 유도된 표본이라 후보가 잘 생기는 쪽으로 치우친다. 그 0건은 이 파일보다 넓은 사실을 말한다: 강제되는 라이브러리 9종이 공식 코퍼스에서 한 번도 발동하지 않는다. 오해 판정은 지금 전적으로 LLM 이 하고 floor 는 패턴을 그대로 담은 발화에서만 운다 — #284 가 가리키는 공백이다. Refs #397 · #284 --------- Co-authored-by: 윤지석 <yunjiseok@yunjiseog-ui-MacBookPro.local>
9/5 — CI 가 살아나고 실문서 흐름이 하루에 섰다. F-DET-001 3단계 완료하루에 팀이 25건 넘게 밀었다. 내 몫은 아래 넷이고 나머지는 리뷰였다. 내 PR 넷이 나갔다★ F-DET-001 3단계 — 원안이 틀렸고 실측이 세 번 방향을 밀었다
M09 에서 됐던 이유는 오해와 정답의 「내용」이 달라서였다(팔 수 있다 ↔ 상장이 안 됐다). → 같은 실패를 세 번 쟀다: n-gram( 그래서 3단계는 「빼는 층」이다1·2단계가 만든 후보에만 극성을 직접 묻는다. 핵심은 두 필드 합의 규칙이다. 갈린 회차가 ❗배선 자리를 세 번 옮겼다 — 2차가 위험했다2차는 전건 초록이라 그대로 낼 뻔했다. → 초록은 「LLM 을 안 불렀다」를 증명하지 않는다. 리뷰에서 받은 지적 — 셋 다 내 규칙의 반대편이었다
❗내가 낸 수치가 또 틀렸다 (
|
|
10.68 의 앞부분만 인용됐고 뒷부분이 그 문장을 뒤집는다.
즉 그래서 오늘 alpha 에서 한 것이 데모 대상이 맞다내가 오늘 alpha 에 실추출을 돌렸고(ELS 13 · 변액 10), 그게 데모에서 쓰는 그 환경이다. 만약 prod 가 대상이었으면 그 작업이 전부 헛것이 될 뻔했다. 같이 적어 둘 것 하나 — 역할 차단 시연은 alpha 에서 안 된다. 개방 모드가 모든 방문자를 나머지 노트 내용은 오늘 내가 본 것과 같다. |
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
* fix(F-DET-001): 극성 게이트가 «지금 믿는 것» 을 먼저 적고 판정한다 — 정정 발화가 U4 에서 빠져나온다 (#503) ## 증상 (alpha 재현) ① "은행에서 파는 거니까 원금은 지켜지는 거죠." → U4 ✅ ② 재설명 ③ "아, 예금자보호가 안 되는 상품이군요. 발행사가 잘못되면 원금을 못 받을 수 있다…" → ❗U4 (모델은 U1 로 봤다) 사유 문면: "…정확히 말했고 … 이해했다고 진술했기 때문. (오해 라이브러리 매칭 [ngram 0.7143])" → apply_misconception_floor 가 끌어올렸다. 재설명 뒤 고객이 고쳐 말해도 빠져나올 수 없었다. ## 기전 1·2단계 «예금자보호가 «안» 되는» ↔ 패턴 «예금자보호 되는 줄» ngram 0.714 문자 바이그램은 「안」을 못 본다 (한국어 부정은 어간을 안 바꾼다) 3단계 극성 게이트가 이걸 빼야 하는데 holds=True·positive → 유지 → floor → U4 이 층은 정확히 이걸 막으려고 만든 것이다 (#397) ## 무엇을 고쳤나 — 두 가지, 둘 다 필요조건이다 ① PolarityVerdict(BaseModel) → (Strict) additionalProperties:false 가 생겨 llm_client 가 strict:true 를 켠다 (#490 과 같은 뿌리). BaseModel 이면 모델이 스키마를 최선노력으로만 따른다. ② belief: str 를 **첫 필드**로 + 시스템 프롬프트에 "먼저 고객이 «지금» 믿는 것을 한 문장으로 적고(고쳐 말한 것은 빼고), 그 다음 그 문장이 오해 문장과 같은 주장인지로 holds 를 정한다" 구조화 출력은 필드를 순서대로 채우므로 이 한 단계가 판정 절차가 된다. ## 실측 (gpt-5-mini · 2026-09-06) — 무엇이 고쳤고 무엇이 아닌가 문제 발화 (기대 False) BaseModel N=3 3/3 오판 Strict 만 N=3 0/3 → ❗N=10 6/10 오판 (3회는 운이었다) Strict + belief N=10 0/10 + 부정어 힌트 N=10 0/10 (더한 것 없음) 실물 match(client=) 끝까지 · 8케이스 × N=10 · 총 80회 V2(이것) 6/80 오판 — 정정·부정·범위제한·#395 M11 오탐·M02·M09 전부 0/10 V4(+반문을 주장으로 지시) 12/80 오판 — M11 반문 0/10 이 되지만 정정 발화 4/10·M09 8/10 이 되돌아옴 프롬프트에 「동사 앞 부정」 지시를 더한 것: 4/5 ↔ 4/5 로 실패를 옮길 뿐. 임계값: 진짜 오해 최저 0.727 vs 이 오탐 0.714 — 1.3% 차이라 못 가른다. 라벨(«예금자보호 오인»)을 오해 문장으로: 명제가 아니라 전부 True — 더 나쁘다. ## ❗잔여 — 정직하게 진짜 오해 M11 반문형 «이것도 예금처럼 전액 보호되는 거 아닌가요» (기대 holds=True) 옛 게이트 10/10 오판 (전부 뺀다 — 미탐, P5 0.2절 방향) ← #425 가 M11 을 링크할 때 게이트 없는 매처로만 재서 아무도 못 본 자리 이것 6/10 오판 — 줄었지만 안 닫혔다 회귀가 아니라 기존 미탐이고, 반문 지시(V4)로는 실패가 옮겨간다. 라이브러리에 명제형 claim 이 생기면 다시 잰다 (#503 후속). docstring 에 표로 적었다. ## 그물 test_the_verdict_schema_is_strict_eligible Strict · required={belief,holds,polarity} · belief 가 첫 필드 test_the_system_prompt_asks_for_the_current_belief_first 프롬프트가 지시를 든다 (필드와 한 벌) test_structured_output_strict EXPECTED PolarityVerdict False → True (실제로 보내 봤다) 변조 4/4 ⓐ BaseModel 되돌림 2 failed · ⓑ belief 제거 8 failed · ⓒ belief 마지막 필드 1 failed ⓓ 프롬프트 지시 제거 1 failed ❗belief 는 고객 발화에서 유도된 문장이다 — 로그에 싣지 않는다 (#397 ① · P3). ## docs/proposal.md — 이 기능에 맞춰 세 곳 §4 핵심 엔진·오해 탐지 "오해는 「고쳤다」로 끝나야 한다" — 정정 발화가 빠져나오는 경로 한 줄 §5 생성형 AI의 역할 "LLM 의미 유사도" → 실제 3단계(패턴 → n-gram → 극성만 판정·빼기만). 임베딩은 극성을 못 가른다는 실측으로 채택하지 않았다고 적음 (#283) §5 오판 처리 표 이해→오해 오판 행의 방어 장치에 극성 게이트 추가 docs/ 는 정세현 소유 — 리뷰 요청. ## 검증 ai-service 1040 passed (+1) · eval 84 · LLM 호출 없음(스텁이 belief 를 채운다) alpha 재현 세션: ad6243e9 (①②③ 그대로) 관련: #503 · #397 · #490(strict 의 뿌리) · #395·#425(M11) · #363(자기정정 축) · P5 0.2절 · P3 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(기획서): MVP 에서 실제로 쓴 공시문서 2건을 적는다 §5 [활용 데이터] 가 «수집처» 목록만 들고 있어서, 실제로 무엇을 쓴 문서인지가 문서 어디에도 없었다. 심사에서 «어떤 문서로 돌렸나» 를 물으면 답할 자리가 필요하다. ELS 간이투자설명서 16쪽 13,233자 이해항목 13(필수 10) 금투협 전자공시 변액 상품요약서 18쪽 20,581자 이해항목 10(필수 7) 생보협 공시실 전부 실측이다 — 계약 샘플(parsed_*_sample.json)의 쪽·글자 수, alpha 의 risk-items 조회, 화면 표기는 GET /api/products 응답이다. 세 줄을 같이 적었다. - 텍스트 레이어가 있어 OCR 없이 위치까지 짚는다 → P6(원문 인용) 이 성립하는 이유 - 변액 운용설명서는 «정답지 대조에만» 쓴다 — 상품요약서 하나로는 10종을 못 덮는다(ADR-007). 런타임이 읽는 것은 2건이고 그 구별이 없으면 문서 수가 어긋나 보인다 (ProductRiskItems:36-37 이 그 매핑) - 가명 처리(A증권·B생명)는 화면에 실제로 그렇게 나간다 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(기획서): 「제출 전 5~10건 확인」을 MVP 범위 2건으로 고친다 미이행 계획이 현재형으로 남아 있었다 — 실제 문서는 2종이다. #505(v1.2)가 미구현을 미구현으로 적은 것과 같은 기준으로 맞춘다. 전 "제출 전 동일 유형 문서를 5~10건 실제로 내려받아 파서의 형식 편차 대응 범위를 확인한다" 후 "MVP 범위는 위 2건이다 … 파서는 이 두 문서의 표 구조에 맞춰 고쳐 왔으므로 다른 발행사 서식에서의 형식 편차는 아직 재지 않았다 — … 넓히는 것은 다음 단계다" ❗«아직 재지 않았다» 를 적은 것이 요점이다. 파서를 이 두 문서에 맞춰 고쳐 온 것이 사실이고 (#452 표 칸 순서 · #458 같은 y 로 합쳐 온 칸 가르기), 그 사실을 안 적으면 «신상품에도 바로 붙는다»(§4)가 서식 편차까지 검증된 것으로 읽힌다. §4 는 «상품유형 템플릿» 축의 주장이고 여기는 «발행사 서식» 축이라 다른 말이다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: 윤지석 <yunjiseok@yunjiseog-ui-MacBookPro.local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
yoonjiseok
changed the title
2 participants
9/15 — 내가 승인한 PR 에서 내 문장이 낡는 것을 오준서가 잡았다 (갱신 46회차)
★★ 내 코드가 어디에 있나
❗이 PR(
#283)에는 코드가 없다 — 빈 커밋 + 본문만(#196).#617draft 드러내기 ·#619「N 벌」 주석main#613F-EXT-002 인용 넓힘origin/fix/F-EXT-002-evidence-covers-required-456be3b7a4#623Judgment.rubric_statusorigin/feat/F-SCR-001-judgment-rubric-status-6091823ae1❗
CLAUDE.local.md는 안 넘어간다(gitignore) · 작업 전git fetch(#298·#338).46회차 — 조용하다. 새로 온 것이 하나도 없다
❗조회는 돌았고 변화가 없는 것이다(못 돈 것이 아니다).
main도 내 PR 둘도 그대로이고,#625의 마지막 발언은 내 답이다. 45회차 내용이 그대로 유효하다.★★
#625— 내가 승인한 PR 이 내 문장을 낡게 만든다. 오준서가 잡았다#619(내 것, 어제 06:27 머지)가main에 넣은 줄이다.#625가 그 코드를 계약 enum 에 넣는다(openapi.yaml:942). 머지되는 순간 거짓이 된다.단정이 아니라 docstring 이라 안 빨개진다 — 그래서 더 나쁘다.
❗내가 그 PR 을 승인하면서 못 봤다. 더 나쁜 것은 같은 리뷰에서 "정확한 문면은 「대개는
다르고 겹치는 예외가 둘」" 이라고 적어 놓고 그 문장이 걸리는 내 파일을 안 본 것이다.
내가 보탠 것 — 낡는 것이 한 줄이 아니라 둘이다
:106이routes.py의 문장을 인용하는데 이 PR 이 그 문장을 지운다.→ 머지되면 없는 문장을 인용한다.
#341(절 제목 인용이#305로 끊긴 것)과 같은 종류다.대체 문면은 인용 대신 표 이름(
_REFUSAL_RESPONSE)으로 가리키게 냈다 — 그쪽 문면이 또바뀌어도 안 끊긴다.
❗고치는 자리는 그 PR 이다 — 내가 따로 내면 순서 창이 생긴다
#623↔#624와 같은 모양이라 내 파일 편집에 동의한다고 적었다.전수로 훑었고 한 곳 더 있는데 그건 안 낡는다
❗훑을 때 백틱 때문에 한 번 빗나갔다 —
ApiError.code 가 아니로 찾으니`ApiError.code` 가가 안 잡혔다. "정규식 이스케이프 때문에 부분열 검사가 빗나간다" 를 또 밟았다.
#612— 전원 승인·재타겟 완료인데 아무도 안 누르고 있다정세현이
#610을 머지하고#612base 를main으로 돌렸다(결정 9.1 대로 재타겟 먼저 →브랜치 삭제라 자식이 안 닫혔다). 지금 가드
pass(전원 승인)인데 강희진 PR 이라 나도 정세현도안 누른다. 그 위에
#614가 대기 중이다.#625앞선 왕복 — 규약은 아직 안 올린다내가 "그물을 만들면 자기 문면부터 걸어 본다" 를 규약 후보로 냈고, 강희진이 두 사례가 반대
방향이라 한 문장이 반쪽만 막는다고 답했다.
→ 공통 모양은 모집단이라고 답하고("그 모집단에 지금 내가 쓰는 파일이 들어가는지"),
지금 안 올리는 데 동의했다. 이건
#533ⓒ 의 "그물은 모집단이 맞아야 한다" 재발이라셋째 사례가 나와야 붙일지 세울지 정해진다.
지금 열린 PR
다음에 할 것
#625가 내 파일 두 줄을 같이 고치면 재확인 → 승인 유지#624머지되면#623main 합쳐 다시 재고 draft 해제#628머지되면 두 대조가 서로 가리키는 한 줄#613강희진 승인 → 머지#589ⓐ ·#630심사 근거 ·#491투영 — 전부 답 대기0.7이 gemini 관측값이다#615재생성(정세현) ·#377움직이면 내가 신호이 회차에서 굳은 것
거짓으로 만드는지 본다. 이번엔 같은 리뷰에서 옳은 문면을 적어 놓고 내 파일에 적용을
안 했다 — 말과 자리가 따로 놀았다.
(
#341이 절 제목에서 밟은 자리).`X` 가는X 가로 안 잡힌다.#612).로컬 상태
❗
CLAUDE.local.md는 git 에 안 올라간다 — 인계 정본은 이 PR 이다.