Прикладная AI-инженерия для production: маршрут на восемь недель¶
English · Русский · Учебный маршрут · Engineering
Маршрут помогает опытным разработчикам объяснять устройство и эксплуатацию ограниченного сервиса вокруг модели. Он входит в AI Engineering вместе с AI-ассистированным кодингом. Существующий восьминедельный план остаётся широкой базой, включая attention, обучение и специализации. Здесь акцент на контрактах, оценке и эксплуатационных решениях.
Планируйте восемь недель по 6–8 часов — редакционная оценка, а не измеренный срок подготовки. Нужны знания небольших сервисов, HTTP-сбоев, асинхронности, БД и отложенной оценки; пробелы закрывайте через базовый маршрут. Сейчас требуются вопросы, чтение, объяснения и чеклисты. Python-лабораторные, реализация сервиса и AI-оценщик отложены по текущему решению сопровождающего. Завершение не подтверждает готовность к production и не предсказывает найм.
Один концептуальный кейс¶
Рассмотрите помощника для вымышленного каталога обслуживания оборудования. Он отвечал бы по версионированным инструкциям и предлагал заявку на обслуживание. У двух вымышленных групп разный доступ к документам. Разберите запросы с ответом, без оснований и без доступа; создавать датасет, аккаунт модели, API-ключ или работающий сервис не нужно. Редакционные уточнения находятся вне банка опубликованных и созданных по радару вопросов.
Явно задайте границы проекта: запрос модели сам не разрешает действие; запрещённый документ не даёт оснований для ответа; предусмотрены недостаточность данных, владелец релиза и лимит времени, расхода и повторов. Отличайте обещание архитектуры от того, что подтвердит лишь выполненная проверка. Читайте первичные материалы у связанных вопросов, затем используйте ответы как один обоснованный подход, а не заученный сценарий.
Восемь модулей¶
Отведите 1–1½ часа на чтение, 3–4 часа на разбор вопросов и короткую записку с решением, 1 час на устное объяснение и 1–1½ часа на обратную связь и отложенные повторы. Оценка и контроль доступа начинаются с первого модуля.
| Неделя | Вопросы и чтение | Чеклист объяснения и отказной случай |
|---|---|---|
| 1 — задача и baseline | Какой результат оправдывает AI? Что уже даёт ручной или лексический поиск? Прочитайте system design, основы и обработку документов. | Назовите пользователей, доступные документы, успех, критическую ошибку и причину остановки. Различайте наличие ответа, отсутствие оснований и запрет доступа. Миллион обработанных объектов не доказывает полезность или корректность. |
| 2 — модели и контракты | Как сравнить конфигурации на одной задаче и бюджете? Кто проверяет и исполняет вызов? Прочитайте structured outputs и выбор метода. | Объясните корректный, неверный по формату, отказной и усечённый ответы, неизвестный ID свидетельства и запрещённый вызов с валидной схемой. Назовите предел восстановления и видимый окончательный отказ. |
| 3 — оценка | Как оценить задачу без единственного эталона? Прочитайте дефицит разметки, оценку агентов и production-действия. | Разделите сбои поиска, ответа, контракта и действия. Предложите отложенный набор, повторные попытки и экспертный разбор. Объясните, почему синтетика не даёт реальную частоту ошибок, а некалиброванный модельный судья не разрешает релиз. |
| 4 — поиск и контекст | Когда сложность поиска оправдана? Прочитайте RAG и свежесть индекса. | Сравните лексический поиск с одной альтернативой через план проверки релевантности, оснований и задержки. Проследите точный ID, устаревшую инструкцию, удаление и отзыв доступа через поиск, кеш и ответ. Атомарная смена alias сама не проверяет полномочия. |
| 5 — инструменты и исполнение | Как workflow останавливается и восстанавливается? Прочитайте повторы, подмену цели и MCP security. | Опишите разрешённые переходы и исходы для неизвестного инструмента, неверных аргументов, запрета, таймаута и лимита шагов. После таймаута записи сначала сверяют результат по ID операции, затем решают о повторе. |
| 6 — эксплуатация и стоимость | Что нужно для трассы и отката? Прочитайте экономику инференса, откат конфигурации и мониторинг SRE. | Назовите версии, длительность, расход, статус и категорию ошибки; исключите лишнее чувствительное содержимое. Учтите неудачные попытки в стоимости успеха. Объясните таймаут, ограничение конкурентности, fallback и зависимость, способную сорвать откат. Отмечайте оценки. |
| 7 — безопасность и релиз | Какой вход влияет на план, но не получает полномочий? Прочитайте OWASP prompt injection, безопасность и release gates. | Проследите инструкцию в документе с запросом чужих данных или действия. Проверять права должно приложение. Критический сбой доступа блокирует релиз при росте среднего качества; назовите владельца, остановку и откат. |
| 8 — итоговая защита | Защитите baseline, архитектуру и непроверенное через прикладные сценарии. Уменьшите бюджет вдвое, уберите провайдера или отзовите документ. | Представьте схему, план оценки и чеклист релиза. Объясните повторные проверки, отвергнутую альтернативу и слабейшее допущение. Итог — защита проекта; реализация остаётся отложенной. |
Четыре важных различия¶
Формат и смысл. Схема не доказывает фактическую или бизнес-корректность. Поведение зависит от версии провайдера: документация Claude описывает исключения для отказа, лимита токенов и регистра enum. Проверяйте завершение и правила приложения; не повторяйте бесконечно.
Повторяемые проверки и переменные результаты. Фиксированный набор не делает ответы и оценщиков детерминированными. Материал Anthropic рассматривает типы оценщиков и калибровку. Объясните повторы, разногласие и тяжесть ошибок; рост среднего не отменяет утечку доступа.
Фильтрация и полномочия. Очистка входа сама не создаёт границу безопасности. OWASP описывает минимальные права и отделение внешнего содержимого. Авторизация находится в приложении и охватывает поиск, инструменты, кеши и логи.
Протокол и доверие. MCP стандартизирует интеграцию, но не делает сервер и инструменты доверенными. Датированное руководство рассматривает аудиторию токена, согласие, SSRF и риски локальных серверов. Назовите источник полномочий, ресурсы и отзыв. Схемы одного протокола недостаточно.
Завершение и границы¶
Используйте существующую шкалу 0–3. Объяснение модуля и отложенная попытка требуют не менее 2: самостоятельный механизм, допущения, компромисс и подходящая проверка. Балл 3 включает изменение ограничения и отказной случай. При 0–1 нужен повторный разбор; критическая ошибка корректности или доступа блокирует переход независимо от среднего. Повторите примерно через два дня и на следующей неделе, записывая дату, обратную связь и следующий слабый пункт.
Текущий маршрут можно пройти без модели. Это показывает рассуждение, а не измеренное качество, задержку, отказы модели или устойчивость к инъекции. Будущая реализация могла бы использовать синтетические данные и детерминированные заглушки без API-ключей; даже их успешные тесты подтвердили бы лишь управление потоком, не качество живой модели. Не заявляйте невыполненных проверок. Источники и границы доступа — в исследовании Engineering, отложенная реализация — в плане расширения.