Основы работы с искусственным интеллектом и нейросетями

Что такое ИИ и нейросети: ключевые понятия и примеры

Зачем разбираться в ИИ

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

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

Базовые определения

Искусственный интеллект

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

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

Дополнительно:

Wikipedia: Artificial intelligence

IBM: What is artificial intelligence?

Машинное обучение

Машинное обучение (ML) — раздел ИИ, где система учится по данным, а не получает все правила в явном виде. Вместо «если‑то» алгоритм находит закономерности в примерах.

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

Глубокое обучение

Глубокое обучение (DL) — подраздел машинного обучения, в котором используются многослойные нейросети. Они особенно сильны в задачах с изображениями, аудио и текстом.

Дополнительно:

Wikipedia: Machine learning

Wikipedia: Deep learning

Как соотносятся ИИ, ML и DL

ИИ шире, чем машинное обучение, а машинное обучение шире, чем глубокое обучение.

| Понятие | Что это | Пример | |---|---|---| | ИИ | Всё, что имитирует интеллектуальное поведение | экспертная система с правилами + ML‑модель | | ML | Обучение по данным | классификация писем на спам/не спам | | DL | ML на многослойных нейросетях | распознавание объектов на фото, распознавание речи |

!Вложенная схема: ИИ ⟶ ML ⟶ DL

Что такое нейросеть

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

Идея «нейрона» простыми словами

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

Это часто записывают так:

Обозначения:

— входные значения (например, признаки объекта)

— веса (то, что модель подбирает при обучении)

— смещение (помогает сдвигать результат)

— операция суммирования

— функция активации (добавляет нелинейность)

— выход нейрона

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

Слои нейросети

Нейросеть обычно состоит из:

входного слоя (принимает данные)

одного или нескольких скрытых слоёв (извлекают промежуточные представления)

выходного слоя (даёт ответ: класс, число, последовательность токенов)

!Базовая архитектура: входной слой → скрытые слои → выход

Как модели учатся: «данные, ошибка, настройка»

В самом общем виде обучение — это процесс подбора параметров (весов), чтобы модель давала правильные ответы на примерах.

Обычно присутствуют три компонента:

данные: примеры, на которых учимся

цель: что считаем хорошим результатом (например, «верно предсказать класс»)

метрика/ошибка: численное измерение, насколько модель ошиблась

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

Основные типы задач машинного обучения

Обучение с учителем

Есть примеры и правильные ответы (метки).

Типичные задачи:

классификация (например, кот/собака)

регрессия (например, прогноз цены)

Обучение без учителя

Меток нет, ищем структуру в данных.

Типичные задачи:

кластеризация (группировка похожих объектов)

снижение размерности (упрощение представления данных)

Обучение с подкреплением

Есть агент, который действует в среде и получает награды/штрафы, постепенно улучшая стратегию.

Типичные задачи:

игры

управление (роботы, оптимизация)

Примеры ИИ и нейросетей в жизни

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

Поиск и рекомендации: ранжирование результатов, подбор контента

Компьютерное зрение: распознавание лиц, дефекты на производстве, анализ снимков

Речь и аудио: распознавание речи, синтез голоса

Текст и диалоги: перевод, суммаризация, чат‑боты

Бизнес‑аналитика: прогноз спроса, обнаружение аномалий

Попробовать простую визуальную «песочницу» для нейросети можно здесь:

TensorFlow Playground

Важные ограничения и риски

ИИ-системы могут быть очень полезны, но важно понимать границы.

Типичные ограничения

Зависимость от данных: если данные неполные или «кривые», модель унаследует проблемы

Смещения (bias): модель может воспроизводить несправедливые шаблоны из исторических данных

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

Объяснимость: сложные модели иногда трудно интерпретировать

Практическое правило

ИИ — это не «магия», а инструмент: его результат нужно проверять, а внедрение — сопровождать метриками качества, мониторингом и здравым смыслом.

Что дальше в курсе

В следующих материалах курса мы последовательно разберём:

какие бывают данные и признаки и почему они важны

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

базовые архитектуры нейросетей и их применение к тексту и изображениям

как формулировать задачи для ИИ и проверять результат

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

Данные для машинного обучения: сбор, качество и подготовка

Связь с предыдущей темой

В прошлой статье мы разобрали, что модели машинного обучения (включая нейросети) учатся по данным: видят примеры, сравнивают ответы с правильными и настраивают внутренние параметры.

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

Что считать данными в машинном обучении

Данные — это набор примеров, на которых мы обучаем модель и проверяем её работу.

Обычно используются три понятия:

Объект (пример): то, для чего мы хотим получить предсказание (письмо, фото, строка таблицы).

Признаки: измеримые характеристики объекта, подаваемые на вход модели (текст письма, пиксели изображения, столбцы таблицы).

Метка (цель): правильный ответ для обучения (спам/не спам, класс объекта, цена).

Если меток нет, данные всё равно могут быть полезны (например, для кластеризации), но логика подготовки и проверки будет другой.

Типовой конвейер работы с данными

Ниже — упрощённый процесс, который встречается в большинстве ML‑проектов.

!Типовой путь данных от задачи до обучения и контроля качества

Важно: это не одноразовая история. Данные меняются, поэтому качество нужно контролировать постоянно.

Сбор данных

Начинаем не с таблицы, а с вопроса

Перед сбором данных нужно формализовать задачу:

что модель должна предсказывать (метка)

какой объект предсказываем

в каких условиях будет использоваться модель

как будем измерять качество

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

Источники данных

Типичные источники:

внутренние системы (CRM, логи, транзакции)

датчики и устройства (IoT)

пользовательский контент (тексты, изображения)

открытые датасеты (для обучения и прототипов)

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

Репрезентативность

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

Частые проблемы:

данные собраны только в одном регионе, а применять хотят в нескольких

в датасете только «успешные» случаи, а в жизни бывают и «проблемные»

