Интересные задачи: перевод сложного документа

Пожалуй, главное изменение, которое у меня произошло в связи с обширным использованием 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 часа, включая неторопливый мозговой штурм. Сколько дней/недель ушло бы на перевод настоящим переводчиком — даже не хочу себе представлять.