CrowsHaveEyes

Начнем с того, что более-менее известно каждому - все современные LLM обучены на гигантских объемах данных, триллионы токенов текста. Часто можно услышать мнение, что OpenAI обучают свои модели на данных "всего интернета", хотя это нельзя воспринимать буквально. Корпусы для обучения моделей статистически приближаются к описанию множества данных всего интернета, но не являются этим множеством в полном объеме. В этом утверждении кроется корень главной ошибки, которую многие делают, представляя себе обучение нейросети.

Я часто слышал: "хочу обучить модель, чтобы она запомнила вот этот список книг от начала до конца", "как обучить нейросеть полной документации по языку программирования X?".

Заблуждение №1

"Нейросеть запоминает текст из моего датасета" - целые предложения, страницы и так далее. Давайте сразу его разрушим, чтобы больше к этой ошибке не возвращаться.

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

Для сравнения, база данных является механизмом, и очень хорошим, для хранения текста в данной конкретной форме. При этом база данных ничего не знает о том, что в тексте говорится. Нейросеть, не имеющая ничего общего с базами данных, является "механизмом" изучения именно того, что означает текст, но практически бесполезна для хранения исходного текста в его полном объеме. Т.е. это машина для понимания данных, хранить которые следует в другом месте.

Объясняется это тем, что в процессе обучения LLM моделирует статистику нашего набора текстовых данных, и больше ничего. Это делали все языковые модели, начиная с простейшей биграммной, которая могла посчитать частоту всех биграмм (пар) токенов в наборе и на основании того, что биграмма "по" (предположим для простоты, что словарь модели - буквенный) встречается чаще, чем "пц", предсказать следующий токен "о" с большей вероятностью, чем "ц", если предыдущий токен - "п". Самая простая статистика. А трансформеры, несмотря на их сложность, концептуально эксплуатируют ту же N-gram идею, моделируя P(next_token | context).

Но есть важное различие.

Заблуждение №2

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

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

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

Но мы слишком быстро коснулись понятий домена знаний и следования инструкциям. Сначала модели научиться бы генерировать что-то кроме "ааааа333333!%;" - то есть изучить синтаксические признаки, семантику языковых конструкций, их структуру и логику. И это тоже слишком большой шаг вперед от N-gram моделей, где признаков всего ничего и все они явные (explicit), основанные на чисто внешних особенностях текста:

• предыдущие k токенов

• их частоты

• вероятности переходов к следующему токену от k предыдущих.

Однако уже по этому короткому списку вы можете заметить, что мы не программируем модель учить те или иные признаки, а другие - не учить. Модель приходит к ним сама от статистики, потому что 1. в данных эти признаки проявляются через распределение и 2. архитектура модели позволяет учить именно эти признаки.

Если модель биграммная, в ее функции аппроксимации P(xn∣xn−1) существует признак предыдущего токена, только одного, и признак частоты тех или иных биграмм. Если она 5-граммная, то архитектура "открывает" признак уже четырех предыдущих токенов, и это, в свою очередь, может выявить новые вероятностные признаки в данных, которые невозможно увидеть на уровне биграмм. Математически можно сказать, что признаки определяются функцией от трех переменных - архитектуры, данных и цели обучения, выраженной через функцию потерь, которая определяет, какие признаки существенны для правильной аппроксимации, а какие нет.

А нейросети пошли намного дальше! От явных признаков, которые в N-граммной модели представлены V^k-размерной матрицей, где V - размер словаря, они перешли к латентным признакам, которые являются абстракцией над явными и поэтому могут быть приведены к тензору меньшей размерности, чем V^k - ведь такая размерность, как уже было показано, при чуть большем контексте k уже слишком велика для наших вычислительных возможностей. Я имею в виду V x d-размерный embedding-вектор, который способен вместить d латентных признаков. При современных внушительных контекстах kVd - это все-таки очень много, но уже реально для обучения.

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

