Метод и машина

Можно ли поручить LLM подготовку инженерной лекции?

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

🔎 Но довольно быстро возникает другой вопрос: можно ли преподавателю просто принять полученный материал и идти с ним в аудиторию?

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

Например, хорошая экспериментальная визуализация реальных микроконтактов была получена не для пары «колесо–рельс», а в модельной системе: шероховатая полимерная сфера — стеклянная поверхность.

Для объяснения физики контакта такой материал полезен. Но если показать его студентам как непосредственное доказательство процессов в контакте «колесо–рельс», смысл уже будет другим.

⚠️ То же самое относится к формулам, нормативам и интерактивным моделям. Красивая анимация ещё не становится расчётной моделью. Старая цифра из методички не становится действующим нормативом. А подходящая по смыслу научная иллюстрация не обязательно описывает именно тот объект, о котором идёт речь на лекции.

📌 Поэтому моя рабочая схема сейчас выглядит примерно так:

источник → что он действительно показывает → где применим → как объяснить студенту → что обязательно оговорить

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

👤 Именно поэтому я бы не поручил LLM «сделать инженерную лекцию». Я бы поручил ему помочь её собрать — при условии, что преподаватель остаётся редактором и предметным экспертом.

Я не разработчик ИИ. Тогда почему веду канал про него?

Я не занимаюсь разработкой нейросетей, не обучаю большие языковые модели и не работаю Data Scientist.

По основной профессии я инженер, исследователь и преподаватель.

И именно поэтому мне интересно работать с ИИ.

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

При этом почти каждый раз повторяется одна и та же ситуация.

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

Но почти никогда этого недостаточно.

⚙️ Нужно поставить задачу, задать требования, понять, что именно получилось, проверить результат и решить, можно ли его вообще использовать дальше.

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

Иногда наоборот: проверка и исправление результата съедают значительную часть экономии.

А иногда работа останавливается вообще не из-за качества ИИ, а потому что недоступен сам сервис или зависимый от него инструмент.

📌 Поэтому этот канал не про то, как устроен искусственный интеллект.

Он про другое:

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

Где это действительно помогает.
Где снижает трудоёмкость.
Где создаёт новые ошибки и зависимости.
Что нужно проверять.
И какие решения всё равно должны оставаться за человеком.

🛠 В работе используются разные инструменты — ChatGPT, Codex, модели машинного обучения, Cursor, сервисы автоматизации, Google Workspace и другие. Но сам по себе выбор сервиса для меня вторичен.

Главное — что именно я ему поручаю, как проверяю результат и даёт ли это реальную пользу в профессиональной задаче.

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

Почему инструкции недостаточно, чтобы работа с ИИ стала процессом?

На втором практическом семинаре мы попробовали перейти от привычного «задал вопрос — получил ответ» к более управляемой работе с LLM:

задача → уточнение → план → выполнение → проверка → корректировка → результат

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

🔎 И здесь проявилась важная вещь: понять схему работы и уметь воспроизвести её в своей профессиональной задаче — не одно и то же.

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

📊 При этом практическая ценность подхода тоже проявилась. Участники отмечали поэтапную работу и схему «Диспетчер → Рабочий чат» как полезные элементы, а интерес к дальнейшим практическим занятиям оказался высоким.

Экономию времени в этом семинаре я специально не измерял, поэтому приписывать её методу было бы неправильно. Здесь выгода оказалась другой: процесс заставляет явно выделить этапы работы и место, где результат нужно остановить и проверить.

🛠 Что использовали: GigaChat и Qwen — для работы с профессиональными задачами; Google Forms и Sheets — для итоговой диагностики и анализа обратной связи.

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

Этому процессу тоже нужно учить — постепенно: от одного понятного цикла к более сложной архитектуре работы.

Почему средней ошибки модели недостаточно?

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

В проекте по прогнозированию межобточного пробега колёсных пар я сравнивал модель по MAE — средней абсолютной ошибке.

На проверочном периоде получилось:

15,28 тыс. км у модели против 19,87 тыс. км у простого прогноза.

Средняя ошибка снизилась на 23,1%. На первый взгляд — хороший результат.

Но здесь возникает более важный инженерный вопрос: имеет ли значение, в какую сторону ошибается модель?

Простой условный пример.

Фактический пробег — 100 тыс. км.

Прогноз 70 тыс. км → ошибка 30 тыс. км.
Прогноз 130 тыс. км → ошибка тоже 30 тыс. км.

Для MAE эти ошибки одинаковы.

Для планирования технического обслуживания — уже нет.

В первом случае прогноз консервативный: обслуживание может быть запланировано раньше необходимого.

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

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

Это именно контрольный критерий проекта, а не производственный норматив.

На текущей проверочной выборке из 27 наблюдений у модели таких случаев не было. Но 27 наблюдений недостаточно, чтобы по этому результату делать вывод о безопасности модели или её готовности к эксплуатации.

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

Метрика машинного обучения ещё не является инженерным критерием качества сама по себе.

Когда ИИ перестаёт быть отдельным сервисом и становится рабочим процессом?

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

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

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

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

задача → требования → работа с ИИ → проверка → корректировка → следующий шаг.

И именно этап проверки здесь принципиален.

В инженерной задаче нужно проверить, правильно ли вообще поставлена цель модели.

При обработке эксперимента — не только получить расчёт, но и убедиться, что выбранный метод применим и результат имеет физический смысл.

