Як я автоматизував робочий процес електронної пошти на 13 мовах, використовуючи лише ШІ та інструменти Microsoft

Локалізація електронних кампаній у кількох регіонах раніше була повільним, повторюваним завданням з багатьма кроками Обробки вручну. Кілька рецензентів працювали над окремими версіями, один і той самий вміст переписувався кілька разів, а управління узгодженістю для 13 мов вимагало значної координації.

Замість впровадження нових платформ чи зовнішніх інструментів, я провів внутрішній експеримент: \n Чи можна автоматизувати локалізацію, використовуючи лише інструменти, які вже доступні в стандартному корпоративному середовищі Microsoft?

Прототип базувався переважно на SharePoint, Power Automate та Teams, з одним додатковим компонентом - GPT-4.1 mini, доступним через Azure OpenAI - який використовувався виключно для контрольованого етапу QA. Це дозволило процесу отримати переваги від міркувань на основі 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 для QA

Наступна версія додала крок перегляду:

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

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 для QA
• створення гілки для кожного регіону
• надсилання результатів електронною поштою місцевим командам
• публікація карток схвалення Teams
• фіксація "схвалити" або "запитати зміни"
• збереження затверджених файлів у 04_Approved
• збереження оновлених версій у 03InReview
• архівування старих версій у 99_Archive

Усі маршрутизації, повторні спроби та переходи стану оброблялися Power Automate.

3. Етап перекладу Copilot

Copilot перекладав витягнутий вміст і зберігав більшу частину структури електронної пошти - списки, інтервали та форматування - краще, ніж GPT самостійно.

4. Етап QA GPT-4.1 Mini

GPT-4.1 mini перевіряв:

• узгодженість тону
• узгодження значення
• стабільність форматування
• цілісність заповнювачів

Це створювало більш надійну чернетку для регіонального перегляду.

5. Регіональний перегляд (електронна пошта + Teams)

Для кожного регіону Power Automate:

• надсилав перекладений файл електронною поштою
• публікував адаптивну картку Teams з Схвалити / Запитати зміни

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

6. Остаточне зберігання

Затверджені переклади зберігалися в 04_Approved з використанням послідовного формату іменування.

Відхилені або застарілі версії переміщувалися до 99_Archive. Це забезпечувало повний і чистий аудиторський слід.

Результати

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

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

Це не замінило спеціалізовані системи локалізації, але усунуло значну кількість повторюваної ручної роботи.

Обмеження

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

Це було прийнятно для прототипу.

Наступний крок: пам'ять термінології

Наступним запланованим удосконаленням є векторна бібліотека термінології, що містить:

• глосарій
• назви продуктів
• обмежені терміни
• регіонально-специфічні фрази
• групи синонімів
• правила тону

Обидві моделі використовуватимуть цю бібліотеку перед створенням або перевіркою перекладів.

За