Донавчання LLM методом Instruction Tuning: повний посібник

Зазначимо: коли внутрішній помічник на базі LLM генерує загальні міркування замість відповідей за регламентом — це типова проблема base-моделі. Ви даєте інструкцію «Напиши відповідь клієнту за шаблоном CRM», а вона видає абстрактний текст. Щоб перетворити загальну модель на асистента, який розуміє контекст компанії, потрібен інструктивне навчання (instruction tuning). Цей метод налаштовує модель на корпоративну мову та стандарти, гарантуючи передбачувані відповіді. Підхід у 2–3 рази ефективніший за традиційний fine-tuning для завдань, що вимагають дотримання складних текстових інструкцій. Наприклад, доналаштування Llama 3.1 8B на 2000 прикладів коштує близько 150 000 грн, що на 60% дешевше за навчання з нуля. Середня економія бюджету на такому проекті становить 200 000–500 000 грн за рахунок виключення необхідності навчання з нуля.

Чим відрізняється Base LLM від Instruct?

Base LLM (наприклад, Llama 3.1 8B) просто продовжує текст. Дайте їй початок — вона продовжить, але не відповість як асистент. Instruct LLM (Llama 3.1 8B Instruct) виконує інструкції: відповідає, аналізує, відмовляється від небажаного контенту. При донавчанні корпоративної моделі ми зазвичай беремо готову Instruct-версію (Llama Instruct, Mistral Instruct) і адаптуємо під домен. Але іноді потрібен повноцінний Instruction Tuning з нуля — наприклад, для роботи з base-моделлю або перевизначення поведінки.

Які формати даних використовуються для Instruction Tuning?

{
  "instruction": "Переклади текст з англійської на українську",
  "input": "The contract must be signed before the deadline",
  "output": "Договір повинен бути підписаний до кінця терміну"
}

{
  "conversations": [
    {"from": "human", "value": "Проаналізуй баланс компанії"},
    {"from": "gpt", "value": "Для аналізу балансу потрібні наступні показники..."},
    {"from": "human", "value": "Як інтерпретувати співвідношення активів?"},
    {"from": "gpt", "value": "Співвідношення поточних та довгострокових активів показує..."}
  ]
}

messages = [
    {"role": "system", "content": "Ти — асистент з фінансового аналізу"},
    {"role": "user", "content": "Розрахуй ROE"},
    {"role": "assistant", "content": "ROE = Чистий прибуток / Власний капітал × 100%..."},
]
formatted = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)

Оптимальний обсяг даних для Instruction Tuning

Дослідження LIMA показало: 1000 якісних прикладів працюють так само добре, як 52000 звичайних. Інструктивне навчання потребує в 52 рази менше даних для досягнення високої якості порівняно з традиційним донавчанням. Якість важливіша за кількість. Орієнтири для спеціалізованого Instruction Tuning:

Ключова роль Instruction Tuning у корпоративному ІІ

Бізнес-асистент повинен не просто відповідати, а дотримуватись регламентів, корпоративного тону та термінології. Без інструктивного навчання модель може генерувати стилістично невірні відповіді або розголошувати конфіденційну інформацію. Ми донавчали Llama 3.1 8B на 1800 прикладах внутрішніх переписок IT-компанії. Результат: дотримання корпоративного тону (adherence to corporate tone) зросло з 2.9 до 4.4 (за LLM-judge), точність доменної термінології — з 61% до 87%, коректні відмови — з 34% до 89%, а хибні відмови знизились з 8% до 2%. У датасет ми включили negative examples — запити, на які модель повинна відмовляти (конкуренти, персональні дані). Економія бюджету порівняно з навчанням з нуля може досягати 60%, що в грошовому виразі становить сотні тисяч гривень на проект.

from trl import SFTTrainer, SFTConfig
from peft import LoraConfig

trainer = SFTTrainer(
    model=model,
    args=SFTConfig(
        output_dir="./corporate-instruct",
        num_train_epochs=4,
        learning_rate=2e-4,
        per_device_train_batch_size=4,
        gradient_accumulation_steps=4,
        max_seq_length=2048,
        bf16=True,
        dataset_text_field="text",
    ),
    train_dataset=formatted_dataset,
    peft_config=LoraConfig(r=16, lora_alpha=32, target_modules=["q_proj","v_proj"]),
)

Методологія збору якісного датасету

1. Визначте цілі: який стиль і тон потрібні, які теми охопити.
2. Зберіть корпоративні документи: внутрішні переписки, регламенти, FAQ.
3. Згенеруйте інструкції: використовуйте LLM для створення прикладів на основі документів.
4. Перевірте якість: видаліть невідповідності, виправте помилки.
5. Відформатуйте датасет: оберіть Alpaca, ShareGPT або Chat Template.

Приклад генерації інструкцій через LLM:

def document_to_instructions(doc_text: str, llm_client) -> list:
    response = llm_client.chat.completions.create(
        model="gpt-4o",
        messages=[{
            "role": "user",
            "content": f"""З наступного документа створи 10 навчальних прикладів для LLM.
Кожен приклад: {{"instruction": "завдання", "output": "правильна відповідь на основі документа"}}.
Різноманіть типи завдань: питання, сумаризація, аналіз, порівняння.

Документ:
{doc_text[:3000]}

Поверни JSON-масив прикладів."""
        }],
    )
    return json.loads(response.choices[0].message.content)

Процес роботи

Строки та вартість

• Проектування датасету та збір джерел: 2–3 тижні
• Генерація та верифікація прикладів: 2–4 тижні
• Навчання та ітерації: 1–2 тижні
• Разом: від 5 до 9 тижнів

Вартість розраховується індивідуально залежно від обсягу датасету, розміру моделі та необхідних ітерацій. Для точної оцінки зв'яжіться з нами — надамо детальний комерційний план. Економія бюджету порівняно з навчанням з нуля може досягати 60%.

Що входить у роботу

• Формування датасету: скрипти генерації, верифікація, розмітка
• Код навчання з використанням сучасного стеку (TRL, Transformers, PEFT)
• Експорт навченої моделі в потрібний формат (GGUF, ONNX, SafeTensors)
• Документація з архітектури, конфігів та метрик
• Доступ до репозиторію з кодом та датасетом
• Підтримка протягом 30 днів після здачі

Типові помилки при Instruction Tuning

• Нечисті дані: відповіді з помилками, неузгоджений стиль
• Ігнорування маскування loss на промпті — модель вчиться запам'ятовувати інструкцію, а не відповідати
• Занадто маленький learning rate (1e-4–5e-5 оптимально для LoRA)
• Недостатня різноманітність інструкцій — модель перевчається на вузький патерн

Instruction Tuning — це метод, який перетворює загальну LLM на асистента, що говорить мовою вашої компанії. Наш досвід: більше 5 років у NLP та CV, 50+ проектів з донавчання LLM для корпоративних замовників. Зв'яжіться з нами, щоб обговорити ваш проект. Отримайте консультацію з налаштування Instruction Tuning.

Ссилка: Instruction Tuning на Wikipedia

Практичний розбір 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 або гібрид — розповімо, що підійде саме вам.