Прежде всего, данные должны быть статистически репрезентативными. Как следует из приведенного выше интуитивного объяснения основ representation learning - обучения признакам, чтобы модель научилась признакам, они должны быть выражены статистически в обучающем наборе. Но что это значит? Давайте посмотрим на эволюцию открытых датасетов.

CommonCrawl

Мы уже поняли, что устойчивого статистического моделирования нужных нам признаков ВСЕ данные модели видеть не нужно, как не нужно прочитать всю существующую в мире английскую литературу, чтобы научиться читать по-английски. Однако, если вы все-таки хотите "весь интернет" - почти - то вот он. 10 петабайт нефильтрованных веб-данных, собранных начиная с 2008 года. Использовать эти данные для обучения полностью практически невозможно, поэтому разработчики обычно выбирают из CommonCrawl подходящие для них сабсеты.

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

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

Самое, пожалуй, известное и громкое проявление этого эффекта от обучения на данных масштаба CommonCrawl описано в статье о GPT-3 - "Language Models are Few-Shot Learners". Тогда разработчики просто опытным путем обнаружили, что способность модели интерполировать известные ей знания на новые примеры эволюционировала настолько, что она стала успешно выполнять инструкции по нескольким примерам из промпта - few-shot, и это стало предпосылкой для ChatGPT и всех генеративных языковых моделей, предназначенных для именно таких задач.

Однако мы помним и крупный недостаток GPT-3, ее подверженность галлюцинациям. Это связано с шумностью данных CommonCrawl, так как этот набор содержит огромное количество (до 50% в нефильтрованном виде) веб-страниц низкого качества. SEO-тексты, где полно "воды", спам и бесконечные дубликаты. Это все плохо сказывается на reasoning-способностях модели и способствует оверфиттингу на тех паттернах текста, у которых в датасете слишком много дубликатов. Поэтому данные из CommonCrawl всегда тщательно фильтруют, и так появился следующий кандидат в этом списке.

FineWeb

Есть замечательная опция - воспользоваться уже готовым, фильтрованным CommonCrawl, то есть FineWeb. Это 15 триллионов токенов достаточно чистых данных. Эффективность обучения на FineWeb гораздо выше, поэтому в большинстве случаев его стоит выбирать как дефолтный базовый датасет для обучения - кому хочется выбрасывать сотни GPU-часов на ветер, пока модель молотит терабайты SEO-мусора и вытаскивает из них редкие полезные признаки?

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

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

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

ClimbMix

Из сказанного выше уже понятно, что качество и состав данных часто важнее их объёма. Один из подходов, развивающих эту идею — фреймворк кластеризации данных CLIMB от NVIDIA. С его помощью создан набор ClimbMix, основанный на методе оптимизации смеси обучающих данных (data mixture optimization), направленный на максимизацию полезных статистических признаков в датасете.

Основная идея ClimbMix - не просто собрать много данных, а подобрать такое соотношение доменов, которое максимизирует обучение полезных представлений. Обычный pretraining датасет, включая два уже перечисленных, представляет собой смесь различных источников: web-тексты, код, научные статьи, книги, диалоги, форумы. Проблема в том, что разные источники обучают разные способности модели.

Можете представить в качестве интуитивного примера такую таблицу:

Тип данных Какие признаки формируются

Веб  общая языковая статистика

Код  строгая логика и синтаксис

Math  reasoning паттерны

Книги  длинный контекст

QA  instruction following

Если распределение выбрано плохо, некоторые признаки переобучаются, другие почти не представлены - возникает неэффективное использование токенов. Это можно сформулировать так: неоптимальная смесь данных приводит к неоптимальному распределению признаков в representation space модели. Естественно, хорошо бы это representation space как-то проанализировать, поэтому первым делом метод преобразует тексты в embeddings с помощью небольшой модели. После этого данные кластеризуются по тематике, стилю, сложности, типу reasoning. То, что мы имеем в итоге - это набор семантических доменов, которые описывают карту пространства признаков для обучения. Далее обучается небольшая прокси-модель на разных смесях этих кластеров.

