LLM архитектура против промпта: почему 97% надёжности недостаточно для продакшена

Готовясь к сертификации по архитектуре LLM-систем, автор оригинала раз за разом проваливал один и тот же тип вопросов и обнаружил границу, которую стабильно путают практики: промпт (промпт) снижает вероятность ошибки, но не гарантирует результат, а LLM архитектура выстраивает гарантии кодом.

Разбор пришёл из подготовки к CCA-F (Claude Certified Architect, Foundations, базовая сертификация по проектированию систем на языковых моделях от Anthropic). Автор ожидал зубрить параметры API и лимиты контекста. Вместо этого экзамен бил по одной точке: где кончается промпт и начинается LLM архитектура. Три типа вопросов, три ошибки, и все растут из одного мифа: «хорошо написанный промпт и есть архитектура».

В чём миф и почему он живучий?

Миф звучит так: если модель ошибается, нужно дописать в промпт ещё правило, ещё пример, ещё слово «ВАЖНО» заглавными буквами. Автор оригинала формулирует это жёстко: промпт для языковой модели это пожелание, высказанное вероятностной системе. Архитектура это гарантии, которые работают вне зависимости от того, как модель сегодня интерпретирует текст.

Аналогия для нетехнарей: написать над полем формы «пожалуйста, вводите только цифры» вместо того, чтобы запретить буквы на уровне кода. На демо всё выглядит идеально. На тысяче реальных пользователей кто-нибудь вставит пробел, и форма сломается.

Что понадобится

• Доступ к любой языковой модели с API: Claude, ChatGPT, GigaChat, YandexGPT
• Среда, в которой можно писать код или хотя бы скрипт на Python (Google Colab подойдёт)
• Понимание, что такое системный промпт (системный промпт, это скрытая инструкция, которую разработчик задаёт модели до начала диалога с пользователем)
• 30 минут на три упражнения ниже

Пошаговая инструкция: три ловушки и как их обойти

Ловушка 1. «В промпте написано, значит, так и будет»

1. Откройте чат с моделью и задайте ей системный промпт с жёстким ограничением:

Классифицируй обращение строго в одну из категорий:
Billing, Technical, Account, Feedback.
ВСЕГДА возвращай только название категории из списка.
НИКОГДА не придумывай новые категории.

1. Отправьте 20 разных обращений. В большинстве случаев модель ответит корректно.

2. Попробуйте подать неоднозначный запрос, например сообщение одновременно про оплату и про техническую проблему. На дистанции модель рано или поздно вернёт что-то вроде «Billing/Technical» через слэш, просто «Bill» или даже «Customer Care», категорию, которой нет в списке.

3. Теперь добавьте валидацию на стороне кода:

ALLOWED = {"Billing", "Technical", "Account", "Feedback"}

def classify(text, max_retries=2):
    for attempt in range(max_retries + 1):
        result = call_llm(text).strip()
        if result in ALLOWED:
            return result
    return "Unclassified"  # fallback на ручную обработку

1. Результат: промпт становится короче, из него уходят все «ВСЕГДА» и «НИКОГДА». Их работу теперь выполняет код, который не умеет фантазировать. Это и есть переход от промпта к LLM архитектуре.

Ловушка 2. «Цепочка рассуждений улучшает всё»

1. Возьмите ту же задачу классификации и добавьте в промпт инструкцию «думай шаг за шагом» (chain-of-thought, CoT, метод, при котором модель рассуждает вслух перед ответом).

2. Прогоните десять обращений и замерьте три вещи:

3. Сколько токенов (токен, минимальная единица текста для модели, примерно 3/4 слова на русском) потрачено на каждый ответ

4. Насколько сложнее вытащить финальную метку из абзаца рассуждений

5. Были ли случаи, когда модель начала с верной категории, а потом «переубедила» сама себя

6. Сравните с простым промптом без CoT. Для задачи «верни одну метку из списка» цепочка рассуждений увеличивает расход токенов в разы, усложняет парсинг и может ухудшить точность.

7. Правило: CoT это инструмент для задач с многошаговым выводом (математика, планирование, разбор противоречий). Классификация по фиксированным категориям требует хороших примеров (few-shot), жёсткого формата вывода и низкой температуры (параметр, который управляет «случайностью» ответов модели), а не пространства для сомнений.

Ловушка 3. «Один порог уверенности на все задачи»

1. Если ваша система умеет оценивать уверенность ответа (confidence score), не ставьте одно пороговое значение для всех типов запросов.

2. Подумайте о цене ошибки. Модель может показать уверенность 0.85 на вопросе про обработку персональных данных. Для обычного запроса ошибка стоит минуту неудобства. Для юридически или финансово чувствительного запроса это инцидент.

3. Вынесите пороги в конфигурацию по категориям: для высокорисковых тем порог выше и путь к ручной проверке короче, для рутинных можно пропускать автоматически.

Что делать с этим прямо сейчас, по ролям?

Авторам Дзена и копирайтерам. Если вы генерируете тексты через ИИ и даёте модели инструкцию «пиши только в таком-то формате», добавьте проверку результата хотя бы вручную. Галлюцинация (галлюцинация, когда модель уверенно выдумывает то, чего не было) не лечится более строгим промптом, она лечится проверкой на выходе.

Маркетологам. Если строите чат-бот для классификации заявок или маршрутизации лидов, заложите в техзадание валидацию ответов на уровне кода. Промпт это демо, код это продакшен.

Предпринимателям в РФ и СНГ. Доступные в России модели (YandexGPT, GigaChat) ведут себя так же: инструкция в промпте снижает вероятность ошибки, но не обнуляет. Принцип «валидация выше промпта» не зависит от провайдера и работает одинаково с любой языковой моделью.

Разбор из экзамена CCA-F звучит академически, но бьёт в ежедневную практику каждого, кто встроил языковую модель в рабочий процесс. Если из всей статьи вы запомните одну мысль, пусть будет эта: промпт это пожелание, архитектура это гарантия, и одно не заменяет другое.