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

Что в научной конференции стоит автоматизировать, а что нельзя отдавать алгоритму?

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

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

Значительную часть такой работы можно автоматизировать. Но не всю.

🛠 В нашем проекте мы разделили процесс на операции, которые должна выполнять система, и решения, которые остаются за организаторами конференции.

Что можно поручить программе?

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

Это не требует научного суждения. Зато уменьшает объём повторяющихся действий и помогает не терять информацию между этапами.

А где автоматизация должна остановиться?

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

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

🔎 Здесь обнаружилась ещё одна важная особенность: недостаточно автоматизировать отдельные операции. Нужно правильно распределить полномочия.

Секретарь конференции, секретарь секции и председатель решают разные задачи. Поэтому система должна не просто показывать очередную кнопку, а учитывать, кто имеет право выполнить конкретное действие.

Сейчас приложение ещё разрабатывается и проходит испытания. Говорить о полном внедрении и измеренной экономии времени преждевременно.

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

Как я без IT-бэкграунда автоматизировал публикацию канала — и что осталось за человеком?

⚙️ Когда начал регулярно публиковать материалы в этом канале, обнаружилась довольно простая проблема: готовый и утверждённый текст приходилось вручную переносить в MAX, восстанавливать оформление, прикреплять изображение и проверять результат.

Решил попробовать автоматизировать эти операции. При этом я не программист и раньше не занимался разработкой подобных интеграций.

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

🛠 С помощью ИИ собрали рабочую связку Google Sheets, Apps Script, Yandex Cloud и MAX API.

С первого раза ничего не заработало. Сначала возникла проблема с SSL-сертификатом при прямом подключении к MAX. Пришлось изменить архитектуру. Затем столкнулись с недоступностью технических журналов и организовали другой способ получения событий.

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

🔎 23 октября через тот же контур вышел следующий материал — уже с подтверждённой разметкой текста и изображением.

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

Повторяющихся ручных операций стало меньше. Точную экономию времени пока не измерял.

Но главное — что осталось за человеком.

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

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

Можно ли поручить 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 или что-то сложнее?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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