Глава 1 — Дисциплина AI-инженерии

Первый пост поглавного разбора LLM Primer V: Building Real-World LLM Applications. Глава, утверждающая, что причина, по которой демо работает, а продакшен-система — нет, это не проблема модели, а проблема инженерии, и у этой инженерии есть имя.

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

Каждая команда, выпускающая LLM-фичу, обнаруживает один и тот же разрыв. Демо нормально работает на двадцати входах, отобранных командой; продакшен-система плохо работает на двадцати тысячах входов, которых команда никогда не видела. Модель не стала хуже. Команда вышла из области, где правдоподобный однократный выход считается успехом, и попала в область нагрузки, дрейфа, вредоносных входов и платящих клиентов, чей комплейн-метрик беспощаден. Глава 1 называет эту область и даёт ей дисциплину. AI-инженерия — это не наука об обучении модели и не практика написания умных промптов. Это инженерия детерминированного поведения системы вокруг вероятностного ядра. Остальная часть книги — прогулка по поверхностям, на которых живёт эта дисциплина; данная глава — рамка.

Если коротко: AI-инженерия — это дисциплина построения детерминированных обёрток вокруг вероятностных ядер, и именно в обёртке, а не в модели, живёт надёжность системы.

1.1 Разрыв надёжности между демо и продакшеном

Демо и продакшен-система на архитектурной диаграмме выглядят одинаково. Различаются они нагрузкой, распределением хвостовых входов, бюджетом задержки, ценовым давлением и характером отказа. Доминирующее различие — статистическое: демо прогоняет несколько десятков отобранных вручную входов, а продакшен — миллионы против длинного хвоста, тех запросов, которые сформулированы странно, частично на другом языке, лишены контекста или намеренно вредоносны. Надёжность — это вопрос про хвосты, а не про средние. Поверх этого — сама модель недетерминирована: сэмплинг, балансировка нагрузки на стороне провайдера и тихие апдейты модели складываются, — и отказы тихие. Неправильный ответ парсится чисто, проходит все type check, которые команда написала, и доходит до пользователя без единого алерта. Классическая наблюдаемость, считающая HTTP 200, этот режим отказа увидеть не может. Первый ход команды — признать, что повторяемость, корректность и стоимость — это инженерные свойства, которые нужно построить, а не свойства, которые унаследуются от классического стека.

1.2 Детерминированная обёртка вокруг вероятностного ядра

Архитектурный ответ — оставить модель вероятностной и обернуть её в классический софт. Обёртка владеет формой входа, формой выхода, валидацией, ретраями, фолбэками, кэшированием, наблюдаемостью и учётом стоимости. Снаружи она предстаёт детерминированной функцией: заходит запрос, выходит валидированный ответ. Внутри она содержит вероятностный компонент, который вызывается с таймаутом, схемой и планом восстановления на случай, если модель вернёт мусор. У обёртки четыре полосы: валидация входа, подготовка промпта, выполнение по контракту, восстановление и выдача. Только пройдя все четыре, ответ становится официальным выходом обёртки. Повторяющееся искушение — вернуть логику внутрь модели («пусть модель сама проверит свой ответ») — и каждый шаг в этом направлении есть шаг от тестируемости. Дисциплина — держать вероятностное ядро маленьким, чётко определённым и изолированным, а как можно больше поведения системы держать в детерминированном коде, который команда может версионировать и обосновывать.

1.3 Пять опор: надёжность, качество, производительность, стоимость, эволюция

Глава 1 проходит пять инженерных постур, повторяющихся в каждой продакшен-системе. Надёжность приходит из избыточности: ретраи с экспоненциальным бэкоффом, цепочки фолбэков от дешёвого первичного к более сильному вторичному и к правиловому дефолту, мультипровайдерная абстракция и circuit breaker, не дающий проблемному провайдеру каскадировать. Качество приходит из валидации на двух уровнях: schema-валидация ловит ошибки формы, а content-валидация — проверка обоснованности, порог уверенности, guardrail-проверки — ловит семантические ошибки, прошедшие схему. Производительность приходит из кэширования в три слоя: точное совпадение, семантическое, префиксное. Контроль стоимости приходит из измерения и атрибуции, из маршрутизации трафика в наименьшую достаточную модель, из бюджетов на пользователя и на запрос, не дающих agent-циклу молча потратить тысячу долларов, и из экономии на промптах. Эволюция приходит из пяти петель обратной связи — логирование, оценка, трассировка, human feedback и canary-выкатка, — соединённых в контур, где продакшен-трейс становится eval-кейсом, регрессия в evals блокирует деплой, а система улучшается из месяца в месяц.

Стоит запомнить: никакой один вызов модели не должен нести на себе надёжность системы. Если в вашей ментальной модели есть шаг, где «модель обязана дать это правильно, иначе запрос падает», архитектура ещё не впитала следствий вероятностного вычисления.

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

Остальная часть книги — это обёртка, слой за слоем. Глава 2 заходит внутрь самого вызова модели: тиринг моделей, параметры сэмплинга, защитные промпты и структурированные выходы. Глава 3 расширяется вовне, к retrieval, чтобы модель имела правильный контекст, над которым рассуждать. Глава 4 превращает обёртку в агента, способного вызывать инструменты. Главы 5 и 6 добавляют рельсы оценки и наблюдаемости. Главы 7 и 8 закрывают безопасностью и экономикой serving-а. Рамка главы 1 — то, что делает каждую следующую главу читаемой: любая техника есть либо способ ужать обёртку, либо способ сделать вероятностное ядро внутри неё легче оборачиваемым.

Дальше — Глава 2: Foundation-модели и prompt engineering. Слой внутри обёртки — выбор модели, сэмплинг, промпты и структурированные выходы — как инженерные поверхности, а не как искусство.

Хочется всю картину? Книжная глава включает «In Plain English»-врезки, полный рабочий пример классификационной обёртки на Python и расширенную композицию retry-fallback, которую статья только резюмирует. LLM Primer V на Amazon →