данные собраны в один сезон, а спрос или поведение меняются по времени

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

Юридические и этические ограничения

Если данные связаны с людьми, обычно важны:

согласие и законность обработки

минимизация собираемых данных (собирать только нужное)

контроль доступа и безопасное хранение

Для ориентира по терминологии персональных данных можно начать с обзора: Wikipedia: Personal data.

Разметка данных

Разметка — это процесс получения меток (правильных ответов) для примеров.

Ключевые практики качественной разметки:

понятные инструкции разметчикам (что считать правильным классом)

примеры «сложных случаев» и правила решений

проверка согласованности разметки разными людьми

отдельная категория «не уверен/недостаточно данных», если это допустимо

Плохая разметка превращается в «обучение на ошибках», и модель начинает воспроизводить шум.

Качество данных: что проверять

Качество данных — это не один показатель. На практике проверяют несколько измерений.

Основные измерения качества

Полнота: нет ли пропусков в критичных полях.

Точность: соответствуют ли значения реальности.

Согласованность: нет ли противоречий между полями и источниками.

Актуальность: не устарели ли данные.

Уникальность: нет ли дубликатов.

Репрезентативность: покрывают ли данные реальные сценарии.

Частые проблемы и что с ними делать

| Проблема | Как выглядит | Чем опасна | Типичные меры | |---|---|---|---| | Пропуски | пустые значения в столбцах | модель учится на неполной картине | заполнение, удаление, сбор недостающего | | Дубликаты | одинаковые строки/объекты | искажение статистики и метрик | дедупликация по ключам | | Выбросы | «невозможные» значения | ломают обучение и масштабирование | фильтрация, правила, робастные методы | | Дисбаланс классов | редкий класс почти не встречается | модель игнорирует редкие события | стратификация, взвешивание, пересэмплинг | | Смещения (bias) | перекос по группам/условиям | несправедливые и нестабильные решения | пересбор данных, аудит признаков, метрики по группам |

Термин смещение (bias) здесь означает перекос данных, а не математическое смещение оценок.

Подготовка данных (preprocessing)

Подготовка — это преобразования, которые делают данные пригодными для обучения.

Табличные данные

Типовые шаги:

приведение типов (числа остаются числами, даты — датами)

обработка пропусков (удалить, заполнить, выделить отдельное значение)

кодирование категорий (например, город → набор чисел)

масштабирование числовых признаков (чтобы разные масштабы не мешали обучению)

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

Текстовые данные

Часто применяют:

очистку явного мусора (служебные вставки, дубли, сломанные кодировки)

нормализацию простых вариантов записи (например, лишние пробелы)

разбиение текста на элементы, удобные модели

В современных языковых моделях текст обычно превращается в последовательность токенов.

Токен — это элемент текста (часть слова, слово или символ), который используется как единица представления в модели.

Изображения

Часто делают:

приведение к фиксированному размеру

нормализацию значений пикселей

аугментации

Аугментации — это искусственные преобразования (поворот, обрезка, изменение яркости), которые увеличивают разнообразие обучающих примеров и помогают модели лучше обобщать.

Временные ряды

Типовые шаги:

выравнивание по времени и частоте (например, «раз в час»)

обработка пропусков во времени

формирование окон наблюдений (например, последние 24 часа как один пример)

Разделение на train/validation/test

Чтобы честно оценивать качество, данные обычно делят на части:

train (обучающая выборка): на ней модель учится

validation (валидационная): на ней подбирают настройки и сравнивают варианты

test (тестовая): итоговая независимая проверка

Зачем это нужно:

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

валидирование помогает выбирать модель, не «подглядывая» в тест

Для практики разделения данных в Python часто используют функцию из документации scikit‑learn: scikit-learn: train_test_split.

Утечка данных

Утечка данных (data leakage) — ситуация, когда в обучение или признаки попадает информация, которая не должна быть доступна в момент реального предсказания.

Примеры утечки:

признак «статус доставки» используется для предсказания «вернёт ли клиент заказ», хотя статус известен только после события

нормализацию посчитали по всем данным сразу, включая тест, и тем самым частично передали статистику теста в обучение

Утечка почти всегда делает метрики «красивыми», но модель проваливается после внедрения.

Документация и воспроизводимость

Чтобы работа с данными была управляемой, полезно фиксировать:

откуда взяты данные и за какой период

правила формирования датасета и фильтры

версию датасета и версию разметки

список признаков и их смысл

известные ограничения

Один из известных подходов к описанию наборов данных — идея «паспортов датасетов»: arXiv: Datasheets for Datasets.

Итог

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

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

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

Связь с предыдущими темами

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

Теперь соберём это в практическую основу обучения моделей:

как измерять качество (метрики)

как понять, что модель переобучилась или недообучилась

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

Зачем нужны метрики

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

Примеры различий:

модель может снижать потери, но при этом плохо ловить редкие события (например, мошенничество)

высокая общая точность может скрывать провал по важному классу (например, пропуск опасных медицинских случаев)

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

Метрики для классификации

Классификация отвечает на вопрос: к какому классу относится объект (например, спам/не спам).

Матрица ошибок

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

TP (true positive): модель сказала положительный класс, и это правда

FP (false positive): модель сказала положительный класс, но это ошибка

TN (true negative): модель сказала отрицательный класс, и это правда

FN (false negative): модель сказала отрицательный класс, но это ошибка

!Матрица ошибок помогает понять, какие именно ошибки делает классификатор

Эта таблица нужна не ради формальностей: она показывает цену ошибок. Например, в антиспаме FP означает «хорошее письмо попало в спам», а FN означает «спам прошёл во входящие».

Accuracy

Accuracy (точность по доле верных ответов) показывает, какая часть предсказаний верна.

Обычно её считают так:

Где:

и это количество верных ответов

и это количество ошибок

знаменатель это общее число примеров

Когда accuracy подходит:

классы более-менее сбалансированы

цена FP и FN примерно одинакова

