Методичка · Библиотека ДИС
Проектирование и запуск AI-решений
Пошагово проводит от бизнес-задачи и архитектуры до RAG, MVP, управления рисками и запуска в эксплуатацию.
МЕТОДИЧЕСКОЕ ПОСОБИЕ
Проектирование и запуск AI-решений
От бизнес-задачи и архитектуры до RAG, MVP, контроля рисков и промышленной эксплуатации
| Практическая направленностьПособие содержит методику принятия архитектурных решений, контрольные вопросы, чек-листы и сквозной пример платформы AutoSfera AI. |
|---|
Автор: Степанов Дмитрий Александрович
2026
Аннотация
Методическое пособие предназначено для AI-архитекторов, руководителей проектов, аналитиков, разработчиков и предпринимателей, которым необходимо превратить идею AI-продукта в управляемую техническую систему. Основной акцент сделан на прикладных решениях: выборе архитектуры, разделении ответственности между компонентами, построении RAG, оценке моделей, организации команды, управлении рисками и подготовке MVP.
Материал можно использовать как учебный конспект, рабочую инструкцию для проектной команды или основу технического задания. Сквозной пример AutoSfera AI показывает применение методики к платформе для продаж автомобилей, записи на сервис и внутренних коммуникаций сотрудников.
Как работать с пособием
- Сначала сформулируйте бизнес-результат и ограничения проекта.
- Затем заполните архитектурную карту и определите границы компонентов.
- После этого выберите модели, данные, интеграции и метрики качества.
- Соберите ограниченный MVP и проведите испытания на контрольном наборе запросов.
- Только после подтверждения качества, безопасности и экономики переходите к промышленному запуску.
Результаты обучения
- отличать AI-функцию от обычной автоматизации и выбирать подходящий уровень сложности;
- проектировать модульную архитектуру LLM-приложения;
- обосновывать выбор LLM, RAG, оркестратора и интеграционного слоя;
- определять требования к данным, безопасности, наблюдаемости и передаче оператору;
- планировать MVP, пилот, промышленный запуск и последующее улучшение системы.
1. От бизнес-задачи к AI-решению
1.1. Начинать нужно не с модели
Главная ошибка AI-проектов — выбирать модель или фреймворк до определения задачи. Архитектура должна быть следствием измеримого результата: сокращения времени ответа, роста конверсии, снижения нагрузки на сотрудников, повышения полноты поиска или уменьшения числа ошибок.
| Главный принципAI нужен там, где правила трудно перечислить заранее, а результат можно оценить. Если задача полностью описывается фиксированными условиями, надёжнее использовать обычную автоматизацию. |
|---|
1.2. Карточка бизнес-задачи
| Поле | Что зафиксировать | Пример AutoSfera |
|---|---|---|
| Пользователь | Кто получает ценность | Покупатель, клиент сервиса, сотрудник |
| Проблема | Что сейчас долго, дорого или нестабильно | Менеджеры вручную отвечают на типовые вопросы |
| Целевое действие | Что должна сделать система | Ответить, подобрать, записать, создать лид |
| Метрика | Как измеряется улучшение | Конверсия, время ответа, доля передачи оператору |
| Ограничения | Что системе запрещено | Не раскрывать ПДн, не обещать несуществующие условия |
| Владелец | Кто принимает результат | Руководитель продаж или сервиса |
1.3. Критерии применимости AI
- входные данные содержат естественный язык, изображения или неструктурированные документы;
- существует достаточное количество примеров и экспертных знаний для проверки ответа;
- ошибку можно обнаружить, ограничить и при необходимости передать человеку;
- ожидаемый экономический эффект превышает стоимость разработки и эксплуатации;
- процесс допускает постепенный запуск: сначала подсказка сотруднику, затем частичная автоматизация.
2. Базовая архитектура AI-приложения
Производственное AI-приложение — это не только LLM. Оно включает каналы общения, маршрутизацию, данные, инструменты, контроль качества, безопасность и наблюдаемость. Модель выполняет лишь часть работы: интерпретирует запрос и формирует ответ.
| Слой | Назначение | Примеры |
|---|---|---|
| Каналы | Приём запроса и выдача результата | Web, Telegram, CRM, внутренний портал |
| API и оркестрация | Маршрутизация, контекст, последовательность шагов | FastAPI, LangGraph, LangChain |
| Интеллектуальный слой | Классификация, извлечение, генерация, рассуждение | LLM, embeddings, reranker |
| Знания и данные | Факты, документы, состояния процессов | PostgreSQL, векторная БД, файловое хранилище |
| Действия | Изменение внешних систем | n8n, CRM API, календарь, уведомления |
| Контроль | Логи, метрики, трассировка, оценка и безопасность | OpenTelemetry, eval-наборы, аудит |
2.1. Монолит или модульная система
Для демонстрации допустим один сценарий, но в развиваемом продукте функции разделяются. Независимые модули проще тестировать, масштабировать и заменять. Общими остаются формат сообщений, идентификация пользователя, журналирование, политики безопасности и механизм передачи человеку.
| Подход | Когда подходит | Ограничение |
|---|---|---|
| Один workflow | Прототип одной простой функции | Быстро становится трудно поддерживать |
| Оркестратор + sub-workflow | Несколько независимых бизнес-направлений | Нужен строгий контракт данных |
| Событийная архитектура | Высокая нагрузка и много интеграций | Выше сложность наблюдаемости |
| Мультиагентная система | Роли требуют разных инструментов и контекстов | Риск лишней автономности и стоимости |
2.2. Единый контракт данных
Все модули должны принимать и возвращать согласованный набор полей. Минимальный вход: request_id, timestamp, channel, user_id, tenant_id, intent, message, context и consent. Минимальный выход: status, answer, sources, actions, confidence, escalation и error. Персональные данные передаются только при наличии цели и правового основания.
3. Выбор модели и провайдера
Выбор модели выполняется по сценарию, а не по общему рейтингу. Для классификации и извлечения может быть достаточно компактной модели, а для сложного диалога или подготовки предложения — более сильной. Использование нескольких моделей снижает стоимость, но повышает сложность маршрутизации.
| Критерий | Как проверять | Почему важно |
|---|---|---|
| Качество | Слепой тест на реальных запросах | Публичный рейтинг не отражает ваш домен |
| Русский язык | Ошибки смысла, терминологии и стиля | Качество заметно различается по языкам |
| Стоимость | Цена полного пользовательского сценария | Важна стоимость задачи, а не одного токена |
| Задержка | p50 и p95 времени ответа | Медленный ответ снижает конверсию |
| Контекст | Фактическая работа с длинными документами | Заявленный лимит не гарантирует качества |
| Инструменты | Корректность structured output и tool calling | Критично для CRM и записи |
| Приватность | Регион, хранение, обучение на данных | Определяет допустимость провайдера |
3.1. Практический тест моделей
- Соберите 30–50 обезличенных запросов по основным сценариям, включая неоднозначные и ошибочные формулировки.
- Определите эталонные требования к каждому ответу и запрещённые утверждения.
- Запустите одинаковые промпты на кандидатах с фиксированными параметрами.
- Проведите слепую оценку без названий моделей.
- Сравните качество, задержку, стоимость, устойчивость structured output и частоту опасных ошибок.
- Выберите основную и резервную модель, зафиксируйте дату и условия теста.
4. RAG: ответы на основе корпоративных знаний
Retrieval-Augmented Generation дополняет запрос релевантными фрагментами из управляемой базы знаний. RAG особенно полезен, когда факты часто меняются, должны сопровождаться источниками или отсутствуют в знаниях модели.
4.1. Конвейер RAG
- Сбор и инвентаризация документов.
- Очистка, нормализация и удаление дублей.
- Разбиение на логические фрагменты с сохранением заголовков и метаданных.
- Построение embeddings и индексация.
- Поиск кандидатов по запросу пользователя.
- Переранжирование и фильтрация по правам доступа.
- Формирование контекста и генерация ответа со ссылками.
- Проверка достаточности источников и передача оператору при неопределённости.
4.2. Требования к базе знаний
| Требование | Контроль |
|---|---|
| Актуальность | У каждого документа есть владелец, версия и дата пересмотра |
| Достоверность | Разрешены только утверждённые источники |
| Доступ | Документы фильтруются по роли, подразделению и организации |
| Прослеживаемость | Ответ хранит идентификаторы использованных фрагментов |
| Удаление | Удалённый документ исчезает из полнотекстового и векторного индекса |
| Качество поиска | Используется отдельный набор вопросов для retrieval-метрик |
| ВажноRAG не гарантирует истинность ответа. Он повышает управляемость знаний, но требует проверки качества поиска, промпта, цитирования и поведения модели при отсутствии достаточного контекста. |
|---|
5. Оркестрация, workflow и AI-агенты
Оркестрация определяет последовательность действий, состояние диалога, повторные попытки, ограничения и передачу между модулями. AI-агент отличается от фиксированного workflow тем, что модель может выбирать следующий инструмент или шаг. Чем выше автономность, тем строже должны быть разрешения и контроль.
| Инструмент | Основная роль в AutoSfera | Не следует поручать |
|---|---|---|
| LangGraph / LangChain | Состояние диалога, ветвление рассуждения, инструменты | Хранение бизнес-данных без отдельной БД |
| Langflow | Визуальная сборка и тестирование LLM/RAG-цепочек | Критические транзакции без контроля |
| n8n | CRM, уведомления, расписание, внешние API | Свободное рассуждение вместо модели |
| MCP | Стандартизированный доступ модели к инструментам и данным | Неограниченный доступ без политик |
5.1. Правила безопасного tool calling
- каждый инструмент имеет минимально необходимые права и строгую JSON-схему;
- операции чтения отделены от создания, изменения, публикации и удаления;
- опасные или финансово значимые действия требуют подтверждения человека;
- идемпотентность и request_id защищают от повторного создания записи;
- таймауты, повторные попытки и circuit breaker описаны заранее;
- в журнале сохраняются запрос инструмента, результат и инициатор без лишних ПДн.
6. Команда и ответственность
Небольшой MVP может собрать один сильный специалист, однако ответственность всё равно должна быть распределена по ролям. Роль — это область принятия решений, а не обязательно отдельный сотрудник.
| Роль | Ответственность | Ключевой результат |
|---|---|---|
| Владелец продукта | Ценность, приоритеты, бюджет | Принятые метрики и backlog |
| AI-архитектор | Архитектура, модели, интеграции, риски | Архитектурная схема и ADR |
| Domain expert | Правильность бизнес-правил и знаний | Эталонные ответы и источники |
| AI/Backend engineer | Реализация API, RAG, агентов | Работающий и тестируемый сервис |
| Data engineer | Пайплайны, качество и версии данных | Воспроизводимая база знаний |
| QA/Evaluation | Тесты, регрессии, метрики | Отчёт о готовности |
| Security/Legal | Доступ, ПДн, договорные ограничения | Согласованные политики |
7. Жизненный цикл AI-проекта
| Этап | Результат | Критерий перехода |
|---|---|---|
| Discovery | Задача, пользователи, процессы, данные, ограничения | Подтверждена ценность и доступность данных |
| Архитектура | Схема, контракты, ADR, угрозы, смета | Решения понятны и проверяемы |
| PoC | Проверка ключевой технической гипотезы | Гипотеза подтверждена на примерах |
| MVP | Минимальный сквозной пользовательский сценарий | Достигнуты первичные метрики |
| Пилот | Работа с ограниченной группой и реальными процессами | Риски и экономика приемлемы |
| Production | SLA, мониторинг, поддержка, регрессии | Назначены владельцы эксплуатации |
| Развитие | Новые сценарии и оптимизация | Изменения проходят повторную оценку |
7.1. Что считать MVP
MVP — не уменьшенная копия всей платформы и не набор макетов. Это минимальный сквозной сценарий, который создаёт измеримую ценность для одного сегмента пользователей. Для AutoSfera первым MVP может быть обработка входящей заявки: классификация, ответ по проверенной базе, создание лида и передача менеджеру.
8. Оценка качества и наблюдаемость
Качество AI нельзя оценивать только субъективным впечатлением. Нужны офлайн-тесты до выпуска и онлайн-мониторинг после запуска. Метрики модели связываются с результатом бизнес-процесса.
| Уровень | Примеры метрик |
|---|---|
| Retrieval | Recall@k, MRR, доля найденных релевантных источников |
| Ответ | Полнота, корректность, groundedness, соблюдение формата |
| Безопасность | Галлюцинации, утечки, нарушения политики, prompt injection |
| Технический | Доступность, p95 latency, ошибки инструментов, стоимость запроса |
| Бизнес | Конверсия, время обработки, FCR, CSAT, доля ручной работы |
8.1. Минимальный evaluation-набор
- типовые запросы, составляющие основную нагрузку;
- сложные запросы с несколькими условиями;
- неполные, разговорные и ошибочно сформулированные запросы;
- вопросы, на которые в базе знаний нет ответа;
- провокации, prompt injection и попытки получить закрытые данные;
- критические сценарии, где требуется немедленная передача человеку.
| Решение о выпускеВерсия принимается только тогда, когда улучшена primary-метрика, guard-метрики не ухудшились сверх порога, а критические тесты пройдены полностью. |
|---|
9. Безопасность и управление рисками
Управление рисками начинается на этапе архитектуры. Для каждого риска определяются вероятность, ущерб, предупредительные меры, способ обнаружения, реакция и владелец. Подход NIST AI RMF группирует работу в функции Govern, Map, Measure и Manage.
| Риск | Пример контроля | Реакция |
|---|---|---|
| Галлюцинация | RAG, ограничения промпта, проверка источников | Не отвечать уверенно; передать оператору |
| Утечка ПДн | Минимизация, маскирование, RBAC, журнал доступа | Блокировка сессии и расследование |
| Prompt injection | Изоляция инструкций и данных, allowlist инструментов | Отклонить действие, записать событие |
| Ошибочное действие | Подтверждение, лимиты, идемпотентность | Компенсирующая операция или откат |
| Зависимость от провайдера | Абстракция модели, резервный маршрут | Переключение на резервную модель |
| Рост расходов | Бюджеты, кэширование, модельная маршрутизация | Ограничение или деградация функции |
10. Экономика AI-решения
Экономика оценивается на уровне полного сценария. В расчёт входят модель, embeddings, reranker, хранение, интеграции, наблюдаемость, инфраструктура, поддержка и экспертная проверка. Дешёвая модель может увеличить общую стоимость, если создаёт больше повторных обращений и ручных исправлений.
| Показатель | Формула или смысл |
|---|---|
| Стоимость сценария | Сумма всех вызовов моделей, поиска, инструментов и инфраструктуры |
| Стоимость успешного результата | Общие расходы / число корректно завершённых сценариев |
| Экономия времени | Сокращённые часы × полная стоимость часа сотрудника |
| Дополнительный доход | Изменение конверсии × число лидов × маржинальный доход |
| ROI | (Эффект − затраты) / затраты × 100% |
| Срок окупаемости | Первоначальные вложения / ежемесячный чистый эффект |
11. Сквозной пример: AutoSfera AI
11.1. Целевая архитектура
AutoSfera AI целесообразно строить как единую платформу с общей точкой входа и независимыми бизнес-модулями. Главный оркестратор определяет направление, проверяет контекст и передаёт запрос соответствующему sub-workflow.
| Компонент | Функция |
|---|---|
| Главный оркестратор | Идентификация, классификация намерения, маршрутизация, общие политики |
| Ассистент продаж | Квалификация лида, подбор автомобиля, ответы по комплектациям, CRM |
| Ассистент сервиса | Определение услуги, поиск слота, запись, подтверждение и напоминание |
| Внутренний ассистент | Поиск регламентов, инструкций и корпоративных знаний с RBAC |
| RAG-платформа | Каталог, комплектации, сервисные правила, внутренние документы |
| Интеграционный слой n8n | CRM, Telegram, уведомления, календарь, внешние API |
| Langflow / LLM-слой | Анализ запроса, retrieval-цепочки, генерация ответа |
| Контур контроля | Логи, трассировка, метрики, eval, алерты, handoff оператору |
11.2. Рекомендуемый порядок реализации
- Утвердить единый контракт входных и выходных данных.
- Собрать главный оркестратор с маршрутизацией без генерации ответов.
- Реализовать ассистента продаж как первый сквозной MVP.
- Подключить утверждённую базу знаний и оценить retrieval отдельно от генерации.
- Добавить CRM-действия через n8n с подтверждением и идемпотентностью.
- Настроить журналирование, алерты и передачу менеджеру.
- После прохождения evaluation-набора добавить модуль сервиса.
- Последним подключить внутреннего ассистента с ролевым доступом к документам.
11.3. Минимальный формат сообщения
| Направление | Обязательные поля |
|---|---|
| Вход | request_id, channel, user_id, tenant_id, message, timestamp, consent, context |
| Маршрутизация | intent, confidence, target_workflow, escalation_reason |
| Выход | status, answer, sources, actions, next_step, escalation, error |
| Аудит | model, prompt_version, knowledge_version, latency, token_cost, trace_id |
12. Практические шаблоны
12.1. Паспорт AI-сценария
| Поле | Заполняемое содержание |
|---|---|
| Название сценария | |
| Владелец процесса | |
| Пользователь и канал | |
| Проблема и ожидаемый результат | |
| Входные данные | |
| Источники знаний | |
| Разрешённые действия | |
| Запрещённые действия | |
| Условия передачи человеку | |
| Primary-метрика | |
| Guard-метрики | |
| Критерий готовности к пилоту |
12.2. Карточка архитектурного решения ADR
- Контекст: какая проблема и ограничения привели к решению.
- Решение: что именно выбрано.
- Альтернативы: какие варианты рассматривались.
- Обоснование: почему выбранный вариант лучше в данном контексте.
- Последствия: новые риски, стоимость и обязательства.
- Статус и дата пересмотра: proposed, accepted, superseded.
12.3. Чек-лист готовности к запуску
| Область | Контрольный вопрос |
|---|---|
| Ценность | Метрика результата определена и имеет исходное значение? |
| Данные | Источники утверждены, версии и владельцы назначены? |
| Качество | Evaluation-набор пройден, критические ошибки отсутствуют? |
| Безопасность | Права, ПДн, секреты и журналирование проверены? |
| Надёжность | Настроены таймауты, retries, fallback и handoff? |
| Экономика | Известна стоимость успешного сценария и лимиты бюджета? |
| Эксплуатация | Есть мониторинг, алерты, ответственные и план отката? |
| Изменения | Модели, промпты и знания версионируются? |
13. Типичные ошибки
| Ошибка | Почему опасно | Правильное действие |
|---|---|---|
| Начать с выбора модели | Технология подменяет бизнес-задачу | Сначала определить пользователя, действие и метрику |
| Сделать один огромный workflow | Изменения ломают несвязанные функции | Разделить на оркестратор и независимые модули |
| Оценивать по красивым ответам | Не видны редкие и критические ошибки | Создать фиксированный evaluation-набор |
| Разрешить агенту все инструменты | Ошибка модели превращается в реальное действие | Минимальные права и подтверждение |
| Загрузить документы без владельцев | База знаний быстро устаревает | Версии, метаданные и цикл пересмотра |
| Не считать эксплуатацию | MVP оказывается экономически нежизнеспособным | Считать полный пользовательский сценарий |
| Запускать без handoff | Система удерживает запрос, который не понимает | Явные условия передачи человеку |
Заключение
Успешное AI-решение создаётся не вокруг одной модели, а вокруг управляемого процесса принятия решений. Сильная архитектура связывает бизнес-цель, данные, модели, инструменты, безопасность, экономику и ответственность команды. Она предусматривает ошибки и делает их обнаруживаемыми, ограниченными и исправимыми.
Для AutoSfera AI практический приоритет — единый оркестратор, три независимых бизнес-модуля, управляемая RAG-база, n8n для внешних действий, LLM-слой для анализа и генерации, а также обязательный контур оценки и передачи оператору. Такой подход позволяет начинать с небольшого MVP и развивать платформу без переписывания всей системы.
Список литературы и источников
1. Huyen, Chip. AI Engineering: Building Applications with Foundation Models. O’Reilly Media, 2024. Источник
2. Huyen, Chip. Designing Machine Learning Systems. O’Reilly Media, 2022. Источник
3. Alto, Valentina. Building LLM Powered Applications. Packt Publishing, 2024. Источник
4. Lakshmanan, V.; Robinson, S.; Munn, M. Machine Learning Design Patterns. O’Reilly Media, 2020. Источник
5. Kleppmann, Martin. Designing Data-Intensive Applications. O’Reilly Media, 2017. Источник
6. Skelton, Matthew; Pais, Manuel. Team Topologies. 2nd edition, 2025. Источник
7. Lewis, Patrick et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS, 2020. Источник
8. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. Источник
9. NIST. Artificial Intelligence Risk Management Framework: Generative AI Profile, 2024. Источник
10. Thoughtworks. Emerging Patterns in Building GenAI Products. Источник
Приложение. Контрольные вопросы
- Какой измеримый бизнес-результат должен создать AI-сценарий?
- Какие части процесса требуют AI, а какие лучше оставить детерминированными?
- Какие данные являются источником истины и кто отвечает за их актуальность?
- Как система ведёт себя при отсутствии ответа или низкой уверенности?
- Какие действия требуют подтверждения пользователя или оператора?
- Как проверяется качество поиска отдельно от качества генерации?
- Какие логи и метрики нужны для воспроизведения ошибки?
- Сколько стоит один успешно завершённый сценарий?
- Как выполнить откат модели, промпта или базы знаний?
- Кто имеет право принять решение о промышленном запуске?
