Розробка рішень на базі LLM та генеративного AI

LLM: Fine-tuning, RAG, Агенти та Production Розгортання

GPT-4 або Claude 3.5 Sonnet через API — це не рішення задачі, це інструмент. Коли приходить вимога "зробити ChatGPT-подібну систему на наших даних", за цим скривається спектр реальних задач: від настройки промптів до навчання моделі з 70B параметрів. Де саме розташована ваша задача — залежить від даних, вимог latency, бюджету та того, наскільки критична конфіденційність.

Розберемо кожен шар стеку окремо.

RAG: Де Найчастіше Ламається та Чому

RAG (Retrieval-Augmented Generation) — архітектурно простий: знайти релевантні документи, покласти в контекст, модель відповідає. На практиці ламається в кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох chunk'ів, retrieval не знайде жоден з них з достатньою впевненістю. Рішення: overlap 15-25%, розглянути sentence-aware splitting через spaCy або NLTK замість наївного розбиття за символами.

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

Відсутність re-ranking. Векторний пошук оптимізований по швидкості, не по релевантності. Cross-encoder re-ranking (ms-marco-MiniLM-L-6-v2, bge-reranker-large) після первинного retrieval істотно покращує точність топ-3 результатів при прийнятній latency (+50-150ms). Часто важливіше за поліпшення embedding-моделі.

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

Типова production-архітектура RAG-системи для корпоративної knowledge base: документи → preprocessing (PyMuPDF, Unstructured) → chunking → embedding (BGE-M3) → Qdrant → гібридний пошук → cross-encoder re-ranking → контекст → LLM (vLLM або OpenAI API) → відповідь з джерелами.

Fine-tuning: Коли Prompt Engineering Вже Не Допомагає

Prompt engineering розв'язує 70% задач адаптації LLM під домен. Решта 30% потребують fine-tuning. Ознаки того, що без нього не обійтись: модель ігнорує специфічний формат виводу навіть при детальному описі в промпті; задача потребує глибокого знання спеціалізованої лексики (медицина, право, техніка); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для supervised fine-tuning. LoRA додає trainable low-rank матриці до attention-шарів, не змінюючи основні ваги. Типова конфігурація для Llama-3 8B: r=64, lora_alpha=128, target_modules=["q_proj", "v_proj", "k_proj", "o_proj"]. Trainable параметрів ~0.8% від 8B — навчання укладається на одну A100 40GB.

QLoRA додає 4-бітну квантизацію базової моделі: завантажуємо в NF4 через bitsandbytes, учимо тільки LoRA-адаптери в bf16. Це дозволяє fine-tune 70B моделі на двох A100 40GB, хоча швидкість навчання падає приблизно вдвічі порівняно з повним bf16.

DPO замість RLHF. Direct Preference Optimization — більш проста альтернатива RLHF для alignment під стиль або переваги. Потребує пар (chosen, rejected) замість скалярних reward-сигналів. trl (Transformer Reinforcement Learning) від Hugging Face має готовий DPOTrainer — реалізація займає десятки рядків коду.

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

Prompt Engineering та Structured Outputs

Prompt engineering — це не "напиши хороший промпт". Це систематична робота з форматом, few-shot прикладами, chain-of-thought та управлінням контекстом.

Для задач, що потребують структурованого виводу (JSON, видобування сутностей, класифікація), використовуємо function calling / tool use (OpenAI, Claude, Mistral) або constrained generation через Outlines або Guidance. Це дає гарантований формат виводу без postprocessing regex.

Structured outputs через response_format={"type": "json_schema", ...} в OpenAI API — найнадійніший спосіб для production, де downstream-система очікує конкретну схему.

Оцінка промптів — окрема задача. Будуємо eval-датасети з 50-200 реальних прикладів з ground truth, прогоняємо автоматичні метрики (ROUGE, BERTScore для відкритих відповідей; accuracy для класифікації) плюс LLM-as-judge для якісної оцінки.

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

Агенти — LLM з доступом до інструментів: пошук в інтернеті, виконання коду, запити до API, робота з базами даних. Ключові паттерни:

ReAct (Reason + Act). Модель рассуджує → вибирає інструмент → спостерігає результат → рассуджує знову. LangChain та LlamaIndex реалізують цей паттерн з коробки. Для production рекомендуємо додавати timeout на інструменти та максимальну кількість кроків.

Multi-agent orchestration. Кілька спеціалізованих агентів з coordinator-агентом зверху. Наприклад: coordinator → researcher (пошук + summarization) + coder (генерація та виконання коду) + critic (перевірка). AutoGen (Microsoft), CrewAI або кастомна реалізація на LangGraph.

Практична замітка. Агентні системи недетерміновані. У production це означає: обов'язкові guardrails (валідація виводу, ліміти на кроки та вартість), логування кожного кроку, можливість human-in-the-loop для критичних дій.

vLLM та Production Розгортання LLM

Якщо задача — serving власної або open-source моделі під навантаженням, vLLM — перший вибір.

PagedAttention. Ключова інновація vLLM: KV-cache управляється як virtual memory в ОС, без фрагментації. Це дозволяє обробляти паралельні запити з різною довжиною контексту без зайвих копіювань пам'яті. Результат: throughput у 2-4x вище порівняно з наївним HuggingFace Transformers inference.

Continuous batching. Запити додаються в батч по мірі надходження, а не чекають формування повного батча. Знижує latency при нерівномірній навантаженості.

Типові числа на A100 80GB для Llama-3 8B (bf16): 400-600 req/s (output tokens/s), P50 latency 200-400ms, P99 latency 600-900ms при concurrency 64. Для 70B на двох A100 80GB з tensor parallelism: 80-120 req/s, P99 latency 1.5-2.5s.

Квантизація через AWQ або GPTQ знижує потребу в пам'яті в 2x при деградації якості в межах 1-3% на більшості benchmarks. На A10G (24GB) це дозволяє запустити 13B модель там, де без квантизації помішається тільки 7B.

Моніторинг розгортання. Логуємо: latency (P50/P95/P99), throughput (tokens/s), queue depth, cache hit rate. Grafana + Prometheus — стандарт. vLLM експортує метрики нативно у форматі Prometheus.

Вибір Базової Моделі

Для більшості задач fine-tuning 8B моделі достатньо. 70B потрібен коли задача потребує глибокого рассуджень або baseline 8B не досягає потрібної якості навіть після дообучення.

Етапи Роботи над LLM-Проектом

Аудит задачі. Формалізуємо що саме модель повинна робити, збираємо eval-датасет з 100+ реальних прикладів. Без eval неможливо виміряти прогрес.

Baseline через prompt engineering. Тестуємо OpenAI/Anthropic API з хорошо налаштованим системним промптом. Часто цього достатньо. Якщо ні — бачимо конкретний gap та розуміємо, що потрібно менять.

RAG або fine-tuning. Якщо проблема в знаннях про конкретні документи — RAG. Якщо проблема в стилі, форматі, специфічній лексиці — fine-tuning. Часто потрібне й те, й інше.

Навчання та валідація. Готуємо датасет, запускаємо навчання з трекингом у W&B, оцінюємо на holdout-сеті та на реальних користувацьких запитах.

Розгортання та моніторинг. vLLM на власній інфраструктурі або managed inference (Together, Replicate, Modal). Налаштування alert'ів на latency та якість.

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