Когда accuracy опасна:

один класс встречается очень редко (дисбаланс классов)

Пример дисбаланса: если 99% писем не спам, модель, которая всегда говорит «не спам», даст accuracy 99%, но будет бесполезной.

Precision и recall

Если положительный класс важнее (например, «мошенничество», «болезнь», «дефект»), часто смотрят две метрики:

Precision: среди тех, кого модель назвала положительным классом, сколько действительно положительные

Recall: среди всех действительно положительных, сколько модель нашла

Интуитивно:

precision отвечает за качество срабатываний (меньше ложных тревог)

recall отвечает за полноту поиска (меньше пропусков)

F1-score

F1-score помогает сбалансировать precision и recall одним числом. Его часто используют, когда важны оба типа ошибок.

Формула:

Где:

это значение precision

это значение recall

множитель означает, что это гармоническое среднее, которое сильно штрафует перекос (например, высокий precision при низком recall)

ROC AUC и PR AUC

Если модель выдаёт не только класс, но и оценку уверенности (скор), можно менять порог решения и смотреть качество по кривым.

ROC AUC часто используют как общую характеристику разделимости классов

PR AUC обычно информативнее при сильном дисбалансе, потому что фокусируется на precision и recall

Если вы только начинаете, практическое правило такое:

при дисбалансе и важности редкого класса чаще выбирают precision, recall, F1, PR AUC

при более равных классах и равной цене ошибок можно начинать с accuracy и ROC AUC

Полезные справки:

Документация scikit-learn по метрикам классификации

Документация scikit-learn по матрице ошибок

Метрики для регрессии

Регрессия предсказывает число (например, цену, время доставки, спрос).

MAE

MAE (mean absolute error) это средняя абсолютная ошибка: насколько в среднем модель ошибается по модулю.

Когда удобно:

нужно понятное в единицах измерения число (например, «в среднем ошибаемся на 1200 рублей»)

хочется, чтобы выбросы не доминировали слишком сильно

MSE и RMSE

MSE (mean squared error) возводит ошибки в квадрат, поэтому сильнее штрафует большие промахи.

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

Когда удобно:

большие ошибки особенно нежелательны, и их нужно штрафовать сильнее

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

Важно:

удобно для сравнения, но его стоит использовать вместе с MAE или RMSE, чтобы понимать абсолютный масштаб ошибок

Полезная справка:

Документация scikit-learn по метрикам регрессии

Обучающая, валидационная и тестовая выборки

Чтобы честно оценивать качество, данные делят на части:

train: на ней модель учится

validation: на ней выбирают настройки (гиперпараметры) и сравнивают варианты

test: итоговая независимая оценка, к которой обращаются в конце

Ключевая идея:

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

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

Переобучение и недообучение

Недообучение

Недообучение (underfitting) означает, что модель слишком простая или обучена недостаточно и плохо работает даже на train.

Типичные причины:

слабая модель для задачи

слишком сильные ограничения (например, чрезмерная регуляризация)

недостаточно информативные признаки

Признак:

качество плохое и на train, и на validation

Переобучение

Переобучение (overfitting) означает, что модель подстроилась под особенности train (включая шум), но не переносит знания на новые данные.

Типичные причины:

слишком сложная модель для объёма данных

мало данных или они нерепрезентативны

много шума в разметке

утечка данных, создающая иллюзию качества

Признак:

качество очень хорошее на train, но заметно хуже на validation

!Иллюстрация того, как переобучение проявляется в динамике ошибки

Полезный материал для закрепления идеи:

Раздел про переобучение в Google Machine Learning Crash Course

Как бороться с переобучением

Ниже перечислены типовые приёмы. Они применимы и к классическим ML-моделям, и к нейросетям (с нюансами).

Улучшать данные

Самый сильный рычаг:

собрать больше данных

улучшить репрезентативность

исправить шум и ошибки разметки

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

Упростить модель

Возможные варианты:

выбрать более простую модель

уменьшить число признаков или слоёв

ограничить сложность (например, глубину дерева)

Регуляризация

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

Примеры:

L2-регуляризация в линейных моделях

weight decay в нейросетях

dropout в нейросетях

Практический смысл: модель «платит штраф» за чрезмерно сложные параметры.

Ранняя остановка

Ранняя остановка (early stopping) это прекращение обучения, когда качество на validation перестаёт улучшаться.

Почему это работает:

модель успевает выучить общие закономерности

но не успевает «дотачивать» себя под шум train

Аугментации

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

Примеры для изображений:

случайные повороты

обрезки

изменения яркости

Важно: аугментации должны сохранять смысл метки.

Валидация: как проверять качество правильно

Holdout-валидация

Самый простой подход: один раз разделить данные на train и validation.

Плюсы:

быстро и просто

Минусы:

оценка зависит от конкретного разбиения

Кросс-валидация

Кросс-валидация (k-fold) делит данные на частей, обучает модель раз, каждый раз оставляя одну часть для проверки, и усредняет результат.

Зачем:

получить более стабильную оценку качества на небольших данных

лучше сравнивать модели и настройки

Справка:

Документация scikit-learn по кросс-валидации

Стратификация

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

Это называется стратифицированное разбиение.

Временные ряды

Если данные идут во времени (прогноз спроса, нагрузки), нельзя случайно перемешивать прошлое и будущее.

Базовое правило:

обучаемся на прошлом, проверяем на будущем

Иначе появляется скрытая утечка: модель «видит будущее» через статистику разбиения.

Утечка данных как главная причина ложных метрик

Утечка данных (data leakage) это попадание в обучение информации, которой не будет в момент реального предсказания.

Частые источники утечки:

Признаки, которые формируются после события

Предобработка, сделанная на всём датасете до разделения (например, нормализация по всем данным, включая test)

Дубликаты или почти дубликаты объектов, попавшие и в train, и в test

Практический чек:

для каждого признака задайте вопрос: будет ли он известен в момент предсказания?

Итог

