Как быть с ИИ простому MLщику?

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

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

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

На этом фундаменте я уже построил некоторый практический опыт, в 2021 дополнив ещё и базовым теоретическим пониманием нейросетей. Самую основу основ (а больше про те технологии вам, скорее всего, и знать не надо, скорее даже это избыточно) я свёл тут. Не смотрите на его формальную дату публикации, реально тот конспект почти полностью из 2021 года и на март 2023 уже подотстал от жизни. Оканчивается он на свёрточных нейросетях и Трансформере — в 2021 он уже несколько лет как был, и уже рвал LSTM в клочья, но это было только начало.

Ведь тем временем (а именно в 2020-2025) поэтапно разворачивалась LLM-революция (Large Language Model, если кто не в курсе — все эти ваши хайповые ChatGPT, Claude, Grok и иже с ним). Согласно Илье Суцкеверу, это было всего лишь масштабирование результатов исследований 2010-х, и теперь оно приблизилось к потолку. Но это с его точки зрения тех, кто делает топовые state-of-the-art (SotA) нейронки.

А точки зрения не только простых пользователей, никогда не слышавших слова вроде sklearn, PyTorch или backpropagation, но и простых MLщиков, вершилась самая настоящая революция — когда подходы становились классическими раньше, чем ты успевал о них узнать:

Это из другой супертоп mustread-статьи, написанной максимально простым языком, но дающей максимум понимания, как же правильно использовать LLM. Статья максимально рекомендуется к прочтению всем, использующим LLM в разработке, особенно менеджерам (для ещё более менеджерского взгляда советую вот эту статью того же автора, тут интересно про различия LLM и всего предшествовавшего ML с точки зрения внедрения).

Всё дальнейшее в данном тексте предполагает, что читатель прочитал обе вышеупомянутых mustread-статьи, либо и так знает всё написанное в них (мой конспект 2021 года тоже лишним не будет, уж во всяком случае его начало). Они образуют теормин — то, что для работы в дата саенсе знать необходимо. Достаточно ли? Едва ли. Попытаюсь дополнить некоторыми другими релевантными знаниями.

Для тех же, кто хочет разобраться подробнее, как же так вышло, что нейросети, теоретически разрабатываемые с 1950-х, бомбанули на практике только в 2010-х, а по-крупному — в 2020-х, советую вот эту статью и дополнения к ней: там вся история ИИ от Тьюринга до 2024-2025. Они тем более показательны, что сами сгенерированы LLM (с минимальными моими правками, дополнениями и наводящими вопросами) — но не теми тупыми LLM, которые уже засрали весь интернет ИИ-слопом, а SotA Claude Opus 4.5. Разница с какими-нибудь DeepSeek или тем более ChatGPT-4o впечатляет, а давно ли те вышли? (ChatGPT-4o — в мае 2024, DeepSeek и вовсе в январе 2025.) Уж тем более не ожидал такого уровня, разбираясь с нейросетями в 2021... Единственное, про последнюю на данный момент (декабрь 2025) прорывную технологию — рассуждающие модели, reasoning models, к которым относится и сам Claude Opus 4.5 — в тексте нет: когда Claude учили, достижения ризонинга были ещё в будущем, а значит и текстов про них ещё не было (knowledge cutoff). Свежак же LLM умеют подгружать только с помощью доработки напильником тем или иным образом (файн-тюнинг либо RAG, про оба см. ниже).

Self-Supervised Learning (SSL)

Напомню базовые схемы из must-read статьи №1:

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

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

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

Выход из казалось бы безвыходной ситуации придумали, как всегда, позабытые кабинетные учёные, изобретшие аналог semi-supervised learning, основанный на на reinforcement learning ("обучении с подкреплением") — вот он и к нейросетям подошёл, и эффективность повышалась куда более понятным образом. Суть reinforcement learning прекрасно описывают картинки из всё той же mustread статьи (нейросетевые и не нейросетевые модели в данном вопросе не отличаются):

Вот основнанный на RL аналог semi-supervised learning и получил название self-supervised learing — и позволил обучать нейросети на по-настоящему огромных массивах данных, из которых лишь малая часть размечена. В сочетании с изобретённой в 2017 прекрасно масштабируемой архитектурой "Трансформер" это привело к LLM-революции первой половины 2020-х (подробнее см. вышеупомянутые дополнения к истории ИИ, ИИ же и написанные).

