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

Мабуть, головна зміна, яка відбулася у мене у зв'язку з широким використанням LLM, – зникли неможливі завдання. Будь-яка складність або завдання, пов'язані з великою кількістю інформації або автоматизацією чогось рутинного, тепер сприймаються як своєрідний виклик – а ну, як з цим впоратися?

З іншого боку, звичайно, іноді в розпал боїв з Claude Code відчуваєш себе героєм мультика про крила і ноги – «краще день втратити, потім за дві години долетіти». Набагато частіше виходить навпаки.

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

Зрозуміло, кілька сотень сторінок на десятки мегабайт в жоден перекладач не запхаєш. Переклад по частинах передбачає виснажливий процес копіювання і вставки, причому щоразу збивається форматування, а картинки вимагають особливої обробки – адже виносні написи на схемах повинні бути точно позиціоновані.

У загальних рисах завдання було зрозумілим відразу – запустити Claude Code і перекладати через нього. На відміну від звичайного чату, йому можна показати файл і вказати, що перекладати його треба розділами, щоб не втрачати контекст. Але я вже звик починати вирішення завдань з «установчої» чат-сесії з LLM – як правило, витрачені десятки хвилин на такий мозковий штурм з формулюванням рішень обертаються солідною економією або навіть несподіваним розв'язанням проблеми зовсім з іншого боку.

Так вийшло і тут – Claude відразу сказав, що docx-файл це по суті архів з XML всередині (це я знав, тому і розраховував на успіх всієї справи) і додав, що всі текстові поля (ті самі виноски) там теж прописані. Тому процес нескладний – розпакувати файл, витягнути з xml всі елементи, перекласти їх текстовий вміст, замінити ним оригінальний вміст і запакувати назад.

Звичайно, не все так просто. Точно було зрозуміло, що великий файл навіть поетапно сам Claude без переповнення контексту не перекладе. Але тут вже я можу генерувати ідеї – в такій ситуації штатним рішенням є винести об'ємну за контекстом операцію для виконання субагентом, а головний процес буде тільки координувати процес. Оскільки у кожного екземпляра субагента свій незалежний контекст, практично можна не турбуватися про його переповнення – будь-який розділ на кілька сторінок завідомо поміститься, навіть з урахуванням місця на глосарій. Так, оскільки текст технічний і містить багато термінів, важливо правильно та однаково перекладати всі терміни.

Знову ж таки – все не так просто, диявол знайде, в яких деталях сховатися, особливо при недосконалості технічних та інших рішень. Наприклад, Claude не знає, як створювати своїх власних агентів і робить просто великі промпти. Або вміє вказати агенту, щоб той, зустрівши новий термін, позначив його, але передбачити обробку таких позначок забув – довелося нагадати. Люди теж недосконалі – вже кілька поколінь користувачів в очі не бачили друкарської машинки, але звичку відбивати відстані пробілами якось набули. А для машини це значущий символ, через який рядок у документі не збігається з перекладом.

У підсумку комплекс виглядав наступним чином:

• python-скрипт, що парсує docx-файл. Після його роботи в робочій директорії вийшов xml вихідного документа, вихідний текст кожного розділу в md-форматі, і json-файл, що містить дані про всі текстові написи.
• субагент translator, який отримував на вхід глосарій, md-файл для перекладу (або фрагмент json з текстовими блоками), перекладав і записував результат перекладу в такий же md-файл для кожного розділу.
• python-скрипт asseble_docx, який, як зрозуміло з назви, збирав перекладений контент в єдиний docx-файл.
• власне, сам Claude Code, який цим всім керував – запускав перший скрипт, передавав завдання субагенту, перевіряв виконання і запускав збирач. Це так зараз гладко описано, а насправді частина рядків залишилася неперекладеною, крім написів на картинках збірка ламалася на списках і таблицях – в цілому, кінцевий файл створювався приблизно 18 разів. Не рахуючи тестових запусків на парі розділів, перш ніж результат став близьким до правильного. Все одно залишилася деяка кількість проблем. Наприклад, українська мова в середньому довша за англійську, тому частину текстових боксів доведеться збільшувати вручну. Десь загубилося форматування жирним шрифтом тощо. Але це в цілому дрібниці, які набагато простіше виправити вручну.

Зате в сухому залишку маємо – технічний документ на 250 сторінок зі схемами й таблицями задовільно перекладений за 4 години, включаючи неквапливий мозковий штурм. Скільки днів/ тижнів пішло б на такий переклад живим перекладачем – навіть не хочу собі уявляти.

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