품질 게이트

answer_evidence_recall

답을 만든 사례만 보면 세 실행 모두 1.0000(변동폭 0)입니다. 그래서 좁게 둘 수 있고, 이것이 이 게이트의 본 규칙입니다.

answer_failure_rate

낮은 쪽이 좋은 지표입니다. 관측 범위 0.0333~0.1000의 최대에 사례 한 건을 더했습니다. 3회차가 정확히 0.1000이었으므로 이전 상한 0.10은 경계에 걸터앉은 값이었습니다.

hit_at_k

구조적으로 2/3 근처가 상한입니다(author·topcited 12건은 Text2Cypher가 답합니다, ADR-008). 게다가 변동폭이 0.166이라 n=30에서는 작은 회귀를 구별할 수 없습니다. 하한은 파국만 잡습니다. **그리고 이 지표가 재는 것이 순위 품질이 아니라는 것을 2026-10-19에 측정했습니다**(ADR-033): 답변 조회의 ORDER BY가 30건 중 24건에서 제목 알파벳순이고, retrieved_ids 집합이 30/30에서 골드 집합과 정확히 같습니다. 즉 1위는 '제목의 첫 글자'이고 1.0000은 '목록이 전부 골드'라는 뜻입니다. 지우지는 않습니다 - 검색이 깨지면 내려가므로 회귀 탐지기로는 유효합니다.

no_drop_on_rank_metrics

순위 지표의 관측 변동폭이 커서 허용폭을 두지 않습니다. 관측값: {"answer_evidence_precision": 0.0, "answer_evidence_recall": 0.0, "answer_failure_rate": 0.0667, "completed_cases": 2.0, "hit_at_k": 0.166, "recall_at_k": 0.143, "reciprocal_rank": 0.1488}

ragas_faithfulness

**파국만 잡는 하한입니다.** 5회 관측 0.9833 / 0.9667 / 0.9500 / 0.9000 / 0.9806이고 변동폭은 4회에서 0.0833이 된 뒤 5회에서도 0.0833입니다(2회 0.0167, 3회 0.0333에서 넓어진 뒤 멈췄습니다). 이 지표의 집계는 **사례별 0/1 판정의 개수**이고(한 건 = 1/30 = 0.0333), 그 0점은 답변 품질을 따라가지 않습니다 - reference-01의 답변이 1회차와 4회차에서 사실상 같은데 1.0000에서 0.0000으로 뒤집혔습니다(EXPERIMENTS 11-13절). 작은 회귀는 구별할 수 없으므로 하한은 심은 결함 수준(0.0000~0.6100, 11-10절)만 잡게 0.80에 둡니다. **2026-10-19(ADR-043) 저장소의 모든 실행으로 다시 셌습니다 — 12회입니다.** 세 코드 상태(resolve 3회, routed 3회, study_full 6회)의 집단별 변동폭은 0.0344 / 0.0167 / 0.0917이고, 정상이던 실행 중 최악은 **0.9000**(ragas_study_full_run4)으로 하한까지 0.1000 남습니다. 결함을 심으면 0.4025·0.4192로 내려가 하한이 걸립니다. 그래서 하한 0.80은 그대로 두고 **표본을 더 늘리지 않습니다** — 재서 결정이 바뀌지 않습니다(reports/ragas_floor_basis.json).

ragas_context_precision_stable_families

**가족 집합을 한 번 좁혔고, 다시 좁히지 않습니다.** 처음에는 3회 관측으로 author·citing·topcited를 골랐는데, citing-06이 4회차에, citing-02가 5회차에 0.1667로 무너져 변동폭이 0.0000 -> 0.0463 -> 0.0926으로 계속 넓어졌습니다. citing을 빼면 author·topcited 12사례가 5회 전부 1.0000(변동폭 0.0000)입니다. citing이 움직이는 이유는 그 질문에서 에이전트가 가져오는 문맥 개수가 실행마다 달라지고, 이 지표가 **답변에 의존**하기 때문입니다(11-10절). 하한은 그래도 파국용 0.85로 둡니다 - '변동폭이 0이다'라는 전제는 이미 두 번 깨졌고, 같은 전제에 좁은 하한을 다시 얹지 않습니다. **author나 topcited가 무너지면 하한을 또 내리는 대신 이 지표를 게이트에서 뺍니다.** 하한을 관측에 맞춰 반복해 내리면 게이트가 장식이 됩니다. **2026-10-19(ADR-043) 12회 전부 1.0000입니다**(변동폭 0.0000). 상수에 걸린 하한은 게이트가 아니므로 결함을 심어 확인했습니다 — author·topcited의 사례별 값이 [0.0, 1.0, 0.0, 1.0]이 되어 집계가 **0.5000**으로 내려가고 하한 0.85가 걸립니다. `context_relevance`를 뺀 이유(ADR-021: 결함에서도 1.0000)와 **갈라지는 지점**입니다.

no_drop_on_ragas

RAGAS 지표에는 허용폭도 사례별 규칙도 두지 않습니다. 사례별 판정이 같은 답변에서도 0과 1을 왕복하고(reference-01: 1,1,1,0 / coauthor-02: 1,0,1,0 / citing-06의 context_precision: 1,1,1,0.1667) 집계는 그 개수이므로, n=30에서 작은 회귀를 변동과 구별할 수 없습니다. 구별할 수 없는 값에 규칙을 붙이면 규칙이 아니라 숫자입니다.

