TL;DR
ORBIT — набор настроек LLM-проверяющего для переводов. Модель получает короткую инструкцию (задача, шкала серьёзности ошибок, формат ответа) и ровно два тщательно подобранных примера разметки. На выходе она отмечает конкретные фрагменты с ошибками и ставит им серьёзность. Для максимума качества то же задание прогоняют через модели трёх разных семейств, а отдельный вызов сводит их отчёты в один.
Главная находка: плохие примеры хуже, чем их отсутствие. Если взять «сырую» разметку, где люди спорят о том, что считать ошибкой, модель перенимает этот шум и находит ошибок меньше, чем совсем без примеров. А вот количество примеров почти не влияет на средний результат. Оно лишь делает ответы стабильнее: с одним примером качество «гуляет» от запуска к запуску, начиная с двух — нет. Подробная инструкция без примеров тоже подводит: её «перегруженное» описание ошибок оказалось слабее краткого.
Метод работает по формуле «коротко + два отобранных примера + несколько разных моделей». Примеры подбирают так, чтобы вместе они покрывали все типы ошибок и весь диапазон серьёзности, а разметку делают вдвоём-втроём с согласованием. У разных моделей разные «характеры»: одни находят больше ошибок, но ложно срабатывают, другие осторожнее. Слияние отчётов нескольких моделей даёт результат лучше, чем разметка живого эксперта. Стоит это примерно в 20 раз дешевле экспертов.
Схема метода
ORBIT-SC (один вызов):
ШАГ 1: Короткая инструкция → задача + шкала серьёзности 1–5 + формат ответа
ШАГ 2: Ровно 2 примера → вместе покрывают типы ошибок и всю шкалу серьёзности,
разметка согласована несколькими людьми
ШАГ 3: Перевод на входе → список «фрагмент — тип — серьёзность» + оценки точности и гладкости
ORBIT-MC (несколько вызовов):
ШАГ 1: Тот же промпт → в 3 разные модели (отдельные чаты)
ШАГ 2: Три отчёта → в отдельный вызов-«сводчик» → итоговый список ошибок
Шаги 1–3 ORBIT-SC идут в одном промпте. ORBIT-MC требует четырёх отдельных запросов.
Пример применения
Задача: Редакция VC.ru переводит англоязычные лонгриды The Economist про Nvidia и ИИ-чипы. Переводят фрилансеры, а выпускающий редактор не успевает вычитывать всё сам. Нужен первый фильтр: модель находит смысловые искажения (потерянное «not», перепутанные цифры, «billion» как «миллион») и стилистические огрехи. Редактор читает только подсвеченные места.
Промпт:
Ты проверяешь качество перевода с английского на русский. Это перевод
аналитической статьи для деловой аудитории.
Найди в переводе все ошибки. Для каждой укажи:
- фрагмент перевода (дословно);
- тип: «смысловая» (искажено, потеряно или добавлено значение) или
«языковая» (грамматика, стиль, неестественная фраза);
- серьёзность по шкале 1–5:
1 — придирка, спорный вариант
2–3 — мелкая ошибка, смысл понятен
4–5 — крупная ошибка, смысл искажён или текст нельзя публиковать.
После списка поставь две оценки от 0 до 100: «Точность» (передан ли смысл)
и «Гладкость» (звучит ли по-русски естественно).
Если ошибок нет — так и напиши. Не придумывай ошибки ради списка.
Формат ответа:
1. «фрагмент» | тип | серьёзность | краткое пояснение
...
Точность: N
Гладкость: N
=== ПРИМЕР 1 ===
Оригинал: Nvidia's market value topped $3 trillion, though analysts warn the
rally is not guaranteed to last.
Перевод: Рыночная стоимость Nvidia превысила 3 миллиарда долларов, хотя
аналитики предупреждают, что ралли обязательно продолжится.
Разметка:
1. «3 миллиарда долларов» | смысловая | 5 | trillion — это триллион
2. «обязательно продолжится» | смысловая | 5 | потерян смысл «not guaranteed»,
смысл обратный
Точность: 20
Гладкость: 85
=== ПРИМЕР 2 ===
Оригинал: The firm has been scrambling to secure supply of advanced packaging,
a bottleneck for its flagship chips.
Перевод: Фирма была скремблирована, чтобы обеспечить поставку продвинутой
упаковки, которая бутылочное горлышко для главных чипов.
Разметка:
1. «была скремблирована» | смысловая | 4 | scrambling to — «судорожно
пытается», а не «скремблировать»
2. «продвинутой упаковки» | языковая | 2 | устоявшийся термин — «передовая
упаковка чипов» / «продвинутая упаковка (advanced packaging)»
3. «которая бутылочное горлышко для» | языковая | 3 | нет глагола,
калька «bottleneck»
Точность: 40
Гладкость: 30
=== ПРОВЕРЬ ЭТОТ ПЕРЕВОД ===
Оригинал: {оригинал}
Перевод: {перевод}
Результат: Модель выдаст нумерованный список. В каждой строке будут дословный фрагмент перевода, тип ошибки, серьёзность 1–5 и короткое пояснение. В конце придут две оценки: «Точность» и «Гладкость». Редактор откроет только места с серьёзностью 4–5 и быстро поймёт, где перевод нельзя пускать в публикацию.
Почему это работает
Слабость. Модель, которой просто сказали «проверь перевод», находит не всё. Она осторожничает: ошибки, которые она отметила, чаще настоящие, но многие настоящие ошибки пропущены, в том числе серьёзные. Длинное описание всех категорий ошибок не спасает: оно «зажимает» модель в рамки таксономии. Модель начинает подгонять находки под категории вместо того, чтобы смотреть на текст.
Сильная сторона. Модели отлично подхватывают паттерн из примеров: что здесь считается ошибкой, насколько строго оценивать. Два примера заменяют страницу определений. Но это же и ловушка: если в примерах спорная разметка, модель перенимает спорный стандарт.
Как метод это использует. Короткая инструкция задаёт рамку, два согласованных примера калибруют строгость. Подбор «по покрытию» гарантирует, что в примерах встретились все типы ошибок и вся шкала серьёзности. Модели разных семейств ошибаются по-разному, и сводчик собирает объединение находок, отсеивая шум.
Рычаги управления:
- Примеры → самый сильный рычаг. Берите разметку, с которой согласны минимум двое. Дали больше двух, получите стабильность, но не прирост среднего.
- Инструкция → если примеров нет, добавьте краткие определения ошибок с мини-примерами в строку. Если примеры есть, оставьте инструкцию короткой.
- Строгость → хотите ловить больше ошибок (recall), берите меньше примеров (k=2). Хотите меньше ложных тревог, берите k=4: точность выше, находок меньше.
- Модель → GPT-линейка склонна находить больше всего ошибок. Claude Opus осторожнее и точнее. Gemini 3.1 Pro сильнее всего в итоговом ранжировании переводов и держит высокую точность.
- Режим → один перевод за раз удобен для оценки отдельной системы. Два перевода одного текста вместе (side-by-side) лучше определяют, какой из них лучше, но находят ошибок меньше.
Шаблон промпта
Ты проверяешь качество перевода с {язык_оригинала} на {язык_перевода}.
Контекст: {тип_текста_и_аудитория}.
Найди в переводе все ошибки. Для каждой укажи:
- фрагмент перевода (дословно);
- тип: «смысловая» (искажён, потерян или добавлен смысл) или «языковая»
(грамматика, стиль, неестественность);
- серьёзность по шкале 1–5:
1 — придирка, спорный вариант
2–3 — мелкая ошибка, смысл понятен
4–5 — крупная ошибка, смысл искажён или текст нельзя публиковать.
В конце поставь две оценки от 0 до 100: «Точность» и «Гладкость».
Если ошибок нет — напиши, что их нет. Не придумывай ошибки ради списка.
Формат:
1. «фрагмент» | тип | серьёзность | краткое пояснение
Точность: N
Гладкость: N
=== ПРИМЕР 1 ===
Оригинал: {оригинал_1}
Перевод: {перевод_1}
Разметка: {согласованная_разметка_1}
=== ПРИМЕР 2 ===
Оригинал: {оригинал_2}
Перевод: {перевод_2}
Разметка: {согласованная_разметка_2}
=== ПРОВЕРЬ ЭТОТ ПЕРЕВОД ===
Оригинал: {оригинал}
Перевод: {перевод}
Что подставлять. {тип_текста_и_аудитория} — например, «рекламная рассылка для подписчиков» или «инструкция к медицинскому прибору». Примеры 1 и 2 подбирайте так, чтобы вместе они показывали разные типы ошибок (смысловая и языковая) и разные уровни серьёзности (от 1 до 5). Разметку делайте вдвоём и согласуйте спорные места. Если ошибок слишком много, оставьте в примерах только характерные.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки перевода по методу ORBIT. Адаптируй под мою задачу:
[твоя задача: какие языки, какой тип текстов].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
Модель спросит про языки, тип текста и аудиторию. Ещё она запросит два-три перевода с типичными для тебя ошибками. Это нужно, чтобы собрать два примера разметки, покрывающие разные типы и уровни ошибок. Именно они калибруют строгость проверяющего. Разметку из этих примеров обязательно просмотри и поправь сам.
Адаптации и экстраполяции
🔧 Техника: добавить слияние отчётов → меньше пропусков
Это не промпт из исследования (в доступной части статьи его нет), а моя реконструкция идеи ORBIT-MC. Прогони один и тот же промпт в ChatGPT, Claude и Gemini. Потом дай четвёртому чату:
Ниже три отчёта об ошибках в одном переводе от трёх независимых проверяющих. Оригинал: {оригинал} Перевод: {перевод} Отчёт А: {отчёт_1} Отчёт Б: {отчёт_2} Отчёт В: {отчёт_3} Собери единый список ошибок: объедини совпадающие, отсеки те, что явно ошибочны (проверь по тексту), сохрани уникальные находки с настоящей проблемой. Серьёзность — по шкале 1–5.
🔧 Техника: сравнение двух версий вместо оценки одной
Если надо выбрать лучший из двух переводов, подай оба сразу и попроси отдельный отчёт на каждый. В исследовании это улучшало определение лучшего перевода, но снижало число найденных ошибок.
Экстраполяция на другие тексты. Принцип «2 согласованных примера, покрывающих типы проблем и шкалу серьёзности, вместо длинных определений» можно перенести на другие проверки: ревью лендингов, проверку ответов поддержки на соответствие стандарту. В статье это не проверялось, только перевод.
Ограничения
⚠️ Узкая область: всё проверено на оценке переводов. Перенос на проверку других текстов — догадка, не результат статьи.
⚠️ Нужна хорошая разметка: два примера придётся собрать и согласовать вручную. Без согласования они могут навредить сильнее, чем их отсутствие.
⚠️ Примеры вытесняют определения: при двух хороших примерах краткая инструкция работает лучше подробной. Но без примеров подробная инструкция с мини-иллюстрациями ошибок всё ещё лучше краткой.
⚠️ Не все модели годятся: некоторые (Grok-4, DeepSeek-V3.2) заметно завышают число ошибок. DeepSeek-V3.2 находил более чем вдвое больше ошибок на фрагмент, чем люди-эксперты, и большинство находок оказались ложными. Остальные открытые модели стабильно слабее ведущих.
⚠️ Режим влияет на результат: оценка пары переводов вместе лучше выбирает победителя, но находит меньше ошибок.
⚠️ Детали слияния не раскрыты в доступном тексте: промпт для «сводчика» и точная схема объединения здесь не приведены. Текст статьи доступен не полностью.
Как исследовали
Команда Яндекса собрала новый набор данных: 600 пар «оригинал — перевод» с английского на русский из конкурсов WMT24 и WMT25. Каждый перевод разметили профессиональные лингвисты (по три независимых разметки). Рядом поставили «ассессоров» без переводческой подготовки и стандартную разметку WMT. Для примеров отдельно собрали пул из 8 текстов по 12 переводов, который лингвисты размечали вместе с согласованием.
Сравнивали разные формулировки инструкции, источники примеров, число примеров (1, 2, 4, 8) и 12 моделей. Результат проверяли по двум показателям: находит ли модель те же ошибки, что и эксперты (полнота, точность, F1), и верно ли выбирает лучший из двух переводов. Выводы перепроверили на пяти других языковых парах и на других системах разметки (MQM, ESA).
Что удивило. Без примеров короткая инструкция проигрывала подробной с мини-примерами, но стоило добавить хорошие примеры, и краткая инструкция слегка обогнала подробную. «Сырая» разметка WMT в качестве примеров дала F1 37,0 против 39,3 без примеров: шум в демонстрациях хуже, чем их отсутствие. Согласованная лингвистами пара примеров подняла F1 до 41,2 и выше. Полнота с двумя примерами выросла, число примеров почти не сдвигало среднее, а только снижало разброс.
Итог для практики. Лучшая одиночная конфигурация (ORBIT-SC на GPT-5.4) дала F1 48,7 против 45,5 у эксперта. Сводная схема из трёх моделей (ORBIT-MC) дала F1 52,1, а полноту 60,3 против 46,8 у экспертов. Базовые промпты из литературы набирали F1 около 31–36. Модели при этом заметно различались: GPT-5.4 находил больше всего ошибок, Claude Opus 4.6 — самый точный в серьёзных ошибках, Gemini 3.1 Pro — лидер по ранжированию.
Ресурсы
- Beyond Prompts: A Systematic Study of LLM-Based Machine Translation Evaluators — Dmitry Popov, Roman Bokhyan, Ekaterina Enikeeva, Artem Mekhraliev, Stepan Vysotsky, Nikolay Karpachev (Яндекс, НИУ ВШЭ)
- Датасет и промпты: huggingface.co/datasets/yandex/orbit-mt-eval
- Протокол RATE (Popov et al., 2025); протоколы MQM, ESA; базовые промпты GEMBA-MQM, AutoMQM