Например, микс A - 40% веб, 20% код, 20% книги, 20% академические тексты, микс B - процентное соотношение меняется, а книги, скажем, заменяем на QA. Затем для всех оцениваем validation loss, downstream performance, training efficiency. Читайте подробнее в статье - Nemotron-CLIMB: CLustering-based Iterative Data Mixture Bootstrapping for Language Model Pre-training. Таким образом находим, какой микс дает наилучший обучающий сигнал.

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

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

В свете недавнего выхода обновления Deep Research для Gemini стоит разобраться, как этот и подобные ему агенты работают.

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

Многие AI-лаборатории - OpenAI, Google, IBM - имеют свои версии Deep Research агента. Но мы, тем не менее, знаем и его открытые его реализации, взять хотя бы Open Deep Research от LangChain. Последний дает хорошее представление об архитектуре - как и любой Deep Research пайплайн, он включает уточнение границ исследования, собственно поиск и формирование конечного отчета. Все это - хорошо знакомые мультиагентные сценарии, когда агент-супервайзер планирует конкретные поисковые задачи для агентов-исполнителей, вызывающих внешние функции. Основных проблем две: скорость выполнения задач и доступ к качественным источникам данных.

Скорость зависит от LLM - именно поэтому для агентных систем сейчас разрабатываются модели с высокой пропускной способностью, а также с упором на быстрый и точный reasoning. К этим разработкам относится недавний релиз первой модели нового поколения Nemotron 3 от Nvidia. Эта серия LLM была заявлена именно как вклад компании в развитие открытого агентного AI. Скорость инференса была повышена за счет гибридной архитектуры - трансформер плюс мамба, преимущества последней в отношении пропускной способности и экономного расхода памяти на KV-кэш хорошо известны. Впрочем, гибриды - не единственный путь для усиления агентных способностей AI. DeepSeek имеет очень выгодную для этого архитектуру, реализующую MLA-внимание (Multi-Head Latent Attention), которое обеспечивает высокопроизводительный инференс за счет очень малых, по сравнению с полным вниманием, расходов на KV-кэш.

Далее, мы сталкиваемся с проблемой, когда одна и та же реализация Deep Research дает очень разные результаты в зависимости от доступных данных. Для веб-поиска есть удобные, интегрируемые с AI агентами инструменты типа Tavily. Но далеко не на все вопросы можно получить ответы, просто “погуглив”. Для доступа к данным из частных источников, например, часто возникает необходимость деплоить Deep Research в приватное окружение. Я работаю с разными подходами к решению этой проблемы, включая облачные приватные эндпоинты, или собственный LLM-сервер, развернутый локально или в облаке. Все сводится к тому, как предоставить модели безопасный доступ к данным. Ответом может быть использование вашего собственного конфиденциального MCP-сервера, имеющего доступ к закрытым данным и реализующего определенный механизм авторизации для LLM, запрашивающим доступ к определенным частям этих данных (MCP-ресурсам). Например, если к LLM имеет доступ кто-то кроме вас, доступ не даем вообще или ограничиваем. Всегда можно запрашивать разрешение пользователя - владельца данных, что поддерживается протоколом MCP.

Наконец, необходимо совершенствовать поисковые способности открытых моделей. Крупные компании усиленно “качают” свои модели для повышения эффективности в многошаговых поисковых сценариях - например, Gemini 3 Pro, на котором работает их новый Deep Research агент. Основные вызовы, для достойного ответа на которые тренировали модель - улучшение качества финального отчета агента, в котором должны быть сведены к минимуму галлюцинации и должна присутствовать верификация выводов фактами из достоверных источников. Продуктом исследований Google стал углубленный бенчмарк DeepSearchQA, который может помочь и для улучшения открытых моделей, направленных на решение тех же задач. Преимущество этого бенчмарка - категоризация данных по различным областям исследований, их качество (примеры составлены вручную), и фокус на оценке не только правильности ответа, но и его полноте.

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

Вместо ChatGPT я использовал Open WebUI, который поддерживает MCP из коробки. Логичный выбор — это самый полноценный открытый аналог веб-интерфейса ChatGPT.

