# Дефицит навыков ИИ начинается с инженерного мышления

> Как закрыть дефицит навыков ИИ: практический порядок обучения инженеров на основе вакансий и реалистичных сроков освоения.

Дефицит навыков ИИ не так велик, как можно подумать по каталогам курсов. Большинству работающих инженеров не нужно становиться исследователями. Им нужно подключать модели к реальным программным системам, измерять качество результата, ограничивать сбои и объяснять владельцу продукта принятые компромиссы.

Вакансии подтверждают такой порядок. В отчете Stanford AI Index за 2026 год, который опирается на данные Lightcast по вакансиям в США за 2025 год, в десятку самых востребованных специальных навыков для работы с ИИ вошли Python, информатика, масштабирование, автоматизация, управление рабочими процессами, анализ данных, SQL, управление проектами, data science и Amazon Web Services. Список гораздо прозаичнее, чем кажется по публикациям в соцсетях.

Те же данные показывают быстрый рост спроса на большие языковые модели, генерацию с дополнением из найденных данных, промпт-инжиниринг и агентные системы. Рост имеет значение, но фундамент от этого не становится необязательным. Я скорее найму инженера, который умеет по журналам и тестам найти причину плохого результата поиска, чем человека, прошедшего пять учебных курсов по фреймворкам для агентов.

Порядок обучения ниже учитывает три фактора: частоту навыка в вакансиях, технические зависимости и время до самостоятельной работы. Сроки рассчитаны на работающего разработчика, который может выделять восемь-десять часов сосредоточенной работы в неделю. Это мои практические оценки, а не заявления Lightcast или Stanford.

## Данные вакансий требуют изучать весь стек, а не модный термин

По данным найма работодателям нужны возможности ИИ внутри обычных программных систем. Из них не следует, что каждый инженер должен обучать базовую модель.

В таблице Stanford AI Index Python встречался в 258 674 американских вакансиях с навыками ИИ за 2025 год. Информатика шла почти следом с 257 127 вакансиями. Масштабирование упоминалось в 197 744 вакансиях, автоматизация в 190 758, управление рабочими процессами в 186 325, анализ данных в 170 396, а SQL в 151 191. Эти числа пересекаются, потому что одна вакансия может требовать несколько навыков. Они описывают сочетания требований, а не отдельные рабочие места.

Новые термины значимы, но встречаются реже. Генеративный ИИ упомянут в 138 188 вакансиях, большие языковые модели в 38 526, промпт-инжиниринг в 22 227, а генерация с дополнением из найденных данных в 12 609. Контекстная инженерия выросла с 9 упоминаний в 2024 году до 703 в 2025-м. Последний процент роста выглядит впечатляюще, но 703 вакансии не должны ставить этот навык выше Python в учебном плане. Процент роста показывает движение, а число вакансий показывает текущую широту спроса. Ни одна из этих величин не определяет техническую очередность обучения.

Агентная терминология тоже быстро распространилась. В отчете насчитали 15 217 упоминаний agentic AI, 14 376 упоминаний AI agents и 4 294 упоминания LangGraph в 2025 году. Авторы при этом заметили переход от общего знакомства с чат-инструментами к координации и эксплуатации систем, выполняющих конкретные задачи. Толкование полезное: работодателям все важнее, умеет ли инженер заставить модель выполнять работу в заданных границах.

Indeed Hiring Lab предупреждает, что ключевые слова нельзя понимать буквально. При анализе нескольких сотен тысяч вакансий, опубликованных с июля 2024 года по июнь 2025 года, примерно в четверти объявлений с упоминанием ИИ не нашлось ясного объяснения, как работодатель собирается его применять. Общие термины про ИИ встречались часто, названия конкретных продуктов редко. Вакансия может показывать спрос, а может показывать, что нанимающий руководитель еще не определился с самой работой.

Я ставлю навык выше, если он широко востребован, нужен для освоения нескольких следующих навыков и его можно подтвердить работой, похожей на производственную. На первом месте остается разработка и отладка программ, которые уже должны быть знакомы инженеру. Затем идут Python, API, SQL и обработка данных. На рабочий уровень в этом блоке требуется от двух до четырех недель, а доказательством станет типизированный API с моделью и сохраненной историей запусков.

Поведение модели, структурированный вывод и оценка качества займут еще две-три недели. На поиск и проектирование контекста уйдет две-четыре. Инструменты и ограниченные агенты потребуют трех-шести недель, затем еще три-шесть уйдут на эксплуатацию, стоимость и безопасность. Каждый срок заканчивается видимым результатом: версионированным набором проверок, измеренным поиском, восстанавливаемым рабочим процессом или учебным разбором инцидента.