Метрики, переобучение и валидация это три опоры обучения моделей:

метрики переводят качество в измеримые числа, связанные с целью

анализ переобучения показывает, обобщает ли модель знания или запоминает train

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

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

Нейросети на практике: архитектуры и сценарии применения

Связь с предыдущими темами курса

Ранее мы разобрали:

что ИИ, машинное обучение и нейросети решают задачи через обучение по данным

почему качество и подготовка данных часто важнее, чем «самая умная» модель

как метрики, валидация и контроль переобучения защищают от самообмана

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

Что такое архитектура нейросети

Архитектура — это «схема» модели: из каких слоёв она состоит, как данные проходят через неё, и какие ограничения или преимущества это даёт.

Полезная интуиция:

архитектура задаёт, какие шаблоны модель умеет извлекать проще всего

данные и постановка задачи определяют, какие шаблоны вообще нужны

!Карта соответствия типов данных и популярных архитектур

Полносвязные сети (MLP) для табличных данных

MLP (multilayer perceptron) — полносвязная сеть, где каждый нейрон слоя связан со всеми нейронами следующего слоя.

Где MLP особенно уместны:

табличные данные: скоринг, прогноз оттока, предсказание спроса

случаи, когда признаки уже хорошо подготовлены и имеют смысл (возраст, стаж, сумма покупок)

Ограничение:

MLP обычно не используют «как есть» для изображений и текста, потому что там нужна архитектура, учитывающая структуру данных (пространство или порядок токенов)

Практическая связь с темой данных:

для MLP критична качественная подготовка признаков: пропуски, кодирование категорий, масштабирование

утечка данных часто возникает именно в табличных задачах через «будущие» признаки

Свёрточные сети (CNN) для изображений

CNN (convolutional neural network) устроены так, чтобы эффективно находить локальные шаблоны в изображении: края, углы, текстуры, затем более сложные формы.

Почему CNN работают хорошо:

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

это снижает число параметров и помогает обобщать

Типичные задачи:

классификация: что на фото

детекция: где объект на фото

сегментация: выделение пикселей объекта

!Упрощённая схема того, как CNN выделяет признаки в изображении

Практическая связь с темой переобучения:

CNN часто переобучаются на малых датасетах

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

Полезные ссылки:

Документация PyTorch по CNN

Документация Keras по слоям Conv2D

Рекуррентные сети (RNN, LSTM, GRU) для последовательностей

Когда данные идут в порядке (текст, аудио, показания датчиков), важно учитывать, что элемент зависит от предыдущих.

RNN обрабатывают последовательность шаг за шагом, сохраняя внутреннее состояние.

Проблема классических RNN:

им трудно учить дальние зависимости (важное слово в начале текста может влиять на конец)

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

LSTM

GRU

Типичные задачи:

классификация текста (например, тональность)

прогноз временных рядов

обработка сигналов

На практике в современных NLP-задачах RNN часто уступают трансформерам, но полезны как концепция и иногда как более лёгкое решение.

Трансформеры для текста и не только

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

Ключевая идея:

механизм внимания помогает модели определять, какие части входа важны для текущего вывода, даже если они далеко друг от друга

Типичные сценарии:

классификация и извлечение информации из текста

суммаризация и перевод

генерация текста

чат-боты

!Иллюстрация того, как внимание связывает токены в трансформере

Практический вывод:

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

Полезные ссылки:

Hugging Face Transformers

Статья «Attention Is All You Need»

Автоэнкодеры для сжатия, восстановления и поиска аномалий

Автоэнкодер — сеть, которая учится восстанавливать входные данные через «узкое горлышко».

Интуитивно автоэнкодер состоит из двух частей:

энкодер сжимает данные в компактное представление

декодер восстанавливает исходный объект

Зачем это используют:

сжатие признаков и снижение размерности

восстановление сигналов и изображений (например, подавление шума)

обнаружение аномалий: если модель хорошо восстановила «нормальные» примеры, то на аномальных восстановление хуже

Связь с метриками:

качество часто оценивают ошибкой восстановления, но важно проверять на отложенной выборке, чтобы не принять переобучение за «умение восстанавливать»

Как выбирать архитектуру под задачу

Ниже практическая шпаргалка, отталкивающаяся от типа данных и цели.

| Тип данных | Частые задачи | Типичные архитектуры | Комментарий | |---|---|---|---| | Таблица | классификация, регрессия | MLP, также классические ML-модели | нейросеть не всегда лучший старт, но полезна при сложных зависимостях | | Изображения | классификация, детекция, сегментация | CNN, иногда трансформеры | чаще выгодно начинать с предобученной модели | | Текст | классификация, извлечение, генерация | трансформеры, реже RNN/LSTM | токенизация и контроль утечек критичны | | Временной ряд | прогноз, аномалии | RNN/LSTM/GRU, 1D-CNN, трансформеры | разбиение должно соблюдать время | | Без меток или мало меток | представления, сжатие | автоэнкодеры, self-supervised подходы | удобно как этап до обучения «с учителем» |

Предобученные модели и дообучение

Во многих практических задачах разумно не обучать «с нуля», а использовать transfer learning.

Как это выглядит:

берём модель, обученную на большом корпусе данных

адаптируем под свою задачу: дообучаем часть слоёв или добавляем небольшой «головной» слой под свои метки

Преимущества:

нужно меньше данных

обучение быстрее

качество часто выше, чем у модели «с нуля»

Риски:

доменная разница: если ваши данные сильно отличаются (медицина, промышленность), качество может просесть

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

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

Этот список связывает архитектуры с темами данных, метрик и валидации.

Сформулируйте задачу и метрику

Проверьте, что метка корректна и не содержит скрытой информации о будущем

Разделите данные на train/validation/test без утечек

Начните с базовой модели

Выберите архитектуру под тип данных

Следите за разрывом качества между train и validation

Улучшайте данные раньше, чем усложняете модель