Для тех, кто хочет разобраться с устройством self-supervised learning подробнее, вот хорошая точка входа.

Промпт-инжиниринг

Он же контекст-инжиниринг — их пытаются разделять, но это бред, т.к. контекст это главное в промпте. Промт без контекста это как запрос в гугл без уточнения деталей и переход по первой ссылке (кнопка "Мне повезёт!"), или как неформальная постановка задачи без ТЗ — в простых случаях может сработать, но даже там никаких гарантий... а попытки улучшения это уже задание контекста.

Короче, задавайте контекст. Как? Детально тут, а основу основ лучше mustread-статьи про LLM всё равно не передать, поэтому просто процитирую с небольшими дополнениями.

С изменения промпта всегда надо начинать. Удивительно, но часто делать больше ничего не надо. Но не стоит здесь сходить с ума и обещать LLM 100 долларов за правильный ответ. Есть несколько базовых правил:

• пишите подробно и с как можно более точными формулировками
• пробуйте Few-Shot, то бичь примеры правильного ответа: эффект велик
• используете reasoning (рассуждающие модели) или просто Chain of thoughts
• для чего-то на выходе, более сложного чем тупо 1-3 поля (массивы, вложенность), используйте Structured Output на YAML или JSON, а если вам нужен совсем сложный формат (≥3 уровней вложенности, рекурсия), то на помощь придёт xgrammar... если ваша LLM его поддерживает (скорее да, но но вы проверьте)
• дробите большую задачу на подзадачи. Вместо одного огромного промпта используйте несколько небольших. Далее последовательно их применяйте, чтобы решить исходную задачу. Это называется LLM-workflow.

Имеет смысл также ознакомиться с теми рекомендациями к написанию промптов для Claude и Gemini, которые дают сами Anthropic и Google. С другими LLM тоже должны работать.

RAG (Retrieval Augmented Generation)

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

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

По принципу устройства RAG суть хитрый вариант промпт-инжиринига:

• Сперва мы ищем релевантную информацию в своей базе знаний (про неё ниже). Это первое слово в Retrieval Augmented Generation — Retrieval.
• Затем мы добавляем результат поиска к пользовательскому промпту — он получается Retrieval Augmented. По сути это всё то же насыщение контекста.
• Ну и наконец мы скармливаем получившийся промпт LLM и наслаждаемся тем, что она сгенерировала в ответ — Retrieval Augmented Generation.

Что за база знаний такая? Да хоть тот самый гугл, если нам нужно что-то общеизвестное, просто свежее. Но это неинтересно, слишком просто. В каноническом RAG база знаний это хранилище векторных описаний документов — эмбеддингов. Заполняется это хранилище так:

• текст каждого документа бьётся на небольшие (от нескольких строк до нескольких абзацев, 100-1000 слов) фрагменты — чанки;
• для каждого чанка делается вектор признаков (собственно эмбеддинг);
• чанки всех документов кладутся в БД, где ключ — их эмбеддинг: dict = {embedding(chunk) : chunk};
• при этом вычисленение эмбеддингов сохраняют непрерывность, т.е. у схожих чанков будут схожие эмбеддинги, и лежать при этом они будут рядом, из каких мест каких документов бы не пришли.

Если вы совсем уж далеки от этого всего, рассмотрите аналогию БД с картой чанков, а эмбеддинги — с координатами на ней.

Далее, когда система получает вопрос, он тоже преобразуется в эмбеддинг-вектор, для которого система ищет похожие чанки. Метод поиска — k ближайших соседей (k-NN). Найденные чанки и добавляются в запрос к LLM (если нашлось уж совсем много — можно попробовать взять суммаризацию с помощью LLM же).

RAG-подход чрезвычайно полезен при анализе документов, где LLM отлично умеют парсить, но уж очень любят сочинять отсебятину (галлюцинировать), что в бизнесовых задачах неприемлемо. А вот RAG-подход с целевыми документами в качестве базы знаний позволяет контролировать процесс, радикально снижая вероятность галлюцинаций. Подробно, но так же на пальцах, про применение RAG для борьбы с галлюцинациями при анализе документов (включая ссылки на актуальные на конец 2025 библиотеки*, и quickstart-примеры, и краткий обзор общедоступных отечественных RAGов) см. вот эту статью на Хабре, а кому интересен статус соперничества и сотрудничества RAG-LLM (точнее, VLM, т.к. на входе изображение) и классических методов OCR-IDP см. тут (вот тут подробнее, с цифрами).

