Здравствуйте, bnk, Вы писали:

bnk>Понял. Я переключился в моем случае на structured outputs (но это не про редактор, немного другой случай, намного проще)
bnk>Проблема с текстом была в том что несмотря на инструкции, модель им (иногда) не следовала. structured output фиксирует схему генерируемого моделью json, и гораздо практичнее для использования кодом, ничего не нужно парсить.

Ха! Если бы все было так просто. Проблема в том, что у LLM нет интуиции. Если повесить на нее структурные ограничения с API или схемой, то, по сути, за каждый токен будут драться две подсети: одна, пытающаяся вписаться в формат, и другая, пытающася выдать смысловой результат.
В итоге, на выходе часто получается структурно корректное сообщение, абсолютно бесполезное для пользователя. Как в анекдоте про программиста и воздушный шар.

Свежий пример: код, который собирается, но вместо текущего значения даты, пишет для всех строк самое первое, потому что импульс "вынести переменную за цикл" переборол импульс "не менять поведение кода".

Это решается переключением на более мощные модели, но рефакторинг по цене чашки кофе, которого ждать надо, как эту самую чашку — дело довольно бесполезное.

А если дать модели больше свободы, и структуру парсить отдельно, таких косяков получается заметное меньше. Теоретически, можно взять разные модели для генерации идеи, и воплощения в конкретные правки, но мой подход с парсингом работает практически мгновенно, в отличие от дополнительной модели.