Глава 57. Что должен уметь сильный LLM/backend engineer

Кандидат за десять минут собрал агента с тремя tools. Затем не смог объяснить, что произойдёт, если платёжный API завершит операцию, а соединение оборвётся до ответа. В production второй вопрос важнее первого. Собрать агента за десять минут сегодня умеет и сам агент; отвечать за деньги, ушедшие дважды, пока приходится человеку.

Работа видна по артефактам

Сильный инженер переводит расплывчатый use case в контракт и метрику результата. Он собирает golden dataset до полировки prompt, различает ошибку модели, retrieval и orchestration, умеет посчитать бюджет и поставить его в код.

Он проектирует обычный backend: timeout, retry policy, idempotency, очередь, транзакционную границу, права, секреты, миграции и observability. Вероятностный компонент не освобождает от этого, а добавляет версии prompt, модели, данных и evals.

Минимальный разбор изменения выглядит так:

hypothesis -> dataset -> offline eval -> code review
           -> shadow/canary -> outcome metrics -> rollback or rollout

class RunRecord(BaseModel):
    request_id: str
    use_case: str
    prompt_version: str
    model: str
    corpus_version: str | None
    input_tokens: int
    output_tokens: int
    latency_ms: int
    outcome: str | None

Главный навык проявляется при неопределённости. Инженер не обещает убрать hallucinations, а ограничивает ущерб. Не говорит «модель уверена», пока confidence не откалиброван. Не строит multi-agent систему, если конечный автомат решает задачу.

Как проверять себя и кандидата

Дайте грязный кейс: документы разных tenant, лимит $0,10 на результат, внешний API с timeout после записи. Попросите схему, код критической границы, eval-план и разбор инцидента. Хороший ответ содержит места отказа и наблюдаемые доказательства. Названия фреймворков вторичны.

Failure mode специалиста состоит в локальной оптимизации: prompt стал лучше на пяти примерах, latency p50 упала, demo понравилось. Система при этом может хуже решать задачу. Нужна привычка доходить до outcome.

Чего этот навык не требует

Что часто путают с квалификацией и на что уходит много чужого времени:

• Знание последних моделей наизусть. Имена и цены живут в приложении А и устаревают быстрее, чем печатается страница.
• Опыт с конкретным фреймворком. Оркестратор пишется за неделю; понимание границ — за годы.
• Умение делать эффектные демо. Демо доказывает, что случай возможен, и не доказывает больше ничего.
• Мнение о том, «настоящий ли это интеллект». Философский вопрос, не меняющий ни одного технического решения.

Зато требуется скучное: транзакции, идемпотентность, права, наблюдаемость, умение считать деньги и привычка доводить измерение до результата, а не до впечатления.

Правило главы

Сила LLM/backend engineer измеряется тем, насколько предсказуемой он делает систему с непредсказуемым компонентом.

Чеклист главы

• Расплывчатый use case превращается в контракт и метрику результата, а не в задачу «прикрутить LLM».
• Golden dataset собирается до полировки промпта.
• Ошибка раскладывается на модель, retrieval и оркестрацию; диагноз ставится по данным.
• Бюджет считается до запуска и живёт в коде, а не в документе.
• Обычный backend сделан как обычный backend: таймауты, ретраи, идемпотентность, очередь, транзакции, права, секреты, миграции.
• Версионируются промпт, модель, данные и evals; по запросу восстанавливается конфигурация.
• Изменения проходят путь hypothesis → dataset → offline eval → review → shadow/canary → outcome.
• Обещания калиброваны: hallucinations ограничиваются, а не «убираются»; confidence используется только после калибровки.
• Сложность обосновывается: конечный автомат предпочитается агенту, пока агент не доказан данными.
• Привычка доходить до outcome-метрики, а не останавливаться на демо и p50.

Практикум

Задача 57.1 — сервис за два дня и защита по отказам. ⭑⭑⭑

Соберите сервис извлечения данных и защитите его не по happy path.

Критерии приёмки:

• Есть строгая схема, 50 размеченных примеров, лимиты, trace и ручная очередь.
• На защите показаны: timeout после побочного эффекта, смена промпта, попытка утечки между tenant, откат модели.
• Для каждого сценария видно наблюдаемое доказательство поведения, а не рассказ.
• Записано, какие свойства доказаны тестом, а какие пока предполагаются.
• Названа стоимость одного успешного результата и порог, при котором сервис выключается.

Подсказки:

1. Список «предполагается, но не доказано» — самая честная часть защиты. Он ценится выше, чем безупречный happy path.
2. Два дня — это ограничение, а не оценка сложности: оно заставляет выбирать, что действительно критично.

Задача 57.2 — разбор чужого инцидента. ⭑⭑

Возьмите реальный или описанный инцидент LLM-системы и напишите разбор.

Критерии приёмки:

• Восстановлена временная шкала: что произошло, когда заметили, что сделали.
• Ошибка разложена на слои: модель, retrieval, оркестрация, данные, процесс.
• Названо, какое наблюдение позволило бы заметить проблему раньше, и оно реализуемо.
• Предложены два изменения: одно дешёвое на завтра, одно структурное на квартал.
• Сказано, что осталось неизвестным; гипотезы помечены как гипотезы.

Подсказки:

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