Fine-tuned vs RAG:
баланс производительности

Когда что выбрать, как настроить, как сочетать. On-prem ВМ + Kubernetes + cloud.

60%
проектов в production используют оба подхода (2026)
40%
naive RAG pipeline fails при retrieval
15–35%
прирост качества от reranker над чистым vector search
6 нед.
типичное время затрачено на ненужное fine-tuning

// 01

Ментальная модель: где хранить интеллект

Главная ошибка 2025–2026: команды задают вопрос «RAG или fine-tuning?» — и пытаются выбрать одно. Правильный вопрос: где должен жить каждый тип знания и поведения?

Ответ: волатильные факты → в retrieval, стабильное поведение → в весах модели. Эти слои не конкурируют — они дополняют друг друга.

RAG — знание (facts)
  • Часто меняющаяся информация: документы, политики, цены
  • Большой корпус: тысячи документов не влезут в контекст
  • Нужны цитаты: пользователь должен видеть источник
  • Per-user данные: разные пользователи видят разные данные
  • Нет обучающих примеров: есть документы, но нет Q&A пар
  • Быстрый запуск: прототип за выходные
  • Обновление без retraining: обновил документ — изменения мгновенны
Fine-tuning — поведение (behavior)
  • Стабильный тон и стиль: фирменный голос, формат ответов
  • Domain reasoning: модель должна рассуждать как эксперт
  • Специфичный формат: JSON schema, código templates
  • Отказ от нежелательного: не отвечать на определённые темы
  • Инструкции в промпте не работают: промпт не даёт нужного поведения
  • Снижение latency: меньше токенов в промпте
  • Работа без retrieval: сокращённая архитектура для edge/embedded

Ключевое правило из практики 2026: fine-tuning не фиксирует проблему галлюцинаций с фактами. Модель, fine-tuned на ваших данных, всё равно будет галлюцинировать детали. Если проблема — устаревшие или неточные факты, это проблема retrieval, а не обучения.

Третий вариант: long-context prompting

Когда не нужны ни RAG, ни FT

Если весь корпус знаний влезает в контекст (<200K токенов) — full-context prompting + prompt caching часто быстрее и дешевле, чем строить retrieval. Anthropic рекомендует этот подход для небольших внутренних knowledge base.

Prompt engineering — всегда первый шаг

Перед любым вложением в RAG или FT: попробовать улучшенный промпт. Часто 90% качества достигается правильным системным промптом за 1 день vs 6 недель обучения.

Правило убывающих вложений

Prompt engineering → RAG → Fine-tuning + RAG. Каждый уровень значительно дороже предыдущего по setup и поддержке. Двигаться вперёд только с доказанной необходимостью.

// 02

Дерево решений

Вопросы упорядочены по убыванию приоритета. Ответы ведут к конкретной рекомендации архитектуры.

Данные меняются чаще раза в месяц?
RAGFine-tuning не подходит для волатильных данных — retraining дорог
Нужны ссылки на источники?
RAGFine-tuning не умеет цитировать источники — он «знает» но не «помнит откуда»
Корпус <200K токенов?
Prompt cacheПопробуй full-context + prompt caching до построения retrieval pipeline
Проблема — формат/тон, не факты?
Fine-tuningСтиль, структура, отказы, domain-specific reasoning — это поведение, не знание
Есть 500+ размеченных Q&A примеров?
Fine-tuningLoRA/QLoRA — 500–5000 примеров достаточно для domain adaptation
Нет размеченных данных, только документы?
RAGRAG работает с raw документами. Fine-tuning требует обучающих примеров
Нужно и то и другое?
HybridFT для поведения/стиля, RAG для фактов. 60% production систем используют оба
Latency критична, нет GPU для retrieval?
Fine-tuningMerged adapter = zero retrieval overhead. Или малый контекст + кеш

Сравнение по ключевым параметрам