Обучение моделей и продвинутое машинное обучение идут по отдельной траектории длиной от трех до шести месяцев. Там подтверждением навыка станет проект обучения или дообучения под конкретную роль, а не очередная обертка над API.

Эти блоки пересекаются. За шестинедельный проект можно затронуть первые шесть, однако для самостоятельных решений нужно больше времени, чем для знакомства. Тот, кто один раз вызвал API модели, начал учиться, но еще не достиг рабочего уровня.

## Первый приоритет все еще принадлежит программной инженерии

Прежде чем специализироваться на ИИ, инженер должен устранить пробелы в тестировании, отладке, контроле версий, HTTP, параллельной работе и проектировании систем. Модели добавляют в программы неопределенность. Они не оправдывают слабую разработку.

Этот совет раздражает, потому что звучит не так ново, как промпт-инжиниринг. Зато он совпадает с данными вакансий. Информатика, масштабирование, автоматизация, управление рабочими процессами и управление проектами входят в число самых востребованных специальных навыков в вакансиях с ИИ. Работодатели описывают выпуск систем с ИИ, а не отдельную лабораторию моделей.

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

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

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

Опытный инженер часто получает здесь преимущество перед недавним выпускником программы по машинному обучению. Опытный специалист уже знает, как разрушаются производственные системы: меняются входные данные, зависимости не отвечают вовремя, права расползаются, а недокументированное поведение превращается в API. Теперь эту настороженность нужно применить к ответам модели.

## Второй приоритет охватывает Python, API, SQL и данные

Освойте Python, интеграцию через API, SQL и обработку данных настолько, чтобы собрать небольшой сервис без копирования учебной архитектуры. Этот блок пользуется самым широким спросом и нужен для всех следующих этапов.

Python возглавляет список Stanford и Lightcast, а SQL и анализ данных тоже входят в первую десятку. Такое сочетание говорит больше, чем число упоминаний любого отдельного фреймворка. Работодатель ожидает, что ИИ-инженер передаст данные модели, проверит результат, сохранит историю и найдет сбои запросом. JavaScript и другие языки подходят для продуктовой разработки, но Python дает самый короткий путь к SDK моделей, библиотекам оценки, ноутбукам и инструментам данных.

Работающему инженеру хватит двух-четырех недель по восемь-десять часов, чтобы выйти на практический уровень, но не стать мастером. Изучите аннотации типов, классы данных или модели валидации, виртуальные окружения, асинхронный HTTP, обработку исключений, pytest и основы упаковки. Для данных отработайте соединения таблиц, оконные функции, поля JSON, индексы и миграции. Вы должны уметь объяснить, почему запрос работает медленно и почему схема допускает недопустимое состояние.

Соберите один узкий артефакт: API принимает обращение в поддержку, просит модель определить категорию и уверенность, проверяет структурированный ответ, сохраняет запрос с результатом и позволяет найти запуски с низкой уверенностью. В тестах подставляйте фиктивный или локальный ответ модели. Вызов поставщика спрячьте за интерфейсом, чтобы набор тестов не тратил деньги и не зависел от сети.

Минимальный контракт результата может выглядеть так:

```yaml
ticket_id: t_1842
model_version: provider-model-2026-01
prompt_version: triage-v3
category: billing
confidence: 0.74
needs_review: true
latency_ms: 842
input_tokens: 611
output_tokens: 47
```

Поля заставляют задавать полезные вопросы. Кто назначил версии модели и промпта? При каком пороге уверенности нужна проверка человеком? Можно ли воспроизвести входные данные? Число токенов взято из ответа поставщика или рассчитано приблизительно? Как долго хранится текст обращения? Учебник, который возвращает одну строку, обходит все эти решения, поэтому завершенный урок почти ничего не говорит о рабочем уровне.

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

## Третий приоритет делает поведение модели проверяемым

Изучайте промпты, сборку контекста, структурированный вывод и оценку одним блоком, потому что промпт не имеет профессиональной ценности без способа проверить ответ. Опытному инженеру хватит двух-трех сосредоточенных недель, чтобы приобрести полезный навык.

Рынок явно требует эту работу. Lightcast насчитал 22 227 упоминаний промпт-инжиниринга в 2025 году, что на 261 процент больше, чем в 2024-м. В отчете LinkedIn о рынке труда за 2026 год говорится, что число вакансий в США с требованием грамотности в ИИ, включая промпт-инжиниринг, выросло за год на 70 процентов. Эти цифры оправдывают изучение навыка, но не карьеру, построенную только на формулировке промптов.

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