Однако, ограничения Open WebUI по части MCP меня сильно разочаровали. Моей целью было сделать как у OpenAI: при желании пользователь может передать URL своего MCP-сервера на инференс-API, и этого должно быть достаточно, чтобы вызывать его tools.

tools=[

{

"type": "mcp",

"server_label": "deepwiki",

"server_url": "https://mcp.deepwiki.com/mcp",

"require_approval": {

"never": {

"tool_names": ["ask_question", "read_wiki_structure"]

}

}

},

]

Но Open WebUI не поддерживает напрямую транспортные протоколы, через которые MCP-клиент и сервер обмениваются сообщениями - streamable HTTP и SSE. Вместо этого у Open WebUI есть собственный прокси (mcpo), с помощью которого можно конвертировать MCP сервер, доступный локально через stdio, в RESTful HTTP. Прямо скажем, неудобно.

У большинства разработчиков задача сводится к деплою готового MCP сервера, реализующего какую-либо внешнюю интеграцию - например, с Jira или PostgreSQL — и его связке с AI-агентом.

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

Хорошо бы, чтобы платформа поддерживала понятный удобный пользовательский интерфейс - Open WebUI, но без выявленных выше ограничений. На самом деле одного Open WebUI мало; с учетом запросов рынка, как подсказывает мой опыт, нельзя забывать о популярности телеграм-ботов применительно к AI, а также о необходимости программного доступа по API. Но все же Open WebUI — хорошая стартовая точка.

Решение, которое позволяет обойти ограничения поддержики MCP протокола — это пайплайны Open WebUI. Например, вы можете поднять свой AI агент как отдельный микросервис. Пайплайн — это модуль, который свяжет агента через Open WebUI и позволит вам написать тонкую программную прослойку, чтобы конвертировать ответы агента в формат Open WebUI, добавить какие-то кастомные фичи. В моем случае это передача URL внешнего MCP-сервера.

Здесь тоже все не так просто. Предположим, что код агента написан, например, на LangChain. Мне очень не нравится официальный MCP адаптер для LangChain, мне нужно что-то более простое, желательно синхронное, совместимое с любой python-библиотекой. Клиентской библиотеки, обладающей перечисленными свойствами, в открытом доступе не хватает, и я решил написать свою.

Сам по себе MCP протокол очень прост. Клиент инициализирует сессию, согласно конвенции, определенным JSON-RPC сообщением, может вызывать список tools, prompts, resources сервера, и вызывать тулзы. По замыслу разработчиков протокола, передача JSON-RPC сообщений должна быть возможна поверх нескольких транспортных протоколов - как минимум, HTTP-стрима и stdio. Оба транспорта достаточно легко реализуются стандартными средствами Python.

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

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

Правда, когда мне пришлось реализовать такой механизм в реальном агенте, выбранный мной способ был далек от того elicitation, который мы видим в официальном MCP SDK от Anthropic, и не без причин. Мало того, что elicitation требует двустороннего обмена сообщениями между агентом и пользователем, так еще и агент сам должен иметь возможность задавать вопрос, выступая в некоторых случаях инициатором диалога, а не тем, кто только отвечает на сообщения пользователя. Эти ситуации пока что не проработаны в большинстве диалоговых AI-систем.

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

• MCP-сессию, реализующую отправку JSON-RPC сообщений на сервер;

• Транспортный слой, который включает поддержку HTTP-стрима и stdio;

• Адаптер, в настоящий момент - для LangChain/LangGraph, но с возможностью добавлять другие агентские бэкенды.

В ближайшем будущем я планирую выложить его в открытый доступ, как и часть других модулей моей платформы. Мне кажется, современная AI-платформа должна быть открытой и обеспечивать максимальную кросс-совместимость с различными AI-инструментами. Именно поэтому я изначально выбрал MCP протокол, который предназначен как раз для этого, и Open WebUI, как самый популярный открытый AI интерфейс.

