Я потратил 3 месяца на создание конвейера с открытым исходным кодом, который переводит книги целиком с помощью любых ИИ-моделей, в том числе локальных.
Приоритет был в том, чтобы для управления самим конвейером хватало даже бесплатных лимитов на OpenCode (а по опыту в текущей сборке по качеству вполне хватает даже локального Квена, который крутится на персональном компе на видеокарте с видеопамятью 16 ГБ), а основную нагрузку по переводу можно было бы поручить локальной узкоспециализированной модели, такой как Hy-MT2-7B (для повышения качества можно использовать Hy-MT2-30B-A3B). Вёрстка автоматизирована за счет создания множества скриптов на Питоне и скиллов, учитывающих обширный опыт исправления ошибок вёрстки.
Более того, управлять конвейером можно даже просто из командной строки руками.
Один скилл — для всего конвейера перевода, 26 скиллов — для повышения качества вёрстки!
1. Зачем нужен ещё один переводчик
В интернете уже полно самодельных переводчиков. Про один из них уже была статья на Хабре.
Но там нигде нет самого главного — возможности переводить бесплатно сколько угодно, одновременно при этом верстать полноценные книги сразу (LaTeX + PDF) и при этом полностью избегать отказов моделей переводить. Современные LLM-модели очень часто отказываются переводить и верстать статьи и книги по самым разным причинам.
Поэтому в этом конвейере массовый перевод выполняет локальная модель, а вёрстку — Python-скрипты. Вы сами выбираете модель и объём работы. На всех книгах, с которыми я работал, такая схема позволила выполнять перевод без каких-либо отказов.
Иллюстрации к разделам 1–8 подготовлены с помощью ИИ.
Кроме того, если вы попробуете попользоваться тем, что уже выложено, то обнаружите, что внезапно возникает очень много непредвиденных ошибок вёрстки или проблем с переводом, которые не были предусмотрены авторами этих конвейеров. Именно поэтому мне понадобилось целых 3 месяца и перевод нескольких десятков книг, чтобы наделать для этого скиллов. Более того, проект на GitHub я планирую обновлять, как только буду обнаруживать новые проблемы и непредвиденные сценарии, клепать новые скиллы и улучшать скрипты.
Если вы воспользуетесь моим конвейером и вдруг обнаружите какие-то проблемы, которые он не решает самостоятельно (а для их решения нужна помощь ИИ-агента), — пишите мне. Приложите подготовленное агентом описание этого опыта: он будет учтён в следующем обновлении.
Конечно, для самых современных крутых моделей это всё не является проблемой, они любые проблемы вёрстки решают самостоятельно. Но суть-то в том, чтобы их не использовать вообще и переводить книги бесплатно, причем без всяких ограничений.
2. Начало работы
Первый опыт был самым наивным. Я просто взял подписку Claude за 200 долларов и перевел книгу почти на 900 страниц (комплексный анализ Тристана Нидхэма). Затем поручил ему на основе опыта этой работы разработать скилл, потом 3 дня допиливал этот скилл для того, чтобы он позволял переводить с помощью Hy-MT2-7B, верстать настроенным конвейером (куча скриптов на Питоне) и управлялся агентом на базе бесплатных моделей в OpenCode.
Кроме того, для распознавания сканов использовался MinerU, который тоже крутится на видеокарте (на GitHub есть подробное описание того, что это такое и как его использовать).
3 дня ушло на то, чтобы добиться результата — бесплатные вёрстка и перевод были почти ничем не хуже. Разве что для обеспечения качества перевода требовался очень подробный глоссарий, но этот глоссарий можно было составить тем же Клодом, потратив в десятки раз меньше токенов, чем было потрачено на полный перевод книги с его же помощью.
3. Первое разочарование
Воодушевившись, я начал переводить этим конвейером всё подряд. С 12 по 17 июля перевел несколько книг по математике и философии. Внезапно оказалось, что вёрстка много где была ужасной (куча ошибок, неожиданные повторы параграфов, неправильные оглавления, странные расположения текста на страницах, вырезанные рисунки, ужас в формулах). Более того, возникали странные сбои и прекращения работы, модель-переводчик внезапно могла перестать отвечать или дублировать ответы (например, 2 раза подряд напечатать перевод одного куска вместо того, чтобы перевести 2 куска подряд).
После каждой проблемы чинил всё Клодом и поручал ему переделать конвейер. Казалось, этот процесс переделки бесконечен, а вплоть до 17 июля не было видно даже прогресса, несмотря на то, что Клод уже сильно переписал скрипты и написал несколько скиллов.
4. Первая надежда
С 18 по 24 июля я продолжал с помощью Клода чинить конвейер тем же самым образом: запускаю конвейер, фиксирую проблемы, запускаю диагностику всех проблем Клодом и пишу ему о тех проблемах, что нашел лично, затем с помощью Клода же довожу работу конвейера до конца и исправляю весь конвейер, получая новые изменения скриптов, новые скрипты и новые скиллы для конвейера.
Но, в отличие от предыдущего периода, прогресс стал значительно заметнее. Конвейер уже в большинстве случаев работал как надо с книгами. К 24 июля я уже даже решил, что в принципе сделал очень полезный переносимый инструмент, и стал раздавать его знакомым.
Кроме того, оказалось, что Claude отказывается переводить и верстать сам больше половины нужных мне книг по тем или иным причинам. А конвейер делает всё, что нужно. Более того, оказалось, что Claude отказывается делать работу только лично — управлять конвейером, который делает всю эту запрещенную ему работу, он не отказывается.
В принципе, это уже был успех. Оставались только мелкие проблемы, которые возникали, если конвейером управлял не Claude, а какая-нибудь бесплатная модель на OpenCode. Управление конвейером требует совершенно незначительного количества токенов.
5. Новые испытания
Я решил довести конвейер до такого состояния, чтобы им могла управлять даже самая тупая модель, и гарантированно получать хороший результат. Кроме того, хотелось настроить его так, чтобы помехой не были сложные случаи OCR и трудно распознаваемые сканы (диагностика проблем сканов, повторные сканы той же страницы, реконструкции и тому подобное).
Первые две недели августа специально набрал сложных сканов древних книг. Самыми убойными были сканы древних изданий по философии Гегеля, которые были написаны немецким готическим шрифтом и содержали страницы низкого качества. Отдельной сложностью этих томов было то, что сканы содержали дубликаты страниц, а местами страницы были отсканированы в неправильном порядке — конвейер должен уметь с этим справляться, превращая это всё в хорошо свёрстанные переведенные LaTeX-документы.
С историческими книгами проблемы возникали, даже когда конвейером управлял Claude.
Еще 2 недели в августе ушли на то, чтобы настроить конвейер до такого состояния, чтобы даже бесплатные модели на OpenCode правильно переводили и верстали подобные книги.
6. Длинная отладка
Затем в сентябре я перешел с подписки на Claude на подписку ChatGPT. Каждый день конвейер переводил новые книги абсолютно бесплатно и без отказов, а я через Codex диагностировал проблемы, если они были, и снова чинил конвейер.
Ошибок уже было мало, но они появлялись вновь и вновь, снова казалось, что процесс отладки бесконечный. Но к середине октября ошибки почти исчезли.
Более того, с бесплатных моделей на OpenCode я перешел к управлению конвейером через локальный Qwen. Это повысило требования к качеству конвейера, но всё работало отлично.
11 и 12 октября решил ещё доработать конвейер и выложить на GitHub. В этот раз я взял конвейер и стал гонять его на малых фрагментах и главах самых разных книг. Это позволило расширить список возможных проблем и их исправлений.
Кроме того, запустил через GPT Astra полную диагностику и анализ возможных несовершенств конвейера еще перед этим.
Закончилось всё благополучно — конвейер теперь готов и под управлением бесплатных моделей справляется даже с довольно тяжелыми случаями.
Кроме того, он умеет не только работать с тем LaTeX-каркасом, который строит сам, но и переводить в уже готовый чужой каркас. Для этого настроен отдельный оркестратор.
Наконец, для тех, кто любит работать руками: управлять конвейером можно с помощью ручного запуска скриптов и вообще отказаться от использования управляющей LLM.
7. Пример запуска без управляющего агента
Источник: v0.1.0-beta.3 — предварительный релиз, commit cef3ff16ea06b37f395d66005e75723f43f5beeb.
Для обычного запуска скачать из Assets translate-pdf-latex.zip и соответствующий .sha256; автоматически создаваемые GitHub Source code ZIP/TAR — другие архивы.
Сначала установить зависимости по инструкции.
Команды — из папки распакованного конвейера в PowerShell; venv и локальный сервер уже настроены, папки demo-01 ещё нет. Это Markdown-тест без OCR.
.\venv\Scripts\python.exe -X utf8 scripts\pipeline.py init assets\quickstart.md --out 'D:\Translations\demo-01' .\venv\Scripts\python.exe -X utf8 scripts\pipeline.py plan 'D:\Translations\demo-01' .\venv\Scripts\python.exe -X utf8 scripts\pipeline.py run 'D:\Translations\demo-01' .\venv\Scripts\python.exe -X utf8 scripts\pipeline.py status 'D:\Translations\demo-01'
Умолчания: localhost:1234, точный ID hy-mt2-7b, hymt, один одновременный запрос. При другом ID/endpoint передать JSON через init --settings; для общей модели — режим generic.
Для PDF с формулами отдельно нужны MinerU, его веса, extract: math и проверка выбранного извлекателя. Не запускать вторую GPU-модель поверх работающей.
Готовые books/skeleton — EN→RU; подготовленный OCR проверен DE→RU.
Иные пары требуют проверки OCR, шрифтов, шаблонов и приёмки.
8. Схемы работы и пример перевода
Схемы подготовлены с помощью ИИ.
Схема 1. CLI или агент управляет стадиями; массовый OCR/MT выполняется локально. Облачный контроллер может передавать свои входы провайдеру.
Схема 2. Последовательные GPU-стадии.
Исходник: первая страница собственного двухстраничного теста. Сноска правильно задаёт единицу силы: kg·m/s².
Результат: четвёртая физическая страница PDF, номер на полосе — 3. Структура сохранена, но в сноске неверно переведена единица силы. Для исключения таких ошибок и ошибок перевода терминологии как раз и нужен глоссарий.
Если статья оказалась полезной, вы можете поддержать меня кнопкой «Задонатить» под публикацией. Также сильно помогут ваши лайки и распространение материала.