CrowsHaveEyes

Теперь о минусах 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, для самовалидации системой извлеченной информации и ее автоматического итеративного приближения к ожидаемому результату.

Выполнена выборка промптов из открытых англоязычных датасетов с последующим переводом на различные языки. Для перевода использовалась 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 примера на русском.

От поставленных на предыдущем этапе целей для MVP вашего агента и от собранных данных зависит решение, какую именно LLM использовать, и какой будет архитектура всей системы. Выбор сейчас очень широкий - есть модели с открытым исходным кодом и коммерческие решения, и выбор, очевидно, влияет на последующую инфраструктуру и масштабирование. Например, многие разработчики обращаются к моделям с открытыми весами наподобие LLaMA, учитывая их гибкость и возможность дальнейшего файнтюнинга. Однако вычислительные требования и довольно сложный программный стек накладывают определенные ограничения. Необходимо рассчитать заранее мощности, ваша инфраструктура в большинстве случаев должна поддерживать CUDA или один из немногочисленных альтернативных фреймворков для GPU-ускорения (можно посмотреть в сторону облачных платформ, где CUDA-стек поставляется из коробки), а также возможность интеграции с ML-библиотеками, такими как PyTorch или TensorFlow.

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

Самая замечательная часть - обучение и оптимизация модели. Чаще всего это файнтюнинг - если используется предобученная LLM, то её можно адаптировать под конкретные задачи с помощью дополнительного обучения на специализированных датасетах. Затем происходит настройка гиперпараметров, промпт-инжиниринг и оптимизация модели под конкретные сценарии использования. На этом этапе не обходится без множества evaluation-тестов. Можно взять очень общий пример - бенчмарк MT-bench для проверки на следование инструкциям. Но агенты чаще всего специализированы под конкретные случаи использования, так что полезно будет собрать свой кастомный evaluation датасет. Это позволит облегчить ручное тестирование.

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

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

Наконец, пару слов о финальном этапе разработки – это развертывание системы в рабочей среде и её последующее обслуживание. Нужно быть готовым к частым обновлениям - в стремительно развивающейся ML-отрасли LLM приходится постоянно дообучать, а то и менять на совершенно новые, сегодня GPT-4o, а завтра DeepSeek. Вычислительные ресурсы при этом то и дело приходится масштабировать. Поэтому для поддержки агентской системы понадобится полноценная MLOps-команда. Это лишь некоторые из трудностей, поскольку, возвращаясь к первоначальной мысли этой статьи, разработка агентских систем - во многом неисследованная территория.

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

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

Помимо Grok 3 и Grok 3 mini, xAI выпустили в релиз две бета-модели рассуждений - Grok 3 (Think) и Grok 3 mini (Think). Как легко догадаться, они обучены на весах двух названных базовых моделей с помощью Reinforcement Learning совершенствовать процесс chain-of-thoughts. Это позволяет моделям Think находить оптимальные стратегии решения задач, находить ошибки в своих рассуждениях, то есть делать все то, чему обучены OpenAI o1 и DeepSeek R1. На процесс рассуждений у Grok 3 может уходить от нескольких секунд до нескольких минут.

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

Особенность Grok 3 в том, что Reinforcement Learning осуществлялся в GPU-кластере невиданных до этого масштабов.

Доступ к Grok 3 первоначально предоставлялся подписчикам X уровня Premium+, стоимость которой составляет около $40 в месяц. Кроме того, xAI предлагает подписку SuperGrok за $30 в месяц или $300 в год, предоставляющую расширенные возможности, включая доступ к новым функциям и неограниченное количество кредитов для генерации изображений.

Впоследствии, однако, xAI анонсировала в X, что доступ к чат-боту с Grok 3 в настоящее время предоставляется бесплатно, “пока наши сервера не расплавятся”.

В посте также говорится, что подписчики X Premium+ и SuperGrok получат расширенный функционал, а также ранний доступ к возможностям вроде Voice Mode, которые еще не вышли в релиз.

Здесь следует отметить, что речь идет об использовании модели Grok 3 через интерфейс чатбота. В ближайших планах xAI — добавить в Grok 3 голосовой режим и предоставить программный доступ к модели через API.

Особенный интерес представляют агенты на базе Grok 3, первый из них - DeepSearch - уже доступен через интерфейс чата. Он также будет доступен через корпоративный API, чтобы компании автоматизировали с его помощью свои бизнес-процессы.

Как заявили xAI в анонсе Grok 3:

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

Сам по себе Chain-of-Thoughts - это формат промпта, который заставляет модель строить цепочки мыслей вроде этой. Но как в случае с моделью Marco, чтобы нейросеть могла эффективно работать с таким форматом, ее нужно файнтюнить на Chain-of-Thoughts датасете. Точно так же Instruct модель требует файнтюнинга на данных с определенной структурой промптов и ответов.

