Дообучення (Fine-Tuning) мовної моделі Qwen (Alibaba)

Ми часто стикаємося з ситуацією: готова LLM не розуміє корпоративної термінології або помиляється в розрахунках за шаблоном. Fine-tuning Qwen2.5 від Alibaba вирішує цю проблему — модель адаптується під ваш домен, мову та формат виведення. Qwen — потужна багатомовна модель, яка за даними технічного звіту досягає MMLU score 85%, що вище, ніж у багатьох open-source моделей. Наприклад, Qwen2.5-72B перевершує Llama 3.1 70B в MMLU на 2 процентних пункти, а на китайських завданнях — на 15%. Qwen2.5-7B обробляє українські тексти в 2 рази швидше, ніж Mistral 7B. Це сімейство моделей від 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 скорочує вимоги до пам'яті в 7 разів порівняно із повним fine-tuning, а вартість GPU-годин знижується вдвічі. Вартість fine-tuning 7B моделі на 2×A100 (8 годин) становить близько $200, а 72B моделі (72 години) — близько $1800. Економія від використання vLLM з INT4 квантизацією становить до $500 на місяць при навантаженні 100k запитів. Ми гарантуємо якість дообучення та надаємо підтримку після деплою. Наша команда має сертифікати з NLP та досвід понад 30 проектів.

Переваги Qwen для багатомовності та довгих контекстів

Багатомовність: Qwen навчений на даних із суттєвою часткою китайської, англійської та ще 27 мов. Українська та російська мови представлені значно краще, ніж у ряді західних моделей, що важливо при роботі з україномовними/російськомовними корпусами.

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

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

Як підготувати набір даних для fine-tuning Qwen?

1. Збір даних: зберіть від 500 до 2000 прикладів, релевантних вашому завданню. Для фінансового аналізу NLP — звіти з розрахунками.
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 значно нижча, ніж у 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 для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

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

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.