Качество дообученной модели: метрики, LLM-as-judge, эксперты

После каждой итерации fine-tuning встаёт вопрос: стало ли лучше? Без структурированной системы метрик легко попасть в ловушку — модель может переобучиться, потерять общие знания или деградировать на краевых случаях. Мы видели проекты, где команда делала 15+ итераций «на глаз», пока не выстроила evaluation pipeline. Наш подход — иерархия метрик от быстрых автоматических до дорогой человеческой оценки — позволяет остановиться в нужный момент и гарантировать качество.

Почему важна комплексная оценка дообученной модели?

Одна метрика не даёт полной картины. BLEU может быть высоким, а модель — галлюцинировать факты. Perplexity может падать, а полезность ответов — снижаться. Только комбинация автоматических метрик, LLM-as-judge и человеческой оценки показывает реальное качество дообученной нейросети. Мы используем этот подход во всех проектах уже более 5 лет — накопили портфолио из 50+ fine-tuning проектов.

Иерархия метрик оценки

Уровень 1: Автоматические метрики

Быстрые, дешёвые, работают без человека. Дают грубую оценку, но незаменимы для быстрых итераций.

Уровень 2: LLM-as-judge

Сильная модель (GPT-4o, Claude 3.5) оценивает ответы тестируемой модели. Хорошо коррелирует с человеческой оценкой при правильном промпте.

Уровень 3: Человеческая оценка

Золотой стандарт. Дорого, но необходимо для финальной валидации и калибровки нижних уровней. Обычно 200–500 примеров достаточно.

Сравнение типов метрик:

Как LLM-as-judge дополняет автоматические метрики?

Автоматические метрики (BLEU, ROUGE) измеряют только поверхностное совпадение с референсом. LLM-as-judge оценивает семантику: точность фактов, полноту, логику. В одном кейсе базовая Llama 3.1 8B показала BLEU-4=0.18, а после fine-tuning — 0.39, но LLM-судья выявил, что модель начала выдумывать юридические статьи. Без судьи это бы пропустили. LLM-as-judge коррелирует с человеческой оценкой на 85%, что в 1.5 раза выше, чем у автоматических метрик. Кроме того, LLM-as-judge важен для оценки генерации текста, где автоматические метрики бессильны.

Практическая реализация LLM-as-judge

from openai import OpenAI JUDGE_PROMPT = """Ты — строгий эксперт, оценивающий качество ответов AI-ассистента. Вопрос: {question} Ответ ассистента: {answer} Референсный ответ: {reference} Оцени ответ по критериям (каждый 1–5): 1. Фактическая точность 2. Полнота охвата темы 3. Структурированность 4. Соответствие стилю Верни JSON: {{"accuracy": X, "completeness": X, "structure": X, "style": X, "overall": X, "reasoning": "..."}}""" def llm_judge(question: str, answer: str, reference: str, client: OpenAI) -> dict: response = client.chat.completions.create( model="gpt-4o", messages=[{ "role": "user", "content": JUDGE_PROMPT.format(question=question, answer=answer, reference=reference) }], response_format={"type": "json_object"}, temperature=0.1 ) return json.loads(response.choices[0].message.content) 

Автоматические метрики: реализация в коде

Ниже — пример вычисления BLEU и ROUGE для пайплайна оценки. Код можно использовать как шаблон.

from nltk.translate.bleu_score import corpus_bleu, SmoothingFunction from rouge_score import rouge_scorer references = [[ref.split()] for ref in reference_list] hypotheses = [hyp.split() for hyp in hypothesis_list] bleu_4 = corpus_bleu(references, hypotheses, weights=(0.25, 0.25, 0.25, 0.25), smoothing_function=SmoothingFunction().method1) scorer = rouge_scorer.RougeScorer(['rouge1','rouge2','rougeL'], use_stemmer=True) rouge_scores = [scorer.score(ref, hyp) for ref, hyp in zip(reference_list, hypothesis_list)] 

Perplexity — метрика уверенности модели

import torch from transformers import AutoModelForCausalLM, AutoTokenizer def compute_perplexity(model, tokenizer, texts: list[str]) -> float: total_loss = 0 total_tokens = 0 model.eval() with torch.no_grad(): for text in texts: encodings = tokenizer(text, return_tensors="pt").to(model.device) outputs = model(**encodings, labels=encodings["input_ids"]) total_loss += outputs.loss.item() * encodings["input_ids"].shape[1] total_tokens += encodings["input_ids"].shape[1] avg_loss = total_loss / total_tokens return torch.exp(torch.tensor(avg_loss)).item() 

Классификация и извлечение — оцениваем через F1 и accuracy

from sklearn.metrics import classification_report, f1_score def evaluate_classification(model_outputs: list, ground_truth: list) -> dict: predictions = [] for output in model_outputs: try: pred = json.loads(output)["category"] except: pred = "parse_error" predictions.append(pred) report = classification_report(ground_truth, predictions, output_dict=True) return { "macro_f1": report["macro avg"]["f1-score"], "weighted_f1": report["weighted avg"]["f1-score"], "accuracy": report["accuracy"], "per_class": {k: v for k, v in report.items() if isinstance(v, dict) and k not in ["macro avg", "weighted avg"]} } 

Практический пример: комплексная оценка fine-tuned модели

Базовая модель: Llama 3.1 8B Instruct. Fine-tuning: QLoRA r=16, 2000 примеров юридических документов.

Perplexity на MMLU выросла на 11% — умеренное катастрофическое забывание, но для узкого юридического use-case это приемлемо. Решение: добавить 10% общих данных в следующий раунд.

Что входит в нашу работу по оценке модели

• Разработка кастомного evaluation pipeline под вашу задачу (включая скрипты, конфиги и документацию)
• Настройка автоматических метрик (BLEU, ROUGE, perplexity, F1, accuracy)
• Интеграция LLM-as-judge с выбором модели-судьи и калибровкой промпта
• Проведение человеческой оценки (привлечение экспертов, сбор разметки)
• Построение дашборда метрик и мониторинга (MLflow, Weights & Biases)
• Финальный отчёт с рекомендациями по улучшению модели
• Обучение вашей команды работе с пайплайном

Начните с evaluation pipeline — свяжитесь с нами для аудита вашей модели. Экономия на лишних итерациях может достигать 40% бюджета проекта.

Сроки и процесс оценки

1. Анализ задачи и метрик — 1–2 дня
2. Разработка pipeline и интеграция — 3–5 дней
3. Автоматическая оценка — несколько часов
4. LLM-as-judge (до 1000 примеров) — 1–2 дня
5. Человеческая оценка — 1 неделя
6. Отчёт и рекомендации — 1–2 дня

Итого на одну итерацию fine-tuning — 1–2 недели. При комплексном проекте с несколькими раундами — от 3 недель.

Мониторинг после деплоя

import mlflow def log_inference_quality(prompt, response, user_feedback): with mlflow.start_run(run_name="production-monitoring"): mlflow.log_metrics({ "response_length": len(response.split()), "refusal_detected": int("не могу" in response.lower()), "user_rating": user_feedback.get("rating", -1), }) 

Мониторинг в продакшене обязателен — мы гарантируем, что модель не деградирует со временем. Сертифицированные инженеры нашей команды сопровождают проект на всём жизненном цикле. Наша команда имеет 5+ лет опыта в fine-tuning и выполнила более 50 проектов.

Если вы хотите внедрить системную оценку, свяжитесь с нами. Мы поможем выстроить пайплайн и сэкономить на лишних итерациях. Закажите консультацию: оценим ваш проект за 2 дня.