Запрос «разработка с AI» в поиске звучит широко: чат-бот, распознавание документов, ассистент в CRM, генерация кода, классификация обращений. Разница между демо на конференции и продуктом, которым пользуются каждый день, — в данных, контроле качества, безопасности и экономике токенов. Модель — лишь один компонент в контуре, где не менее важны права доступа, журналирование, fallback и измеримые метрики.

В этой статье — как спроектировать AI-функцию так, чтобы она пережила первый месяц production-нагрузки без сюрпризов для бизнеса и инженеров.

Где AI даёт измеримый эффект

ИИ оправдан, когда есть повторяющаяся когнитивная работа с чёткими входами и критериями «достаточно хорошо»:

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

Когда AI не нужен: табличные отчёты по фиксированным правилам, жёсткие workflow с валидацией на уровне БД, задачи с нулевой терпимостью к ошибке без human-in-the-loop.

Архитектура AI-контура в продукте

Типовая схема production-контура:

[Клиент / API]
      ↓
[Orchestrator] — маршрутизация, лимиты, кэш
      ↓
[Retrieval] — поиск по индексу (RAG)     [Tools] — CRM, БД, калькуляторы
      ↓                                        ↓
[LLM / ML model] ← контекст + политики
      ↓
[Post-processing] — валидация JSON, модерация, цитаты
      ↓
[Audit log] + [метрики]

Синхронный vs асинхронный путь

Для критичных операций (изменение данных, финансы) — двухфазный сценарий: модель предлагает, человек или rule engine подтверждает.

RAG: когда и как

Retrieval-Augmented Generation нужен, когда ответ должен опираться на ваши документы, а не на обучение модели:

1. Индексация: chunking (500–1500 токенов с перекрытием), метаданные (версия, отдел, дата).
2. Поиск: гибрид dense + keyword (BM25) часто стабильнее чистого embedding.
3. Сборка промпта: top-k фрагментов + инструкция «отвечай только по контексту».
4. Цитирование: возврат source id в ответе — снижает галлюцинации и упрощает аудит.

Типичные ошибки RAG:

• Слишком крупные чанки — модель «теряет» деталь.
• Нет версионирования базы — ответы ссылаются на устаревший регламент.
• Индексация без ACL — пользователь видит чужие фрагменты при поиске.
• Один промпт на все типы вопросов — лучше маршрутизация intent → отдельный pipeline.

Агенты и tool use

Агент — это цикл: модель решает вызвать инструмент (API, SQL, поиск), получает результат, повторяет до финального ответа. Полезно для многошаговых задач («найди заказ → проверь статус → сформируй письмо»).

Ограничения для production:

• Allowlist инструментов — не произвольный shell.
• Лимит шагов (например, 5–10) против бесконечных циклов.
• Идемпотентные side-effect операции или обязательное подтверждение.
• Санитизация аргументов SQL и path traversal.

Агент без guardrails в демо выглядит магически; в prod без них — источник инцидентов.

Пошаговый процесс внедрения

Шаг 1. Задача и метрика

Не «внедрить GPT», а «снизить время обработки заявки с 12 до 6 минут при допустимой ошибке извлечения полей < 3%». Одна primary metric, одна guardrail metric (например, доля эскалаций на человека).

Шаг 2. Данные и границы

Для госсектора и НИИ часто нужен контур on-prem или выделенный inference — см. разработку для НИИ.

Шаг 3. Базовый pipeline без «магии»

Сначала — детерминированный baseline (правила, шаблоны, keyword). Затем A/B: модель должна бить baseline по метрике, а не только «казаться умнее» на трёх примерах.

Шаг 4. Оценка качества

• Набор эталонных кейсов (50–500+ для серьёзного пилота) с разметкой.
• Регрессия промптов и моделей в CI — сравнение F1, exact match, human rubric.
• Human review на пилоте: выборочный аудит 5–20% ответов.
• Online метрики: thumbs down, эскалации, время до исправления.

Таблица уровней зрелости оценки:

Шаг 5. Стоимость и производительность

Инференс — операционная статья расходов:

Считайте стоимость на успешную операцию (например, на один обработанный документ), а не только цену за 1M токенов.

Шаг 6. Деградация и fallback

При недоступности модели или превышении latency:

1. Ответ из кэша или шаблона.
2. Упрощённый rule-based путь.
3. Явное сообщение пользователю и постановка в очередь.

«Тишина» или пустой ответ хуже честного «сервис временно недоступен».

Безопасность, compliance и риски

Конфиденциальность: договор с провайдером о неиспользовании данных для обучения (где применимо), шифрование в transit/at rest, минимизация контекста.

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

Воспроизводимость: temperature, seed (где есть), версия модели и промпта в audit log — иначе невозможно разобрать инцидент.

Зависимость от провайдера: абстракция над API, возможность смены модели с тем же контрактом ответа; для критичных систем — резервный провайдер или локальная модель.

Prompt injection: пользовательский ввод не должен переопределять system policy; разделение ролей в сообщениях, фильтры на выходе, запрет исполнения инструкций из retrieved-текста как команд.

Модерация: токсичность, утечка секретов в ответе — классификаторы или правила на post-processing.

Интеграция AI в процесс разработки ПО

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

Практики для команды:

Для промышленных сценариев связка с классическими системами разобрана в автоматизации с AI: предиктивное обслуживание и анализ телеметрии — отдельный контур с ML, не обязательно LLM.

Выбор модели: практические критерии

Нет универсальной «лучшей» модели — есть соответствие задаче и бюджету:

Стратегия cascade: дешёвая модель отсекает простые запросы (FAQ, классификация), дорогая вызывается только для сложного reasoning. На практике 60–80% трафика часто закрывается первым уровнем без заметной потери качества.

При смене провайдера или версии модели — shadow period: новая модель отвечает параллельно, сравнение метрик на живом трафике без показа пользователю, затем переключение по feature flag.

Типичные ошибки при «разработке с AI»

1. Демо = scope. Один красивый сценарий без edge cases и негативных тестов.
2. Нет владельца качества. «Модель сама научится» — не стратегия.
3. Промпт как единственная спецификация. Бизнес-правила дублируют в коде там, где нужна детерминированность.
4. Игнор latency. 40 секунд на ответ убивают UX в операторском интерфейсе.
5. Всё в один контекст. Длинная история чата без summarization — рост счёта и падение качества.
6. Отсутствие kill switch. Feature flag на AI-функцию обязателен до full rollout.

Чеклист готовности к production

• Primary и guardrail метрики согласованы с заказчиком.
• Offline-набор и порог регрессии в CI.
• Audit log: user id, model version, prompt hash, sources (для RAG).
• Лимиты, rate limit, кэш, оценка месячного burn.
• Fallback при отказе модели протестирован.
• Политика PII и согласования с ИБ/юристами.
• Runbook: деградация качества, смена модели, откат промпта.
• Human-in-the-loop для необратимых действий.

Заключение

Разработка с AI — это инженерия продукта: постановка измеримой задачи, контур данных, оркестрация, оценка, экономика и безопасность. Модель даёт возможности, но устойчивость обеспечивают правила, метрики, fallback и дисциплина версионирования — те же принципы, что и в любой критичной системе. Начинайте с узкого сценария, который бьёт baseline по цифрам; масштабируйте только после того, как контур оценки и эксплуатации работает так же предсказуемо, как остальной backend.