ragas_judge_model

기준선의 RAGAS 값은 이 판정 모델로 쟀습니다. 다른 모델로 잰 점수를 같은 표에 올리면 모수가 다른 값을 비교하게 됩니다(metrics_split과 같은 규칙). 2026-10-17에 CI가 OPENAI_MODEL을 넘기지 않아 실제로 그 일이 있었고, 그래서 게이트가 막습니다.

answer_evidence_precision

0.99에서 0.95로 **넓혔습니다**(2026-10-18). 라우팅(ADR-024) 뒤 재측정에서 3회 중 한 번 `citing-03`이 시드 논문 자신을 근거에 넣어 precision이 0.6667이 됐고, 30건 집계가 (29 + 0.6667)/30 = 0.9889로 하한 0.9900을 0.0011 넘겼습니다. 즉 **기준선을 만든 실행이 그 기준선에 걸립니다.** 관측 변동폭 0.0111이 하한까지의 여유 0.0063보다 커서, 0.99는 품질이 아니라 변동을 막는 하한입니다(90 사례-실행 중 1건 -> 30건 실행이 빨개질 확률 약 28%). 0.95는 같은 사례 4~5건까지 견디고 계통적 고장은 여전히 막습니다. **근본 원인은 따로 고칩니다**: 제목을 arxiv_id로 바꾸는 중간 조회의 행이 `evidence_ids`에 시드를 담고, 그것이 (1) `retrieved_ids` 1위를 차지해 reciprocal_rank 상한을 0.7000으로 묶고 (2) RAGAS context_precision을 절반으로 깎고 (3) 드물게 답변 근거로 새어 나옵니다. 중간 조회 결과를 근거와 분리하면 셋이 한 번에 풀리지만 지표 정의가 바뀌어 기준선을 다시 써야 하므로 다음 주기로 둡니다.

retrieval_precision

**순서에 의존하지 않는 지표라서 하한이 뜻을 가집니다**(ADR-033). 세 상태를 쟀습니다 - 그래프 경로 1.0000(3회, 변동폭 0.0000) / 2026-10-16 라우팅 전 0.7908 / 같은 보고서의 vector_only 0.0083. 재난은 세 번째입니다: 그래프 질문이 그래프 경로로 가지 않는 상태. 0.70은 그것을 확실히 잡고(0.0083), 라우팅 전의 섞인 상태(0.7908)는 잡지 않습니다 - 그 상태는 나빴지만 답변 근거는 1.000이었고 우리가 이미 고쳤습니다. 측정값 1.0000과 같게 두지 않는 이유는 ADR-004와 같습니다.

retrieval_recall

같은 세 상태에서 1.0000 / 0.9667 / 0.0111입니다. 라우팅 전 0.9667이 하한을 넘지 않아야 합니다 - 그때의 문제는 **못 찾은 것이 아니라 너무 많이 찾은 것**이었고(집합 recall 1.0000인데 recall_at_k 0.1667), 그 구별이 이 지표를 더한 이유 자체입니다. 그래서 0.90입니다: 골드를 10% 넘게 놓치면 답변이 맞을 수 없습니다.

drop_on_set_metrics_but_not_rank_metrics

순위 지표에는 허용폭을 두지 않고(아래 no_drop_on_rank_metrics) 집합 지표에는 둡니다. 차이는 **측정된 변동폭**입니다 - 집합 지표는 90 사례-실행(3회x30건) 전부에서 1.0000이고 변동폭 0.0000입니다. 조회가 돌려준 집합에 대한 순수 집합 연산이라, 흔들릴 여지가 모델이 다른 질의를 고르는 경우뿐입니다. 0.05의 뜻은 '사례 세 건이 초과 조회를 시작했다'입니다 (한 건이 2편 골드에 7편을 돌려주면 그 건 0.2857, 30건 평균 0.9762 -> 하락 0.0238이므로 한두 건은 통과하고 세 건에서 걸립니다). 이 규칙이 있어야 ADR-024가 찾은 회귀(1.0000 -> 0.8244)를 게이트가 잡습니다 - 하한 0.70만으로는 지나갑니다.

ragas_floor_basis

두 하한의 근거를 **게이트가 보는 양**으로 셉니다. `evals.ragas_spread`의 METRICS는 RAGAS 원래 지표이고, 전체 가족 평균 context_precision은 약 0.70인데 게이트의 하한은 author·topcited만의 평균(1.0000)에 걸려 있습니다. 전체 평균의 변동폭을 하한의 근거로 읽으면 다른 양을 근거로 삼는 것이므로, `--floors`가 가족을 좁힌 뒤 셉니다.

물을 것은 "평균이 하한보다 큰가"가 아닙니다(ADR-004·ADR-043). 정상이던 실행 중 최악이 하한을 넘는가, 그리고 결함을 심으면 걸리는가입니다. 둘째가 아니면 그 하한은 상수에 걸려 있습니다.

sha256 앞 12자입니다. 지문이 다르면 다른 프롬프트이고, 게이트의 prompt_version 규칙이 막습니다 — git_sha로는 대신할 수 없습니다(ADR-018·ADR-041).