При подготовке учебного материала — проверить не только текст, но и то, действительно ли он помогает объяснить предмет.

При разработке приложения — отличить технически работающую функцию от решения, которое корректно с точки зрения реального процесса.

Получается, что предметный специалист постепенно начинает управлять не отдельными ответами нейросети, а циклом работы с ней.

И здесь меняется сама роль человека.

ИИ может предложить вариант, написать код, обработать данные, собрать черновик или быстро перестроить решение после замечаний.

Но человек по-прежнему должен определить:
— какую задачу мы вообще решаем;
— по каким признакам считаем результат правильным;
— где нужно остановиться и перепроверить;
— какой результат допустимо использовать дальше.

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

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

Можно ли без IT-бэкграунда сделать рабочий MVP?

Ещё недавно я бы, скорее всего, ответил: для такого проекта нужен разработчик. Сейчас ответ для меня уже сложнее.

Я не программист. Но в одном из своих проектов постепенно собираю приложение для автоматизации научной конференции.

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

Один из таких сценариев уже прошёл первую пользовательскую проверку: 14 из 14 заданий были выполнены самостоятельно.

И здесь для меня оказался важен один момент.

Что оказалось важным:

Главная работа — не в том, чтобы написать ИИ: «сделай приложение для конференции». Код он действительно может генерировать быстро.

Гораздо сложнее другое:

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

Поэтому разработка у меня идёт не как один большой запрос к ИИ, а короткими этапами:

задача → требования → реализация → тесты → ручная проверка → решение о следующем шаге.

Если проверка показывает проблему, следующий этап не начинается, пока она не разобрана.

Могу ли я сделать такой проект без ИИ? Скорее всего, нет. Сделал ли ИИ меня программистом? Тоже нет.

Он позволил предметному специалисту пройти значительно дальше от идеи и технического задания — до работающего и проверяемого прототипа.

⚠️ Но по мере приближения к реальной эксплуатации граница становится особенно заметной.

Персональные данные, информационная безопасность, резервное копирование, развёртывание, миграции, аудит, внешние интеграции — здесь уже недостаточно того, что «у меня всё запускается».

Перед реальной эксплуатацией такие решения требуют профессиональной технической проверки и организационного согласования.

Вывод:

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

Предметный специалист действительно может собрать рабочий MVP. Но его главная роль остаётся не в написании кода, а в другом: определить, что система должна делать, чего она делать не должна и как проверить, что она работает правильно.

Как проверить понимание, если студент использовал LLM

Если студент использовал языковую модель (LLM), хорошо выполненная работа сама по себе ещё не позволяет уверенно судить, насколько он понял предмет.

Именно поэтому в педагогическом эксперименте я сознательно разделяю четыре аспекта, которые легко смешать в одну оценку:

— корректность самой инженерной работы;
— проверку источников, расчётов и решений;
— прозрачность использования ИИ;
— понимание материала.

Последний пункт я проверяю отдельно — короткой мини-защитой без ИИ.

Не пересказом всей работы, а несколькими вопросами по ключевым решениям.

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

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

Но и обратная крайность неверна: сам факт использования LLM ещё не означает, что студент «не работал сам».

Гораздо полезнее проверить три вещи:

что он получил;
как он это проверил;
может ли он объяснить, почему результат имеет смысл.

Эксперимент ещё продолжается, поэтому выводов о том, улучшает или ухудшает LLM понимание инженерной дисциплины, я пока не делаю.

Но уже на уровне методики меняется сам объект оценки.

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

И это, кажется, относится уже не только к студентам.

Почему постановка задачи важнее выбора алгоритма

В ML-проекте легко начать с вопроса: какую модель выбрать — линейную, Random Forest или что-то сложнее?

Но в одном из моих реальных проектов главным оказался другой вопрос:

что именно мы вообще прогнозируем?

Я работал с данными по эксплуатации колёсных пар локомотивов. Исходная постановка была достаточно широкой — прогнозирование ресурса колёсных пар и бандажей.

ИИ здесь действительно помогал: объяснять методы, готовить и проверять код, быстро пересчитывать модели, сравнивать варианты.

Но по мере работы проявилась проблема, которую нельзя решить выбором более сложного алгоритма.

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

Поэтому целевую переменную пришлось уточнить:

пробег колёсных пар между обточками, тыс. км.

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

подразделение × серия локомотива × период.

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

Для меня это стало одним из главных выводов всего проекта.

Перед тем как выбирать модель, стоит ответить хотя бы на четыре вопроса:
— Что именно является целевой переменной?
— Что означает одно наблюдение в данных?
— С чем будет сравниваться прогноз?
— Какое профессиональное решение будет принято по результату?

Если хотя бы один ответ расплывчатый, усложнять модель рано.

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

Поэтому теперь перед вопросом «какая модель лучше?» для меня стоит другой:

«Что именно мы прогнозируем — и для какого решения?»

И именно здесь предметная экспертиза остаётся важнее алгоритма.

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

И почти каждый раз повторяется одна и та же история.

ИИ быстро предлагает решение. Иногда полезное. Иногда убедительное, но неверное. Иногда такое, которое действительно экономит часы работы.

Но после ответа всё равно остаётся главный вопрос:

можно ли этому доверять в реальной профессиональной задаче?

Из этого вопроса и появился «Метод и машина».

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

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

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

Коротко принцип канала такой:

реальная задача → ИИ → проверка → граница применимости → решение человека.

Посмотрим, как эта схема работает на практике.