Closed theoremonemehdi closed 2 months ago
@jemc noticed this: { index: 0, delta: {}, logprobs: null, finish_reason: 'length' }
Basically, the LLM response exceeded the remaining available tokens that's why JSON.parse is failing.
This is the successful finish_reason { index: 0, delta: {}, logprobs: null, finish_reason: 'stop' }
@theoremonemehdi - thinking through the different use cases here... How does this sound for developer experience?
Any response with finish_reason: "length"
throws a KurtResultLimitError
, containing the text-so-far in a property called text
Any response which fails to parse JSON throws a KurtResultParseError
, containing the text that failed to parse in a property called text
Any response which fails Zod constraints throws a KurtResultValidateError
, containing the text in a property called text
, and the not-valid data object in a property called data
(or additionalData
in the case of additional parallel tool calls). Note that all these property names match the corresponding property names in the KurtResult
interface type, for consistency.
All of the above error classes would be subclasses of a common KurtResultError
type, so that they could be handled together by applications that don't care to differentiate these cases.
KurtResultError
itself would be a subclass of KurtError
, which would be the superclass of any errors thrown by Kurt, including other categories like KurtFeatureIncompatibleError
(see discussion in ticket #47).
This has been resolved in tickets #48 and #49.
In some cases, Kurt fails during a structured data flow for the following reasons:
In order to build a follow-up prompt for the LLM, we need to capture the returned text value that failed. Maybe expose the text value inside a
KurtStructuredDataError