Prometheus

Коротко

Prometheus полезен, когда:

• нужны custom score rubrics;
• judge должен быть open and controllable;
• важно fine-grained feedback, а не только один общий score;
• long-form outputs оцениваются массово.

Оцени ответ по кастомной rubric: factual accuracy, child-readability и actionable clarity. Дай score и краткую feedback rationale по каждому критерию.

Это техника про customizable open judging.

Чем Prometheus отличается от просто 'LLM as judge'

LLM-as-a-Judge часто работает с довольно общими критериями. Prometheus строится вокруг более богатой judge setting:

• кастомная rubric;
• fine-grained scoring;
• language feedback;
• open evaluator model.

Это делает его ближе к reusable evaluation infrastructure, чем к ad hoc judging prompt.

Когда техника особенно полезна

Prometheus хорошо подходит для:

• rubric-based prompt evaluation;
• long-form answer review;
• domain-specific quality control;
• enterprise evaluation stacks;
• open evaluator deployment.

Если вам нужен только грубый pairwise winner, Prometheus может быть тяжелее, чем нужно.

Когда выбирать Prometheus, а не просто G-Eval или Prometheus 2

Эти статьи легко спутать, но практическая разница есть:

• G-Eval полезен как judging protocol поверх сильной general-purpose модели;
• Prometheus полезен, когда вы хотите именно специализированный open evaluator с fine-grained rubric behavior;
• Prometheus 2 идёт дальше и закрывает сразу несколько judge formats, включая более выраженный pairwise mode.

То есть Prometheus особенно уместен в середине пути:

• generic judge prompt уже слишком хрупкий;
• но full unified multi-format evaluator layer пока не обязателен;
• при этом нужна кастомная rubric и controllable open model.

Ограничения

Кастомные rubric тоже могут быть плохо сформулированы. В таком случае даже хороший evaluator будет уверенно оценивать по слабым критериям. Кроме того, open evaluator может не дотягивать до frontier proprietary judge на части задач.

Есть и типичная ошибка внедрения: команды пишут слишком много пересекающихся критериев вроде clarity, readability, easy to understand, а потом удивляются, что judge многократно штрафует один и тот же дефект. Для rubric-based evaluator это особенно разрушительно.

Но его controllability часто окупает эту разницу.

Почему техника актуальна в 2026

Продуктовые команды всё реже довольствуются универсальными evaluation labels. Prometheus важен как открытый путь к customized, fine-grained LLM evaluation.

Это делает технику особенно полезной в production QA and prompt-iteration loops.

Техническая реализация

const score = await evaluator({
  rubric,
  instruction,
  response
})

Практический совет: проектируйте rubric так, чтобы критерии были orthogonal. Иначе judge будет многократно наказывать или награждать одно и то же качество под разными названиями.

Ещё полезно хранить examples для каждого rubric level. Без anchor examples даже хороший evaluator со временем начинает дрейфовать в интерпретации шкалы.