Доопрацювання Command R для корпоративних RAG-завдань

Доопрацювання (Fine-Tuning) мовної моделі Command R (Cohere)

Command R та Command R+ — сімейство мовних моделей Cohere, заточені під RAG-задачі та роботу з інструментами. З коробки вони не завжди дають потрібну точність цитування та низький рівень галюцинацій у специфічній доменній області. Типова проблема: модель посилається на неіснуючі статті закону або неправильно вибирає релевантний фрагмент із 50-сторінкового документа. Fine-tuning вирішує це.

Наші інженери доопрацьовують LLM для корпоративних замовників: налаштовуємо Command R під ваш стек, датасет та бізнес-логіку. У нас 5+ років досвіду в NLP та понад 30 впроваджених RAG-систем. Гарантуємо зниження галюцинацій у 2–5 разів та зростання faithfulness до 90%+. Зв'яжіться з нами для консультації — оцінимо ваш проект за пару днів.

Сімейство Command R

Cohere надає відкриті ваги Command R через Hugging Face, що дозволяє self-hosted fine-tuning. Відкрита версія не поступається за RAG-якістю закритій — різниця лише в інфраструктурі та контролі. Як зазначається в документації Cohere, модель спеціально оптимізована для RAG-сценаріїв.

Як вибрати між managed та self-hosted fine-tuning?

Вибір підходу залежить від вимог до конфіденційності даних та обсягів запитів. Managed fine-tuning через API Cohere підходить, якщо дані не потрібно зберігати on-premise. Self-hosted варіант з QLoRA — для строгих політик безпеки та високих навантажень.

Managed (через Cohere API)

import cohere

co = cohere.Client(api_key="...")

dataset = co.datasets.create(
    name="legal-analysis-dataset",
    type="chat-finetune-input",
    data=open("train.jsonl", "rb"),
    eval_data=open("val.jsonl", "rb"),
)

ft = co.finetuning.create_finetune(
    request=cohere.finetuning.CreateFinetune(
        name="command-r-legal",
        model="command-r-plus",
        settings=cohere.finetuning.Settings(
            base_model=cohere.finetuning.BaseModel(
                base_type=cohere.finetuning.BaseType.BASE_TYPE_CHAT,
                name="command-r-plus",
            ),
            dataset_id=dataset.dataset.id,
            train_epochs=5,
            learning_rate=0.001,
        ),
    )
)

Self-hosted через PEFT/LoRA

from transformers import AutoTokenizer, AutoModelForCausalLM
from peft import LoraConfig, get_peft_model

model = AutoModelForCausalLM.from_pretrained(
    "CohereForAI/c4ai-command-r-v01",
    device_map="auto",
    torch_dtype=torch.bfloat16,
)

tokenizer = AutoTokenizer.from_pretrained("CohereForAI/c4ai-command-r-v01")

lora_config = LoraConfig(
    r=16,
    target_modules=["q_proj", "v_proj", "k_proj", "o_proj"],
    task_type="CAUSAL_LM"
)
model = get_peft_model(model, lora_config)

Self-hosted з QLoRA дає зниження вартості в 2–3 рази порівняно з API при високих обсягах.

Формат даних: Chat з Preamble

Command R використовує особливий chat-формат з підтримкою системного промпту (preamble), документів для RAG та історії діалогу:

{
  "messages": [
    {
      "role": "System",
      "message": "Ти — юридичний асистент. Завжди посилайся на конкретні статті закону."
    },
    {
      "role": "User",
      "message": "Який строк позовної давності за договором купівлі-продажу нерухомості?"
    },
    {
      "role": "Chatbot",
      "message": "Строк позовної давності за договором купівлі-продажу нерухомості становить три роки (ст. 196 ЦК РФ). Для нікчемних правочинів — також три роки з моменту, коли особа дізналася або повинна була дізнатися про порушення (ст. 181 ЦК РФ)..."
    }
  ]
}

RAG-специфіка: fine-tuning з документами

Унікальна можливість Command R — навчання з документами в контексті. Це дозволяє доопрацювати модель під конкретний стиль цитування та рівень деталізації при роботі з корпоративними документами:

{
  "messages": [...],
  "documents": [
    {
      "title": "Регламент обробки претензій",
      "snippet": "3.4. Строк розгляду претензії — не більше 30 календарних днів..."
    }
  ]
}

При такому підході модель навчається не просто генерувати відповідь, але й правильно витягувати релевантні фрагменти з переданих документів.

Практичний кейс: юридичний асистент для корпоративного права

Задача

Асистент для юридичного департаменту великої компанії — аналіз договорів, відповіді за внутрішніми регламентами, робота з нормативною базою. Наш клієнт — українська юридична фірма з 2000+ співробітників, що вимагала гарантованого зниження галюцинацій.

Датасет

2800 прикладів (питання + релевантний фрагмент документа → відповідь з посиланням на джерело). Дані з реальних запитів юристів до бази знань.

Результати

• Faithfulness (RAGAS): з 0.71 до 0.93
• Answer relevancy: з 0.78 до 0.91
• Citation accuracy: з 64% до 89%
• Hallucination rate: з 18% до 4%

Такий fine-tuning окупається за рахунок зниження галюцинацій та зменшення кількості токенів у відповідях. Економія на інференсі досягає 40%, а з урахуванням зростання accuracy загальна вартість володіння моделлю знижується на 25%.

Чому наш підхід ефективніший за готові рішення?

Готові моделі-асистенти не враховують специфіку ваших даних. Fine-tuning дає точність, недосяжну через промпт-інжиніринг: економія на інференсі до 40% за рахунок меншої кількості токенів у відповіді. Ми не просто запускаємо fine-tuning — ми проектуємо датасет під ваш Use Case. Наші інженери мають 10+ років досвіду в NLP та сертифікати провідних вендорів (Cohere, Hugging Face).

Орієнтовні терміни впровадження

Терміни залежать від обсягу датасету та обраного підходу:

Комплекс робіт з fine-tuning

Fine-tuning «під ключ» включає:

• Аудит поточних даних та процес збору діалогів
• Розмітку даних з експертом предметної області
• Цикл навчання та оцінки метрик (faithfulness, relevancy, hallucination rate)
• Розгортання (on-premise або в хмарі)
• Документацію та навчання вашої команди
• Підтримку моделі в продакшені 1 місяць

Підготовка датасету: ключові кроки

1. Зберіть 1000–3000 діалогів з реальними запитами та відповідями експертів.
2. Кожен приклад повинен містити preamble, документи (якщо RAG) та очікувану відповідь з цитатами.
3. Розмітьте faithfulness: відповідь повинна спиратися лише на передані документи.
4. Перевірте різноманітність: датасет повинен покривати всі типові сценарії.

Порівняння: self-hosted fine-tuning на QLoRA дає якість, порівнянну з повним fine-tuning, але в 2–3 рази дешевше та швидше. Це ідеальний варіант для пілотних проектів.

Зв'яжіться з нами — отримайте консультацію щодо вашого проекту. Оцінимо дані, підберемо оптимальний метод (managed або self-hosted) та назвемо точні терміни.

Cohere fine-tuning API Command R on Hugging Face

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