Розробка системи автоматичної оцінки якості промптів

Якісний промпт для GPT-4o або Claude 3.5 потребує валідації на сотнях кейсів, перш ніж потрапити в продакшен. Ручна розмітка дорога — середня вартість одного еталонного відповіді $5-10, а суб'єктивна оцінка інженера не масштабується. Поганий промпт непомітно знижує якість відповідей, погіршує користувацький досвід та призводить до регресій. Ми розробляємо системи автоматичної оцінки якості промптів (evaluation systems), які заточуємо під вашу задачу та бізнес-метрики. За 5+ років у NLP та LLM ми реалізували понад 40 проєктів, де eval-пайплайни скорочували час валідації в 5 разів і знижували витрати на ручне тестування на $10,000–$15,000 щомісяця. Наприклад, для fintech-клієнта з ботом на GPT-4o вдалося досягти окупності інвестицій за 3-4 місяці.

Метрики оцінки промптів: що працює в production?

Є три основні підходи до оцінки:

• Reference-based метрики — порівнюють відповідь з еталоном. ROUGE вимірює overlap n-грам, BERTScore — семантичну близькість через ембеддінги. Вони хороші для завдань з однозначною відповіддю (сумаризація, переклад).
• LLM-as-judge — використовує сильну модель (GPT-4o, Claude 3.5) для оцінки за заданими критеріями. Підходить для суб'єктивних аспектів: корисність, безпека, відповідність тону.
• Task-specific метрики — наприклад, F1 за сутностями для NER, точність ретрівера для RAG, perplexity для генерації.

Гібридний підхід у 2 рази точніший, ніж використання будь-якої однієї метрики — ми комбінуємо reference-based та LLM-judge з вагами, адаптованими під задачу.

Що враховувати при виборі метрик для оцінки?

Для завдань з однозначною відповіддю (сумаризація, переклад) достатньо ROUGE та BERTScore. Для вільної генерації (креативні тексти, листи) необхідний LLM-суддя. Якщо у вас RAG-пайплайн, додайте метрики повноти контексту та точності ретрівера. Завжди калібруйте пороги на репрезентативному датасеті — ми використовуємо крос-валідацію по 5 фолдам.

Чому LLM-as-judge не завжди перемагає reference-метрики?

Дослідження та наш досвід на 15+ проєктах показують, що LLM-суддя може бути нестабільним: до 20% оцінок змінюються при повторному прогоні. Reference-метрики детерміновані та в 80% випадків корелюють з людською оцінкою для чітких завдань. Але для творчих завдань (написання листів, креатив) LLM-суддя незамінний. Наш підхід — гібрид: для сумаризації 50% ROUGE + 30% BERTScore + 20% LLM-judge; для RAG — 40% метрики ретрівера + 30% BERTScore + 30% LLM-judge.

Як ми будуємо пайплайн оцінки промптів: кейс fintech

Клієнт — fintech-компанія з ботом на базі GPT-4o. Ми впровадили систему оцінки за 3 тижні. Ключові етапи:

1. Збір датасету — 500 пар питання-відповідь, розмічених експертами (середній бал 4.2/5).
2. Вибір метрик — обрали BERTScore (зважений) та LLM-judge з критеріями "точність", "повнота", "безпека".
3. Реалізація — обгорнули в Python-класи (див. код нижче). Використовували Hugging Face Transformers для BERTScore, vLLM для low-latency інференсу судді.
4. Регресійні тести — кожен комміт зі зміною промпту запускає прогін на 100 прикладах (CI/CD). Поріг деградації — 5%.

Результат: час валідації нового промпту скоротився з 2 днів до 15 хвилин. Частка регресій, виявлених до релізу — 97%. Окупність інвестицій склала 3-4 місяці.

from abc import ABC, abstractmethod
from dataclasses import dataclass
from typing import Callable

@dataclass
class EvalResult:
    score: float  # 0-1
    passed: bool
    details: dict

class BaseEvaluator(ABC):
    @abstractmethod
    def evaluate(self, input: str, output: str, expected: str = None) -> EvalResult:
        pass

