Дообучение (Fine-Tuning) языковой модели Qwen (Alibaba)

Мы часто сталкиваемся с ситуацией: готовая LLM не понимает корпоративную терминологию или ошибается в расчётах по шаблону. Fine-tuning Qwen2.5 от Alibaba решает эту проблему — модель адаптируется под ваш домен, язык и формат вывода. По данным технического отчёта Qwen2.5, MMLU score достигает 85%, что выше, чем у многих open-source моделей. Например, Qwen2.5-72B превосходит Llama 3.1 70B в MMLU на 2 процентных пункта, а на китайских задачах — на 15%. Это семейство моделей от 0,5B до 72B параметров под лицензией Apache 2.0 (базовые версии) и Tongyi Qianwen License (крупные). Специализированные варианты: Qwen2.5-Coder для программирования, Qwen2.5-Math для математики и Qwen-VL для мультимодальных задач. Если вам нужно обрабатывать длинные документы (договоры, научные статьи, нормативные акты), Qwen2.5 поддерживает контекст до 128K токенов. Для большинства продуктовых задач выбирают 7B или 14B, но если требуется максимальная точность — 72B. А для edge-устройств подходят 0.5B и 1.5B.

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

Для большинства продуктовых задач достаточно 7B или 14B. 0.5B и 1.5B подходят для инференса на устройствах, 72B — для максимальной точности на сложных сценариях.

QLoRA использует 4-битную квантизацию весов, что позволяет дообучать 7B модель на одной A100 40GB. При этом качество падает не более чем на 2% относительно полного fine-tuning. Снижение затрат на вычислительные ресурсы: использование QLoRA вместо Full сокращает стоимость GPU-часов значительно — примерно в 2 раза за эксперимент на 7B модели.

Почему Qwen удобен для многоязычных и длинных контекстов?

Многоязычность: Qwen обучен на данных с существенной долей китайского, английского и ещё 27 языков. Русский язык представлен значительно лучше, чем в ряде западных моделей, что важно при работе с русскоязычными корпусами.

Длинный контекст: Qwen2.5 поддерживает до 128K токенов. При fine-tuning задач с длинными документами (договоры, научные статьи, нормативные акты) это критическое преимущество.

Qwen2.5-Coder: специализированная версия, превосходящая по HumanEval большинство открытых моделей того же размера. При дообучении на корпоративной кодовой базе даёт лучший старт, чем дообучение общей модели.

Как подготовить датасет для fine-tuning Qwen?

1. Сбор данных: соберите от 500 до 2000 примеров, релевантных вашей задаче. Для финансового анализа — отчёты с расчётами.
2. Очистка: удалите дубликаты, исправьте опечатки, проверьте соответствие формату.
3. Разметка: каждый пример должен содержать пару user-assistant в формате chat template Qwen.
4. Валидация: создайте тестовую выборку (10% от датасета) для оценки качества.

Сравнение методов fine-tuning

QLoRA снижает требования к памяти в 7 раз без критической потери качества — оптимальный выбор для быстрых экспериментов.

Fine-tuning через LLaMA-Factory

LLaMA-Factory — наиболее удобный инструмент для fine-tuning Qwen, поддерживающий весь спектр методов (Full, LoRA, QLoRA, DoRA) с единым конфигурационным форматом:

# config.yaml
model_name_or_path: Qwen/Qwen2.5-7B-Instruct
method: lora
dataset: my_dataset
template: qwen
finetuning_type: lora
lora_rank: 16
lora_alpha: 32
lora_target: q_proj,v_proj
output_dir: ./qwen25-7b-finetuned
num_train_epochs: 3
per_device_train_batch_size: 4
gradient_accumulation_steps: 4
learning_rate: 2.0e-4
lr_scheduler_type: cosine
warmup_ratio: 0.1
bf16: true

llamafactory-cli train config.yaml

Альтернативно — использование swift от ModelScope (Alibaba):

swift sft \
  --model_type qwen2_5_7b_instruct \
  --dataset my_dataset \
  --train_type lora \
  --output_dir ./output

Формат данных: Qwen Chat Template

Qwen2.5 использует специфический chat template с тегами <|im_start|> и <|im_end|>:

<|im_start|>system
Ты — ассистент для анализа финансовой отчётности.<|im_end|>
<|im_start|>user
Рассчитай EBITDA по данным: выручка 850M, COGS 420M, OpEx 180M, DA 45M<|im_end|>
<|im_start|>assistant
EBITDA = Выручка - COGS - OpEx + DA = 850 - 420 - 180 + 45 = 295M<|im_end|>

При использовании transformers напрямую применяем tokenizer.apply_chat_template() для корректного форматирования.