ПараметрFine-tuningRAGHybrid
Time to first value 4–8 недель (данные+обучение+eval) 1–2 недели до MVP 2–4 недели (RAG сначала, FT потом)
Обновление знаний Retraining (дорого, медленно) Мгновенно: обновил документ Знания: мгновенно; поведение: retraining
Hallucinations Не решает проблему фактов Снижает при хорошем retrieval Лучший результат из двух
TTFT / Latency Ниже: нет retrieval overhead +50–200ms на retrieval+rerank RAG latency + FT inference
Стоимость setup GPU время + data labeling Vector DB + embedding costs Оба + инженерный overhead ×1.6
Explainability Черный ящик: почему так ответил? Прозрачно: видны retrieved chunks Прозрачно в части знаний
Data requirements 500–5K размеченных примеров Raw документы в любом формате Оба типа

// 03

RAG: архитектура production-уровня

Наивный RAG (embed → retrieve → generate) работает в demo. В production он failsы в 40% случаев из-за semantic gap, плохого chunking и отсутствия reranking. Правильная архитектура сложнее.

Компоненты production RAG pipeline

Ingestion Pipeline (offline, при обновлении документов)
1 → Document Parsing Unstructured.io или Apache Tika: PDF, DOCX, HTML → clean text. Убрать footer, header, boilerplate CRITICAL
2 → Chunking Recursive character split 512 токенов — лучший по данным 2026. Overlap 10–20%. Preserve headings внутри чанка, не только в metadata CRITICAL
3 → Metadata enrichment doc_title, section, date, department, version. Prefix-breadcrumb перед каждым чанком для контекста ВАЖНО
4 → Embedding On-prem/sensitive: BGE-M3 или GTE-Qwen2. Managed: Voyage-3-large (лучший на MTEB 2026). OpenAI text-embedding-3-small — хороший бюджетный вариант VECTOR
5 → Vector Store Self-hosted: Qdrant (6ms p50 latency, лучший self-hosted) или pgvector в PostgreSQL. Включить hybrid search (dense + BM25 sparse) STORAGE
Query Pipeline (real-time, на каждый запрос)
1 → Query Transform HyDE (Hypothetical Document Embeddings) или query expansion — LLM генерирует гипотетический ответ для лучшего embedding match ОПЦИОНАЛЬНО
2 → Hybrid Retrieval Dense (semantic) + Sparse (BM25 keyword). Reciprocal Rank Fusion (RRF) для объединения списков. +17% recall vs чистый vector search CRITICAL
3 → Reranking Cross-encoder: BGE-Reranker (self-hosted) или Cohere Rerank-3 (API). Берёт top-20 чанков, возвращает top-5. +15–35% quality vs чистый retrieval CRITICAL
4 → Context Assembly Держать assembled context <8K токенов. Если постоянно превышает — reranker threshold слишком мягкий ВАЖНО
5 → Generation + Citations LLM генерирует с retrieved context. Всегда включать source references. Проверять relevance score перед включением в контекст OUTPUT

80% провалов RAG — на этапе ingestion и chunking, не на этапе генерации. Если модель даёт плохие ответы, сначала проверь: правильно ли парсятся документы, правильный ли размер чанков, включены ли headings в чанки. Это не проблема LLM.

Выбор Vector DB для self-hosted

Qdrant (рекомендуется)

6ms P50 latency. Лучший self-hosted выбор 2026. Hybrid search из коробки. Docker + Helm chart. HNSW индекс. Rust-based = стабильная производительность под нагрузкой.

pgvector (если PostgreSQL уже есть)

Нет дополнительной инфры. ACID транзакции. Metadata filtering через SQL. Медленнее Qdrant при больших объёмах (>1M векторов). Для <500K документов — отличный выбор.

Weaviate (cloud-native)

Встроенный BM25, hybrid search из коробки. GraphQL API. Self-hosted через Helm. Хорош для multi-tenancy. Более сложная операционная нагрузка.

ChromaDB (только dev)