class LLMJudgeEvaluator(BaseEvaluator):
    """LLM-as-judge для суб'єктивних задач"""

    def __init__(self, judge_model: str = "gpt-4o", criteria: list[str] = None):
        self.model = judge_model
        self.criteria = criteria or ["accuracy", "relevance", "conciseness"]

    def evaluate(self, input: str, output: str, expected: str = None) -> EvalResult:
        criteria_str = "\n".join(f"- {c}" for c in self.criteria)

        prompt = f"""Evaluate the following AI response on these criteria:
{criteria_str}

User input: {input}
AI response: {output}
{f'Expected answer: {expected}' if expected else ''}

For each criterion, provide a score 1-5 and brief reasoning.
Respond with JSON: {{"scores": {{{{"criterion": score}}}}, "overall": 0-1, "reasoning": "..."}}"""

        response = self.llm_client.complete(prompt)
        result = json.loads(response)

        return EvalResult(
            score=result['overall'],
            passed=result['overall'] >= 0.7,
            details=result
        )

class RougeEvaluator(BaseEvaluator):
    """Reference-based метрика ROUGE"""

    def evaluate(self, input: str, output: str, expected: str) -> EvalResult:
        from rouge_score import rouge_scorer
        scorer = rouge_scorer.RougeScorer(['rouge1', 'rouge2', 'rougeL'])
        scores = scorer.score(expected, output)

        rouge_l = scores['rougeL'].fmeasure
        return EvalResult(
            score=rouge_l,
            passed=rouge_l >= 0.4,
            details={"rouge1": scores['rouge1'].fmeasure,
                    "rouge2": scores['rouge2'].fmeasure,
                    "rougeL": rouge_l}
        )

class BERTScoreEvaluator(BaseEvaluator):
    def evaluate(self, input: str, output: str, expected: str) -> EvalResult:
        from bert_score import score
        P, R, F1 = score([output], [expected], lang='en', model_type='microsoft/deberta-xlarge-mnli')
        bert_f1 = float(F1[0])
        return EvalResult(score=bert_f1, passed=bert_f1 >= 0.85, details={"f1": bert_f1})

class CompositeEvaluator:
    def __init__(self, evaluators: list[tuple[BaseEvaluator, float]]):
        """evaluators: [(evaluator, weight), ...]"""
        self.evaluators = evaluators

    def evaluate_prompt(self, prompt_version: str,
                        test_cases: list[dict]) -> dict:
        results = []
        for case in test_cases:
            rendered = render_prompt(prompt_version, case['input_variables'])
            output = llm_call(rendered)

            case_scores = {}
            for evaluator, weight in self.evaluators:
                result = evaluator.evaluate(
                    input=case.get('input', ''),
                    output=output,
                    expected=case.get('expected')
                )
                case_scores[type(evaluator).__name__] = {
                    'score': result.score,
                    'weight': weight,
                    'passed': result.passed
                }

            weighted_score = sum(
                v['score'] * v['weight'] for v in case_scores.values()
            )
            results.append({'case': case, 'output': output,
                           'scores': case_scores, 'weighted': weighted_score})

        return {
            'mean_score': np.mean([r['weighted'] for r in results]),
            'pass_rate': np.mean([all(s['passed'] for s in r['scores'].values())
                                  for r in results]),
            'results': results
        }

# Використання
evaluator = CompositeEvaluator([
    (LLMJudgeEvaluator(criteria=["accuracy", "helpfulness"]), 0.5),
    (RougeEvaluator(), 0.3),
    (BERTScoreEvaluator(), 0.2),
])

score = evaluator.evaluate_prompt("summarization-v3", test_cases)
print(f"Overall score: {score['mean_score']:.3f}, Pass rate: {score['pass_rate']:.2%}")

def check_for_regression(new_score: float, baseline_score: float,
                          threshold: float = 0.05) -> bool:
    """Повертає True якщо регресію виявлено"""
    relative_change = (new_score - baseline_score) / baseline_score
    if relative_change < -threshold:
        print(f"REGRESSION: score dropped {abs(relative_change):.1%}")
        return True
    return False

