Трое редакторов, один бриф, три совершенно разных результата. Один переписал каждый сегмент с нуля. Второй исправил только орфографические ошибки. Третий сделал что-то между этим — и честно говоря, именно этот результат был ближе всего к правильному. Все трое читали один и тот же документ перед началом работы. Проблема была не в том, что они проигнорировали бриф. Проблема была в том, что бриф не говорил им то, что им действительно нужно было знать.
Написание эффективного бриффа для постредактирования — это один из тех навыков, который выглядит простым, но им не является. Большинство менеджеров знают, что они хотят получить на выходе. Но преобразовать это в письменные инструкции, которые постредактор может применить последовательно, на протяжении 10 000 слов, которые он никогда раньше не видел? Вот в чём сложность.
Вот что на самом деле должно быть в таком документе.
Почему большинство брифов для постредактирования не работают¶
Исследование MTPE-workflow, опубликованное в Journal of Specialised Translation, показало, что даже опытные переводчики с трудом применяют стандартные руководства по постредактированию последовательно. Причина: большинство руководств либо слишком общие (distinctions ISO 18587 между light и full оставляют «серые зоны», которые каждый редактор заполняет по-своему), либо слишком специфичные для одного проекта (бриф написанный для технического документа переиспользуется без изменений для маркетингового текста).
Результат — вариативность. Одно исследование показало, что до 34% редактирования в MTPE-workflow были ненужными — редакторы делали изменения, которые бриф не требовал, и никто их не останавливал, потому что бриф никогда не сказал «не трогайте это». Это дополнительное время, дополнительный биллинг и качество, которое сложнее проверять QA, потому что вы сравниваете с движущейся целью.
Ярлыки «light» и «full» — главный виновник. Различие имело смысл, когда вывод машинного перевода явно звучал по-машинному. Сегодня, при использовании нейронного машинного перевода и LLM-based переводов, вывод часто звучит правильно, но содержит тонкие ошибки значения. Редактор, который опирается только на ярлык «light» без конкретного руководства, будет принимать решения на основе собственного суждения — и это суждение варьируется.
Различие light vs. full: определите его для ВАШЕГО проекта¶
Не начинайте свой бриф с общего определения light и full постредактирования. Все в MTPE знают общее определение. Что они не знают — это что это значит для вашего специфического проекта, вашего конкретного клиента и конкретного MT-движка, который вы использовали.
Определите это примерами:
| Ситуация | Light PE (этот проект) | Full PE (этот проект) |
|---|---|---|
| Неловкое, но точное предложение | Оставить | Переписать в соответствии с человеческим стилем |
| Неправильная терминология (нет в глоссарии) | Исправить на ближайший вариант | Исправить на официальный термин из глоссария |
| Пропущенное отрицание («может» вместо «не может») | Всегда исправлять | Всегда исправлять |
| Неправильное число или дата | Всегда исправлять | Всегда исправлять |
| Пассивный залог где предпочтен активный | Оставить | Переписать |
| Стилистическое несоответствие между абзацами | Оставить | Исправить |
Эта таблица займёт 10 минут вашего времени и исключит половину решений, которые ваши редакторы иначе принимали бы по-разному.
7 разделов, которые должны быть в брифе для постредактирования¶
1. Контекст проекта — не просто название проекта¶
Редакторы принимают десятки микро-решений в час. Чем лучше они понимают, ПОЧЕМУ этот контент существует, тем лучше будут эти решения.
Включите: что этот контент предназначен для, кто конечный читатель, что происходит с текстом после постредактирования (идёт в печать, публикуется онлайн, остаётся внутри). Также: какой MT-движок или AI-инструмент был использован. Вывод GPT-4o имеет другие режимы отказа, чем вывод DeepL. Редактор, который знает, что он работает с DeepL, знает что нужно смотреть на окостенелый синтаксис и слишком длинные предложения. Редактор, работающий с LLM-выводом, знает что нужно смотреть на правдоподобно звучащие добавления, которых не было в исходном тексте.
Одного абзаца достаточно. Но этот абзац должен быть.
2. Уровень качества с конкретными примерами¶
Укажите уровень (light или full), затем немедленно покажите пример того, что это означает на практике. Пара до/после стоит 500 слов объяснения:
Исходный текст (оригинал на русском): «Перед выполнением любых операций по техническому обслуживанию устройство должно быть отключено от сети.»
Вывод MT: «Устройство следует отключать от сети перед каждой операцией техническое обслуживание.»
Ожидаемое Light PE: «Перед выполнением любых операций по техническому обслуживанию устройство должно быть отключено от сети.» — исправить грамматику и структуру, оставить всё остальное.
Ожидаемое Full PE: Та же коррекция плюс проверка стилистического соответствия с остальной частью документа.
Это якорит абстрактную инструкцию к чему-то, что редакторы могут использовать в качестве справки, когда они сталкиваются с неоднозначным сегментом.
3. Фреймворк приоритизации ошибок¶
Укажите три уровня ошибок и что делать с каждым:
Критические — всегда исправлять, без исключений: - Ошибки значения (неправильные переводы, которые меняют смысл текста) - Пропуски (всё, что выпало из исходного текста) - Числа, даты, измерения, имена - Контент с юридическими, медицинскими или safety-импликациями
Основные — исправлять в full PE, отметить и исправить в light PE если быстро: - Грамматические ошибки, которые ухудшают читаемость - Терминология, которая не совпадает с глоссарием - Структура предложения, которая делает текст сложным для понимания
Минорные — исправлять только в full PE, оставить в light PE: - Несоответствия в регистре - Пунктуационные предпочтения - Стилистические проблемы, которые не влияют на смысл
Этот фреймворк, взятый из ISO 18587:2017 MTPE-стандарта и адаптированный для практического использования, даёт редакторам правило решения вместо суждения. Когда они сомневаются в том, к какому уровню отнести проблему, они по умолчанию переходят к более низкому уровню в light PE и более высокому уровню в full PE.
4. Терминология и глоссарий¶
Два режима отказа, которых нужно избежать:
Слишком тонкий: «Пожалуйста, используйте одобренный глоссарий.» Какой глоссарий? Где он? Что если термина в нём нет?
Слишком обременительный: Таблица из 400 рядов, приложенная отдельным файлом, который никакой редактор не откроет перед тем как начать работу с партией из 2000 слов.
Рабочий компромисс: включите 20-30 самых критических терминов прямо в бриф — исходный термин, требуемый целевой термин и однострочное обоснование, если выбор не очевиден. Для всего остального линкуйте полный глоссарий и уточняйте правило отката («если термина нет в глоссарии, используйте наиболее распространённый эквивалент в целевом домене, затем отметьте для review»).
Также уточните do-not-translate элементы отдельным списком: названия продуктов, бренды, UI-строки, названия юридических лиц, placeholders. Не закапывайте это в глоссарии. Редакторы пропускают это и переводят то, что не должно переводиться, чаще чем любую другую ошибку.
5. Стиль и тон¶
Держите этот раздел коротким и специфичным. Длинные описания стиля не читаются. Редакторам нужно:
- Регистр: формальный / неформальный / нейтральный
- Лицо: первое, второе, третье
- Залог: активный предпочтителен или пассивный приемлем
- Длина предложения: соответствовать исходнику или адаптировать к нормам целевого языка
- Любые специфичные паттерны для избежания (например, «никогда не используйте сокращения», «избегайте пассива с ‘было’»)
Если есть документ style guide, линкуйте его — но также извлеките 3-5 правил, которые имеют значение для ЭТОГО контента, и положите их прямо в бриф. Предполагайте, что полный style guide не будет открыт до тех пор, пока редактор не столкнётся с конкретным вопросом.
6. Зоны do-not-edit¶
Каждый MTPE-проект имеет сегменты, которые не должны быть тронуты. Большинство брифов не список их. Затем редактор «улучшает» юридический дисклеймер, UI-строка ломается в программе, или ранее проверенный сегмент перезаписывается.
Список категорий: юридический бойлерплейт (требуется точное формулировка), ранее проверенные и заблокированные сегменты, торговые марки и зарегистрированные названия брендов, коды форматирования, placeholders, теги.
Если вы используете CAT-инструмент, блокируйте эти сегменты на уровне проекта — не полагайтесь только на бриф. Но бриф всё равно должен назвать категории, чтобы редакторы понимали почему определённые сегменты заблокированы.
7. Правило решения: когда оставить, когда переделать¶
Это раздел, который большинство брифов пропускают, и это тот, который имеет наибольшее значение для производительности.
Постредакторы тратят больше всего времени на пограничные сегменты — те, где вывод MT частично правильный. Без правила решения, редакторы размышляют. Они пытаются исправить, частично преуспевают, пытаются снова, тратят 3 минуты на одно предложение.
Правило: если исправление сегмента занимает больше 20-30 секунд в light PE, переделайте с нуля. В full PE порог выше, но пороговое значение всё равно должно быть.
Как Linearis говорит в своих MTPE инструкциях: «Принимайте быстрые решения (3-5 секунд максимум за сегмент)» для проходящей сортировки, и «переделывайте когда сырой MT не имеет никакого смысла.» Правило подобное этому, написанное явно в вашем брифе, предотвращает коллапс производительности, который происходит, когда редакторы пытаются спасти каждый сегмент независимо от усилий.
Включите конкретный язык: «Если исправление сегмента занимает больше [X] секунд и вывод MT меняет смысл, переделайте его. Не пытайтесь сохранить как можно больше текста MT — точность важнее, чем leverage MT в этом проекте.»
Или наоборот, если MT leverage — ваш приоритет: «Если смысл правильный, сохраните вывод MT даже если он звучит неловко. Ваша работа — точность, не стиль, в этом проекте.»
Одно из этих утверждений верно для вашего проекта. Напишите это.
Как понять работает ли ваш бриф¶
Пилотируйте перед масштабированием. Возьмите один файл, назначьте один и тот же отрывок из 500 слов двум разным редакторам с одним брифом, сравните результаты. Если результаты выглядят существенно различно, в брифе есть серые зоны, которые вы не закрыли. Найдите где решения расходились и добавьте специфичность в эти разделы.
Отслеживайте процент ревизии по редакторам в проектах. Если один редактор постоянно выдаёт гораздо более высокие word counts для «light PE», чем другие, они over-editing. Если другой постоянно показывает низкие процент ревизии в full PE, они under-editing. Бриф должен сузить этот gap — если он не делает этого, то он не достаточно детальный.
Собирайте feedback в конце первого проекта. Вопрос не «было ли качество хорошим?» Это «какие инструкции были неясны или отсутствовали?» Ответы улучшат ваш следующий бриф быстрее, чем любой внутренний QA-review.
Типичные ошибки, которые делают брифы бесполезными¶
Переиспользование одного и того же бриффа для разных типов контента. Бриф написанный для технических руководств производит неправильный результат когда применяется к маркетинговому контенту, и наоборот. Приоритеты ошибок разные, ожидания по стилю разные, покрытие глоссария разное. Ведите как минимум три бриф-шаблона: технический, маркетинг и юридический/регулируемый контент.
Слишком длинный для чтения перед началом. Если ваш бриф длиннее двух страниц, редакторы его бегло просматривают. Они всосут первый раздел и последний, и пропустят всё между ними. Положите наиболее критичные инструкции в начало, используйте таблицы и маркированные списки, и удалите всё, что не действительно actionable.
Без примеров. Абстрактные инструкции («сохранить appropriate register») производят вариативные результаты. Примеры до/после для level качества и ошибки-приоритета разделов удаляют двусмысленность. Добавьте как минимум три примера из фактического типа контента.
Отсутствует механизм feedback. Бриф — это живой документ. Если редакторы не могут отметить неясные инструкции во время проекта, бриф остаётся сломанным. Создайте канал для вопросов и сделайте понятным что флагирование ожидается, не знак некомпетентности.
Управление контекстом терминологии внутри инструментов перевода¶
Если ваш workflow включает AI-assisted инструменты перевода, которые поддерживают поля brief или context, информация бриффа не должна жить только в отдельном документе. Инструменты как ChatsControl позволяют вам установить домен, аудиторию, тон, и список терминологии перед тем как перевод запустится, поэтому AI-драфт уже отражает эти предпочтения перед постредактированием начинается. Это сужает gap между выводом MT и целевым level качества, и значит ваш бриф работает с инструментом вместо против него.
Это не замена для письменного бриффа — постредакторы всё равно нуждаются в полном контексте документа. Но это снижает систематические проблемы которые им нужно исправить, что значит они тратят больше времени на genuine ambiguities и меньше времени на исправление recurring patterns. ChatsControl также имеет standalone QA validator, который может быть использован для проверки постредактированного вывода against терминология и критерии ошибок перед финальным deliverable.
FAQ¶
Какая разница между брифом для постредактирования и style guide?¶
Style guide описывает общие лингвистические предпочтения для клиента или языковой пары — это общее и долгосрочное. Бриф для постредактирования — это project-specific: он специфицирует PE level, приоритеты ошибок для этого контента, конкретные термины глоссария которые применяются здесь, и правила решения для вывода этого MT-движка. Бриф ссылается на style guide для общего регистра и пунктуационных предпочтений, но он не заменяет его.
Насколько длинным должен быть бриф для постредактирования?¶
Максимум одна-две страницы для основного документа, плюс любые приложенные глоссарии. Если это длиннее, разделите его: положите критичные инструкции на страницу один, поддерживающую деталь в приложении. Редакторы читают страницу один. Они ссылаются на приложение когда они сталкиваются с конкретным вопросом.
Мне нужен другой бриф для light и full постредактирования?¶
Один бриф работает хорошо — структурируйте это с колонкой или разделом «light PE» и «full PE». Что имеет значение это что scope для каждого level определён в одном документе. Два отдельных документа fall out of sync когда вы обновляете один и забываете другой.
Что если качество MT настолько плохое что бриф не помогает?¶
Тогда проблема не в брифе — это вывод MT. Установите pre-evaluation шаг перед тем как назначить редакторам: пустите sample через быструю человеческую проверку. Если больше чем 30-40% сегментов нуждаются в полном переделывании, вы уже не делаете MTPE — вы делаете человеческий перевод с MT как грубой справкой. Либо выберите лучше-подходящий MT-движок либо бюджетируйте для полного человеческого перевода с самого начала.
Должны ли постредакторам быть разрешены вопросы во время проекта?¶
Да, и скажите им явно что вопросы ожидаются. Молчание не значит редакторы понимают бриф — это часто значит они делают предположения. Dedicated канал (Slack тред, CAT инструмент comment функция, или shared документ) для вопросов бриффа драматически улучшает качество первого-проекта результата.
Что это ISO 18587 и нужно ли мне это?¶
ISO 18587:2017 это международный стандарт для постредактирования вывода машинного перевода. Он определяет компетенции, workflow требования, и ожидания качества. Вам не нужна сертификация для запуска хорошего MTPE-проекта, но фреймворк полезен для структурирования вашего бриффа и выравнивания ожиданий с клиентами которые спрашивают о вашем QA-процессе. Language service providers работающие с enterprise клиентами всё более часто встречают ISO 18587 compliance как часть vendor qualification требований.