Простейший старт, нет production-grade фич. Нет horizontal scaling. Нет hybrid search. Для прототипа и dev — ок. Для production — заменить.

// 04

RAG: настройка self-hosted

Docker Compose — полный RAG стек

yamldocker-compose.rag.yml
services:
  # Vector Database
  qdrant:
    image: qdrant/qdrant:v1.10.0
    ports: ["6333:6333", "6334:6334"]
    volumes:
      - qdrant_data:/qdrant/storage
      - ./qdrant-config.yaml:/qdrant/config/production.yaml:ro
    environment:
      QDRANT__SERVICE__API_KEY: ${QDRANT_API_KEY}
    restart: unless-stopped

  # Embedding model (BGE-M3, self-hosted)
  embedding-service:
    image: ghcr.io/huggingface/text-embeddings-inference:latest
    command: --model-id BAAI/bge-m3 --port 8080
    deploy:
      resources:
        reservations:
          devices:
          - driver: nvidia
            count: 1
            capabilities: [gpu]
    ports: ["8080:8080"]

  # Reranker (BGE-Reranker, self-hosted)
  reranker-service:
    image: ghcr.io/huggingface/text-embeddings-inference:latest
    command: --model-id BAAI/bge-reranker-v2-m3 --port 8081
    deploy:
      resources:
        reservations:
          devices:
          - driver: nvidia
            count: 1
            capabilities: [gpu]
    ports: ["8081:8081"]

  # RAG API layer (LangChain/LlamaIndex приложение)
  rag-api:
    build: ./rag-service
    environment:
      QDRANT_URL: http://qdrant:6333
      QDRANT_API_KEY: ${QDRANT_API_KEY}
      EMBEDDING_URL: http://embedding-service:8080
      RERANKER_URL: http://reranker-service:8081
      LLM_URL: http://vllm:8000   # ваш vLLM endpoint
    ports: ["9000:9000"]
    restart: unless-stopped

volumes:
  qdrant_data:

Ingestion pipeline — Python пример

pythoningest.py — загрузка документов в Qdrant
from langchain.text_splitter import RecursiveCharacterTextSplitter
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
import httpx, uuid

# Конфигурация
EMBEDDING_URL = "http://embedding-service:8080/embed"
QDRANT_URL    = "http://qdrant:6333"
CHUNK_SIZE    = 512   # оптимальный по 2026 бенчмаркам
CHUNK_OVERLAP = 64    # ~12.5% overlap

client = QdrantClient(url=QDRANT_URL, api_key="...")

def create_collection(name: str, dim: int = 1024):
    # BGE-M3 даёт 1024-dim embeddings
    client.create_collection(name, vectors_config=VectorParams(
        size=dim, distance=Distance.COSINE
    ))

def ingest_document(text: str, metadata: dict, collection: str):
    # 1. Chunking
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=CHUNK_SIZE,
        chunk_overlap=CHUNK_OVERLAP,
        separators=["\n\n", "\n", ". ", " "]
    )
    chunks = splitter.split_text(text)
    
    # 2. Добавить breadcrumb prefix к каждому чанку
    breadcrumb = f"{metadata.get('title','')} → {metadata.get('section','')}"
    chunks_with_ctx = [f"{breadcrumb}\n{c}" for c in chunks]
    
    # 3. Embedding (batch)
    resp = httpx.post(EMBEDDING_URL, json={"inputs": chunks_with_ctx})
    embeddings = resp.json()
    
    # 4. Upsert в Qdrant
    points = [
        PointStruct(
            id=str(uuid.uuid4()),
            vector=emb,
            payload={"text": chunk, **metadata}
        )
        for chunk, emb in zip(chunks, embeddings)
    ]
    client.upsert(collection_name=collection, points=points)
    return len(points)