Типичные ошибки внедрения

Нейросеть может показывать отличные метрики на тесте и провалиться в реальности. Частые причины:

нерепрезентативные данные: в проде другой поток объектов

утечка данных: признаки или предобработка «подсмотрели» тест

сдвиг во времени: модель обучили на прошлом, а мир изменился

нет мониторинга: метрики качества не отслеживаются после запуска

Практическая связка с курсом:

качество модели начинается с качества данных

честная оценка начинается с правильной валидации

архитектура помогает, но не заменяет постановку задачи и дисциплину экспериментов

Итог

Архитектуры нейросетей можно воспринимать как набор специализированных инструментов:

MLP для подготовленных табличных признаков

CNN для изображений и пространственных шаблонов

RNN/LSTM/GRU для последовательностей, когда важен порядок

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

Автоэнкодер для сжатия, восстановления и поиска аномалий

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

Генеративные модели и промптинг: работа с LLM

Связь с предыдущими темами курса

Ранее в курсе мы обсудили:

что модели учатся на данных и качество сильно зависит от датасета и постановки задачи

как выбирать метрики и валидировать результат, чтобы не обмануть себя

какие архитектуры нейросетей бывают, и почему трансформеры стали стандартом для текста

В этой статье мы разберём генеративные модели и практику работы с LLM (Large Language Models): как они устроены на уровне ключевых идей, почему иногда уверенно ошибаются, и как писать промпты так, чтобы получать более управляемый и проверяемый результат.

Что такое генеративные модели

Генеративная модель — это модель, которая умеет порождать новые объекты, похожие на те, что были в обучающих данных.

Примеры генерации:

текст (ответы ассистента, суммаризация, перевод)

код (функции, тесты, объяснения)

изображения и видео

аудио (речь, музыка)

Важно: генеративная модель не “достаёт факт из базы” по умолчанию. Она строит выход так, чтобы он был правдоподобным продолжением входного контекста.

Что такое LLM и как она генерирует текст

LLM — это большая языковая модель, обычно построенная на архитектуре Transformer.

На интуитивном уровне LLM решает задачу:

на вход получает текст

преобразует текст в токены

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

добавляет этот токен и повторяет процесс

Токены и токенизация

Токен — это единица текста, с которой работает модель (часть слова, слово или символ). Токенизация — процесс превращения текста в последовательность токенов.

Почему это важно на практике:

ограничения по длине запроса и ответа считаются в токенах, а не в символах

стоимость и скорость работы API обычно тоже зависят от токенов

некоторые ошибки “непонимания” могут быть связаны с тем, как именно текст разбился на токены

Контекстное окно

Контекстное окно — это максимальный объём токенов, который модель учитывает “за один раз” (вход + формируемый выход).

Практические следствия:

если важная информация не попала в контекст, модель не сможет на неё опереться

длинные диалоги требуют управления контекстом: суммаризации, выделения фактов, внешней памяти

!Как LLM превращает промпт в ответ через токены и поэтапную генерацию

Почему LLM могут “уверенно ошибаться”

LLM часто дают ответы, которые выглядят убедительно, даже если в них есть ошибки. Это связано с тем, что модель оптимизировалась под правдоподобность продолжения текста, а не под “истинность” каждого факта.

Типичные причины ошибок:

в промпте мало контекста или он неоднозначен

модель “достраивает” недостающие детали наиболее вероятным способом

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

пользователь дал неверные исходные данные, а модель не может их проверить

Практическое правило из темы про метрики и валидацию:

для критичных задач LLM нельзя считать “источником истины” без проверки

нужен процесс оценки качества: тестовые кейсы, метрики, ручная проверка, мониторинг

Управление генерацией: почему ответы бывают разными

LLM можно запускать в разных режимах выбора следующего токена. Упрощённо есть два подхода:

детерминированные (стабильные, повторяемые)

случайностные (более разнообразные)

Ключевые параметры генерации

| Параметр | Что делает | Когда полезен | Риск | |---|---|---|---| | Temperature | увеличивает или уменьшает случайность выбора токенов | идеи, брейншторм, вариативные тексты | больше фантазий и ошибок при высоких значениях | | Top-p | ограничивает выбор токенов “вероятностным ядром” | мягкий контроль разнообразия | при слишком маленьком значении ответы могут стать шаблонными | | Max tokens | ограничивает длину ответа | контроль объёма, стоимость | риск обрыва ответа | | Stop sequences | останавливает генерацию по маркеру | строгие форматы, парсинг | если маркер выбран неудачно, ответ может обрываться раньше |

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

Промптинг: как “ставить задачу” LLM

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

Удобная структура промпта:

Роль и цель: кем должна быть модель в этой задаче и что нужно получить

Контекст: данные, ограничения, определения, важные факты

Задача: что именно сделать (глагол действия и критерий готовности)

Формат вывода: список полей, стиль, язык, объём

Проверка: попросить выявить неопределённости и задать вопросы или явно отметить “не хватает данных”

Базовые принципы хорошего промпта

Однозначность: меньше расплывчатых формулировок вроде “сделай красиво”

Контекст рядом с задачей: модель не должна “угадывать”, что вы имели в виду

Явный формат вывода: особенно если ответ будет обрабатываться программой

Примеры: 1–3 коротких примера часто улучшают стабильность (few-shot)

Критерии качества: что считать хорошим ответом, какие ошибки недопустимы

Пример промпта для извлечения данных (информационная задача)

Пример промпта для суммаризации (коммуникационная задача)

Few-shot: обучение на примерах внутри промпта

Few-shot — это подход, когда вы показываете модели несколько примеров “вход -> правильный выход”, чтобы она поняла стиль и правила.

Когда few-shot особенно полезен:

нестандартная разметка

сложный формат ответа

классификация с тонкими границами классов

Риск:

примеры должны быть правильными, иначе вы “обучите” модель ошибке

LLM в реальных продуктах: RAG, инструменты и дообучение

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