Конструктивно RAG несложен, но тема допиливания его велика и обильна. Начать можно вот с этой статьи (её более продвинутое продолжение), а дальше куда кривая дата саенс-мечты выведет. Вот например хороший по отзывам с Хабра курс по RAGам (у него тоже есть более продвинутое продолжение), можно посмотреть и обучающие материалы RAG from scratch во фреймворке Langchain (один из самых популярных).

Fine-tuning (дообучение готовой модели)

Куда более сложный и дорогой метод доработки LLM, нежели манипуляции с промптом и RAG. Нужны дорогостоящие видеокарты и велик риск всё сломать (добавить галлюцинации и т.п.).

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

Так что прибегаем только если промпт-инжиниринг не помог, а RAG не подходит.

Но и тут есть возможность отделаться малой кровью. Называется LoRA: low-rank adaptation. Это, можно сказать, "дообучение-лайт": исходную модель не трогаем, а обучаем новые параметры (т.н. адаптер), которые просто складываются с оригинальными весами модели. Из этого сразу вытекают два важных преимущества:

1. Малый размер данных для обучения.
   Если для честного дообучения нам нужно были десятки тысяч примеров, то LoRA заводится даже с несколько сотен. Зависит от размера адаптера, который можно регулировать. Если у вас для дообучения всего лишь тысячи или вовсе сотни примеров, LoRA с правильным размером адаптера ещё и по качеству окажется выше полноценного файн-тюнинга.
2. Удобство содержания зоопарка разных версий одной модели.
   Не нужно держать 20 клонов модели для 20 разных внедрений: запустить на GPU-стенде только одну, а 20 раз использовать разные адаптеры, которые намного меньше. На этапе предсказания веса модели будут на лету складываться с параметрами адаптера и выдавать предсказания для 20 разных задач. Такой функционал реализован во многих библиотеках для инференса LLM (например, в vLLM — см. конец следующего раздела).

Подробнее про LoRA можно почитать тут. Некоторые выводы:

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

Более общий термин для LoRA и подобных её аналогов — Parameter-efficient fine-tuning, PEFT. И для именно LLM (т.е. прям больших моделей) такой подход кажется оптимальным, т.к. на каждый специфический процесс полноценно дообучать полноценную LLM разве что совсем уж крупняк может себе позволить, а если мы не подстраиваемся под специфику процесса, то уж лучше выбирать лучшее из глобальных оптимумов — все эти Claude, ChatGPT, Grok и прочее, что крутится на таком железе, что по карману единичным компаниям в мире.

А вот для тех Large Language Model, что не очень-то и Large (есть даже термин Small Language Model, хотя совсем уж мелкими их тоже не назвать), полноценный файн-тюнинг вполне может дать результат. Можете попробовать, особенно если у вас закрытый контур и/или сильно специфическая задача, и более дешёвые методы результата не дали. Но тут уже включаются всё привычные по классическому ML и "классическим" (не LLM) нейросетям проблемы с борьбой с переобучением, кучей экспериментов с разными наборами датасетов и тьмой версий. О борьбе с ними (не только и не столько в LLM) следующий раздел.

MLOps

ML — математическое программирование, а оно очень легко погружается в нечитаемый хаос и трэш. Добавляем сюда ещё версионирование параметров (в лучшем случае учёт ведётся в Excel, а более вероятно что тупо текстом, разбросанным по гиту, таск-трекерам, txt, рабочим чатам и головам) и датасетов (а они большие) — получаем полный пипец. Решение — связка DVC + MLFlow:

График выше из далёкого 2019 года, но и в наше время, насколько я знаю, нормальных общедоступных альтернатив DVC нет, и связка с MLFlow сохраняет актуальность. Вот отличный quickstart guide по этой связке (а заодно сопутствующим инструментам вроде докера, и ещё порекомендован интересный визуализатор Evidently AI) на хабре. В локальные S3-хранилища и даже обычные файловые системы DVC тоже умеет, так что закрытые контуры и прочие чебурнеты препятствием не станут.