# Hybrid search с reranking
def retrieve_and_rerank(query: str, collection: str, top_k: int = 5):
    # 1. Embed query
    q_emb = httpx.post(EMBEDDING_URL, json={"inputs": [query]}).json()[0]
    
    # 2. Vector search (top 20 candidates)
    results = client.search(collection, query_vector=q_emb, limit=20)
    candidates = [r.payload["text"] for r in results]
    
    # 3. Rerank с BGE-Reranker
    rerank_resp = httpx.post(
        "http://reranker-service:8081/rerank",
        json={"query": query, "texts": candidates}
    ).json()
    
    # 4. Вернуть top_k по rerank score
    ranked = sorted(
        zip(candidates, rerank_resp["scores"]),
        key=lambda x: x[1], reverse=True
    )
    return [text for text, _ in ranked[:top_k]]

// 05

Fine-tuning: методы и выбор

В 2026 году fine-tuning — не «загрузить JSONL и надеяться». Стандарт: LoRA / QLoRA + строгий eval loop. Полное fine-tuning — только для специальных случаев.

LoRA vs QLoRA vs Full FT

LoRA (Low-Rank Adaptation)

Обновляет 0.1–1% параметров через низкоранговые матрицы. 7B: нужно ~20GB VRAM в BF16. Качество близко к full FT. Основной выбор для production.

QLoRA (Quantized LoRA)

База в 4-bit (NF4), адаптеры в BF16. 7B: под 10GB VRAM. 70B: на одной 24GB GPU. 5–10% slower vs LoRA. Выбор при дефиците VRAM.

Full Fine-tuning

Обновляет все параметры. 7B требует 4–8×A100. Лучшее качество, но редко оправдано. Нужно при кардинальном изменении reasoning модели.

DoRA / GaLore (2026 методы)

DoRA: LoRA с weight decomposition — +1–3% vs LoRA при том же VRAM. GaLore: gradient low-rank projection — приближает full FT при LoRA памяти.

Сколько данных нужно

100–500 примеров
Достаточно для стиля, формата, базовой domain adaptation. QLoRA 7B — несколько часов
500–5K примеров
Производственный уровень. Надёжный domain knowledge. Достаточно для большинства задач
5K–50K примеров
Глубокая специализация, сложный reasoning, investment/legal domain knowledge
Нет размеченных данных?
RAGFine-tuning без качественных примеров — хуже baseline. Используй RAG

VRAM требования — быстрая таблица

МодельLoRA (BF16)QLoRA (INT4)Inference после
7B20GB (1×A100 40GB)8–10GB (1×RTX 3090)14GB FP16 / 4GB INT4
13B40GB (1×A100 80GB)16GB (1×RTX 4090)26GB FP16 / 7GB INT4
70B160GB (4×A100 40GB)24GB (1×A100 40GB)140GB FP16 / 35GB INT4

QLoRA позволяет дообучить 70B модель на одной 24GB GPU. Это изменило landscape в 2024–2026: fine-tuning frontier-class моделей стал доступен без кластера A100. При 2-GPU NVLink setup 70B QLoRA занимает 12–18 часов vs 24–36 часов на одной GPU.

// 06

Fine-tuning: конфиги и деплой

Axolotl — production pipeline (YAML-based)

yamlaxolotl_config.yml — QLoRA 7B на одной GPU
base_model: meta-llama/Llama-3.1-8B-Instruct
model_type: LlamaForCausalLM
tokenizer_type: AutoTokenizer

# QLoRA config
load_in_4bit: true
adapter: lora
lora_r: 16          # rank — баланс качество/VRAM
lora_alpha: 16     # обычно = lora_r
lora_dropout: 0.05
lora_target_modules:  # все linear слои = лучшее качество
  - q_proj
  - k_proj
  - v_proj
  - o_proj
  - gate_proj
  - up_proj
  - down_proj

# Данные
datasets:
  - path: data/train.jsonl
    type: chat_template
val_set_size: 0.1
sequence_len: 2048

# Training
micro_batch_size: 2
gradient_accumulation_steps: 4
num_epochs: 3          # 1–3 epochs, не переобучить
learning_rate: 2e-4   # безопасный LR для LoRA
lr_scheduler: cosine
warmup_steps: 10