RAG (Retrieval-Augmented Generation)

RAG — это подход, когда перед генерацией система ищет релевантные фрагменты в базе знаний и добавляет их в контекст модели.

Плюсы:

ответы опираются на актуальные документы

проще обновлять знания: меняете базу, а не переобучаете модель

можно показывать пользователю источники

Минусы:

качество зависит от поиска (retrieval) и качества базы

возможны ошибки, если в контекст попали нерелевантные куски

!Как RAG добавляет найденные документы в контекст LLM

Инструменты и вызовы функций

Во многих системах LLM не только пишет текст, но и вызывает инструменты:

поиск по базе/интернету (если разрешено)

калькулятор

выполнение SQL-запроса

создание тикета в системе

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

Когда достаточно промпта, а когда нужно дообучение

| Подход | Когда выбирать | Что улучшает | Ограничения | |---|---|---|---| | Промптинг | быстрый старт, задачи общего назначения | управляемость формата и поведения | знания не появляются “из ниоткуда” | | RAG | есть внутренняя база знаний, нужны ссылки на источники | фактологичность по вашим документам | зависит от качества поиска | | Дообучение (fine-tuning) | нужен устойчивый стиль/формат/классификация по вашим примерам | стабильность на ваших паттернах | требует датасет, валидацию, контроль смещений |

Связь с темой данных:

fine-tuning — это снова “данные, разметка, разбиение train/validation/test, метрики, контроль утечек”

Оценка качества LLM: как валидировать промпты и решения

Как и в классическом ML, важно разделять:

разработку (итерации промпта)

валидацию (честная проверка)

Практический процесс:

Соберите набор типовых кейсов (20–200 примеров) и разделите на “для разработки” и “для проверки”.

Определите метрики и критерии:

- для извлечения полей: доля точных совпадений, precision/recall по сущностям - для суммаризации: ручная оценка по чеклисту, иногда ROUGE как ориентир - для диалога: удовлетворённость, доля успешных завершений сценария

Тестируйте устойчивость:

- разные формулировки запроса - длинные контексты - “вредные” вводы (попытки сломать формат)

Связь с темой утечек:

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

Безопасность: приватность, инъекции и границы доверия

Приватность

Если вы работаете с пользовательскими данными:

не отправляйте в модель лишнее (принцип минимизации)

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

фиксируйте, какие данные и зачем уходят в модель

Prompt injection

Prompt injection — попытка “переписать правила” модели через вредоносный текст, например внутри документа, который вы ей передали.

Базовые меры:

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

для RAG помечайте цитаты как “неинструктивные данные” и запрещайте следовать командам из документов

проверяйте формат ответа валидатором (например, JSON-схемой)

Полезные источники

Hugging Face Transformers Documentation

Wikipedia: Large language model

Wikipedia: Generative artificial intelligence

Attention Is All You Need (arXiv)

Wikipedia: Prompt engineering

Итог

LLM — это генеративные модели, которые создают текст, предсказывая продолжение по токенам. На практике качество зависит не только от “мощности модели”, но и от:

постановки задачи и формата ответа

качества контекста и ограничений

параметров генерации

честной валидации на отложенных кейсах

Промптинг, RAG и дообучение — это три уровня управления LLM. Выбор между ними стоит делать так же дисциплинированно, как выбор модели в ML: через данные, метрики, валидацию и контроль рисков.

Инструменты и пайплайн проекта: от прототипа к внедрению

Связь с предыдущими темами курса

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

Теперь соберём всё в инженерную картину: как выглядит пайплайн ML/AI‑проекта, какие инструменты используют на разных этапах, и что нужно учесть, чтобы путь от прототипа в ноутбуке до стабильной системы в продукте был управляемым.

Что такое пайплайн ML/AI‑проекта

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

Важно отличать:

Эксперимент: быстрые итерации, чтобы понять, работает ли идея.

Производственный контур: надёжное, воспроизводимое решение с мониторингом, версионированием и контролем качества.

!Общая схема пути от идеи до внедрения и поддержки модели

Роли артефактов: что именно нужно “производить” в проекте

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

Код: скрипты подготовки данных, обучения, инференса.

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

Фичи: описание признаков и правила их построения.

Модель: веса и параметры, формат сохранения.

Метрики и отчёты: качество на validation/test, сравнение экспериментов.

Конфигурации: параметры обучения, пороги, версии зависимостей.

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

Этап прототипа: быстрые проверки гипотез

Прототип — это минимальная реализация, которая отвечает на вопрос: есть ли сигнал в данных и достижимо ли качество.

Типичный набор инструментов для прототипа

Python как основной язык.

Jupyter Notebook для быстрых экспериментов: Jupyter.

NumPy/Pandas для работы с таблицами: pandas Documentation.

scikit-learn для базовых моделей, метрик и разбиений: scikit-learn.

Matplotlib для графиков: Matplotlib.

Дисциплина прототипа

Даже в прототипе полезно сразу ввести минимальные правила.

Формализовать метрику (из темы про валидацию): что именно считаем успехом.

Сделать корректное разбиение без утечек.

Сравнить с базовой линией (baseline): простая модель или простое правило.

Зафиксировать результат: датасет, метрики, параметры запуска.

> Прототип без воспроизводимости часто превращается в ситуацию “вчера работало, сегодня не работает, почему — непонятно”.

Переход от ноутбука к воспроизводимому обучению

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

Что обычно делают при “переезде”

Выделяют код в модули и скрипты: prepare_data.py, train.py, evaluate.py.

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

Фиксируют окружение: версии библиотек должны быть одинаковыми на машине разработчика и в CI.

Инструменты, которые помогают

Git для версионирования кода: Git.

venv или conda для окружений.

pip и файл зависимостей.

Минимально полезная практика: коммит в Git должен соответствовать конкретному результату на validation/test.

Версионирование данных и экспериментов

Код в Git хранить просто, а вот данные часто большие, меняются, имеют версии разметки и фильтров.