Наконец, модульная архитектура пайплайнов в OpenWebUI позволяет легко поддерживать несколько LLM провайдеров - я тестировал свою платформу с API OpenAI и публичными эндпоинтами в облаке.

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

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

Возникает потребность в приватной сети, но об этом уже в другой раз.

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

Однако, как и MCP протокол, эта платформа должна быть открытой для кастомизации, предоставлять разработчикам доступ к своим внутренним модулям и API. Тот уровень контроля, который дает OpenAI в случае со своими MCP коннекторами в режиме разработчика ChatGPT, на мой взгляд, недостаточен.

В этом и состоит рациональное обоснование моего пока еще экспериментального проекта.

Поэтому агентские системы обычно представляют собой микросервисную архитектуру, объединяющую несколько логических блоков. Взять хотя бы ReAct паттерн, в котором reasoning агент выполняет управляющую роль, а action — отвечает за вызов функций и выполнение других действий.
И, как в любой микросервисной архитектуре, мы приходим к необходимости горизонтального масштабирования, что удобнее всего делать в облаке. Во-первых, сами LLM — очень ресурсоемкие элементы системы, инфраструктура для них требует сложной конфигурации. Об этом больше сказано ниже. Во-вторых, обмен данными между ними тоже требует правильного проектирования и развертывания дополнительных сервисов, как например векторная БД, механизмы стриминга данных, кэширования, чанкования, эмбеддингов.

Главные трудности в конфигурации облачной инфраструктуры под AI агенты, согласно моей практике, связаны с рассчетом нагрузки. Особенно это касается GPU-инфраструктуры, ответственной за хостинг LLM. Эта тема заслуживает отдельной статьи — с появлением различных алгоритмов внимания, квантизации моделей и механизмов выделения GPU-памяти, правильный подбор мощностей требует всё более нетривиальных вычислений. Было бы хорошо, если бы эта проблема также была решена на уровне облака и снимала с AI-инженеров заботу о правильно подобранной инфраструктуре. Но мы находимся на ранней ступени адаптации облаков под нужды AI, и многое приходится изобретать самостоятельно.

Зачем вообще мне понадобилось разворачивать свои ИИ модели в облаке, если можно обратиться к API OpenAI, DeepSeek или Qwen? На практике среди преимуществ открытых весов неожиданно в приоритете оказалась скорость генерации ответа. Для ряда агентских систем критическим параметром является именно скорость. На нее оказывают влияние сетевая связность, размер весов и тип квантизации, мощность GPU, параллелизм запросов, размер контекстного окна и масса других параметров, к которым разработчик далеко не всегда имеет доступ, работая с провайдерами закрытых моделей типа OpenAI.

Именно поэтому через практику я пришел к выводу, что индустрии разработки агентских приложений необходима облачная платформа, предоставляющая полный доступ к весам, данным и инфраструктуре — без этого систему не построить. С другой стороны, роль облака — максимально облегчать выделение ресурсов под LLM, дать разработчику что-то вроде «торгового автомата для LLM». Выбрал веса модели, размер контекста, параметры масштабирования, нажал на пару кнопок и получил готовый LLM-сервер.Я предполагаю, что после устранения описанных инфраструктурных трудностей порог входа в разработку AI агентов существенно снизится.

Так ли это — покажет время.

Retrieval‑Augmented Generation (RAG) — тандем LLM и векторных баз для поиска релевантных фрагментов, вставляемых в контекст перед генерацией, который обрел популярность в последние год-полтора благодаря нескольким безусловным преимуществам.

Этот подход позволяет использовать модели общего назначения на узкоспециализированных доменах без полного дообучения. Он и сейчас является самым надежным и дешевым способом снизить галлюцинации, даёт ссылки на документы и улучшает точность ответа. RAG используется в цепочке следующих логических шагов, через которые проходят данные в системе: векторизация → recall → prompt → LLM → извлечение структурированных данных.

