Глава 2 — Foundation-модели и prompt engineering

Второй пост поглавного разбора LLM Primer V: Building Real-World LLM Applications. Глава, относящаяся к prompt engineering как к инженерии — версионированные шаблоны, защитные разделители, структурированные выходы, — а не как к искусству, оцениваемому по ощущениям.

Почему существует эта глава

Глава 1 утверждала, что модель — один компонент внутри детерминированной обёртки. Глава 2 внимательно смотрит именно на этот компонент. Каталог моделей в 2026 году — это таксономия с резкими различиями, а не список эквивалентов. Параметры сэмплинга превращают одни и те же веса в детерминированный классификатор или в творческого писателя. Промпты — это структурированные артефакты, чья анатомия отличает поведение, переживающее вредоносный ввод, от поведения, не переживающего. Существуют механизмы, форсирующие выход в форму, которую обёртка может валидировать, и выбор неправильного механизма под задачу обходится в валидационные ретраи дороже, чем сам механизм экономит. Команда, относящаяся к «модели» как к единому безличному ресурсу, использующая дефолты повсюду, пишущая промпты как одноразовые строки и валидирующая выход на надежду, — эта команда оставила бо́льшую часть доступного инженерного контроля на полу.

Если коротко: prompt engineering — это инженерия: выбор модели, параметры сэмплинга, анатомия промпта и структурированные выходы — четыре поверхности контроля, которыми команда либо управляет осознанно, либо принимает последствия.

2.1 Выбор модели как инженерное решение первого класса

Каталог делится на четыре семейства: малые языковые модели, настроенные на скорость и стоимость на ограниченных задачах; средне-tier general-модели, тянущие большинство продакшен-задач; фронтирные модели для самых трудных рассуждений и самых длинных контекстов; и reasoning-модели, тратящие дополнительный inference-компьют на скрытый шаг обдумывания. Мультимодальность пересекает все четыре. Выбор — это решение маршрутизации на запрос, а не глобальный дефолт: короткие запросы — в SLM, нетривиальные, но хорошо ограниченные задачи — в средний tier, самое трудное рассуждение — во фронтир, reasoning-модели — там, где задержка приемлема, а прирост точности реален. Роутер логирует своё решение вместе с ответом, чтобы регрессию можно было отфильтровать по tier. Выбор — это ещё и не одноразовое решение: ландшафт моделей движется быстрее любой другой инфраструктуры, от которой зависит команда, и дисциплина — раз в квартал перепрогонять оценочный набор и мигрировать, когда данные это поддерживают.

2.2 Сэмплинг как осознанный профиль

Temperature масштабирует распределение токенов перед сэмплингом; top-p обрезает его до нуклеуса выше вероятностного порога; min-p отфильтровывает токены сильно ниже верхних; seed даёт best-effort повторяемость. Два профиля, которые стоит явно назвать, — это детерминированный (temperature 0, top-p 1.0, seed выставлен) для классификации, извлечения и маршрутизации, где контракт «один вход — один выход»; и творческий (temperature около 0.8, top-p 0.95) для генерации, где вариация — это и есть продукт. Смешивать их случайно, используя дефолт temperature 0.7 на классификационной задаче, — значит производить тот класс нестабильных тестов и периодических отказов, которые команды списывают на модель, тогда как ответственность лежит на выборе параметров. Стриминг ортогонален сэмплингу: те же параметры применяются, меняется транспорт, а time-to-first-token заменяет полную задержку в качестве метрики воспринимаемой скорости.

2.3 Защитные промпты и структурированные выходы

У продакшен-промпта пятичастная анатомия — роль, задача, ограничения, примеры, обрамлённый вход — и порядок важен, потому что внимание модели к каждому компоненту зависит от того, что стоит перед ним. Обрамлённый вход, с обеих сторон окружённый напоминанием, что содержимое между маркерами — данные, а не инструкции, — это пол, ниже которого промпт опускаться не должен. Промпты — версионированные кодовые артефакты; имя вроде prompts/classify_support_v3, логируемое в каждом трейсе, — это способ проследить регрессию до изменения, её вызвавшего. Структурированные выходы — Pydantic в Python, Zod в TypeScript, передаваемые провайдеру как response schema — обеспечивают форму выхода на этапе декодирования. Provider-side JSON Schema-энфорсмент убирает целый класс валидационных отказов. Там, где JSON Schema не хватает выразительности — SQL, регексо-подобные форматы, аргументы инструментов против закрытого каталога, — grammar-constrained decoding через Outlines даёт ту же гарантию на уровне токена.

Стоит запомнить: каждое решение, задвинутое обратно внутрь модели, — это решение, которое команда потеряла возможность протестировать. Constrained decoding гарантирует форму; содержание по-прежнему принадлежит обёртке.

Что подготавливает глава 2

Глава 2 предполагала, что содержимого промпта достаточно для задачи. Для многих задач — классификация, извлечение, преобразование — предположение выполняется. Для большинства пользовательских продакшен-систем — не выполняется, потому что пользователь спрашивает про факты, которыми владеет команда, а модель никогда их не видела: внутренние документы, политика этой недели, история заказов клиента. Инженерный ход, закрывающий этот разрыв, — retrieval-augmented generation. Глава 3 проходит RAG-конвейер от начала до конца — загрузка, chunking, эмбеддинг, retrieval, генерация — и затем техники, отделяющие демо-конвейер от продакшена: гибридный retrieval, структуро-чувствительный chunking и трансформации запроса вроде HyDE и step-back.

Дальше — Глава 3: Retrieval-Augmented Generation. Конвейер, дающий модели контекст, которого никогда не было в её обучающих данных, — от загрузчика до генератора.

Хочется всю картину? Книжная глава включает полные рабочие примеры Pydantic и Zod, grammar-constrained SQL на Outlines и композированную защитную обёртку извлечения в конце главы. LLM Primer V на Amazon →