Как я автоматизировал рабочий процесс электронной почты на 13 языках, используя только ИИ и инструменты Microsoft

Локализация email-кампаний в нескольких регионах раньше была медленной, повторяющейся задачей с множеством этапов Обработки вручную. Несколько рецензентов работали над отдельными версиями, один и тот же контент переписывался несколько раз, а управление согласованностью на 13 языках требовало значительной координации.

Вместо внедрения новых платформ или внешних инструментов я провел внутренний эксперимент: \n Можно ли автоматизировать локализацию, используя только инструменты, уже доступные в стандартной корпоративной среде Microsoft?

Прототип в основном опирался на SharePoint, Power Automate и Teams с одним дополнительным компонентом - GPT-4.1 mini, доступным через Azure OpenAI - который использовался строго для контролируемого этапа контроля качества. Это позволило процессу извлечь выгоду из рассуждений на основе LLM, сохраняя все данные в той же корпоративной среде.

Для поддержки этого рабочего процесса я создал структурированную библиотеку SharePoint под названием Email translations с папками, представляющими каждый этап жизненного цикла локализации:

| Папка | Назначение | |----|----| | 01IncomingEN | Исходные файлы на английском; триггер Power Automate | | 02AIDrafts | Автоматически переведенные черновики от Copilot + GPT | | 03InReview | Файлы, ожидающие регионального рассмотрения | | 04Approved | Окончательно утвержденные переводы | | 99Archive | Архивированные или отклоненные версии |

Файлы автоматически перемещались между этими папками в зависимости от их состояния.

Целью было не создание идеальной системы локализации, а только проверка, насколько далеко может зайти прототип с использованием внутренних инструментов.

В итоге удалось устранить большую часть повторяющейся работы и создать гораздо более структурированный процесс рассмотрения.

Проблема: процесс, а не язык

Ручная локализация контента во многих регионах создавала несколько постоянных проблем:

• Каждый регион редактировал свой файл, поэтому одновременно существовало несколько разных версий.
• Когда исходный текст менялся, не все регионы обновляли свою версию, что приводило к несоответствию контента.
• Файлы сохранялись в разных местах и с разными именами, что затрудняло определение текущей версии.
• Рассмотрение вручную занимало время, особенно когда команды находились в разных часовых поясах.
• Повторение одних и тех же правок в нескольких файлах увеличивало риск мелких ошибок

Попытка 1: Перевод только с помощью Copilot

Хотя Copilot теперь работает на более новых моделях серии GPT-5, этот прототип был построен на более ранней версии, и поведение перевода отражало те ранние возможности.

Первая версия рабочего процесса была простой:

1. Файл загружался в 01IncomingEN.
2. Power Automate запускался автоматически.
3. Copilot генерировал перевод для каждого региона.

Поскольку триггеры SharePoint могут срабатывать до завершения загрузки файла, поток включал проверку завершения размера файла (ожидание, пока размер > 0, прежде чем продолжить).

Однако основная проблема быстро стала очевидной: переводы Copilot не были достаточно надежными для сквозной локализации.

Распространенные проблемы включали:

• CTA переводились слишком буквально
• тон и стиль различались между языками
• заполнители удалялись или изменялись
• различия в форматировании списков, интервалов и структуры

Это делало Copilot полезным только для создания первого черновика. \n Был необходим второй уровень проверки качества.

Попытка 2: Добавление GPT-4.1 Mini для контроля качества

Следующая версия добавила этап рассмотрения:

1. Copilot → начальный перевод
2. GPT-4.1 mini (Azure) → контроль качества и проверка согласованности

GPT-4.1 mini улучшил:

• согласованность тона
• сохранение заполнителей
• стабильность форматирования
• соответствие исходному значению

Промпты нуждались в настройке, чтобы избежать ненужного переписывания, но после корректировок выходные данные стали достаточно согласованными для использования в рабочем процессе.