А вот у MLFlow появилась серьёзная альтернатива в лице ClearML: у меня с ним не самый позитивный опыт взаимодействия, но если возможности MLFlow вам кажутся недостаточными — welcome. Вот тут хорошее сравнение MLFlow vs ClearML, как их подружить с DVC, а равно и чем можно заменить последний, если он для ваших задач overkill.

Окей, а что с готовыми моделями, как их оркестрировать на проде, если у нас пайплайн с целым их зоопарком? В целом тут всё вариативно, но есть и платформы оркестрации. Точно встречается оркестрация разных LLMок с помощью n8n, вот на хабре quickstart guide для простых задач, но это так, чтоб хоть какое-то представление иметь. Ещё есть Camunda, она типа более enterprise...

Ещё есть Apache Airflow, в 2025 там тоже добавили AI SDK, и его реально используют для MLOps — он в этом сравнении ближе к Camunda (не low-code, больше возможностей), но больше заточен под обработку данных, на Питоне, и с коннекторами к БД проблем нет. Звучит как оптимальный вариант для серьёзных задач, но забиваться не стану, надо пробовать. Вот какое-то сравнение n8n vs Airflow, но с позиции какого-то казуального фрилансера, в его задачах ожидаемо побеждает n8n.

Ну и последнее: инференс на проде. Сразу к самому жоскому enterprise-варианту: vLLM. По этой ссылке всё, что нужно про него знать, и ссылки на рассказы про его более простые альтернативы для более простых задач: Ollama, LM Studio, llama.cpp (продублировал ссылки для удобства).

ИИ-агенты

Мегахайповая штука в 2025 году, но полезность всё ещё сомнительна из-за ненадёжности. Ещё раз сошлюсь на mustread-статью (см. также её более менеджерское дополнение, которое тоже уже скидывал выше). LLM-workflow как правило лучше в серьёзной разработке.

Но что, если вам нужно по-быстрому срубить бабла с не шарящих за ИИ лохов сделать MVP, решающий LLMкой сложную задачу? Здесь пригодится библиотека, делающая написание ИИ-агентов максимально простым: smolagents. Подробностей не будет, не моя тема. Я всегда был за максимальную инкапсуляцию и изолированность, дабы не плодить спагетти-код. А тут вообще чёрный ящик делает невесть что с непонятно каким результатом.

Вайб-кодинг

Это уже не ML, а прога, но что-то базовое знать надо:

• Это инструмент, который не для любых задач годится, но при грамотном применении отлично помогает набросать фронт и всё что с ним рядом, юнит-тесты и прочее типовое говно, на которое лень тратить время + супертоп для MVP и прочего "начать с нуля, чтоб было что править и допиливать". Нравится, не нравится — без этого должного уровня перформанса не будет и вас уволят нахрен (ну смотря где, конечно, но вероятность такая есть).
• Claude 4.5 прям хорош при правильном применении, но просит инвалюты, эрзац-бомж-заменой можно использовать например Gemini CLI, но и результат будет сильно хуже. ChatGPT и Grok бывают полезны, но именно в кодогенерации НЯЗ клод топ + они точно так же просят инвалюты. Про модели, выпущенные до 2025 года, просто забудьте — они не тянут. Даже DeepSeek уже устарел, хотя в качестве бесплатной эрзац-бомж-замены может и лучше аналогов (надо проверять).
• Очень сильно помогает документирование ТЗ (documentation-driven developement, в идеале DDD->TDD), подробно см. тут (очень хорошая статья про сравнительно простые типовые задачи, в любых сложных специфических неизбежно начинаются приколы, причём мб и такие, какие человек бы не допустил).
• Более серьёзный подход к DDD-вайбкодингу: Github Spec Kit. Читаем, разбираемся, пробуем. В статье много всяких best practices, примеров типовых ошибок и т.п. — если tl;dr, то листайте в конец, там самая суть. Когда оно вообще надо? Скрин:

• Инструментов вайб-кодинга тьма-тьмущая разной степени платности и доступности из РФ, наиболее популярен, кажется, Cursor, но местами пишут, что для прям серийной разработки лучше Claude Code, а чисто на халяву чут чут пофигачить можно и в каком-нибудь Gigacode от Сбера, где можно не грузить мозг иностранными картами и т.п.... в общем, мнения и ситуация разнятся, так что читайте статью по ссылке и комментарии к ней, пробуйте сами, и смотрите что больше подходит именно вам.