SGR на практике: частые ошибки и как их избежать В предыдущем посте не описал, как правильно готовить технику SGR, чтобы результат был хорошим. В этом разберем частотные ошибки и подводные камни, на которые можно налететь в процессе ее реализации. Напомню цель: хотим заставить LLM давать более качественные ответы с помощью комбинации двух техник: - Structured Output (SO) — модель генерирует токены согласно заданной нами схеме. - Chain-of-Thought (CoT) — перед тем, как дать финальный ответ, модель проходит заданные нами явно шаги рассуждения. Проблемы здесь могут возникать на каждом из этапов. 1️⃣ Поддержка Structured Output — не предполагается «по умолчанию» Сначала проверьте, поддерживает ли ваш провайдер/движок Structured Output вообще. Не все провайдеры умеют принимать Pydantic-модели напрямую; если провайдер этого не умеет, вы не сможете гарантировать соответствие ответа схеме. Даже при формальном наличии SO, его реализация от провайдера к провайдеру может отличаться. Например, в Gemini API указано, что: - полноценной поддержки Pydantic-классов нет — используется JSON Schema; - в схеме поддерживается ограниченный набор свойств; - после получения схемы сервис может переупорядочивать ключи по алфавиту. В результате, если вам критичен порядок, приходится либо подбирать префиксы/ключи, либо явно задавать порядок через свойство propertyOrdering. С локальными движками тоже бывает неоднозначно. Пример: GPT-OSS-120b, на бенчмарках радует, но до недавнего времени в vLLM Structured Output мог работать нестабильно из-за изменений формата ответа. По состоянию на 13 сентября вышел фикc в мастере и появился docker-образ с исправлениями. Я его ещё не успел потестировать, но сам факт показателен: движок может неожиданно подвести. Обходной путь — компилировать ответ модели в нужную схему и валидировать постфактум; при ошибке — делать повторный запуск с тем же контекстом. 2️⃣ Схема ответа должна быть у модели «в контексте» Даже если вы включили формат ответа на уровне движка, схему для ответа всё равно нужно дать в промпте. У модели не появятся «правильные» токены из воздуха: она должна видеть, какого формата ей ответ нужно дать, заранее, чтобы распределение вероятностей токенов было правильным. Логика тут следующая: вы можете «закручивать гайки» через провайдера, минимизируя явные ошибки, но вот повысить шанс дать правильный ответ вы можете только правильным промптингом, который покажет модели заранее, как ей нужно отвечать. 3️⃣ CoT должен реально помогать думать (а не мешать) Хороший Chain-of-Thought — это не «магическая мантра», а внятная декомпозиция ключевых решений на проверяемые подшаги. Если финальный ответ зависит от одного критически важного решения, сначала заставьте модель пройти лесенку из более простых вопросов, чтобы снизить шанс промаха. Пример. Бот поддержки интернет-магазина должен ответить: «Достаточно ли данных, чтобы оформить доставку?». Вместо прямого вопроса модели сразу про достаточность, задаём последовательность проверок: - поздоровались ли мы с клиентом? (да/нет) - уточнили полное имя? (да/нет) - получили дату доставки? (да/нет) - …и т.д. Только после прохождения чеклиста модель формирует финальное действие: «создаём заявку» или «уточняем N недостающих полей». Это резко снижает количество глупых ошибок и делает поведение предсказуемым. Да, это может быть неприятно, нужно погружаться в предметную область заказчика, глубоко анализировать бизнес-процесс, возможно даже реальные разговоры менеджера с клиентом. Но в качестве подарка за такое неприятное погружение вы получите очень стабильное решение, которое будет делать гораздо меньше ошибок, так еще и потенциально на инференсе сэкономите за счет более дешевых моделей. Ну красота же? @korneychukov