Зачем версионировать данные

Если вы улучшили качество, важно понимать, что именно помогло.

новые данные

исправленная разметка

другая фильтрация

другие признаки

Без версий вы не сможете честно сравнивать эксперименты.

Инструменты

DVC для версионирования датасетов и пайплайнов поверх Git: DVC Documentation.

MLflow для трекинга экспериментов, метрик и артефактов модели: MLflow.

Практическое правило: в карточке эксперимента должны быть ссылка на версию данных и ссылка на версию кода.

Оркестрация шагов: от ручных запусков к пайплайну

Когда шагов становится много (загрузка, чистка, фичи, обучение, оценка, упаковка), ручные запуски начинают ломаться.

Что такое оркестрация

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

Инструменты

Apache Airflow: расписание и зависимости задач: Apache Airflow.

Prefect как альтернатива для пайплайнов: Prefect.

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

Упаковка и деплой: как “донести” модель до пользователя

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

Типовые режимы применения

Онлайн‑инференс (API): ответ нужен сразу.

Батч‑инференс: считаем предсказания пачками по расписанию.

Встраивание в приложение: модель как библиотека внутри сервиса.

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

Упаковка

Docker помогает сделать окружение воспроизводимым: Docker.

Для API часто используют FastAPI: FastAPI.

Пример минимальной структуры сервиса:

Контроль качества на входе и выходе

В продакшене “ломается” не только модель, но и данные.

Что проверяют перед предсказанием

типы и диапазоны значений

обязательные поля

долю пропусков

известные категориальные значения

Что проверяют после предсказания

распределение скорингов

долю срабатываний

частоту ошибок формата

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

Мониторинг: метрики модели и сдвиг данных

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

Два разных класса мониторинга

Технический мониторинг: задержки, ошибки, нагрузка.

ML‑мониторинг: качество и поведение модели.

Что такое сдвиг данных

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

Примеры:

изменился источник трафика

изменились правила бизнеса

сезонность, акции, новые продукты

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

!Цикл мониторинга и переобучения модели

Особый случай: LLM‑решения в продакшене

LLM добавляют свои риски: нестабильность формата, галлюцинации, промпт‑инъекции, стоимость по токенам.

Типовой пайплайн для LLM‑функции

Определить сценарий и критерии качества.

Сделать промпт с явным форматом вывода.

Подготовить набор кейсов для проверки.

При необходимости добавить RAG.

Добавить пост‑валидацию ответа: проверка формата, обязательных полей.

Логировать запросы и ответы с учётом приватности.

Полезные практики из экосистемы:

LangChain для сборки цепочек, инструментов и RAG: LangChain Documentation.

LlamaIndex для задач индексации и RAG: LlamaIndex Documentation.

Важно: даже для LLM действует логика из тем про данные и валидацию — нужны наборы кейсов, независимая проверка и мониторинг.

Минимальный “чеклист готовности” перед внедрением

Ниже список, который помогает связать весь курс в одну практику.

Метрика определена и соответствует цели.

Разбиение train/validation/test сделано без утечек.

Есть baseline и понимание, почему текущая модель лучше.

Данные и модель версионируются.

Эксперименты воспроизводимы (код, зависимости, параметры).

Выбран режим инференса (API/батч/встраивание).

Добавлены проверки входных данных и формата выхода.

Настроен мониторинг технических метрик и ML‑метрик.

Есть план переобучения и критерии “когда обновлять модель”.

Итог

Пайплайн ML/AI‑проекта — это не только обучение нейросети, а управляемый процесс, где:

данные и метрики определяют, что считать успехом

валидация и контроль утечек защищают от ложных результатов

инструменты версионирования и трекинга делают эксперименты воспроизводимыми

деплой, мониторинг и цикл обновления превращают модель в устойчивую часть продукта

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

Этика, безопасность и правовые вопросы использования ИИ

Связь с предыдущими темами курса

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

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

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

!Схема показывает, что риски и меры контроля распределены по всему жизненному циклу ИИ

Что мы называем этикой, безопасностью и правом в ИИ

Чтобы не путать понятия, зафиксируем простые определения.

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

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

Правовые вопросы — соблюдение законов и договоров: персональные данные, авторские права, требования к продукту, ответственность за ущерб.

Полезная отправная точка по принципам: OECD AI Principles.

Основные риски при использовании ИИ

Ниже — типовые классы рисков, которые чаще всего встречаются в ML и LLM‑проектах.

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

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

Ошибки из-за нерепрезентативных данных и сдвига данных: метрики на тесте хорошие, а в реальности качество падает.

Нарушение приватности: утечки или избыточная обработка персональных данных.

Уязвимости и злоупотребления: обход ограничений, промпт‑инъекции, атаки на цепочку RAG, подмена входов.

Правовые нарушения: использование данных без прав, некорректные условия обработки, нарушения лицензий.

Вредный контент: токсичность, советы, ведущие к ущербу, небезопасные инструкции.

Эти риски связаны с темами курса напрямую:

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

если у вас нет корректной валидации, вы не заметите деградацию

если вы внедрили LLM без пост‑проверок, система будет ломать формат и “галлюцинировать”

Смещения и справедливость: почему “качество в среднем” недостаточно

Смещение (bias) в практическом смысле — это перекос в данных или в поведении модели, из‑за которого система ухудшает качество для конкретных групп или сценариев.

Откуда берутся смещения

данные отражают историческую несправедливость (например, неравный доступ к услуге)

в датасете некоторые группы представлены значительно хуже

метка построена так, что скрыто содержит дискриминационный сигнал

модель оптимизируется под среднюю метрику и “жертвует” редкими, но важными случаями

Что делать на практике

Проверять метрики по сегментам, а не только общую метрику.

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

Улучшать репрезентативность данных: добавлять недостающие группы и сценарии.

Фиксировать допустимые компромиссы: какие ошибки более критичны и для кого.