Процес впровадження: етапи, терміни, результат

Що ви отримуєте

• Код оцінювачів та регресійних тестів (Python, з коментарями)
• Docker-образ для відтворюваності
• Конфігураційні файли для порогів метрик
• Інструкція з додавання нових кейсів
• 3-місячна підтримка після впровадження

LLM evaluation та MLOps evaluation — наші ключові компетенції. Інтегруємо eval-пайплайн у ваш існуючий workflow без перебудови архітектури.

Типові помилки при автоматичній оцінці промптів

• Використовувати лише одну метрику. Наприклад, опора на ROUGE при роботі з синонімами дає хибні регресії. Наш гібридний підхід знижує цей ризик на 60%.
• Калібрувати пороги на одному датасеті. Ми використовуємо крос-валідацію по 5 фолдам, щоб уникнути перенавчання під конкретні приклади.
• Ігнорувати безпеку. Шкідливі промпт-ін'єкції не ловляться стандартними метриками — додаємо окремий LLM-оцінювач з критерієм "safe" та часткою 10–15%.

Опираємося на 5+ років досвіду у NLP та prompt engineering. Гарантуємо, що система виявить не менше 95% регресій до потрапляння в продакшен. Зв'яжіться з нами — оцінимо ваш промпт та запропонуємо оптимальний набір метрик. Отримайте консультацію безкоштовно.

MLOps: інфраструктура для навчання, деплою та моніторингу ML-моделей

Модель навчена, метрики — F1 0.94 на валідації. Через три місяці в продакшені якість падає на 12%. Ніхто не знає, коли саме — немає моніторингу. Не можна швидко перенавчити — навчальний скрипт лежить у Jupyter-ноутбуці у data scientist’а, який вже звільнився. Дані для ретрейну збирають вручну з трьох розрізнених систем. Приблизно половина проєктів приходять до нас із цим болем. Ми будуємо MLOps платформу під ключ: від трекінгу експериментів до автоматичного деплою та моніторингу дрейфу даних. Оцінимо вашу інфраструктуру за 1–2 тижні, а через 4–6 тижнів ви отримаєте базове ядро MLOps, що працює в продуктивному контурі. Наша команда — 10+ років досвіду в ML-інфраструктурі, понад 50 впроваджень.

Як побудувати MLOps-інфраструктуру?

Experiment tracking та відтворюваність

Без трекінгу ML-проєкт перетворюється на хаос: незрозуміло, який чекпоінт кращий, які гіперпараметри використовувались, який датасет. Відтворити результат через місяць — квест.

MLflow — open source стандарт для трекінгу. Логує параметри, метрики, артефакти (моделі, графіки) та код. MLflow Model Registry — централізоване сховище моделей з версіонуванням та lifecycle stages (Staging → Production → Archived). Деплой через MLflow Serving або інтеграція із зовнішніми системами.

Типова ініціалізація в коді:

import mlflow

mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 3e-4, "batch_size": 64, "epochs": 10})
    mlflow.log_metric("val_f1", val_f1, step=epoch)
    mlflow.pytorch.log_model(model, "model")

Це мінімум. В production додаємо логування системних метрик (GPU utilization, memory), датасету (hash, версія), коду (git commit hash). Weights & Biases — більш багатий UI, collaboration features, sweep для hyperparameter optimization. MLflow — для on-premise deployment без зовнішніх залежностей.

DVC (Data Version Control) — версіонування даних та моделей поверх git. Дані зберігаються в S3/GCS/Azure Blob, у git — лише метадані (хеші). dvc repro відтворює весь пайплайн від сирих даних до метрик.

Як забезпечити відтворюваність навчання?

Фіксуйте random seeds (torch.manual_seed, numpy.random.seed, random.seed) та записуйте їх у метадані експерименту. Без цього дебагінг нерегулярних результатів — біль. Логуйте версію датасету (DVC hash) та git commit — тоді будь-який експеримент можна повторити з точністю до байта. Це скорочує час на відтворення результатів у 2–3 рази.