Marco o1 также использует алгоритм поиска по дереву Монте-Карло (MCTS), который, согласно статье разработчиков, позволяет исследовать несколько путей рассуждения, используя показатель достоверности, полученный из логарифмических вероятностей топ-K альтернативных токенов. К этому значению вероятности для каждого токена и к пяти альтернативным значениям применяют функцию softmax и получают показатель достоверности C(i) для i-того токена. Потом вычисляют среднее значение для всех пяти альтернатив. Более высокое среднее значение показывает большую уверенность в том, что выбранный путь рассуждения является более оптимальным.

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

Дальше есть еще пара интересных идей, например, Action Selection. Чтобы использовать только что описанный алгоритм MCTS, нужно определиться, что использовать в качестве единицы в пространстве решений, или одного шага рассуждения, и для этого разработчики применяли разные подходы - как целый шаг или действие в качестве единицы, так и мини-шаг - 32 или 63 токена.

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

А теперь немного практической части. Веса модели Marco-o1 имеют всего 7 миллиардов параметров. Я запускал ее и локально, и в облаке, в обоих случаях особо мощная видеокарта не требуется, особенно если применять квантизацию. Локально я запустил модель на RTX 4060 c 4-битной квантизацией bitsandbytes.

У меня была идея задеплоить полноценный LLM-server, совместимый с openai или gradio клиентом, и я выбрал два решения:

Первое - Text Generation Inference: на этот сервер уже был обзор на моем YouTube-канале, он высокопроизводительный, поддерживается платформой Huggingface, предлагает квантизацию и другие полезные фичи из коробки.

Запустить TGI локально не проблема, простой и правильный путь - в докере. Иначе придется устанавливать Rust и прочие зависимости, это ни к чему. Команда для запуска:

docker run --gpus all --shm-size 1g -p 8080:80 -v $path_to_volume:/data \

ghcr.io/huggingface/text-generation-inference:2.4.1 --model-id AIDC-AI/Marco-o1 --quantize bitsandbytes-nf4

Докер должен поддерживать GPU, что вообще не проблема на Linux или на Windows с WSL2. Флаг --quantize опциональный - можете выбрать опцию bitsandbytes (по умолчанию 8 бит) или вообще без сжатия, если есть достаточно видеопамяти.

В итоге на 4060 инференс получился очень быстрый. Я использовал следующий код для фронтенда на gradio:
статье.

import gradio as gr

from huggingface_hub import InferenceClient

client = InferenceClient("http://127.0.0.1:8080")

def respond(
message,

history: list[tuple[str, str]],

system_message,

max_tokens,

temperature,

top_p,

):
messages = [{"role": "system", "content": system_message}]

for val in history:

if val[0]:

messages.append({"role": "user", "content": val[0]})

if val[1]:

messages.append({"role": "assistant", "content": val[1]})

messages.append({"role": "user", "content": message})

response = ""
for message in client.chat_completion(

messages,

max_tokens=max_tokens,

stream=True,

temperature=temperature,

top_p=top_p,

):
token = message.choices[0].delta.content

response += token

yield response

system_prompt = """You are a well-trained AI assistant, your name is Marco-o1. Created by AI Business of Alibaba International Digital Business Group.

## IMPORTANT!!!!!!

When you answer questions, your thinking should be done in <Thought>, and your results should be output in <Output>.

<Thought> should be in English as much as possible, but there are 2 exceptions, one is the reference to the original text, and the other is that mathematics should use markdown format, and the output in <Output> needs to follow the language of the user input.

"""

demo = gr.ChatInterface(

respond,

additional_inputs=[

gr.Textbox(value=system_prompt, label="System message"),

gr.Slider(minimum=1, maximum=2048, value=1, step=1, label="Max new tokens"),

gr.Slider(minimum=0.1, maximum=4.0, value=0.7, step=0.1, label="Temperature"),

gr.Slider(

minimum=0.1,

maximum=1.0,

value=0.95,

step=0.05,

label="Top-p (nucleus sampling)",

),

],

)

if __name__ == "__main__":

demo.launch()

Однако я столкнулся с одной проблемой - системный промпт. Он взят из ollama, которая с таким промптом прекрасно работает. А вот TGI выдает ошибку, когда промпт превышает определенную длину. Так что для тех, кто не хочет возиться, предпочтительнее будет ollama, с ней все просто:

ollama pull marco-o1

ollama serve

А о том, как запустить ollama как сервис, чтобы создать таким образом свой LLM-сервер, я расскажу в следующей статье.