Работа с моделью: от baseline до продакшена
Порядок усложнения, baseline за полдня, промпт как артефакт, структурированный вывод, выбор модели и токен-бюджет, деградация
Это база роли AI Engineer. Задача роли — не «подключить нейросеть», а отвечать за то, как продукт использует модель и почему именно так: какой минимальной конструкцией решается задача, во что она обходится и что происходит, когда модель отвечает плохо.
Порядок усложнения: не начинай с конца
Каждый следующий уровень дороже предыдущего — в разработке, в отладке и в деньгах. Поэтому берут его только тогда, когда предыдущий доказанно не тянет, а не потому что «это же AI-продукт».
- Промпт. Инструкция + структурированный вывод. Закрывает больше задач, чем принято думать.
- Промпт с примерами (few-shot). Когда формат или тон не ловится описанием — покажите 2–5 примеров.
- RAG. Когда ответ должен опираться на ваши данные, которых нет в модели.
- Агент с инструментами. Когда нужны действия и ветвление, а не один ответ.
- Мультиагентность. Когда задачи реально разные по ролям — и это отдельный разговор.
Прыжок сразу на уровень 4 «потому что это AI-продукт» — самая частая причина, по которой в декабре нечего показать.
Baseline: первая проба
Не начинай строить без картины в голове — но картину добывай быстрой дешёвой пробой, а не ожиданием озарения. Baseline — это самое простое решение, которое уже работает: один промпт, десяток примеров, ноутбук, полдня работы.
Что даёт baseline:
- точку отсчёта в цифрах — пороги evals ставятся от неё, а не с потолка;
- честный ответ, нужен ли RAG — если простой промпт даёт 80% нужного, строить векторную базу ради оставшегося стоит осознанно;
- раннюю оценку стоимости — сколько токенов ест один запрос.
Baseline не выбрасывается: он остаётся запасным вариантом на случай, когда основной путь недоступен.
Промпт живёт в репозитории
Промпт живёт в репозитории (prompts/), версионируется вместе с кодом и
меняется через PR. Причина простая: промпт определяет поведение продукта не
меньше, чем код, а «поправил кавычку в проде» — не история изменений.
Что делает промпт рабочим:
- Роль и задача одним абзацем, без литературы.
- Явный формат ответа. Все крупные провайдеры поддерживают режим структурированного вывода по JSON-схеме — валидный JSON гарантируется на уровне декодирования. Свободный текст парсить регулярками не надо.
- Границы: чего делать нельзя, когда отказываться, что считать недостаточным контекстом. Заранее прописанные ограничения экономят больше, чем подробное описание желаемого.
- Разделение инструкций и данных — чужой текст обёрнут явно (почему это важно).
Отдельно про приёмы из статей. Промптинг быстро устаревает: «думай пошагово» помогало дешёвым моделям, а рассуждающим скорее мешает — они делают это сами. Вывод не в том, чтобы запомнить актуальный список приёмов, а в том, чтобы проверять любой приём на своём golden dataset: цифры до и после. Приём, который не улучшил метрику на вашей задаче, — чужой опыт, а не ваш.
Выбор модели: самое дорогое решение проекта
Модель определяет качество, скорость и счёт за семестр — поэтому решение оформляется ADR с ценой, а не выбирается по названию.
Кандидаты сравниваются на вашем golden dataset, а не по чужим бенчмаркам. Минимальная таблица сравнения:
| Что сравниваем | Зачем |
|---|---|
| Качество на вашем наборе | единственная релевантная метрика |
| Цена за 1000 запросов | помещаетесь ли в семестровый бюджет |
| Задержка p95 | влезает ли в сценарий из UC |
| Доступность и лимиты | что будет при отказе провайдера |
Токен-бюджет считается до старта, а не когда кончились деньги: средняя длина промпта и ответа × ожидаемое число запросов. Отдельно закладывается запас на прогоны evals — они тоже тратят токены.
RAG: только когда нужен, и с проверяемой ссылкой
RAG нужен, когда ответ должен опираться на данные, которых у модели нет: ваши документы, свежие материалы, внутренние правила.
Что ломается на практике (в таком порядке):
- Нарезка (chunking). Слишком крупные куски размывают смысл, слишком мелкие теряют контекст. Это первое, что настраивают, и первое, что проверяют метриками контекста.
- Поиск не находит нужное — а модель уверенно отвечает по тому, что нашлось. Ловится метриками
Contextual Precision / Recall. - Модель выдумывает поверх найденного — ловится
Faithfulness.
Правило курса: ответ RAG-системы содержит ссылку на фрагмент источника. Это одновременно требование UC, критерий eval и защита от выдумывания.
Деградация: что происходит, когда модель молчит
Внешний провайдер — самая ненадёжная часть системы. Поэтому в UC есть раздел «Альтернативы», а в проекте — план деградации:
- таймаут и ретрай с ограничением попыток (жёсткое ограничение — это код, а не абзац в промпте);
- фолбэк: более дешёвая модель, кэш прошлого ответа, baseline;
- честное сообщение пользователю, если ничего не вышло;
- счётчик деградаций в мониторинге — иначе продукт наполовину живёт на фолбэках, а команда не знает.
Типичные ошибки
- Сразу агент. Три недели на оркестрацию там, где хватало промпта.
- Промпт правится в проде. Нет истории — нет объяснения, почему качество упало.
- Свободный текст вместо схемы. Парсинг регулярками ломается на первой же неожиданной формулировке.
- Выбор модели по бенчмаркам. Чужие цифры не про вашу задачу; меряйте на своём наборе.
- Нет плана на отказ. Провайдер лежит — лежит продукт, на демо это выглядит именно так.