Just ran into one of those sneaky edge cases that can derail an evaluation pipeline, and I'm curious if the community has seen the same. We were stress-testing a retrieval-augmented generation (RAG) system built for a client's internal knowledge base, using a fairly standard eval framework that checks for hallucination, relevance, and answer completeness.
The rubrics and scoring scripts worked beautifully—until the model started responding with a simple "I don't know" or "The provided context does not contain that information" to ambiguous or out-of-scope queries. Suddenly, our "completeness" and "relevance" scores were in the gutter, even though the model was behaving *correctly* and actually following the safety guardrails we'd implemented. It was scoring as a "bad" answer when it was, in fact, the right and responsible one.
This feels like a fundamental misalignment between our evaluation metrics and real-world operational success. In my CRM implementation days, we'd see similar issues when a workflow automation would flag a "null" value as a failure, when sometimes a blank field was the valid business outcome. The eval framework wasn't built to recognize a legitimate "non-answer" as a positive result.
So I'm digging into how to adjust for this. A few thoughts on the table:
* Adding a specific "appropriate abstention" score to the rubric, rewarding the model for correctly identifying unanswerable questions.
* Pre-filtering the evaluation dataset to separate "answerable" from "unanswerable" queries and applying different scoring logic to each bucket.
* Having the scoring logic first check for a refusal pattern, and if found, bypass the usual completeness/relevance checks in favor of a correctness check on the refusal itself.
Has anyone else wrestled with this? What does your scoring rubric or framework tweak look like when the best possible model output is a polite decline to answer? I'm particularly interested in how you weight this against the need for thorough, complete answers when the information *is* available. The last thing I want is a model that learns to say "I don't know" as a safe harbor to game the eval scores.
Implementation is 80% process, 20% tool.
Yeah, this is such a good point. It reminds me of when we set up alerts in CloudWatch. If the alarm is just "error count > 0", it'll go off for a transient, expected failure and you just get alert fatigue. The system is "working" but the metric is wrong.
Have you guys figured out a way to adjust your scoring for that case? Like maybe a separate "safe refusal" flag that gets positive points instead of tanking completeness?
Exactly. Your "safe refusal flag" is the right conceptual fix, but the devil is in how you implement it. You can't just pattern-match for "I don't know" - that's brittle and models phrase things a dozen different ways.
You need to treat "correct refusal" as a distinct evaluation class with its own rubric. We define it as: for a query where the provided context lacks sufficient information, the model must a) explicitly state it cannot answer, and b) not hallucinate. If it does that, it gets a perfect score for that class, and the completeness/relevance metrics are marked N/A. It requires annotating your test set with intent, labeling which queries *should* be unanswerable.
The trap is thinking a refusal is always correct. We've seen models refuse based on a misread context or an overly sensitive safety filter. That's a different failure mode and needs to score poorly.