--- title: "S3 dogfood query 의 nli_model_unavailable consistent fail — hypothesis-side 토큰 overflow 가 NLI tokenizer 의 OnlyFirst-too-short 에러를 trip" date: 2026-05-26 task_id: s3-nli-unavailable status: open target_version: 0.18.1 sibling_of: tasks/HOTFIXES.md "2026-05-25 — fb-41 pre-v0.18 dogfood: multi-hop score-gate 우회" fix_files: - crates/kebab-nli/src/lib.rs # NliVerifier trait 의 hypothesis_token_count default impl - crates/kebab-nli/src/onnx.rs # OnnxNliVerifier::hypothesis_token_count override + HYPOTHESIS_TOKEN_BUDGET - crates/kebab-rag/src/pipeline.rs # truncate_hypothesis_for_nli_with_budget + MAX_NLI_HYPOTHESIS_CHARS_INITIAL/MIN + step 8.5 callsite - crates/kebab-rag/tests/common/mod.rs # SpyNliVerifier helper fix_symbols: - "kebab_nli::NliVerifier::hypothesis_token_count (trait method, default impl)" - "kebab_nli::OnnxNliVerifier::HYPOTHESIS_TOKEN_BUDGET (const 256)" - "kebab_rag::pipeline::MAX_NLI_HYPOTHESIS_CHARS_INITIAL (const 1200)" - "kebab_rag::pipeline::MAX_NLI_HYPOTHESIS_CHARS_MIN (const 150)" - "kebab_rag::pipeline::truncate_hypothesis_for_nli_with_budget" --- # S3 NLI unavailable — Hypothesis-side overflow trips OnlyFirst-only tokenizer ## §1. 진단 (Root cause) `crates/kebab-nli/src/onnx.rs::OnnxNliVerifier::load_tokenizer` (line 216-223) 는 mDeBERTa-v3 tokenizer 를 다음과 같이 설정: ```rust tokenizer.with_truncation(Some(TruncationParams { max_length: MAX_TOKENS, // 512 strategy: TruncationStrategy::OnlyFirst, stride: 0, direction: TruncationDirection::Right, })) ``` `OnlyFirst` 는 *2-sequence input* 일 때 첫 번째 sequence (= premise) 만 자른다. 두 번째 sequence (= hypothesis) 가 *단독으로* `max_length - special_tokens (≈ 509)` 를 초과하면, premise 를 0 까지 잘라도 fit 시킬 방법이 없어 `tokenizers` crate 가 `TokenizerError::SequenceTooShortToTruncate` 를 raise: ``` Truncation error: Sequence to truncate too short to respect the provided max_length ``` `pipeline.rs::ask_multi_hop` (line 1041) 는 premise 측만 char-budget 으로 자르고 (`truncate_for_nli` / `MAX_NLI_PREMISE_CHARS = 1600`), hypothesis (`acc` = LLM-synth answer) 는 raw 로 `v.score(&truncated_premise, &acc)` 호출. `Err` 가 나오면 line 1057-1064 의 `Err(e) => return self.refuse_nli_model_unavailable(...)` 가 *모든* tokenizer/inference err 를 `RefusalReason::NliModelUnavailable` 로 단일화 → wire 상 "모델 unavailable" 로 보고. ### S3 의 특이성 - Query: `"Why does kebab combine multilingual-e5, LanceDB, and RRF together?"` - KB: kebab self-knowledge (README / spec / SMOKE / ARCHITECTURE / HANDOFF). retrieval 이 다수 chunks 반환 → synthesize prompt 가 풍부 → gemma3:4b 가 장황한 답 생성. **Evidence chain (round-1 critic H1 closure — 두 invocation 분리 명시)**: 1. **LLM answer 길이 evidence**: `/build/cache/dogfood-v018/results/s3-multihop.json` (2026-05-25 dogfood, `nli_threshold = 0` 즉 NLI off) — `usage.completion_tokens = 949`, `answer chars = 4564`. *이 invocation 의 refusal 은 `llm_self_judge` (NLI off 상태)* — NLI tokenizer 는 호출조차 안 됨. *오직* "S3 같은 query 가 KB self-knowledge 라 LLM 이 verbose 답을 생성한다" 는 *답변 길이* 만 evidence. 2. **NLI tokenizer error evidence**: `~/.local/state/kebab/logs/kb.log.2026-05-26` 의 5 회 WARN 라인 (2026-05-26 retest, NLI threshold > 0 활성) — `tokenizer.encode failed: Truncation error: Sequence to truncate too short to respect the provided max_length`. 이 retest 의 JSON 결과는 미보존 (별 follow-up `--json` redirect 누락) — wire evidence 는 log 만. 3. **연결 추론**: long answer (#1) + NLI 활성 (#2) → OnlyFirst-only tokenizer 가 hypothesis 단독 cap 초과 → tokenizer error → `nli_model_unavailable` wire. 두 invocation 의 mechanic 이 같은 root cause 로 수렴. 다른 PASS 케이스 (S1=한국어 컴파일러, S7=caffeine, S10=dinosaurs) 는 KB 에 본문 fact 가 *없거나* 부분만 있어 답이 짧다 (S7 retest: `/build/cache/dogfood-v018/results/post-pr9/s7-multihop.json` 의 `usage.completion_tokens = 114`). 그래서 NLI tokenizer 가 정상 작동하고 `nli_score` 가 측정됨 (낮아서 verification_failed 로 거부됨). ### Tracing surface 진단 evidence (`kb.log.2026-05-26` 의 WARN 5 회) 발견 시 *우회 자체* 가 시간 비용 — 별 task `§6 #2 (KEBAB_LOG_STDERR opt-in)` + `§6 #7 (README/SMOKE 안내 한 줄)`. **본 spec scope 외** (round-1 critic M4 closure — root cause 와 무관, defer 로 정렬). ### Hypothesis 별 검증 (analyst empirical) - **A (ort Session::run shape err)** — REJECTED. tokenizer 가 먼저 실패해 Session::run 까지 도달하지 않음. 에러 메시지가 ort 가 아니라 `tokenizer.encode failed`. - **B (tokenizer encode fail)** — **CONFIRMED**. error 메시지 텍스트 일치. - **C (hf-hub Cache::get probe race)** — REJECTED. 모델 cache 존재 + 매 invocation 결정적 같은 실패. - **D (OnceLock partial init race)** — REJECTED. sequential dogfood, single-thread `App` boot. 같은 input 으로 매번 같은 실패 → race 아님. ### 313 s latency 의 정체 NLI 가 hang 한 게 아님. dogfood S3 의 `latency_ms` 는 gemma3:4b 의 **synthesize hop LLM streaming 시간**. NLI tokenizer 는 ms 단위 fast-fail. --- ## §2. 영향 | Surface | 영향 | |---|---| | Production behavior | NLI gate 활성 (`rag.nli_threshold > 0`) 인 KB 에서 LLM 이 **500 tokens 초과** 답변을 생성하면 항상 `nli_model_unavailable` refusal. KB-rich self-knowledge query / 다단계 multi-hop 결과에서 빈번. | | Wire (`answer.v1`) | `refusal_reason = "nli_model_unavailable"`, `verification = null`. 사용자/agent 가 "NLI 모델 다운로드 / 로드 문제" 로 오인. | | Wire (`error.v1`) | 영향 없음 — refusal envelope 만 사용, error envelope 으로는 안 빠짐. | | 사용자 binary | `[rag] nli_threshold = 0` (현 default) 사용자: 미영향. README + frozen design 의 *권장 production 0.5* 활성 사용자: KB-rich self-knowledge query 또는 verbose LLM 답변에서 빈번 노출 — `nli_model_unavailable` refusal 받음 (round-1 critic M5 정정: "일반 사용자 미영향" 은 *현 default 기준* 만 정확, *권장 사용 기준* 으로는 misleading). | | NLI model 자체 | **정상**. Cache 정상, `score` 도 짧은 hypothesis 에는 작동. | --- ## §3. Fix design ### Option A (권장) — Char-budget + token-count fallback retry (round-1 critic H3 + verifier Blocker 2 closure) `crates/kebab-rag/src/pipeline.rs` 의 premise-side `truncate_for_nli` + `MAX_NLI_PREMISE_CHARS = 1600` 패턴을 hypothesis 에도 대칭 적용하되, **char-budget 만으로는 KR-heavy hypothesis (1-2 chars/token) 가 512 cap 을 단독 초과 가능** (1200 KR chars × 1 char/token = 1200 tokens >> 512). 따라서 char-truncate 후 *실 mDeBERTa tokenizer 로 token-count 재검증* → 초과 시 char budget 절반으로 retry. 최악 fallback 시 `nli_model_unavailable` (regression 0). #### `kebab-nli` crate 의 API 작은 확장 **Trait 확장 + impl placement** (round-3 critic RC1-residual closure — `hypothesis_token_count` 가 *inherent* 가 아닌 *trait impl block* 안에 위치해야 trait dispatch 가 vtable 통해 호출 — production silent NO-OP 회피): ```rust // crates/kebab-nli/src/lib.rs — trait 확장 pub trait NliVerifier: Send + Sync { fn score(&self, premise: &str, hypothesis: &str) -> anyhow::Result; /// Probe-only tokenize for caller-side budget verification. round-1 /// critic H3 closure — pipeline 의 char-budget retry loop 가 이 API 로 /// `OnlyFirst` dead-end 회피. /// /// **Default impl 반환 0** — 기존 mock implementations /// (`MockNliVerifier`) 가 trait 확장 후에도 backward-compat (compile /// fail 회피, retry loop immediate 통과). `OnnxNliVerifier` 는 real /// tokenizer 로 *trait impl 블록 안에서* override (round-3 critic /// RC1-residual — inherent method 는 vtable 미등록 → trait dispatch /// 시 default 호출 → silent NO-OP). fn hypothesis_token_count(&self, _hypothesis: &str) -> anyhow::Result { Ok(0) } } ``` ```rust // crates/kebab-nli/src/onnx.rs — inherent 와 trait impl 분리 impl OnnxNliVerifier { /// Hypothesis-side budget. Pipeline uses this to size its /// char-truncation retry loop. = MAX_TOKENS (512) - 3 special tokens /// reserved (CLS, SEP, SEP) - some premise room (caller decides). pub const HYPOTHESIS_TOKEN_BUDGET: usize = 256; // 안전 마진: 512 - 3 - 253 premise room } impl NliVerifier for OnnxNliVerifier { fn score(&self, premise: &str, hypothesis: &str) -> anyhow::Result { // ... 기존 score body 그대로 (현재 onnx.rs:229-280) } /// **Override** the trait default `Ok(0)` with a real mDeBERTa tokenize. /// Pipeline 의 `truncate_hypothesis_for_nli_with_budget` retry loop 가 /// 이 method 를 vtable 통해 호출 — production code path 에서 실 token /// count 측정 (round-3 critic RC1-residual closure: inherent impl 이 /// 아닌 *trait impl block 안* 에 위치해야 vtable 등록). fn hypothesis_token_count(&self, hypothesis: &str) -> anyhow::Result { let (_session, tokenizer) = self.ensure_loaded()?; let enc = tokenizer .encode(hypothesis, /*add_special_tokens=*/false) .map_err(|e| anyhow!("kebab-nli: tokenizer.encode (probe) failed: {e}"))?; Ok(enc.get_ids().len()) } } ``` #### `crates/kebab-rag/src/pipeline.rs` 의 hypothesis-side budget + retry ```rust /// p9-fb-41 S3 follow-up: NLI hypothesis (= synthesized answer) 가 /// 512-token cap 을 단독으로 초과하면 `OnlyFirst` truncation 이 premise 를 /// 0 까지 잘라도 fit 시킬 수 없어 tokenizer 가 err. char-budget 으로 /// 자른 후 *실 mDeBERTa tokenizer* 로 token count 재검증 — 초과 시 char /// budget 절반으로 retry. KR safe (round-1 critic H3 closure). pub const MAX_NLI_HYPOTHESIS_CHARS_INITIAL: usize = 1200; pub const MAX_NLI_HYPOTHESIS_CHARS_MIN: usize = 150; /// Truncate hypothesis with `Right` direction (앞부분 보존 — LLM 답변의 /// 도입부에 핵심 claim 이 있음. 후반 손실은 결론 재요약 영향 적음). /// Empirically validates token-count via `verifier.hypothesis_token_count` /// 와 절반화 retry. 최종 cap = `HYPOTHESIS_TOKEN_BUDGET`. fallback 도달 /// 시 anyhow::Err — caller (step 8.5 hook) 가 기존 unavailable path. pub fn truncate_hypothesis_for_nli_with_budget( verifier: &(dyn kebab_nli::NliVerifier + 'static), hypothesis: &str, ) -> anyhow::Result<(String, bool)> { let original_chars = hypothesis.chars().count(); let mut budget = MAX_NLI_HYPOTHESIS_CHARS_INITIAL; let mut was_truncated = false; loop { let candidate: String = if original_chars <= budget { hypothesis.to_string() } else { was_truncated = true; hypothesis.chars().take(budget).collect() }; // verifier 의 internal tokenizer 로 token count 재검증. // downcast 는 trait method 이라 직접 호출 가능. let token_count = verifier .hypothesis_token_count(&candidate) .with_context(|| "kebab-rag: hypothesis token-count probe failed")?; if token_count <= kebab_nli::OnnxNliVerifier::HYPOTHESIS_TOKEN_BUDGET { return Ok((candidate, was_truncated)); } // 초과 — char budget 절반화 retry. budget = budget / 2; if budget < MAX_NLI_HYPOTHESIS_CHARS_MIN { anyhow::bail!( "kebab-rag: hypothesis remains over token budget after retry (original {original_chars} chars, last budget {} chars, tokens {token_count} > {})", budget * 2, kebab_nli::OnnxNliVerifier::HYPOTHESIS_TOKEN_BUDGET, ); } } } ``` #### Callsite (step 8.5 hook) — round-1 plan critic CRITICAL #1 closure `?` propagation 사용 시 `ask_multi_hop` 이 `Err(anyhow::Error)` 반환 → wire `error.v1` 로 빠짐 (graceful fallback 약속 위반). 기존 `v.score()` Err 분기 (`return self.refuse_nli_model_unavailable(...)`) 와 *대칭* 으로 explicit match + return refuse 사용: ```rust let (truncated_premise, premise_was_truncated) = truncate_for_nli(&packed_text); if premise_was_truncated { tracing::debug!(target: "kebab-rag", "NLI premise truncated to MAX_NLI_PREMISE_CHARS"); } let (truncated_hypothesis, hypothesis_was_truncated) = match truncate_hypothesis_for_nli_with_budget(v.as_ref(), &acc) { Ok(x) => x, Err(e) => { tracing::warn!( target: "kebab-rag", error = %e, "NLI hypothesis budget retry exhausted; refusing with NliModelUnavailable" ); return self.refuse_nli_model_unavailable(query, &opts, hops, started); } }; if hypothesis_was_truncated { tracing::debug!( target: "kebab-rag", original_chars = acc.chars().count(), "NLI hypothesis truncated to MAX_NLI_HYPOTHESIS_CHARS" ); } // ... 기존 v.score() 호출 path — Err 분기 (line 1057-1064) 와 대칭 패턴 match v.score(&truncated_premise, &truncated_hypothesis) { Ok(scores) => { /* 기존 path */ } Err(e) => { /* 기존 refuse_nli_model_unavailable */ } } ``` **핵심**: `?` 대신 explicit `match` + `return self.refuse_nli_model_unavailable(...)` — wire `answer.v1 + refusal_reason=nli_model_unavailable` 유지 (graceful fallback 약속 보존, regression 0). **Pros**: - KR + EN *대부분 케이스* 안전 (token-count retry path + char budget 절반화 retry). 최악 case (KR-extreme density e.g. 압축 한자 텍스트) 시 graceful fallback 으로 기존 unavailable 유지 — regression 0 (round-2 critic RM3 closure). - premise-side `truncate_for_nli` 와 *대칭* (둘 다 pipeline-layer helper). - `kebab-nli::NliVerifier` trait 에 1 method 추가 — wire 영향 0, API 확장 acceptable (v0.18 의 NLI surface 가 아직 unstable internal). **Cons**: - `NliVerifier` trait 에 `hypothesis_token_count` method 추가 — implementations (현재 1 개: `OnnxNliVerifier`) 갱신. mock implementations (`MockNliVerifier`) 도 갱신 필요. - Retry loop 마다 tokenizer 호출 — KR worst case 4-5 회 (1200→600→300→150). 각 호출 ~1 ms (tokenizer-only, no inference). 부담 적음. ### Option B — Tokenizer 의 `OnlyFirst` → `LongestFirst` 로 변경 `crates/kebab-nli/src/onnx.rs:219` 의 `TruncationStrategy::OnlyFirst` → `LongestFirst`. **Pros**: char-budget / retry 도입 불필요, 두 sequence 모두 자연스럽게 truncate. **Cons**: 짧은 premise + 긴 hypothesis 케이스에서 premise 는 살아남고 hypothesis 가 잘림 — premise 가 충분히 사실 정보를 담고 있어야 entailment 가 의미 있음 (보통 그렇지만 보장은 아님). 또한 task spec `2026-05-25-p9-fb-41-finalize-spec.md::§2.2.3` 에 `OnlyFirst` 가 명시되어 있어 task spec amend + HOTFIXES.md entry 필요 (round-1 critic H2 closure — frozen design contract `2026-04-27-kebab-final-form-design.md` 에는 §2.2.3 자체 부재; OnlyFirst 명시는 task spec 수준). ### Option C — NLI crate 가 자기 cap 을 관리 (hypothesis-aware truncate in `score()`) `crates/kebab-nli/src/onnx.rs::score` 안에서 hypothesis tokenize → token-count 체크 → 초과면 char-budget 으로 truncate 후 retry. **Pros**: caller 가 cap 을 모르고도 안전. encapsulation 잘 됨. **Cons**: pipeline-side 의 기존 `truncate_for_nli` 와 layering 불일치 (premise 는 pipeline 이 자르는데 hypothesis 는 nli crate 가 자르는 비대칭). ### 권장: **Option A** (KR best-effort + graceful fallback + 대칭 + frozen design contract 무관) 추후 개선 (별 task): token-count 기반 *premise* budget — 현재 `MAX_NLI_PREMISE_CHARS = 1600` 도 KR-heavy chunks 에서 동일 risk. fix_file 의 기존 주석 *"v0.18.1 candidate: token-count-based budget"* — 별 task 후보 (§6 #1 참조). ### 부수 fix (별 task 권장) **tracing surface — env var + stderr layer 안내** 진단 시간 단축을 위해 다음 중 하나 (별 PR / 별 task): - (B-1) `README.md` / `docs/SMOKE.md` 에 *"진단 시 `RUST_LOG=debug` + `tail -f ~/.local/state/kebab/logs/kb.log.$(date -I)`"* 한 줄 추가. - (B-2) `crates/kebab-app/src/logging.rs` 에 `KEBAB_LOG_STDERR=1` env var 가 set 되어 있으면 stderr fmt::layer 도 추가. opt-in 이라 wire / 일반 사용자 영향 0. **본 S3 fix PR 의 scope 밖** — analyst 권장 따라 별 task 분리 (PR 의 review lens 분리). --- ## §4. Wire / behavior 영향 - **Wire schema**: 변경 없음. `answer.v1` / `error.v1` 모두 영향 없음. - **`schema_version` bump**: 불필요. - **`Cargo.toml` version bump**: 불필요 (test/diagnostic fix, breaking schema 아님). - **Behavior 변화** (round-2 critic RM3 정합): 긴-답변 multi-hop 케이스 *대다수* 가 `nli_model_unavailable` 대신 *실제 NLI score* 를 받음. score 가 낮으면 `nli_verification_failed` (정상 정확한 refusal), 높으면 `nli_passed=true` (이전엔 도달 못함). KR-extreme density 최악 case 만 기존 `nli_model_unavailable` 유지 (graceful fallback, regression 0). 즉 *false-negative 대다수 줄어듦 + 최악 case 의 wire 결과 보존*. - **Default behavior**: 사용자 default config 는 `nli_threshold = 0` (NLI off) — 일반 사용자에는 무영향. NLI 활성 사용자에게는 *옳은 방향의 변경* (이전엔 false unavailable, 이후엔 truthful score). --- ## §5. 검증 plan ### 5.1. Unit test — `crates/kebab-nli/tests/inference.rs` (round-1 critic M1 보강) 3 신규 test (network 요구 → `#[ignore]` 패턴 기존과 동일): ```rust /// Test 6: EN-long hypothesis alone exceeds max_length. Without pipeline-side /// truncation, OnlyFirst strategy dead-ends. Pin raw nli crate behavior so /// any future regression in the pipeline-side budget surfaces as a clear /// nli-level err. #[test] #[ignore] fn score_long_en_hypothesis_returns_err_without_pipeline_truncation() { let cfg = Config::defaults(); let v = OnnxNliVerifier::new(&cfg).expect("verifier construction"); let premise = "short premise"; let hypothesis = "lorem ipsum ".repeat(500); // ~6 000 chars / >>512 tokens let result = v.score(premise, &hypothesis); assert!(result.is_err(), "long hypothesis should err under OnlyFirst"); let msg = result.err().unwrap().to_string(); assert!( msg.contains("Truncation error") || msg.contains("too short to respect"), "expected tokenizer truncation err, got: {msg}" ); } // (round-2 critic RM4 closure: 이전 draft 의 "Test 7 KR-heavy hypothesis" 가 // conditional assertion (`if result.is_err()`) 로 regression pin 가 아닌 // measurement test 패턴이었음 — drop. Test 8 (hypothesis_token_count 의 // bounded range assertion) 이 KR/EN behavior 의 deterministic pin 으로 // 더 안전. KR safety 의 wire-level pin 은 §5.3 의 // `long_kr_synth_answer_retries_with_smaller_budget` 의 retry 시뮬레이션 // 이 담당.) /// Test 7 (renumbered): hypothesis_token_count helper — pure tokenizer probe. /// **vtable dispatch 검증** (round-3 critic RC1-residual + round-1 plan verifier /// Gap 1 closure — concrete type 호출은 inherent method 우선이라 RC1-residual /// 버그 잡지 못함; `&dyn NliVerifier` 통해 dispatch 해야 vtable 등록 검증). /// inherent-only 배치 시 default `Ok(0)` 반환 → `assert!(count > 0)` 실패. /// trait impl block 배치 시 real tokenizer → PASS. /// Pipeline 이 retry budget 결정에 사용하는 API 의 정확성 pin. #[test] #[ignore] fn hypothesis_token_count_dispatches_correctly_via_dyn_trait() { let cfg = Config::defaults(); let v = OnnxNliVerifier::new(&cfg).expect("verifier construction"); // ★ vtable dispatch — &dyn NliVerifier 통해 호출. inherent-only 배치 시 default // `Ok(0)` 반환 → assert!(count > 0) 실패. trait impl block 배치 시 real // tokenizer → PASS. round-3 critic RC1-residual + round-1 plan verifier // Gap 1 closure 의 코드-수준 regression pin. let v_dyn: &dyn NliVerifier = &v; // 짧은 EN — 4 chars/token 추정 (24 chars / 4 = ~6 tokens) let en_count = v_dyn.hypothesis_token_count("short english test sentence") .expect("EN dyn dispatch must reach real tokenizer (vtable check)"); assert!( en_count > 0 && en_count < 20, "EN ~6 tokens expected via vtable dispatch, got {en_count} \ (Ok(0) signals inherent-only placement bug — RC1-residual)" ); // 짧은 KR — 1-2 chars/token (15 chars / 1.5 = ~10 tokens) let kr_count = v_dyn.hypothesis_token_count("짧은 한국어 테스트 문장입니다") .expect("KR dyn dispatch must reach real tokenizer"); assert!(kr_count > 0 && kr_count < 30, "KR ~10 tokens expected, got {kr_count}"); } ``` ### 5.2. Pure-fn test — chars-only sub-helper (round-2 critic RM2 closure) `truncate_hypothesis_for_nli_with_budget(verifier, hypothesis)` 는 *verifier 의존* 이라 pure-fn 아님. round-2 critic RM2 권장 (a) 채택 — chars-only sub-helper 분리: ```rust // crates/kebab-rag/src/pipeline.rs /// Chars-only truncation arithmetic. Pure: input → output, no side effect. /// Used by `truncate_hypothesis_for_nli_with_budget` 의 retry loop 의 각 step. /// Pure-fn test (§5.2) 가 이 helper 의 산술 회귀 핀. pub(crate) fn truncate_chars(s: &str, budget: usize) -> (String, bool) { if s.chars().count() <= budget { (s.to_string(), false) } else { let truncated: String = s.chars().take(budget).collect(); (truncated, true) } } ``` Test (`crates/kebab-rag/tests/multi_hop.rs` 또는 pipeline.rs `#[cfg(test)]` mod) — 4 boundary cases: - 입력 <= budget: identity, `was_truncated=false`. - 입력 > budget: budget chars, `was_truncated=true`. - 입력 = empty: identity. - 입력 = 한글 chars (codepoint, NOT byte): `chars().count()` 정확. `truncate_hypothesis_for_nli_with_budget` 의 retry-loop integration 은 §5.3 mock test 가 검증 (verifier 의 token_count_fn 시뮬레이션). 두 layer 의 *분리된 검증* — pure-fn 산술 + integration retry path. ### 5.3. Mock multi-hop test — long-answer happy path (verifier Blocker 1 closure) `crates/kebab-rag/tests/multi_hop_nli_stream.rs` (또는 신규 `multi_hop_nli_truncate.rs`). **Helper 신규 작성 필요** (verifier Blocker 1): 기존 `crates/kebab-rag/tests/common/mod.rs::MockNliVerifier` 는 *고정 mode* (`MockMode::Scores` / `MockMode::Err`) 만 지원 — closure spy 패턴 불가. 신규 `SpyNliVerifier` (또는 `FakeNliVerifier`) helper 추가: ```rust // crates/kebab-rag/tests/common/mod.rs 에 추가 use std::sync::{Arc, Mutex}; use kebab_nli::{NliScores, NliVerifier}; /// Closure-based NLI verifier — caller 가 `(premise, hypothesis) -> Result` /// + `(hypothesis) -> Result` 두 closures 정의 가능 + spy 로 입력 capture. /// 기존 `MockNliVerifier` (고정 mode) 와 sibling. round-1 verifier Blocker 1 /// + round-2 verifier Caveat 1 closure (struct 필드 위치 + 2-arg constructor). pub struct SpyNliVerifier { pub score_fn: Arc anyhow::Result + Send + Sync>, pub hypothesis_token_count_fn: Arc anyhow::Result + Send + Sync>, pub received_premises: Mutex>, pub received_hypotheses: Mutex>, } impl SpyNliVerifier { /// 2-arg constructor — score + hypothesis_token_count 둘 다 closure 로 /// 주입. Caveat 1 의 "Arc field mutation 불가" 회피. pub fn new(score_fn: F, token_count_fn: G) -> Arc where F: Fn(&str, &str) -> anyhow::Result + Send + Sync + 'static, G: Fn(&str) -> anyhow::Result + Send + Sync + 'static, { Arc::new(Self { score_fn: Arc::new(score_fn), hypothesis_token_count_fn: Arc::new(token_count_fn), received_premises: Mutex::new(Vec::new()), received_hypotheses: Mutex::new(Vec::new()), }) } } impl NliVerifier for SpyNliVerifier { fn score(&self, premise: &str, hypothesis: &str) -> anyhow::Result { self.received_premises.lock().unwrap().push(premise.to_string()); self.received_hypotheses.lock().unwrap().push(hypothesis.to_string()); (self.score_fn)(premise, hypothesis) } fn hypothesis_token_count(&self, hypothesis: &str) -> anyhow::Result { (self.hypothesis_token_count_fn)(hypothesis) } } ``` (NliVerifier trait 확장 + OnnxNliVerifier 의 trait impl override 는 §3 에서 이미 명시 — 중복 제거 (round-3 critic RC1-residual closure 의 일부).) **Pipeline construction pattern** (round-2 plan critic MAJOR #3 closure: Option B inline 채택, helper 신규 작성 안 함): 각 test 안에서 직접 inline. 아래 3 test 의 `build_test_pipeline_with_long_answer(verifier, char_len)` 호출은 *placeholder semantic only* — 실 구현은 `plan §2 step 8` 의 Option B 5-component recipe (`RagEnv::new()` + `ScriptedRetriever::new(...)` + `ScriptedLm::new(vec!["[\"q1\"]", "[]", &"lorem ".repeat(char_len/12)])` + `RagPipeline::new(cfg, retriever, lm, sqlite).with_verifier(verifier)`) 따를 것. 기존 `crates/kebab-rag/tests/multi_hop.rs` 의 happy-path test pattern 그대로. **3 신규 test**: ```rust /// EN long answer → char-budget 만으로 충분 → retry 0회 → grounded. #[test] fn long_en_synth_answer_truncated_before_nli_call() { let verifier = SpyNliVerifier::new( |_premise, _hypothesis| { Ok(NliScores { entailment: 0.9, neutral: 0.05, contradiction: 0.05 }) }, |_h| Ok(100), // budget 안 — retry 0 ); let pipeline = build_test_pipeline_with_long_answer(verifier.clone(), 5_000); // EN-long let answer = pipeline.ask_multi_hop("q", AskOpts::default()).unwrap(); let received = verifier.received_hypotheses.lock().unwrap(); assert_eq!(received.len(), 1, "verifier called exactly once"); let hyp = &received[0]; assert_eq!( hyp.chars().count(), 1200, "hypothesis truncated to MAX_NLI_HYPOTHESIS_CHARS_INITIAL" ); // round-1 critic M2: direction Right pin — hypothesis 의 *첫 1200 chars* 가 // input 의 *첫 1200 chars* 와 일치 (= Right direction = 앞부분 보존). Left/Middle // direction 으로 regress 시 본 test 가 즉시 fail. let input_first_1200: String = "lorem ipsum ".repeat(2000).chars().take(1200).collect(); assert_eq!(hyp.as_str(), input_first_1200, "Right direction = front preserved"); assert_eq!(answer.refusal_reason, None, "long answer must reach happy path"); } /// KR long answer → token count > budget → char budget 절반화 retry → eventual fit. /// round-1 critic H3 + verifier Blocker 2 의 KR safety pin. #[test] fn long_kr_synth_answer_retries_with_smaller_budget() { let token_count_call_count = Arc::new(Mutex::new(0)); let tcc = token_count_call_count.clone(); // 시뮬레이션: 1200 chars → 900 tokens (cap 초과), 600 chars → 450 tokens (cap 초과), // 300 chars → 220 tokens (cap 안). retry 3 회. let verifier = SpyNliVerifier::new( |_premise, _hypothesis| { Ok(NliScores { entailment: 0.85, neutral: 0.10, contradiction: 0.05 }) }, move |h| { *tcc.lock().unwrap() += 1; let count = h.chars().count(); if count > 1000 { Ok(900) } else if count > 500 { Ok(450) } else { Ok(220) } }, ); let pipeline = build_test_pipeline_with_long_answer(verifier.clone(), 2_500); // 2500 chars KR-sim let answer = pipeline.ask_multi_hop("q", AskOpts::default()).unwrap(); assert!( *token_count_call_count.lock().unwrap() >= 3, "retry loop must call token_count >= 3 (1200, 600, 300 candidates)" ); let received = verifier.received_hypotheses.lock().unwrap(); assert!(received[0].chars().count() <= 300, "final hypothesis <= 300 chars after retry"); assert_eq!(answer.refusal_reason, None, "KR long answer reaches happy path after retry"); } /// Retry budget 소진 시 graceful unavailable — fix 의 fallback path 가 /// 기존 unavailable wire shape 유지 (regression 0). #[test] fn unrelenting_token_overflow_falls_through_to_unavailable() { let verifier = SpyNliVerifier::new( |_premise, _hypothesis| { unreachable!("score not reached when token-count check fails"); }, |_h| Ok(9_999), // 모든 budget 에서 token count 초과 — retry 소진 ); let pipeline = build_test_pipeline_with_long_answer(verifier.clone(), 3_000); let answer = pipeline.ask_multi_hop("q", AskOpts::default()).unwrap(); assert_eq!( answer.refusal_reason, Some(RefusalReason::NliModelUnavailable), "graceful fallback to unavailable when retry exhausted" ); } ``` ### 5.4. Dogfood S3 + KR 케이스 retest (round-1 critic H4 + verifier non-blocker closure) Fix 적용 후 EN (S3) + KR (long-answer 시뮬레이션) 두 케이스 retest: ```bash # round-1 plan verifier Gap 2 closure — config 의 nli_threshold > 0 사전 확인. # nli_threshold = 0 (default) 이면 NLI off 상태 → retest 가 vacuous (fix 의 효과 미발현). grep -E "^\s*nli_threshold\s*=" /build/cache/dogfood-v018/config/config.toml \ || echo "WARNING: nli_threshold 미설정 — dogfood retest 전에 config 에 [rag] nli_threshold = 0.3 (또는 원하는 값) 추가 필수" # nli_threshold > 0 확인 후 진행. CARGO_TARGET_DIR=/build/out/cargo-target/target \ cargo build --release -p kebab-cli -j 1 # Non-blocker fix: stdout / stderr 분리 (2>&1 제거 — jq parsing 충돌 회피). # stderr 는 file appender (kb.log) 로만 가므로 stderr redirect 불요. # EN — S3 본래 케이스 RUST_LOG=info,kebab_rag=debug,kebab_nli=debug \ /build/out/cargo-target/target/release/kebab ask \ "Why does kebab combine multilingual-e5, LanceDB, and RRF together?" \ --multi-hop --config /build/cache/dogfood-v018/config/config.toml \ --json > /build/cache/dogfood-v018/results/post-s3-fix/s3-en-retest.json # KR — long-answer 시뮬레이션 (KR self-knowledge query) # KR-heavy hypothesis 가 본 fix 의 token-count fallback retry path 를 trigger 검증 RUST_LOG=info,kebab_rag=debug,kebab_nli=debug \ /build/out/cargo-target/target/release/kebab ask \ "kebab 의 multi-hop RAG + NLI verification 의 동작 원리는 무엇인가?" \ --multi-hop --config /build/cache/dogfood-v018/config/config.toml \ --json > /build/cache/dogfood-v018/results/post-s3-fix/s3-kr-retest.json # 결과 검증 jq -r '.refusal_reason, .verification.nli_score, .usage.completion_tokens' \ /build/cache/dogfood-v018/results/post-s3-fix/s3-en-retest.json jq -r '.refusal_reason, .verification.nli_score, .usage.completion_tokens' \ /build/cache/dogfood-v018/results/post-s3-fix/s3-kr-retest.json # Tracing log 의 truncate path 활성 확인 (file appender 분리 grep) grep "NLI hypothesis truncated\|hypothesis_token_count" \ ~/.local/state/kebab/logs/kb.log.$(date -I) ``` **성공 기준**: - **EN (S3)**: `refusal_reason` 이 `null` (NLI passed) 또는 `nli_verification_failed` (정상 거부). **`nli_model_unavailable` 아님**. - **KR (long-answer)**: 동일 — `nli_model_unavailable` 아님. token-count retry path 가 작동했음을 log 의 *retry budget* line 으로 확인. - `verification.nli_score` 가 finite float (이전엔 `null`). - `~/.local/state/kebab/logs/kb.log.$(date -I)` 에 `truncate_hypothesis_for_nli_with_budget` 의 retry trace 또는 success debug line emit. ### 5.5. 회귀 — 기존 NLI test 전부 ```bash CARGO_TARGET_DIR=/build/out/cargo-target/target \ cargo test -p kebab-nli -j 1 CARGO_TARGET_DIR=/build/out/cargo-target/target \ cargo test -p kebab-rag -j 1 CARGO_TARGET_DIR=/build/out/cargo-target/target \ cargo test --workspace --no-fail-fast -j 1 CARGO_TARGET_DIR=/build/out/cargo-target/target \ cargo clippy --workspace --all-targets -j 1 -- -D warnings ``` 기존 NLI test 전부 PASS 유지 (e.g. `score_empty_hypothesis_returns_err`, `multi_hop_nli_model_unavailable_refuses`, `nli_model_unavailable_emits_final_stream_event_with_refusal`). --- ## §6. 비범위 (별 task 후보) 1. **Token-count 기반 NLI budget** — `MAX_NLI_PREMISE_CHARS` / `MAX_NLI_HYPOTHESIS_CHARS` 둘 다 *char* 기반. KR SentencePiece tokenization 측정 후 token-count 기반 dynamic budget 으로 전환. `MAX_NLI_PREMISE_CHARS` 의 기존 주석에 이미 *"v0.18.1 candidate"* 명시. 2. **`KEBAB_LOG_STDERR=1` opt-in stderr layer** — diagnostic 시 stderr 로 log 흘려보기. logging.rs 의 fmt::layer 한 줄 추가. 3. **`RefusalReason::NliInputTooLong` 신규 variant** — 현재는 OnlyFirst-err 가 unavailable 로 단일화. 길이 초과만 별 wire variant 로 분리하면 사용자/agent 가 retry 전략 결정 가능 (e.g. answer length cap 후 재요청). **wire schema breaking change** — `answer.v1` enum 확장 = additive minor, OK. 그러나 별 cycle 권장. 4. **NLI multi-model adapter** — sentence-pair NLI 외 token-level entailment scorer / chunk-level entailment scorer 같은 알터너티브. 5. **NLI threshold tuning** — S1 (0.058) / S7 (0.0035) / S10 (0.0028) 모두 *매우 낮은* entailment. default `nli_threshold` 결정 (현재 0 = off). 본 S3 fix 후 truthful score 분포 측정 필요. 6. **gemma3:4b 의 4500-char 답변 자체 억제** — synthesize prompt 의 max-output 가이드 강화. NLI 와 무관한 별 문제. 7. **README / SMOKE 의 tracing 진단 안내** — Option B-1 (한 줄 추가). 별 PR / 별 task. --- ## §7. 합의된 출구 조건 이 spec 이 closed 되려면: 1. Fix PR 머지 — round-2 critic RM1 closure: 정확한 신규 심볼 list (frontmatter `fix_symbols` verbatim): - `kebab-nli/src/lib.rs::NliVerifier::hypothesis_token_count` (trait method, default impl `Ok(0)` for backward-compat). - `kebab-nli/src/onnx.rs::OnnxNliVerifier::hypothesis_token_count` (override + `HYPOTHESIS_TOKEN_BUDGET = 256` const). - `kebab-rag/src/pipeline.rs::MAX_NLI_HYPOTHESIS_CHARS_INITIAL = 1200` + `MAX_NLI_HYPOTHESIS_CHARS_MIN = 150` consts. - `kebab-rag/src/pipeline.rs::truncate_hypothesis_for_nli_with_budget(verifier, hypothesis)` helper + step 8.5 hook 의 callsite 수정. - `kebab-rag/tests/common/mod.rs::SpyNliVerifier` helper (closure spy + token_count_fn). 2. Unit test 3개 (5.1 ignored / 5.2 pure-fn / 5.3 mock multi-hop) 추가 + 모두 GREEN. 3. Dogfood S3 retest GREEN — `nli_model_unavailable` → `nli_verification_failed` 또는 happy path 로 전환 확인. 4. `cargo test --workspace --no-fail-fast -j 1` GREEN — 기존 NLI test 전부 PASS, 신규 회귀 0. 5. `cargo clippy --workspace --all-targets -j 1 -- -D warnings` clean. 6. `tasks/HOTFIXES.md` 에 신규 dated entry **`## 2026-05-26 — S3 NLI unavailable — hypothesis truncate + token-count fallback`** 추가 (date-top convention). round-1 critic M6 closure: **HOTFIX 번호 부여 안 함** (HOTFIX #15 처럼 fixture-issue 가 아닌 *production behavior fix* — sibling fb-41 PR-9 closure entry 와 같은 layer 의 follow-up). line 17 (현재 HOTFIX #15) 직전, 그 직전이 2026-05-25 fb-41 entry. 형식: Symptom / Root cause / Action / Amends 4-block — HOTFIX #15 entry 와 동일 sibling pattern. --- ## §8. Risk - **Risk level: 낮음.** fix 가 NLI 입력 정규화 layer (pipeline-side helper + nli crate 의 token-count probe) 만 건드림. Wire 변경 없음, behavior 는 false-negative (정상 답변이 unavailable 로 거부) 줄어듦 + graceful fallback (worst case 시 기존 unavailable 유지 = regression 0). - **Char-budget 단독 부족 (round-1 critic H3 + verifier Blocker 2 closure)**: Option A 의 token-count fallback retry 가 KR safe 보장. budget 1200 → 600 → 300 → 150 chars 까지 retry → 최악 fallback 시 `nli_model_unavailable` (현재 동작 유지). - **Hypothesis truncate direction `Right`** (앞부분 보존, 뒤 손실): LLM 답변의 *도입부* 가 핵심 claim. *결론부* 는 보통 도입부 재요약 — Right direction 이 안전한 default. round-1 critic M2 의 test pin (`long_en_synth_answer_truncated_before_nli_call` 의 `assert_eq!(hyp.as_str(), input_first_1200)`) 으로 회귀 detection. ### Pre-mortem (round-1 critic M3 closure) | 시나리오 | 영향 | Mitigation | |---|---|---| | **(a) KR-extreme hypothesis (e.g. 한자/CJK character density)** — char-truncate + retry 모두 token count 초과 | budget 소진 → graceful `nli_model_unavailable` fallback | spec §3 의 `MAX_NLI_HYPOTHESIS_CHARS_MIN = 150` floor + §6 #1 의 token-count budget 별 task. 현재는 graceful refuse (regression 0). | | **(b) Conclusion-bearing hypothesis** — LLM 의 핵심 claim 이 *후반부* (예: "Therefore, X" 단락 답변 끝) | Right truncation 으로 conclusion 손실 → entailment score 낮아짐 → false `nli_verification_failed` 가능 | NLI entailment 는 *front-loaded fact 위주* — 보통 도입부 claim 만으로 충분. Worst case 도 *false positive (잘못된 entailment passed)* 아닌 *false negative (정상이지만 reject)* — fail-closed semantic 보존. 사용자가 `nli_threshold = 0` 으로 임시 disable + retry 가능. | | **(c) Grapheme cluster split** (emoji ZWJ, KR 조합형 NFD 분해 등) — `chars().take(N)` 가 grapheme 중간 split | tokenizer 가 UNK 폭주 → score 왜곡 | mDeBERTa SentencePiece 가 codepoint-level subword — grapheme split 영향 미미 (worst case UNK 1-2 개, NLI signal 의미 보존). | | **(d) `hypothesis_token_count` probe 자체 fail** (e.g. tokenizer crate panic on edge input) | `with_context` 가 anyhow err 로 wrap → graceful fallback | empty hypothesis 는 `acc.trim().is_empty()` guard 가 step 8.5 진입 전 차단. 비-empty 의 edge input 은 mDeBERTa tokenizer 가 robust 처리 (기존 PR-9b unit test 의 long-premise / empty-hypothesis 검증).