Fix CF-7 Qwen3.5 NoKvSlot prompt overflow - #63
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughContext Fabric now uses runtime-provided exact prompt token counts for evidence admission, budget checks, and metrics. Native completion generation is capped by remaining model context, with fallback estimates for runtimes without loaded-model tokenizers. Tests and capacity documentation were updated accordingly. ChangesExact prompt token accounting
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant ContextFabric
participant Runtime
participant LoadedModel
participant Metrics
ContextFabric->>Runtime: CountPromptTokens(rendered history)
Runtime->>LoadedModel: Tokenize rendered prompt
LoadedModel-->>Runtime: Exact prompt token count
Runtime-->>ContextFabric: Prompt token count
ContextFabric->>ContextFabric: Apply evidence and context budget gates
ContextFabric->>Runtime: Generate within remaining context
Runtime-->>Metrics: Report prompt token usage
Possibly related PRs
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
…NoKvSlot Full 120-question CF-7 gates on Qwen3.5-9B-Q8_0 (41:42) and Q4_K_M (27:51) plus a 1-question Q8_0 smoke replay all completed with zero NoKvSlot / memory-slot / attention-ubatch incidents on PR #63's exact-token admission fix. First valid Qwen3.5 capability scores: Q8_0 B3 75/120 (best B3 on any model to date, Graded capability PASS vs. B2 52), Q4_K_M B3 67/120 (PASS vs. B2 57). §7e marked RESOLVED; compatibility table and bottom-line updated. Also documents the MSIX AppData virtualization gotcha that made the model files appear missing to a non-packaged tool on the same account. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Row 15's cross-reference still said "root-caused; full-gate validation pending" after the same commit marked §7e RESOLVED; now points at row 17's valid replacement result. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@coderabbitai review |
✅ Action performedReview finished.
|
…stive-leaf-coverage fixes) (#65) * CF-7: give open-extraction reads a completeness-repair pass for silently missed facts The last two live CF-7 gate runs on the honest (un-marked) expanded corpus both came back NO-GO on segment_terminal_coverage (5-11 of 128 segments rejected), and root-causing the rejected segments plus two Exhaustive-question failures traced to the same cause: dense segments pack a real planted fact among 15+ near-identical filler lines, and the open-extraction reader silently drops it. Unlike marked-mode reading, open extraction had no recall safety net at all -- worse, a segment returning zero claims short-circuited straight to rejection before the (marked-mode-only) repair logic could even run. ContextFabricFeasibilityRunner.ReadSegmentAsync now runs a parallel completeness check for open-extraction reads: GetCandidateFactSentences flags lines carrying a hyphenated alphanumeric code (BR-540, RPT-013, CASE-12-1, grade-3) -- the generic shape of a citable fact (case numbers, invoice IDs, ratings) that this corpus's planted facts all share and its filler/gap/adversarial lines never do. Any candidate not already covered by the model's claims triggers one repair call (RepairOpenExtractionSegmentAsync) that, unlike the forced marked-mode repair, explicitly lets the model decline a false-positive candidate rather than fabricate a claim -- the detector is a heuristic signal, not ground truth. Live-validated on Qwen3.5-9B-Q8_0: segment_terminal_coverage went from 123/128 to 128/128 on the exact corpus/model combination that was failing. Also fixes a misplaced code comment in ContextFabricBenchmarkGateEvaluator that described question_pass_rate's non-blocking rationale while sitting under segment_terminal_coverage (which stays fully blocking by design). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * CF-7: fix exhaustive-leaf-coverage gate to check the question's own segment set Live-validating the open-extraction recall fix (previous commit) surfaced a second, independent bug: exhaustive-leaf-coverage required the found Exhaustive question's IncludedSegmentIds to equal the ENTIRE corpus segment count. That was correct for DeterministicFabricCorpus's frozen fixture, whose one exhaustive category ("archive tokens") is genuinely defined over every segment -- but DeterministicExpandedFabricCorpus's 15 per-ledger exhaustive categories each scope to their own 3-5 segments by design, so this equality was unsatisfiable there regardless of answer quality. The live gate showed included=4/128 with Verification.Passed=true (a flawless answer to "list every case-file ID under ledger case-ledger-01" correctly cites its 4 segments, never all 128) and sank the gate anyway. Now checks exhaustive.Question.ExpectedSegmentIds against IncludedSegmentIds directly, which is correct for both fixtures. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: CF-7 gate closes GO on the honest expanded corpus (2026-07-17) CURRENT_STATE.yaml previously claimed CF-7 was closed GO from the 2026-07-03 run, which the adversarial pass later found was against an overclaimed (marked/leaked) corpus -- this updates it to the real result: GO against the un-marked cf-expanded-book-v1 corpus with 120 real held-out questions, Qwen3.5-9B-Q8_0 at 128/128 segments and 104/120 questions. Also marks the §7e NoKvSlot handoff doc superseded (PR #63 it describes as open merged the same day it was generated) rather than deleting it -- its root-cause narrative for the NoKvSlot crash stays useful, it just isn't a live status document anymore. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Summary
Root cause
The B3 Reviewer request exhausted its own attention KV context. The fully rendered Qwen3.5 prompt plus requested completion exceeded
n_ctx=8192; the existingchars/4estimate plus safety margin under-counted the JSON-heavy prompt. The matching llama.cpp signature isfailed to prepare attention ubatchesfollowed byfailed to find a memory slot: ggml-org/llama.cpp#20049 (comment)This is distinct from the recurrent
SeqMaxdefect fixed in PR #56.SeqMax=40, recycle threshold 24, hard limit 40, thinking suppression, disposal behavior, and LLamaSharp 0.27.0 are unchanged.Validation
dotnet test OrchestratorIDE.UnitTests\OrchestratorIDE.UnitTests.csproj --no-restore --verbosity minimal— 564 passed, 4 skippeddotnet build OrchestratorIDE.slnx --no-restore --verbosity minimal— succeeded; existing warnings onlyBuild (Windows)— passedLive gate status
Pending. The dedicated
%APPDATA%\OrchestratorIDE\Models-CF7directory and both historical GGUFs are currently absent. The docs deliberately remain at “root-caused; fix implemented; full Q8_0/Q4_K_M validation pending.” Once the exact model files are restored, the planned validation is one Q8_0 replay followed by sequential full 120-question Q8_0 and Q4_K_M gates withTHEORC_KVCACHE_DIAGNOSTICS=1, requiring zeroNoKvSlot/attention-slot failures.Review status
CLEAN. The wrapper exited nonzero only because Grok prefixed eachCLEANwith a sentence.0b97c758…33d6eab2; no actionable comments, zero review threads, status passedSummary by CodeRabbit
Bug Fixes
Documentation