gh#137: explain an empty turn without misattributing its cause. More...
#include <string>
Go to the source code of this file.
Namespaces | |
| namespace | entropic |
| Activate model on GPU (WARM → ACTIVE). | |
Enumerations | |
| enum class | entropic::EmptyContentCause { entropic::not_empty , entropic::budget_truncated , entropic::model_stopped , entropic::unknown } |
| Why a turn produced tokens but delivered no content. More... | |
Functions | |
| EmptyContentCause | entropic::diagnose_empty_content (bool content_empty, bool produced_tokens, const std::string &finish_reason) |
| Classify an empty-content turn from what the decode reported. | |
| std::string | entropic::explain_empty_content (EmptyContentCause cause) |
| Operator-facing explanation for an empty-content turn. | |
Detailed Description
gh#137: explain an empty turn without misattributing its cause.
- Why this exists
- A turn can produce tokens and still deliver zero characters of content: the model opened a reasoning block and never closed it, so the reasoning strip correctly removed everything. That is legitimate — surfacing raw reasoning as if it were the answer would be worse — but the operator needs to know WHICH problem they have, and the two are fixed differently.
The engine previously gave one message for both cases, telling the operator to "Raise max_tokens". That advice is sound only when the generation was truncated. gh#137 reported finish=stop, 154 chars delivering 0 chars — the model ended the turn itself while still inside a reasoning block, and no budget increase can fix that. The engine was pointing at the wrong knob, which is worse than saying nothing.
Kept as a pure function over a finish_reason string, deliberately free of vendor types, so the decision is unit-testable on CPU. The judgment here is the part worth pinning; the logging around it is not.
- Version
- 2.11.0
Definition in file empty_content_diagnosis.h.
