Промт-инжиниринг — техники, шаблоны и тактики надёжности
Раздел Промт-инжиниринга разбирает, как сделать выдачу LLM достаточно стабильной для продакшна: структуры промтов, держащиеся на edge cases; eval-пайплайны, ловящие регрессии; retrieval-паттерны, заземляющие ответы в реальных данных. Меньше про «хитрые одиночные промты», больше про системы, которые идут в прод.
Что покрывается
Промт-паттерны — системные промты с ролью + ограничениями + форматом вывода; few-shot vs zero-shot trade-offs; chain-of-thought когда помогает и когда просто раздувает токены. Evaluation — автоматические eval-сьюты, LLM-as-judge сетапы, регрессионные тесты, ловящие prompt drift. RAG — стратегии чанкинга, выбор эмбеддингов, ре-ранкинг, гибридный поиск. Агенты — tool calling, planning loops, обработка fallback'ов.
Примеры на реальных задачах (извлечь структурированные данные из инвойсов, маршрутизировать тикеты поддержки, суммаризировать длинные митинги) — видно соотношение «промт → выдача» на знакомых проблемах. Где уместно, посты сравнивают выдачу разных моделей (ChatGPT, Claude, Gemini) на одном промте — разные failure modes.
От промта к продакшну
Промт, который раз сработал на happy-path примере — не фича. Раздел делает упор на воспроизводимость: промты, держащиеся на тысячах вызовов; eval-ворота, ловящие 1% случаев, когда модель уходит в сторону; мониторинг, поднимающий silent drift после апдейта модели вендором.
Для билдеров, не для исследователей
Посты целят в практиков, строящих продакшн-фичи, а не в академический prompt-research. Вопрос «хороший ли это промт?» сворачивается к «делает ли этот промт продукт лучше?» с конкретными метриками. Если тюните промты под реальный продукт — начните отсюда.