Теперь о минусах RAG. Описанная методика только дополняет контекст модели релевантными данными, но не повышает способность самой LLM к извлечению нужных признаков. Эта способность зависит от того, каким задачам и на каких данных модель была обучена. К тому же RAG добавляет несколько архитектурных и прикладных сложностей - пайплайн с векторной базой, embedding, поиск по индексу, чанкинг данных, который может быть нетривиальным процессом с применением различных методик (таких как Semantic Chunking).

Сейчас контекстное окно модели позволяет вместить намного больше данных, чем раньше - взять хотя бы 1 млн токенов у Llama 4, так что необходимость в чанкинге и самом RAG уже не настолько острая. Есть, конечно, проблема понимания длинного контекста. Важно понимать, что при решении практических задач точность LLM может падать пропорционально длине контекста - на эту тему есть интересный бенчмарк:

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

Fine‑tuning: точечное улучшение LLM

Файнтюнинг изначально был менее доступен, чем RAG - во-первых, он требует понимания того, как работает оптимизация весов большой языковой модели-трансформера (если мы не говорим про файнтюнинг каких-то других архитектур нейросетей). Во-вторых, он требует набора данных (как правило, размеченных, если мы говорим про Supervised Fine-Tuning), и в третьих, он требует вычислительных мощностей, таких как GPU-кластер.

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

На своем опыте я сделал следующий вывод: файнтюнинг необходим для разработки агентов, особенно в области feature-extraction задач, это очень эффективная практика, которая должна быть взята на вооружение разработчиками, так как она закрывает недостатки RAG и служит необходимым компонентом прикладных ИИ систем. Перечисленные выше трудности файнтюнинга тоже постепенно решаются - во-первых, облачные провайдеры делают доступными вычислительные мощности. В моих статьях и видео достаточно гайдов по использованию облака для файнтюнинга. Чтобы экономить на GPU, по-прежнему остается актуальной методика Low-Rank Adaptation (LoRA), хотя во многих случаях и полный файнтюнинг, который модифицирует веса модели полностью, тоже возможен и оправдан. Ведь для узко специализированной задачи может быть достаточно обучить модель на совсем небольшом наборе данных - 100-500 примеров.

Динамическая квантизация в сочетании с LoRA (QLoRA) позволяет еще сильнее сократить расход видеопамяти и время обучения модели.

В целом SFT-файнтюнинг можно разделить на следующие шаги: подготовка датасета → формирование train и validation наборов → обучение → оценка. В моем последнем видео я "начал с конца" и разобрал прикладные аспекты оценки (evaluation) при разработке агентских систем. Лишь недавно я обратил внимание на библиотеки для evaluation, такие как openevals в экосистеме Langchain/Langsmith, о которых в знал и раньше, но обходился простым скриптингом. Для тех, кто только начинает знакомство с evals, будет полезен мой ноутбук с экспериментами на Langchain/Langsmith и openevals.

При подготовке данных для feature extraction важно выбрать итоговый формат данных, который будет понятен и человеку, и LLM. При небольшом объеме данных самое важное - качественные примеры ответов (output), которые готовятся обычно человеком, вручную. Это особенно актуально для специализированных случаев feature-extraction - например, если вы разрабатываете систему, которая будет читать технические спецификации изделий, товарные коды и тому подобные типы данных. Для составления такого датасета придется привлекать человека с профессиональными знаниями в соответствующем домене. А для LLM чем проще выходной формат данных, тем меньше вероятность галлюцинаций. Поэтому я руководствуюсь тремя принципами -

1. Не усложнять выходной формат данных применением, например, JSON или XML - простого текста в большинстве случаев достаточно;

2. Выполнять feature-extraction из минимальной единицы входных данных за одну генерацию. Это может быть одна PDF-страница, изображение, параграф текста;

3. Использовать Chain-of-Thoughts для валидации процесса извлечения.

Само обучение, как ни странно, вызывает меньше всего проблем - используйте готовые средства обучения библиотеки transformers или API OpenAI, контролируйте качество чекпоинтов, своевременно используя evaluation, и следите за оверфиттингом.

Distillation: перенос знания