Практический кейс: финансовый анализ на Qwen2.5-14B

Из нашей практики: клиенту требовался автоматический анализ квартальных отчётов по МСФО с извлечением показателей, расчётом коэффициентов и флагами аномалий. Датасет — 1800 примеров из корпоративной отчётности. Мы дообучали Qwen2.5-14B Instruct через QLoRA (r=32, alpha=64), 4 эпохи, на 2×A100 40GB за 6 часов. Результаты:

• Корректность расчёта коэффициентов: 71% → 94%
• Точность флагов аномалий (F1): 0.67 → 0.88
• Качество текстового резюме (human eval, 1–5): 3.1 → 4.4

Qwen2.5-14B превзошёл Llama 3.1 8B на 12% по точности извлечения показателей. MMLU и HumanEval подтверждают конкурентные позиции модели. Экономия на инференсе: vLLM с INT4 квантизацией позволяет снизить стоимость на 40% по сравнению с bf16, что даёт экономию до нескольких сотен долларов в месяц при нагрузке 100k запросов.

Деплой дообученной Qwen через vLLM

from vllm import LLM, SamplingParams

llm = LLM(
    model="./qwen25-14b-merged",
    dtype="bfloat16",
    tensor_parallel_size=2,  # 2 GPU
    max_model_len=32768,
    gpu_memory_utilization=0.9
)

sampling_params = SamplingParams(temperature=0.1, max_tokens=2048)
outputs = llm.generate(prompts, sampling_params)

vLLM обеспечивает continuous batching и PagedAttention, что при batch размере 16 даёт throughput ~240 tok/s на 2×A100. Это в 3 раза выше, чем vanilla Transformers.

Что входит в работу по дообучению Qwen?

• Анализ задачи и сбор требований
• Подготовка датасета: очистка, разметка, проверка качества
• Настройка конфигурации обучения (LoRA/QLoRA, гиперпараметры)
• Обучение и промежуточная оценка метрик
• Сравнение baseline vs fine-tuned на тестовой выборке
• Деплой на выбранной инфраструктуре (vLLM, Triton, SageMaker)
• Документация результата и обучение команды

Дополнительно: предоставляем доступ к нашим тестовым стендам и метрикам. Оцените свой проект — напишите нам. Наша команда имеет большой опыт в NLP и доработке LLM, выполнили более 30 проектов по fine-tuning.

Сроки

• Подготовка датасета: 2–5 недель
• Обучение (7B, QLoRA): 3–8 часов
• Обучение (72B, QLoRA, 4×A100): 24–72 часа
• Итерации и оценка: 1–2 недели
• Итого: 4–8 недель

Закажите дообучение Qwen под ключ — получите модель, которая понимает ваш бизнес. Свяжитесь с нами для консультации.

Практический разбор LLM: fine-tuning, RAG, агенты, деплой

Модель GPT‑4 или Claude 3.5 Sonnet через публичное API — не решение, а просто инструмент. Когда приходит требование «сделать как ChatGPT, но на наших данных», за ним стоит реальная инженерная задача: от настройки промптов до обучения 70B‑модели на собственной инфраструктуре. Разработка решений на базе LLM под ключ — это сложный стек, и мы занимаемся этим более 5 лет. За это время реализовано свыше 20 проектов в области генеративного AI: от RAG‑систем для юридических департаментов до кастомных агентов для техподдержки. Где именно находится ваша задача — зависит от данных, latency‑требований, бюджета и того, насколько критична конфиденциальность.

Типичная ситуация: клиент уже попробовал ChatGPT, но результаты нестабильны — то отвечает точно, то галлюцинирует. Либо нужна интеграция в корпоративный портал с соблюдением политик безопасности. Разберём каждый слой стека в деталях — от RAG до production‑деплоя.

Почему RAG‑системы ломаются и как это исправить?

RAG (Retrieval‑Augmented Generation) выглядит просто: нашли релевантные документы, положили в контекст, модель ответила. На практике сбоит в нескольких местах.

Chunking без перекрытия. Классическая ошибка: chunk_size=512, overlap=0. Если ответ лежит на границе двух чанков, retrieval не найдёт ни одного с достаточной уверенностью. Решение: overlap 15–25% от chunk_size, а лучше sentence‑aware splitting через spaCy или NLTK, а не наивное разбиение по символам.

Плохой embedder. Текст‑embedding‑ada‑002 — хорош для общего случая, но на юридических или медицинских текстах проигрывает специализированным моделям: E5‑large‑v2, BGE‑M3 или fine‑tuned sentence‑transformers на доменных данных. Разница в Recall@5 может составлять 15–25%.