Оркестрація пайплайнів: Kubeflow, Airflow, Prefect

Коли потрібен оркестратор пайплайнів?

Скрипт навчання на 100 рядків у cron — нормально для простих задач. Але як тільки з'являється multi-step пайплайн (завантаження даних → preprocessing → feature engineering → навчання → валідація → деплой якщо якість вище порогу), потрібен оркестратор з retry-логікою, візуалізацією, алертами.

Kubeflow — Kubernetes-native оркестратор для ML. Кожен крок — Docker-контейнер. Підтримує паралельні кроки, умовні гілки, артефакти між кроками. Інтегрується з Katib (AutoML), KServe (serving), Feast (feature store). Kubeflow краще за Airflow для ML-пайплайнів у 2–3 рази за швидкістю налаштування та інтеграції з ML-інструментами.

Apache Airflow — більш загальний DAG-оркестратор. Широка екосистема операторів (S3, Spark, DBT, Kubernetes). Простіше розгорнути, якщо в компанії вже є Airflow.

Prefect / Metaflow — менше boilerplate. Prefect 2.x з декораторами @flow та @task — швидкий старт для невеликих команд.

Типова архітектура навчального пайплайну на Kubeflow:

1. Data ingestion component — забирає дані з S3/БД, валідує схему через Great Expectations
2. Preprocessing component — трансформації, normalization, train/val/test split
3. Training component — навчання на GPU, логування в MLflow
4. Evaluation component — обчислення метрик, порівняння з baseline в Model Registry
5. Conditional deployment — деплой тільки якщо нова модель краща за поточну на >2% F1

Кожен component — окремий Docker-образ. Пайплайн версіонується в git. Запуск за розкладом (ретрейнінг раз на тиждень на нових даних) або вручну.

from kfp import dsl

@dsl.pipeline(name='training-pipeline')
def pipeline():
    data_op = data_ingestion_op()
    preprocess_op = preprocessing_op(data_op.output)
    train_op = training_op(preprocess_op.output)
    eval_op = evaluation_op(train_op.output)
    with dsl.Condition(eval_op.output > 0.95):
        deploy_op = deployment_op(train_op.output)

Model Registry та управління життєвим циклом

Model Registry — не просто сховище чекпоінтів. Це централізована система, яка знає:

• Яка модель зараз у продакшені (і з якими метриками)
• Історія всіх версій з параметрами навчання
• Метадані: датасет, git commit, результати валідації
• Lifecycle stage: None → Staging → Production → Archived

MLflow Model Registry — стандарт. Для enterprise — Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Azure ML Model Registry.

Просування моделі через стейджі: автоматично переводимо модель у Staging після успішного проходження eval, потім ручне або автоматичне (при A/B тесті) просування в Production. Rollback — перемикання на попередню Production-версію за секунди.

Serving: від FastAPI до Triton Inference Server

Простий випадок. FastAPI + PyTorch/ONNX на одному сервері — 80% production ML deployments саме так. Достатньо для більшості задач з навантаженням до 100 req/s.

from fastapi import FastAPI
import onnxruntime as ort

app = FastAPI()
session = ort.InferenceSession("model.onnx", providers=["CUDAExecutionProvider"])

@app.post("/predict")
async def predict(request: PredictRequest):
    inputs = preprocess(request.text)
    outputs = session.run(None, {"input_ids": inputs})
    return {"label": postprocess(outputs)}

FastAPI + ONNX підходить для 80% задач, але при навантаженні понад 100 req/s Triton Inference Server дає у 3 рази вищу пропускну здатність. Triton — production-стандарт для високих навантажень (500+ req/s). Dynamic batching, concurrent model execution, model ensemble. Підтримує TensorRT, ONNX, PyTorch TorchScript, TensorFlow SavedModel.

KServe — Kubernetes-native ML serving з autoscaling, canary deployments, A/B testing з коробки. Scale-to-zero для неактивних моделей — економія на інфраструктурі до 40%.

Моніторинг: data drift, model drift, інфраструктурні метрики