Инженерная работа: обеспечение надежности рабочего процесса

Архитектура была простой, но во время реального использования возникло несколько проблем, требующих исправления.

Поведение платформы:

• Триггеры SharePoint не всегда запускались немедленно, поэтому были добавлены проверки и повторные попытки.
• Маршрутизация Teams не работала при переименовании каналов, поэтому сопоставление пришлось обновить.

Проблемы дизайна:

• Некоторые параллельные шаги не выполнялись при первом запуске, поэтому была введена логика повторных попыток.
• В ответах JSON иногда отсутствовали ожидаемые поля, поэтому была добавлена валидация.
• Имена файлов были непоследовательными, поэтому был определен единый формат именования.

После этих корректировок рабочий процесс надежно работал в нормальных условиях.

Окончательная архитектура прототипа

Ниже представлена полная рабочая структура системы.

1. Загрузка и прием SharePoint

Процесс начинался, когда файл загружался в Email translations / 01IncomingEN

Затем Power Automate:

• проверял, что файл полностью загружен (защита от нулевого байта)
• извлекал метаданные
• извлекал текст
• определял целевые регионы

SharePoint выступал в качестве единого источника истины для всех этапов.

2. Оркестрация Power Automate

Power Automate контролировал каждую часть рабочего процесса:

• чтение английского источника
• вызов Copilot для черновика перевода
• отправка черновика в GPT-4.1 mini для контроля качества
• создание ветки для каждого региона
• отправка результатов по электронной почте местным командам
• публикация карточек одобрения Teams
• фиксация "одобрить" или "запросить изменения"
• сохранение утвержденных файлов в 04_Approved
• сохранение обновленных версий в 03InReview
• архивирование старых версий в 99_Archive

Вся маршрутизация, повторные попытки и переходы состояний обрабатывались Power Automate.

3. Этап перевода Copilot

Copilot переводил извлеченный контент и сохранял большую часть структуры электронной почты - списки, интервалы и форматирование - лучше, чем GPT в одиночку.

4. Этап контроля качества GPT-4.1 Mini

GPT-4.1 mini проверял:

• согласованность тона
• соответствие значению
• стабильность форматирования
• целостность заполнителей

Это создавало более надежный черновик для регионального рассмотрения.

5. Региональное рассмотрение (Email + Teams)

Для каждого региона Power Automate:

• отправлял переведенный файл по электронной почте
• публиковал адаптивную карточку Teams с Approve / Request changes

Если были представлены изменения, обновленный файл возвращался в 03InReview и повторно входил в рабочий процесс.

6. Окончательное хранение

Утвержденные переводы хранились в 04_Approved с использованием единого формата именования.

Отклоненные или устаревшие версии перемещались в 99_Archive. Это обеспечивало полный и чистый аудиторский след.

Результаты

После тестирования прототипа в реальных рабочих процессах:

• время перевода сократилось с дней до минут
• меньше конфликтов версий
• минимальное ручное переписывание
• более быстрые циклы рассмотрения
• все данные обрабатывались внутри среды Microsoft

Это не заменило специализированные системы локализации, но устранило значительное количество повторяющейся ручной работы.

Ограничения

• некоторые языки все еще требовали стилистических корректировок
• одобрения Teams зависели от времени отклика рецензентов
• поток нуждался в логике повторных попыток для временных ошибок
• согласованность тона варьировалась в длинных или сложных электронных письмах

Это было приемлемо для прототипа.

Следующий шаг: память терминологии

Следующее запланированное улучшение - векторная терминологическая библиотека, содержащая:

• глоссарий
• названия продуктов
• ограниченные термины
• региональные фразы
• группы синонимов
• правила тона

Обе модели будут использовать эту библиотеку перед созданием или проверкой переводов.

Заключительные мысли

Этот проект был внутренним экспериментом, чтобы понять, насколько рабочий процесс локализации может быть автоматизирован с использованием только стандартных инструментов Microsoft и