# Оптимизации
flash_attention: true
gradient_checkpointing: true
bf16: true

# Output
output_dir: ./checkpoints/llama-8b-domain
save_safetensors: true

# Запуск: axolotl train axolotl_config.yml

Форматирование данных

jsonltrain.jsonl — chat_template формат
# Каждая строка — один пример (conversations format)
{"conversations": [
  {"role": "system", "content": "You are a financial analyst..."},
  {"role": "user",   "content": "Analyze this P&L statement..."},
  {"role": "assistant", "content": "Based on the P&L data: ..."}
]}

# Минимальные требования к качеству датасета:
# 1. Разнообразие примеров — не одинаковые формулировки
# 2. Consistent system prompt — одинаковый во всех примерах
# 3. Качество ответов — лучше 500 хороших, чем 5000 плохих
# 4. Negative examples — примеры правильного отказа от нерелевантных запросов
# 5. Validation split — минимум 10%, лучше 15%

Деплой адаптера: два паттерна

Merged model (рекомендуется)

Адаптер сливается с базовой моделью в один файл. Zero overhead при inference. Деплой как обычная модель через vLLM.

  • Zero latency overhead — нет дополнительных вычислений
  • Любой inference framework — vLLM, TGI, llama.cpp
  • Простая операционная модель
  • Минус: нет возможности swap adapter runtime
Multi-LoRA serving (vLLM)

Один base model, несколько LoRA адаптеров загружены одновременно. Routing по запросу.

  • Экономия VRAM — base model загружен один раз
  • Горячая замена адаптера без перезапуска
  • Минус: небольшой overhead при inference
  • vLLM: --enable-lora --max-loras 4
bashmerge_and_deploy.sh
# Слить адаптер с базовой моделью
python -c "
from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

base = AutoModelForCausalLM.from_pretrained(
    'meta-llama/Llama-3.1-8B-Instruct', torch_dtype='bfloat16')
model = PeftModel.from_pretrained(base, './checkpoints/llama-8b-domain')
merged = model.merge_and_unload()
merged.save_pretrained('./models/llama-8b-domain-merged')
AutoTokenizer.from_pretrained(
    'meta-llama/Llama-3.1-8B-Instruct').save_pretrained(
    './models/llama-8b-domain-merged')
print('Done')
"

# Запуск через vLLM (merged model = обычная модель)
vllm serve ./models/llama-8b-domain-merged \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --port 8001  # другой порт — рядом с базовой моделью

# Multi-LoRA вариант (base + несколько адаптеров)
vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --enable-lora \
  --lora-modules domain-finance=./adapters/finance \
                 domain-legal=./adapters/legal \
  --max-loras 4 \
  --max-lora-rank 16

// 07

Hybrid: как сочетать на практике

60% production систем в 2026 используют оба подхода. Три основных паттерна. Hybrid достигает 96% accuracy в задачах где pure RAG или pure FT дают 80–88%.

Fine-tuning отвечает за
Стиль и тон ответов (brand voice)
Формат вывода (JSON схема, структура)
Domain-specific reasoning
Отказы от нерелевантных запросов
Понимание терминологии домена
Decision protocol / алгоритм решений
RAG отвечает за
Актуальные факты и данные
Политики, регламенты, версии
User-specific документы
Ссылки и citations
Большой корпус знаний
Данные, меняющиеся чаще месяца

Три production паттерна hybrid

Паттерн 1: FT-for-behavior + RAG-for-facts (самый частый)
Most Common

Fine-tune на домен/стиль. RAG для текущих знаний. Fine-tuned модель лучше использует retrieved контекст потому что уже понимает доменную терминологию.

  • Customer-facing agent: FT под brand voice + тон → RAG за актуальными политиками и продуктами
  • Legal research: FT для правовой риторики → RAG за конкретными делами и статьями
  • Engineering copilot: FT для code style → RAG за актуальной документацией