Distillation — это обучение компактных или более слабых моделей на основе поведения более сильной LLM‑«учителя». Это еще один способ повысить качество модели, часто менее затратный, чем SFT-файнтюнинг - достаточно просто сгенерировать датасет с помощью модели-учителя, без участия человека.

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

Авторами была реализована следующая архитектура:

DistilBERT + fine‑tuning на 10 000 документов → компактная модель с эффективным временем обучения (4–9 ч на ПК) с 97% качества модели-родителя. Пайплайн извлечения признаков включал следующие шаги:

• Сэмплинг 10k примеров из тестового корпуса (объявления вакансий) с целью извлечения признаков.

• Разбивка на чанки с применением Semantic Chunking

• Генерация ground‑truth с помощью LLM (Gemini).

• Файнтюнинг DistilBERT - небольшой модели с архитектурой раннего трансформера, которая получена путем дистилляции знаний модели BERT. Дистилляция позволяет сохранить 97% процентов качества, при размере на 40% меньше, чем у исходной модели BERT

• Prediction - извлечение признаков.

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

RAG — поиск релевантных фрагментов, Fine‑tuning для улучшения и стабилизации ответов модели, и Distillation в эффективной агентской системе дополняется промпт-инжинирингом и CoT, Chain‑of‑thoughts, для самовалидации системой извлеченной информации и ее автоматического итеративного приближения к ожидаемому результату.

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

Выполнена выборка промптов из открытых англоязычных датасетов с последующим переводом на различные языки. Для перевода использовалась GPT-4o, которая, кстати, хорошо показала себя при создании моего собственного датасета и русскоязычного файнтюна Llama 3 на нем. Далее авторы мультиязычного CoT-датасета сгенерировали ответы на полученные промпты с помощью deepseek-ai/DeepSeek-R1-Distill-Llama-70B восемь раз, и отфильтровали блоки <think> не на том языке, либо с нарушениями правил языка или логическими ошибками. Это достаточно интересный момент, так как разработчики полностью опубликовали код для генерации своего датасета, включая фильтрацию сгенерированных цепочек рассуждений. Если с автоматическим определением языка цепочки все достаточно просто, то для проверки ее соответствия нормам языка и, самое главное, логической корректности, пришлось опять-таки задействовать LLM. Принцип такой же, как и при использовании модели-судьи для выполнения автоматизированных evaluation-тестов.

Пример оценочного промпта из кода проекта:

fluency_system_message = f"""You are a {language} fluency evaluation AI. Given a piece of text, give the fluency and naturalness of the {language} in the text a score from 1-5. Only include your final number in your output."""

То есть модель-судья выставляет оценку от 1 до 5 правильности и естественности сгенерированного текста. Почему-то разработчики использовали GPT-4o-mini, хотя у нее самой, на мой взгляд, есть проблемы с мультиязычностью. Возможно, более правильной оценки можно добиться, используя тот же DeepSeek V3. В итоговый датасет попали только те ответы, у которых наилучшая оценка по пятибалльной шкале.

После этого датасет готов к файнтюнингу моделей рассуждений — дистиллированных на R1 версий Qwen. Для файнтюнинга моделей от 1.5 до 14B авторы использовали llamafactory (код доступен в репозитории на HF по ссылке выше) и достаточно скромные GPU-мощности: всего лишь около 10 минут на восьми NVIDIA L20. Т.е. Вы вполне можете взять GPU поменьше — например, из доступных моделей в облаке подошли бы две RTX 4090 или A10, или одна V100 - и за несколько часов достичь того же результата.

В остальном это обычный SFT-файнтюнинг в одну эпоху, без квантизации. Отдельно стоит отметить процесс evaluation — код можно найти здесь. Ниже — таблица оценок полученных моделей рассуждений для промптов на разных языках. Из нее можно сделать вывод, что модели генерируют более корректные цепочки на таких языках, как английский, немецкий, испанский и другие, наличие которых в корпусе базовой модели, можно предположить, было относительно высоким. Их оценка около 0.8, тогда как у менее распространенных в цифровом пространстве языков она ниже, например, 0.2 у тамильского.

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