ИИ на пальцах: как работает нейросеть и как ее использовать

В прогнозе (регрессии) модель выдаёт число: цену квартиры, спрос на товар, время доставки. Ошибка здесь — расстояние между предсказанным числом и реальным. Если прогноз продаж был 120, а факт 100, ошибка — 20 (или 20%).

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

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

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

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

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

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

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

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

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

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

Первая причина: утечка данных. Это ситуация, когда в обучение случайно попало то, что должно было остаться только для проверки, или когда в признаках есть подсказка, которая «выдаёт ответ». Например, вы хотите предсказать, вернёт ли клиент кредит, и среди входных данных случайно оказалась колонка «статус возврата» (пусть даже в завуалированном виде). Модель покажет идеальную точность — но это обман, потому что в реальной жизни такой подсказки не будет.

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

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

Один сценарий, который помогает связать всё вместе. Представьте, что вы делаете простую систему для отдела продаж: классификация «лид горячий/не горячий» и прогноз «сколько сделок будет на следующей неделе». Вы собрали таблицу прошлых лидов: источник, регион, сумма, дата обращения, результат (купил/не купил).

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

Шаг 2: вы делите данные: старые записи — на обучение, часть — на проверку, и следите, чтобы одинаковые клиенты не оказались и там и там (иначе модель узнает их и «схалтурит»).

Шаг 3: вы смотрите результаты. На обучении точность 100%, на проверке тоже 100%. Это выглядит как победа.

Шаг 4: вы проверяете, нет ли утечки: находите колонку «дата выставления счёта» — она появляется только когда лид уже почти точно купил. Модель фактически использовала будущее, которое в момент оценки лида неизвестно. Вы убираете колонку, повторяете оценку — и получаете, например, 78% на проверке. Это не провал, а честная картина.

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

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

Глава 9. Переобучение: когда модель «зазубрила»

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

Ключевой принцип здесь такой: переобучение — это когда модель слишком хорошо подстроилась под свои учебные примеры и из‑за этого хуже работает на новых. «Учебные примеры» — это данные, на которых модель училась. Переобучённая модель не столько понимает общий смысл задачи, сколько запоминает частные случаи и мелкие детали, которые случайно встретились в обучении.

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

Первый — устойчивые сигналы (например, что в письме‑жалобе обычно есть проблема, просьба и тон). Второй — случайные детали (например, конкретные фразы, редкие имена, совпадения формата, «любимые» слова в нескольких примерах). Если модель начинает опираться на случайные детали, она выглядит сильной на знакомых примерах, но «ломается» на новых.

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

Как понять, что вы усвоили:

— Вы можете объяснить разницу между «запомнила примеры» и «выучила правило» на любом простом примере (школьные задачи, шаблоны писем).

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

Почему переобучение чаще случается, когда модель слишком сложная, а данных мало. «Сложная модель» — это модель с большим количеством внутренних настроек (параметров), которые можно подогнать под данные. Чем больше таких настроек, тем больше свободы «подстроиться».

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

На простом уровне это можно представить так:

— Мало данных = мало разных ситуаций, чтобы увидеть, что является общим правилом.

— Слишком много «свободы» в модели = можно выучить не правило, а «память» о примерах.

— Итог = высокая точность на учебных примерах и слабая — на новых.

Как понять, что вы усвоили:

— Вы можете своими словами сказать: «мало данных не “учит обобщать”, а большая модель умеет подгонять ответы слишком точно».

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

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

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

— Резкая чувствительность к формулировкам: вы меняете пару слов, а ответ становится то отличным, то слабым.

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

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

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

Один цельный сценарий. Допустим, вы используете ИИ‑сервис, чтобы писать ответы клиентам в поддержку. Вы сделали себе «идеальный» запрос и на пяти прошлых письмах получили отличные черновики. Кажется, что задача решена.

Шаг 1. Вы проверяете перенос на новые ситуации. Берёте два новых письма: одно короткое и эмоциональное, другое — длинное, с несколькими вопросами. Просите сервис ответить тем же стилем.

Шаг 2. Вы делаете небольшие изменения и смотрите, «плывёт» ли качество. Меняете в запросе только одно: вместо «ответь вежливо и по делу» пишете «ответь коротко и по делу». Потом меняете формат: «сначала извинение, потом решение» → «сначала решение, потом извинение».

Шаг 3. Вы фиксируете признаки «узости». Если сервис внезапно начинает:

— забывать часть вопросов из длинного письма,

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

— путать условия возврата/сроки, которые раньше писал правильно,

— или сильно менять тон без причины,

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

Шаг 4. Вы делаете практичный вывод как пользователь. Вы решаете использовать сервис не как «автоматический ответчик», а как генератор черновика, который обязательно проходит быструю проверку по чек‑листу: все вопросы учтены, сроки и условия не выдуманы, тон соответствует ситуации. То есть вы учитываете, что при узком и нестабильном поведении нельзя доверять результату без контроля.

Что унести из этой главы:

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

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

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

Глава 10. Что происходит, когда вы делаете запрос?

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

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

Когда вы отправляете запрос, сначала происходит перевод текста в числа. Компьютер не умеет работать с буквами напрямую, ему нужны числовые представления. В языковых моделях текст режется на кусочки — токены (это могут быть слова, части слов или знаки). Каждый токен превращается в набор чисел, который отражает, «что это за кусочек» с точки зрения модели. Это не словарь значений, а удобный для вычислений код.

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

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

Как понять, что вы усвоили:

— Вы можете объяснить фразой: «Модель превращает мой текст в числа и по шагам выбирает следующие токены по вероятности».

— Вы понимаете, что при инференсе модель не учится заново, а использует уже настроенные веса.

Почему же ответ так сильно зависит от контекста и истории диалога? Потому что для модели «вход» — это не только последняя ваша фраза. Входом становится весь текст, который сервис отправил модели: ваш вопрос, предыдущие реплики, иногда системные инструкции (например, «отвечай вежливо», «не выдавай опасные советы»), а также скрытые подсказки вроде выбранного тона или роли. Всё это вместе называется контекстом — набор текста, на который модель опирается, когда предсказывает следующий токен.

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