Для дисциплины оценки рисков полезен общий фреймворк: NIST AI Risk Management Framework.

Прозрачность и объяснимость: кому и что нужно объяснять

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

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

Важно разделять аудитории:

пользователю обычно нужно понять что произошло и что делать дальше

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

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

Практические механизмы:

политика раскрытия: где и как вы сообщаете, что используется ИИ

карточки модели: назначение, ограничения, данные, метрики, риски

логирование и трассировка: версия модели, версия данных, конфигурация, вход/выход (с учётом приватности)

Подход к документированию: Model Cards for Model Reporting.

Приватность и персональные данные

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

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

Обработка — любые действия с данными: сбор, хранение, передача, анализ.

Практические риски:

вы отправили в модель больше данных, чем нужно

вы обучили модель на данных, на которые нет прав

вы логируете ответы/промпты и тем самым создаёте “вторичную” утечку

Практические меры:

Минимизация: собирать и передавать только то, что необходимо для задачи.

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

Контроль доступа: кто и зачем может видеть данные и логи.

Сроки хранения: не хранить “вечно”, если нет необходимости.

Отдельные среды: не смешивать тестовые данные с боевыми.

Если вы работаете в юрисдикции ЕС или ориентируетесь на лучшие практики, полезно начать с текста GDPR: Regulation (EU) 2016/679 (GDPR).

Безопасность: чем ИИ отличается от обычного софта

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

Типовые угрозы для ML‑моделей

Data poisoning: атакующий подмешивает данные в обучение, чтобы изменить поведение модели.

Adversarial examples: небольшие изменения во входе меняют предсказание.

Model extraction: попытка “вытащить” модель через множество запросов.

Membership inference: попытка понять, был ли конкретный объект в обучающих данных.

Особые угрозы для LLM

Prompt injection: пользователь или документ пытается заставить модель игнорировать правила.

RAG‑инъекции: вредный текст попадает в базу знаний и начинает управлять ответом.

Утечки через инструменты: модель вызывает функцию не по назначению или передаёт лишние данные.

Нестабильный формат: модель должна вернуть строгий JSON, но “съезжает” в текст.

Практические меры для LLM‑систем:

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

Пост‑валидация: проверка формата и ограничений ответа (например, JSON‑схемой).

Ограничение инструментов: минимальный набор функций и строгая схема аргументов.

Принцип наименьших привилегий: модель не должна иметь доступ к лишним данным и действиям.

Тестирование на “вредных” кейсах: попытки сломать правила и извлечь данные.

Хорошая практическая отправная точка по уязвимостям LLM‑приложений: OWASP Top 10 for LLM Applications.

Авторское право, лицензии и “право на данные”

В ML‑проектах юридические риски часто возникают не на этапе деплоя, а раньше — при сборе данных и выборе контента.

Типовые вопросы:

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

можно ли хранить и переиспользовать тексты пользователей

какие ограничения у лицензии (например, запрет коммерческого использования)

кому принадлежат права на сгенерированный контент в вашей юрисдикции

Практические меры:

Вести реестр источников данных: откуда, на каком основании, с какой лицензией.

Отделять “данные для эксперимента” от “данных для продакшена”: то, что можно для прототипа, может быть запрещено в продукте.

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

Добавлять проверку на плагиат/копирование, если риск релевантен сценарию.

Если нужно базовое понимание авторского права, удобная отправная точка: WIPO: Copyright.

Регуляторные подходы: почему важно “классифицировать” риск

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

Пример риск‑ориентированного подхода — европейский AI Act: European Commission: Artificial intelligence.

Практическая логика, которую полезно применять даже без формальной регуляторики:

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

чем сложнее объяснить решение, тем важнее аудит, документация и контроль качества

Ответственность и управление: кто отвечает, если ИИ ошибся

Одна из частых управленческих ошибок — считать, что “ответственность на модели”. В продукте ответственность распределяется по ролям.

владелец продукта отвечает за корректный сценарий использования и коммуникацию с пользователем

команда данных отвечает за источники, качество, репрезентативность и законность обработки

команда ML отвечает за метрики, валидацию, устойчивость и контроль деградации

команда безопасности отвечает за угрозы, доступы, инциденты и уязвимости

юристы и комплаенс помогают определить ограничения и обязательные процедуры

Практический механизм — процесс управления рисками:

Описать сценарий и потенциальный ущерб.

Выбрать метрики качества и метрики безопасности.

Определить меры контроля: проверки входа/выхода, пороги, человек в контуре.

Настроить мониторинг и процедуру инцидентов.

Регулярно пересматривать систему при изменении данных и среды.

“Человек в контуре”: когда нельзя полностью автоматизировать

Человек в контуре — это режим, когда ИИ предлагает решение, но финальное действие подтверждает человек.

Такой режим часто нужен, если:

ошибка может привести к серьёзному ущербу

решение затрагивает права людей

модель работает в условиях высокой неопределённости

есть требования к объяснению и апелляции

Важно: человек в контуре должен иметь реальные инструменты контроля.

понятные причины рекомендации

доступ к ключевым фактам

возможность отклонить и исправить

процесс обучения на обратной связи (если это предусмотрено)

Мини‑чеклист перед запуском ИИ‑функции

Этот список связывает этику и право с инженерным пайплайном из прошлой статьи.

Определено назначение и ограничения: где модель применять нельзя.

Данные законны, источники и лицензии зафиксированы.

Есть проверка качества данных, нет утечек, разбиение корректно.

Метрики проверены по сегментам, не только “в среднем”.

Для LLM добавлены пост‑валидация формата, защита от инъекций и ограничения инструментов.

Логи и мониторинг настроены с учётом приватности.

Определены владелец риска и процесс инцидентов: что делать, если ИИ ошибся.

Итог

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

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

во время обучения: метрики, проверка смещений, честная валидация

в продакшене: контроль входа/выхода, защита от атак, мониторинг сдвига, процесс инцидентов

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