Паттерн 2: RAG-aware fine-tuning (advanced)
Advanced

Обучить модель на примерах (question, retrieved-docs-with-distractors, correct-answer). Модель учится игнорировать нерелевантные retrieved чанки.

  • Снижает irrelevant citations с 18% до 4% без изменений в retrieval pipeline
  • Требует специально подготовленных training examples с диstractors
  • Хорошо для RAG систем где пользователи часто жалуются на «галлюцинирующие ссылки»
Паттерн 3: Model routing (cost optimization)
Cost Optimized

Lightweight classifier маршрутизирует: простые запросы → fine-tuned small model (8B); сложные → large model + RAG. 70–90% cost reduction vs pure frontier model.

  • Router: дообученный 1B классификатор или простые эвристики по типу запроса
  • Simple/FAQ → FT 8B (быстро, дёшево)
  • Complex/edge-case → 70B + RAG (качество)
  • Ключевая метрика: доля запросов попадающих в «простой» путь (цель: 70–80%)

// 08

Evaluation: как измерять качество

Без evaluation невозможно знать стало ли лучше после изменения chunking, смены embedding модели или нового LoRA checkpoint. Teams that don't measure can't improve.

RAG evaluation: RAGAS фреймворк

Faithfulness

Насколько ответ опирается на retrieved документы. Метрика галлюцинаций. Цель: >0.85. Ниже 0.7 — серьёзная проблема.

Answer Relevance

Насколько ответ отвечает на вопрос. Цель: >0.80. Если низкий — проблема в generation prompt или размере контекста.

Context Recall

Насколько полно retrieval покрывает нужную информацию. Если низкий — чанки слишком маленькие или embedding не находит нужное.

Context Precision

Доля retrieved чанков, действительно полезных для ответа. Если низкий — reranker слишком мягкий, много шума в контексте.

pythonragas_eval.py
from ragas import evaluate
from ragas.metrics import (
    faithfulness, answer_relevancy,
    context_recall, context_precision
)
from datasets import Dataset

# Тестовый набор: вопросы + ожидаемые ответы + ground truth
eval_data = {
    "question":  ["Какова политика возврата?", ...],
    "answer":    ["Возврат в течение 30 дней...", ...],  # ответ RAG
    "contexts":  [["Документ о возврате..."], ...],          # retrieved чанки
    "ground_truth": ["Правильный ответ...", ...]
}

results = evaluate(
    Dataset.from_dict(eval_data),
    metrics=[faithfulness, answer_relevancy, context_recall, context_precision]
)
print(results)
# {faithfulness: 0.87, answer_relevancy: 0.82, ...}

# Минимум 50 вопросов для значимой оценки.
# Запускать после каждого изменения в pipeline.

Fine-tuning evaluation

Что проверять после fine-tuning
Engineer
  • Task-specific accuracy: набор задач из вашего домена, сравнение base vs FT
  • Catastrophic forgetting check: MMLU или аналогичный benchmark — убедиться, что общие способности не деградировали
  • Format compliance: если цель — структурированный output, 100% проверка формата на test set
  • Human eval side-by-side: 50–100 примеров, blindfolded оценщик сравнивает base vs FT
  • Eval до и после слияния адаптера: убедиться, что merge не деградировал качество

Мониторинг в production

📊 RAG метрики в production

  • Retrieval latency P99 (добавляет к TTFT)
  • Context relevance score (среднее по запросам)
  • Prefix cache hit rate для системных промптов
  • Empty retrieval rate (запросы без результатов)

🔧 Fine-tuning метрики

  • Format compliance rate в production
  • Task success rate (если есть end-to-end метрика)
  • Hallucination rate (сравнение с baseline)
  • User satisfaction / thumbs up rate

⚠️ Сигналы деградации

  • Faithfulness падает <0.75 — retrieval деградирует
  • Рост жалоб на «неправильные ответы» после обновления документов
  • Format compliance падает после обновления базовой модели
  • Empty retrieval растёт — embedding drift или плохой новый контент