Моніторинг — те, що зазвичай роблять в останню чергу і про що шкодують у першу. Три рівні.

Інфраструктурний моніторинг. Latency (P50/P95/P99), throughput (req/s), error rate (4xx, 5xx), GPU/CPU utilization. Prometheus + Grafana — стандарт. Алерт при P99 latency > threshold або error rate > 1%.

Data drift моніторинг. Розподіл вхідних даних змінюється з часом. Детектуємо через PSI (Population Stability Index) для числових ознак: PSI > 0.2 — сильний дрейф. Chi-squared test для категоріальних, Kolmogorov-Smirnov test для неперервних. Evidently AI — open source бібліотека з готовими дрейф-тестами.

Model drift моніторинг. Якщо є ground truth із затримкою (наприклад, через тиждень знаємо конверсію) — моніторимо реальні метрики. Якщо ні — surrogate метрики: розподіл prediction scores, частка confident predictions.

Alerting. Три рівні: INFO (невеликий дрейф, логуємо), WARNING (значний, повідомляємо команду), CRITICAL (якість впала нижче порогу — автоматичне перемикання на fallback-модель).

Чому важливий моніторинг дрейфу даних?

Без нього ви дізнаєтеся про деградацію моделі тільки за скаргами користувачів або дзвінким SLA. Алерт про дрейф дозволяє перенавчити модель заздалегідь, до того як помилки почнуть приносити збитки. В одному з наших проєктів моніторинг PSI виявив дрейф через 2 дні після зміни джерела даних — це врятувало кампанію з бюджетом понад $100K. За словами CTO клієнта, впровадження моніторингу скоротило час виявлення проблем з 2 тижнів до 2 годин.

Feature Store

Feature Store вирішує проблему training-serving skew. Якщо preprocessing під час навчання та інференсу реалізований у двох різних місцях — розбіжність неминуча.

Коли потрібен Feature Store?

• Кілька моделей використовують одні й ті ж ознаки
• Ознаки обчислюються з потокових даних (real-time)
• Велика команда з різними людьми на feature engineering та model training

Feast — open source Feature Store. Офлайн store (S3 + Parquet) для навчання, онлайн store (Redis, DynamoDB) для low-latency інференсу. Feature definitions як код, materialization job синхронізує офлайн → онлайн.

Tecton (комерційний), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варіанти з меншим ops overhead.

Як автоматизувати CI/CD для ML?

ML CI/CD — звичайний CI/CD плюс специфічні ML-кроки.

ML-специфічні checks в CI:

• Перевірка відтворюваності: запустити навчання з фіксованим seed, результат має збігатися
• Data validation: Great Expectations або Pandera на schema/distribution checks
• Model performance check: автоматичний eval на holdout, блокувати merge якщо деградація > порогу
• Latency regression test: inference має вкладатися в SLA

GitOps для деплою. Merge в main → CI запускає навчання → eval → якщо проходить → автоматичний деплой у Staging → smoke tests → ручне просування в Production або автоматичне при успішному canary.

Інструменти: GitHub Actions / GitLab CI для CI, ArgoCD для GitOps-деплою на Kubernetes.

Що входить у розробку MLOps-платформи

Ми надаємо повний цикл робіт, документацію та навчання команди.

Підсумковий термін від аудиту до повноцінної MLOps-платформи: 3–5 місяців. Базовий рівень (трекінг + serving) за 4–6 тижнів. Вартість розраховується індивідуально під обсяг даних (від 1 ТБ), кількість моделей та вимоги до інфраструктури. Замовте аудит MLOps-інфраструктури — отримайте roadmap за 1–2 тижні. Зв'яжіться з нами для оцінки вашого проєкту — ми надішлемо попередній розрахунок за 2 робочих дні.

Гарантія на архітектурні рішення — 12 місяців. Надаємо сертифікати інтеграції з основними хмарними провайдерами (AWS, GCP, Azure). За час роботи ми не втратили жодного клієнта після першого впровадження — досвід 50+ успішних MLOps-проєктів говорить сам за себе. Отримайте консультацію щодо побудови MLOps платформи вже сьогодні.