Отсутствие re‑ranking. Векторный поиск оптимизирован по скорости, не по релевантности. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) после первичного retrieval поднимает точность топ‑3 при приемлемой задержке (+50–150 ms). Это часто важнее улучшения embedding‑модели.

Гибридный поиск. Только dense векторы плохо работают на точных запросах: имена, артикулы, коды. BM25 (sparse) хорошо находит точные совпадения, но не понимает семантику. Гибрид через RRF (Reciprocal Rank Fusion) — оптимальный компромисс. Qdrant, Weaviate и pgvector 0.7+ поддерживают гибридный поиск нативно.

Когда стоит fine‑tune, а не промпт‑инжиниринг?

Промпт‑инжиниринг решает ~70% задач адаптации LLM под домен. Оставшиеся 30% требуют дообучения. Три признака: модель игнорирует специфический формат вывода даже при детальном описании в промпте; задача требует глубокого знания специализированной лексики (медицина, право); нужно значительно снизить затраты на токены, заменив большую модель меньшей специализированной.

LoRA и QLoRA — стандарт для SFT. LoRA добавляет trainable low‑rank матрицы к attention‑слоям. Типичная конфигурация для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — обучаемых параметров ~0.8%, обучение на одной A100 40GB. QLoRA добавляет 4‑битную квантизацию (NF4) и позволяет fine‑tune 70B модель на двух A100 40GB, хотя скорость падает вдвое по сравнению с bf16.

DPO вместо RLHF. Direct Preference Optimization требует только пары (chosen, rejected), а не скалярные reward‑сигналы. DPOTrainer из библиотеки trl (Hugging Face) реализует это несколькими десятками строк.

Типичная ошибка. Датасет из 500 примеров, 5 эпох, validation loss 0.8 — кажется норм. Но на тесте модель деградировала на общих инструкциях. Причина: catastrophic forgetting. Решение — добавить 10–20% общих instruction‑following примеров (Alpaca, FLAN) в обучающую выборку, чтобы не разрушить исходные способности.

Как выбрать базовую модель: 8B или 70B?

Для большинства задач fine‑tuning 8B модели достаточно. 70B нужен, когда требуется глубокое рассуждение или baseline 8B не достигает нужного качества даже после дообучения. Стоимость инференса Llama‑3 8B через vLLM на A100 — около $0.001/1K токенов, что в 15 раз дешевле GPT‑4.

Что даёт PagedAttention в production?

vLLM — первый выбор для serving open‑source моделей. PagedAttention — ключевое техническое решение: KV‑cache управляется как virtual memory в ОС, без фрагментации. Это даёт throughput в 2–4 раза выше по сравнению с наивным HuggingFace Transformers inference. Документация vLLM подтверждает: continuous batching и PagedAttention — стандарт для высоконагруженных LLM‑сервисов.

Типичные числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двух A100 с tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизация AWQ или GPTQ снижает потребление памяти в 2 раза при потере качества в пределах 1–3%.

Мультиагентные системы

Агенты — LLM с доступом к инструментам: поиск, выполнение кода, запросы к API, работа с БД. Основные паттерны:

• ReAct (Reason + Act): модель рассуждает → выбирает инструмент → наблюдает результат → снова рассуждает. LangChain и LlamaIndex реализуют из коробки.
• Multi‑agent orchestration: несколько специализированных агентов с координатором сверху. Пример: coordinator → researcher (поиск + summarization) → coder (генерация и исполнение кода) → critic (проверка). Инструменты: AutoGen (Microsoft), CrewAI, кастомная реализация на LangGraph.

В продакшене агентные системы недетерминированы. Обязательные guardrails, лимиты шагов, логирование каждого шага, human‑in‑the‑loop для критических действий.

Как мы работаем: этапы, сроки, результат

Что входит в работу

Мы передаём:

• Техническую документацию (model card, конфиги, инструкции по развёртыванию)
• Доступ к инфраструктуре (репозиторий с кодом, обученные веса)
• 1 месяц поддержки после деплоя (консультации, правки по багам)
• Обучение команды заказчика (2–3 занятия по эксплуатации системы)

Сроки: базовый RAG‑прототип — 1–2 недели. Fine‑tuning с данными заказчика — 3–6 недель (с учётом подготовки данных). Production‑система с мониторингом и переобучением — 2–4 месяца. Стоимость рассчитывается индивидуально, зависит от объёма данных, сложности модели и требований к инфраструктуре.

Хотите оценить свой проект? Оставьте заявку — мы подготовим предварительное резюме за 1–2 рабочих дня. Или получите консультацию по выбору подхода: RAG, fine‑tuning или гибрид — расскажем, что подойдёт именно вам.