🚨 Когда переобучать

  • Task accuracy упала >5% от baseline
  • Пользователи жалуются на изменение стиля ответов
  • Появился принципиально новый сценарий (не покрыт train set)
  • Обновлена базовая модель — адаптер надо перепроверить

// 09

Процесс: роли, ритм, инфраструктура

Manager / Product Owner

Определяет use case и constraint. Принимает решение RAG vs FT vs hybrid на основе data/update/latency требований. Устанавливает eval criteria. Budget.

ML Engineer

Реализует RAG pipeline и/или fine-tuning. Eval loop, chunking эксперименты, hyperparameter tuning. Production деплой и мониторинг метрик качества.

Data Engineer / Domain Expert

Подготовка и labeling данных для FT. Качество ingested документов для RAG. Без качественных данных ни подход не работает.

Ритм: от идеи до production

ФазаWEEK 1
Диагностика: что реально нужно

Manager + Engineer: определить проблему. Это знание или поведение? Собрать 50 реальных примеров запросов. Попробовать улучшенный промпт — если решает 80% проблем, остановиться здесь.

ФазаWEEK 2–3
RAG MVP (если выбран RAG путь)

Engineer: Qdrant + embedding model + базовый retrieval. Ingestion 100–500 ключевых документов. Базовый eval dataset (50 Q&A). Измерить baseline faithfulness и context_recall.

ФазаWEEK 3–4
RAG iteration: hybrid search + reranking

Добавить hybrid search (BM25 + dense). Добавить BGE-Reranker. Измерить improvement. Типично: +15–35% context precision. Настроить chunking если recall низкий.

ФазаWEEK 4–8
Fine-tuning (если нужен)

Подготовить 500+ примеров. QLoRA обучение (несколько часов на A100). Eval: task accuracy, catastrophic forgetting check. Merge адаптера. A/B тест vs base model.

РитмDAILY
Production мониторинг

Автоматические алерты: retrieval latency spike, empty retrieval rate, error rate. Никакого ручного контроля в штатном режиме.

РитмWEEKLY
Engineer: eval metrics review

RAGAS метрики за неделю: trend faithfulness, answer_relevancy. Есть ли новые документы для ingestion? FT: format compliance rate, task success.

РитмMONTHLY
Manager + Engineer: качество и ROI

Нужно ли переобучение? Устарели ли документы в RAG? Стоит ли добавить hybrid паттерн? User satisfaction метрики. Cost per query анализ.

Действия менеджера — конкретно

Что Manager должен сделать до начала проекта
Manager
  • Ответить на 4 вопроса: (1) Как часто меняются данные? (2) Нужны ли citations? (3) Проблема — факты или поведение? (4) Есть ли размеченные Q&A примеры?
  • Установить success criteria до начала — не «должно быть умнее», а «faithfulness >0.85 на test set из 100 вопросов»
  • Обеспечить доступ к данным: для RAG — документы + право на ingestion; для FT — размеченные примеры или ресурс на labeling
  • Защитить время на итерации: RAG требует 3–5 итераций chunking/embedding/rerank до production-качества. Это нормально, не баг
  • Не требовать fine-tuning «потому что это настоящий AI» — это bias дорого стоит. RAG часто быстрее и лучше
  • Знать эти три числа: faithfulness score, context_recall, retrieval latency добавка к TTFT

// 10

Чеклисты

Перед выбором подхода (Manager + Engineer)

RAG: production-ready чеклист (Engineer)

Fine-tuning: production-ready чеклист (Engineer)

Ongoing (Engineer, еженедельно)

Главный антипаттерн 2026: тратить 6 недель на fine-tuning когда проблема решается за 3 дня через RAG с хорошим chunking + reranking. Начинать с наименее дорогого решения. Fine-tuning — это инструмент для поведения, не для знаний. Не путать задачу.