Полезная запись проверки скучна и однозначна:

```yaml
case_id: refund-policy-ambiguous-07
input_fixture: fixtures/refund_07.txt
expected:
  action: escalate
  forbidden_claims:
    - refund_approved
checks:
  schema_valid: true
  action_match: true
  forbidden_claims_present: false
reviewer_note: Policy date is missing, so the model must not decide.
```

Запускайте набор после каждого изменения промпта, модели, метода поиска или определения инструмента. Считайте долю успешных проверок по категориям, а не одним общим числом. Общий результат в 95 процентов может скрыть полный провал небольшой категории с юридическим или финансовым риском. Оставьте проверку человеком для суждений, которые нельзя оценить детерминированно, и записывайте разногласия между проверяющими.

Специалисты часто смешивают три разных вида проверки. Модульные тесты проверяют детерминированную часть программы. Оценочные наборы измеряют поведение модели на выбранных примерах. Производственный мониторинг следит за реальным трафиком после выпуска. Один вид не заменяет другой. Если называть все три evals, кто-нибудь решит, что предрелизный набор защищает производственную систему, и пропустит изменение реального распределения входных данных.

Рабочий уровень означает, что вы готовы отказаться от любимого промпта, если результаты по категориям ухудшились. Такая привычка полезнее для работодателя, чем запоминание фраз вроде «думай шаг за шагом», которые для текущей модели и задачи могут оказаться бесполезными или вредными.

## Четвертый приоритет ставит поиск перед агентами

Изучите поиск до автономных рабочих процессов, потому что многие предполагаемые ошибки рассуждения на деле вызваны отсутствием нужных фактов. Генерация с дополнением из найденных данных, или RAG, также дает понятную границу для измерения системы.

В отчете Stanford RAG упоминался в 12 609 американских вакансиях с ИИ за 2025 год, рост составил 337 процентов относительно 2024 года. Абсолютное число уступает Python и общим навыкам работы с моделями, однако поиск уже достаточно распространен, чтобы занять раннее место в плане прикладного инженера. Если вы знакомы с базами данных и API, отведите две-четыре недели на рабочий уровень.

Изучите разбор документов, границы фрагментов, метаданные, эмбеддинги, лексический и векторный поиск, повторное ранжирование и привязку цитат. Не начинайте с выбора векторной базы данных. Начните с вопросов пользователей и свидетельств, которые должен содержать приемлемый ответ. Обычное хранилище SQL с полнотекстовым поиском может обойти более сложный стек на небольшом структурированном корпусе.

Измеряйте поиск отдельно от генерации ответа. Для каждого тестового вопроса укажите документы или фрагменты, которые должны найтись. Проверьте, попали ли ожидаемые свидетельства в первые результаты, разберите ложные совпадения и протестируйте фильтры прав доступа. Затем оцените, остается ли ответ в границах найденных данных. Такое разделение покажет, что именно менять: поисковый запрос, корпус, ранжирование, промпт или модель.

Разберем типичный сбой. Компания делит справочник сотрудников на фрагменты фиксированной длины и выбрасывает метаданные документов. Сотрудник спрашивает об отпуске по уходу за ребенком в Калифорнии. Поиск ставит общий обзор отпусков выше дополнения для Калифорнии, а модель дает складный, но неполный ответ. Команда правит промпт, получает лучший ответ на один вопрос и выпускает функцию. Следующий региональный запрос снова дает ошибку, потому что поисковый слой все еще не учитывает юрисдикцию и дату вступления в силу. Исправлять нужно метаданные, фильтры и тесты, а не силу формулировки инструкции.

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

## Пятый приоритет удерживает агентов в границах

Изучайте агентные системы после оценки и поиска, а агента считайте рабочим процессом, в котором модель выбирает одно из ограниченных действий. Спрос на навык быстро растет, но фреймворки следует осваивать после проектирования контроля.

В AI Index за 2026 год указано 15 217 упоминаний agentic AI и 14 376 упоминаний AI agents в американских вакансиях с ИИ за 2025 год. LangGraph упомянут 4 294 раза. Эти термины росли гораздо быстрее старых базовых значений, а отчет объясняет перемену спросом на координацию и эксплуатацию систем для конкретных задач. Поэтому агентов уже стоит изучать. Но выдавать модели широкие права и надеяться на цикл фреймворка по-прежнему нельзя.

Отведите три-шесть недель, чтобы хорошо собрать одного ограниченного агента. Изучите схемы инструментов, конечные автоматы, пределы планирования, долговечные контрольные точки, подтверждение человеком, идемпотентные действия и компенсацию частичного сбоя. Задайте максимальное число шагов и бюджет стоимости. Каждому инструменту выдавайте минимальные права. Разделите инструменты чтения и записи, а для перевода денег, публикации, удаления данных или контакта с клиентом требуйте решения человека.

