Этап 10 — Переход от Prompt Engineering к AI-архитектуре
На этом этапе prompt перестаёт быть «текстом» и становится частью бизнес-логики.
Темы этапа
- Когда prompt — это уже бизнес-логика
- Разделение ролей: system / developer / user
- Оркестрация LLM в приложении (например, Spring Boot + LLM)
Prompt как бизнес-логика
Если prompt:
- влияет на критичные решения,
- запускает действия,
- управляет маршрутизацией сценариев,
то это уже часть прикладной логики и должно жить как кодовый артефакт с versioning и review.
Разделение ролей в архитектуре
system: глобальные правила и безопасность.developer: инженерные ограничения конкретного workflow.user: пользовательская задача и данные.
Нельзя смешивать эти уровни в один неструктурированный текст.
Оркестрация LLM в приложении
Типовой прод-пайплайн:
- Pre-processing и валидация входа.
- Retrieval/подготовка контекста.
- Вызов модели с жёстким контрактом.
- Пост-валидация и policy-check.
- Интеграция результата в бизнес-процесс.
Архитектурная граница
Архитектурная граница пересекается тогда, когда поведение prompt-а влияет на состояние продукта. Если модель только пишет черновик для человека, сбой prompt-а может быть проблемой качества текста. Если prompt решает маршрутизацию, запускает инструмент, пишет в БД или фильтрует доступ пользователя, сбой prompt-а становится сбоем приложения. Поэтому production AI-системе нужно разделять prompt text, orchestration code, validation, permissions и observability.
Prompt-as-code означает, что prompt хранится, ревьюится, версионируется и тестируется как артефакт, определяющий поведение. Это не значит, что вся логика должна жить внутри prompt-а. Устойчивые правила лучше держать в backend-коде, когда это возможно. Prompt должен выражать инструкции для модели, а приложение — enforce-ить контракты, которые нельзя оставлять только на послушание модели.
| Зона ответственности | Где должна жить в основном | Причина |
|---|---|---|
| Safety policy | System prompt и backend checks | Инструкция модели плюс enforcement |
| Permissions | Backend authorization | Нельзя полагаться на сгенерированный текст |
| Output shape | Prompt и schema validator | Генерация плюс проверка |
| Rollout | Application configuration | Даёт rollback и эксперименты |
Архитектурные практики
- prompts-as-code,
- тестовые наборы и регрессионные проверки,
- feature flags для rollout,
- наблюдаемость (качество, стоимость, latency, safety).
Финальный вывод
Ценность prompt engineering раскрывается только когда он встроен в системную архитектуру, а не используется как разовый ручной приём.
Объяснение для новичка
На ранних этапах prompt выглядит как текст в чате. В production-приложении prompt часто становится частью системы. Если он решает, какой маршрут выбрать, какой tool вызвать, какой ответ отправить клиенту или какой риск присвоить заявке, это уже бизнес-логика. Такую логику нельзя держать как случайную строку без review и тестов.
AI-архитектура разделяет обязанности. Backend проверяет права доступа, валидирует вход, выбирает документы, вызывает модель, проверяет выход и логирует результат. Prompt объясняет модели, что нужно сделать внутри конкретного шага. Если всё положить в prompt, система станет хрупкой. Если всё жёстко закодировать, модель потеряет гибкость. Нужен баланс.
Типовой production workflow выглядит так: вход валидируется, лишние данные отбрасываются, retrieval готовит контекст, prompt вызывает модель с контрактом, output validator проверяет результат, policy-check ловит нарушения, приложение решает, можно ли использовать ответ. Каждый шаг должен быть наблюдаемым: latency, cost, качество, ошибки формата, safety-срабатывания.
Мини-сценарии из практики
- Команда спорит «это проблема модели или архитектуры»: на деле промпт уже содержит бизнес-логику и влияет на продуктовые решения.
- Один универсальный агент используется для всех задач: без разделения ролей растут ошибки и стоимость запросов.
- Интеграция с приложением работает нестабильно: отсутствует оркестрация шагов и контроль состояния диалога.
Быстрые правила принятия решений
- Если правило влияет на бизнес-результат, относись к нему как к части архитектуры, а не «текста в промпте».
- Делай разделение ролей system/developer/user явным и проверяемым.
- Оркестрацию строй через этапы: план -> выполнение -> валидация -> логирование.
Вопросы для самопроверки
- В какой момент prompt engineering превращается в архитектурную ответственность?
- Почему смешивание ролей ухудшает предсказуемость поведения модели?
- Какие элементы оркестрации обязательны для production-сценария?