Представим агента, который напоминает об оплате счета. Он читает учетную запись, готовит письмо и ставит напоминание. Первые две попытки проходят нормально. На третьей API почты принимает сообщение, но не успевает вернуть успех до тайм-аута. Агент повторяет вызов и отправляет дубликат, затем создает два напоминания, потому что и у этого инструмента нет токена идемпотентности. Красивый журнал рассуждений проблему не решает. Нужны стабильные идентификаторы действий, сохраненное состояние и сверка результатов.

Учебники по фреймворкам обычно показывают удачный цикл: модель, инструмент, наблюдение, повтор. Производственная компетентность начинается после этой схемы. Что произойдет после перезапуска процесса? Видит ли оператор ожидающие действия? Может ли агент продолжить работу без повтора завершенных шагов? Какие входные данные пришли из недоверенного документа? Может ли вредоносная инструкция в найденном файле вызвать инструмент записи?

Соберите проект на одном фреймворке, если он экономит время, затем нарисуйте рабочий процесс без терминов этого фреймворка. Если вы не можете объяснить на доске состояния, переходы, сохраненные данные и границы полномочий, вы знаете библиотеку, а не систему.

## Шестой приоритет посвящен производственному контролю

Изучите контроль стоимости, задержку, трассировку, безопасность, конфиденциальность и работу с инцидентами, прежде чем считать себя готовым к производственной системе. Функции с ИИ превращают поведение модели в операционную зависимость, а вакансии все чаще соединяют ИИ с масштабированием, автоматизацией, рабочими процессами и облачными навыками.

Отведите три-шесть недель, чтобы добавить производственный контроль в существующий проект. Записывайте название модели, версию промпта, версию поиска, вызовы инструментов, задержку, число токенов, ошибки валидации, отказы и исправления человека. Не записывайте чувствительные входные данные по умолчанию. Храните ссылки или очищенные образцы, если полный текст создает риск для приватности или безопасности.

Установите бюджеты на нескольких уровнях: на запрос, пользователя или клиента, день и рабочий процесс. Ограничение стоимости также останавливает зацикливание. Добавьте тайм-ауты и запасные варианты на случай отказа поставщика. Решите, должна ли система поставить запрос в очередь, взять меньшую модель, вернуть частичный результат или остановиться. Это часть продуктового контракта, а не обработчик исключения, написанный во время аварии.

Безопасность включает обычный контроль приложений и особые границы моделей. Считайте найденный текст, загрузки пользователей, веб-содержимое и ответы инструментов недоверенными. Не храните системные инструкции там, где пользователь может их менять. Проверяйте каждый аргумент инструмента программно. Разрешайте итоговое действие по правам текущего пользователя, а не по утверждению модели о пользователе. Меняйте секреты и сужайте права служебных учетных записей. Проверьте, может ли косвенная инъекция промпта перейти из документа в действие записи.

Нужна и учебная авария. Принудительно вызовите тайм-аут поставщика, испорченный структурированный ответ, отказ поиска, превышение бюджета токенов и неоднозначный результат инструмента. Убедитесь, что пользователь видит честное состояние, оператор находит трассу, а повторная попытка не дублирует побочные эффекты. Такое упражнение находит больше реальных дефектов, чем еще один день сравнения моделей по рейтингам.

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

## Обучение моделей требует отдельной траектории

Большинству прикладных инженеров следует отложить обучение моделей, пока этого не потребует выбранная роль или продуктовая задача. Машинное обучение остается крупной группой навыков в вакансиях, но прикладная инженерия и инженерия моделей идут разными путями с общим фундаментом.

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

Выбирайте прикладной путь, если роль делает упор на API, RAG, агентов, оценку, интеграцию в продукт, облачное развертывание или автоматизацию процессов. Вам все равно нужна базовая грамотность в машинном обучении: переобучение, точность и полнота, калибровка, дрейф и причины, по которым оценочная выборка может обмануть. Но выводить формулу обратного распространения ошибки перед выпуском надежного помощника по документам не требуется.

Дообучение находится между двумя путями, и команды назначают его слишком рано. Часто к нему обращаются, когда системе не хватает контекста, метки противоречат друг другу, схема ответа слаба или набора оценок вообще нет. Дообучение может изменить поведение или закрепить повторяющийся формат. Оно не даст модели актуальные закрытые факты, если процесс обучения и график обновлений не рассчитаны на такую задачу. Сначала докажите ограничение оценками, затем платите за конвейер обучения.

Разница особенно важна при чтении вакансий. Название AI engineer может скрывать роль интегратора серверной части, инженера ML-платформы или прикладного исследователя. Не смотрите на название, классифицируйте глаголы. «Собирать», «интегрировать», «развертывать» и «наблюдать» обычно указывают на прикладную работу. «Обучать», «оптимизировать», «исследовать» и «публиковать» указывают на модели. Откликайтесь, если ваш опыт подтверждает большую часть настоящей работы, даже когда вы не знаете все существительные в требованиях.

## Шесть недель обучения должны оставить доказательства

Хороший план обучения заканчивается системой и журналом ее сбоев, а не папкой сертификатов. Опытному инженеру хватит шести недель, чтобы собрать убедительные доказательства по прикладной траектории, хотя полностью освоить все блоки за этот срок нельзя.

1. На первой неделе соберите типизированный API на Python и слой хранения. Добавьте детерминированные тесты, структурированный вывод модели, фиктивного поставщика и записи запусков. Напишите короткую архитектурную заметку о сбоях, за которые отвечает API.
2. На второй неделе создайте 30-50 оценочных примеров в категориях обычных, двусмысленных, враждебных запросов и передачи решения человеку. Версионируйте промпт, проведите базовый запуск и запишите три крупнейшие группы сбоев.
3. На третьей и четвертой неделях добавьте небольшой корпус документов, фильтры метаданных, гибридный поиск и цитаты. Оценивайте поиск до ответов. Включите проверку прав, где пользователь не должен найти документ другой группы.
4. На пятой неделе добавьте два инструмента чтения и один обратимый инструмент записи. Сохраняйте состояние процесса, требуйте подтверждения записи, ограничьте число шагов и смоделируйте неоднозначный ответ инструмента.
5. На шестой неделе добавьте бюджеты стоимости и задержки, очищенную трассировку, конвейер выпуска и учебную аварию. Опубликуйте короткое описание проекта с таблицей оценок до и после и решениями, от которых вы отказались.

Не раздувайте проект. Достаточно помощника по сортировке обращений, сервиса ответов по правилам или внутреннего составителя заметок к релизу. Не делайте универсального личного ассистента. Узкая задача дает четкие права, уместные оценочные примеры и правдоподобного пользователя.

В описании проекта укажите размер корпуса, категории тестов, версии модели и промпта, метод поиска, пороги, распределение задержки, предположения о стоимости и известные сбои. Никогда не включайте закрытые данные работодателя. Синтетические примеры подходят, если вы честно их описали и сделали сбои реалистичными.

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

Team & AI Audit применяет ту же логику доказательств в масштабе компании: находит работу, которую ИИ может снять с инженеров, места без достаточного контроля и изменения, где ожидаемая экономия не оправдывает затраты. Для отдельного инженера эквивалентом станет безжалостное ограничение портфолио. Соберите самую маленькую систему, которая доказывает, что вы умеете судить о качестве, полномочиях, стоимости и сбоях.

## Компетентность начинается с самостоятельных компромиссов

Затраченное время помогает только планировать. Компетентный инженер выдает ограниченный результат, замечает ошибку и выбирает следующее техническое действие без подсказки автора учебника.

Примените четыре проверки. Сможете ли вы снова собрать функцию с другой моделью или фреймворком? Можете ли до выпуска предсказать хотя бы пять категорий сбоев? Показываете ли вы оценки и производственные свидетельства вместо рассказа о впечатлениях от демонстрации? Можете ли объяснить, какое действие система никогда не должна выполнять автоматически? Если хотя бы один ответ отрицательный, оставьте проект в учебной среде.

Данные вакансий меняются, а терминология движется еще быстрее. Устойчивая последовательность меньше зависит от обоих факторов: разработка программ, данные и API, измеримое поведение модели, поиск, ограниченное применение инструментов и производственный контроль. Новые фреймворки займут место внутри этой последовательности. Они ее не отменят.

Не ждите полного совпадения с текстом вакансии. Выберите десять должностей, на которые действительно согласились бы, выпишите повторяющиеся глаголы и навыки, затем сопоставьте их с уже имеющимися или доступными для создания доказательствами. Если Python встречается в восьми вакансиях, а обучение моделей в одной, приоритет очевиден. Если в каждой роли нужны проектирование экспериментов и PyTorch, переходите на траекторию моделей и принимайте более долгий срок подготовки.

Дефицит закрывает не тот инженер, у которого длиннее список инструментов. Его закрывает специалист, способный поместить модель в контролируемую систему, показать места отказа и улучшить правильный слой.