Коротко: нейросетевая перевалка книг стала процессом, а не одним промптом
Локальный перевод художественных книг через LLM за год перестал быть экспериментом «загрузил файл и получил готовую книгу». Теперь это управляемый пайплайн: извлечение структуры, сегментация, словарь терминов, перевод в структурированном формате, контроль качества, повторные проходы и сборка результата. Человек остаётся в цикле для вычитки, согласования терминов и стилистической правки. Без него текст рискует стать однообразным, с дрейфом имён и неудачными формулировками.
Зрелость подхода определяется не только качеством LLM, а появлением контрольных точек и воспроизводимых стадий. Одноразовый запрос на длинном тексте даёт нестабильный результат: модель может хорошо переводить отдельные сцены, но терять согласованность на дистанции. Поэтому пайплайн строится как последовательность шагов, каждый из которых можно проверить и при необходимости повторить.
В статье разберём, как устроен такой пайплайн для форматов FB2 и EPUB, зачем нужен словарь терминов, от чего зависит скорость и расход токенов, и где проходит граница между черновиком от нейросети и работой редактора.
Почему перевод художественных книг через LLM перестал быть задачей «загрузить файл и ждать»
Начальная идея простая: берём книгу, отправляем в модель, получаем перевод. На практике для художественного текста это не работает. Книга длинная, в ней сотни страниц, множество персонажей, повторяющиеся термины, сюжетные линии. Модель с ограниченным контекстом не удержит всё это в памяти. Даже с длинным контекстом качество может страдать: чем больше текста, тем сложнее модели сохранять единообразие.
Длинный текст создаёт проблему согласованности, а не только объёма
Ошибки накапливаются: имя персонажа переводится по-разному в разных главах, термин исчезает из контекста, обращение меняет тон, ранняя сюжетная деталь не учитывается позднее. Бенчмарк PII-TRACE показывает, что даже для задачи обнаружения персональных данных в длинных диалогах (от менее 1000 до более 100000 символов) важно согласованное покрытие повторяющихся сущностей. Для перевода книг это ещё критичнее: читатель заметит, если героя зовут то «Джон», то «Джонатан».
Нельзя оценивать перевод по одному удачному отрывку. Нужно проверять весь текст на согласованность. Поэтому пайплайн должен включать механизмы контроля: словарь, повторные проходы, автоматические проверки.
Главная перемена - появление контрольных точек
Надёжность обеспечивается архитектурой процесса, а не надеждой на один удачный ответ модели. После каждого этапа ставятся проверки: валидность структуры, полнота сегментов, соблюдение словаря, разбор подозрительных мест. После перевода и сборки выполняется редакторская вычитка, затем повторная проверка исправленного текста.
Пример общего паттерна многошаговой нейросетевой редактуры даёт сервис 24AI: он разбирает документ по восьми группам ошибок (орфография, пунктуация, логика, единообразие, тон и другие), выдаёт сводку, список правок и чистовую версию, а исправленный документ можно отправить на повторную проверку. Это аналогия к организации контроля, а не доказательство работы сервиса именно с переводом книг.
Качество результата зависит от качества запроса. В обзоре нейросетей для сайтов отмечено: детальное описание даёт заметно лучший результат, чем общий запрос. Разные инструменты могут выдавать как почти готовый результат, так и лишь основу для доработки. Поэтому в пайплайне важно не только переводить, но и проверять, уточнять и исправлять.
Как перевести книгу локальной нейросетью: базовый пайплайн для FB2 и EPUB
Форматы FB2 и EPUB имеют разную внутреннюю структуру. FB2 - это XML, EPUB - набор HTML-документов в ZIP-контейнере. Чтобы обрабатывать их единообразно, стоит сначала привести файл к внутреннему представлению: извлечь текст с разметкой, разделить на сегменты, перевести, затем собрать обратно в целевой формат.
Импорт: сохранить главы, абзацы, сноски и служебные элементы
Задача этапа - определить главы и подзаголовки, отделить основной текст от метаданных, иллюстраций, оглавления, примечаний и технической разметки. В источниках книги часто распространяются в FB2, EPUB, TXT и PDF. PDF с сохранённой вёрсткой требует отдельного и более осторожного сценария извлечения текста, так как структура в нём не всегда явная.
Сегментация: делить текст по смыслу, а не по случайному числу символов
Сегмент должен иметь устойчивый идентификатор, исходный текст, данные о главе и достаточно контекста для местоимений, диалогов и терминов. Слишком крупные блоки упираются в контекст и замедляют обработку, слишком мелкие делают стиль рваным и повышают число повторных запросов. Оптимальный размер зависит от модели и жанра, но обычно это несколько абзацев или сцена.
JSON-вывод: сделать результат проверяемым и пригодным для сборки
Структурированный ответ LLM удобнее свободного текста при массовой обработке глав. Минимальная схема: идентификатор сегмента, переведённый текст, список замечаний или флаг неопределённости, при необходимости использованные термины. JSON позволяет валидировать ответ, сопоставлять его с исходным сегментом, повторно отправлять только проблемные фрагменты и не путать порядок частей книги. Нужно предусмотреть обработку невалидного JSON и неполных ответов: повторный запрос или ручное исправление.
Сборка: вернуть перевод в читаемую книгу без потери навигации
После перевода всех сегментов нужно восстановить заголовки, абзацы, сноски, оглавление и внутренние ссылки там, где это поддерживает исходный формат. Отдельная техническая проверка готового FB2 или EPUB: открывается ли файл в читалке, сохранился ли порядок глав, не пропали ли сегменты и не осталась ли разметка в тексте.
Словарь терминов: защита от дрейфа имён, мира и голоса персонажей
Модель может хорошо переводить отдельную сцену, но быть непоследовательной на дистанции целой книги. Словарь терминов фиксирует переводы имён, названий, терминов мира и стилистические правила. Это не только таблица «оригинал - перевод», но и варианты транслитерации, географические названия, титулы, обращения, магические системы, единицы измерения, устойчивые выражения, запреты на перевод и редакторские комментарии.
Что фиксировать до первого массового прогона
Стартовый словарь должен включать: главный персонаж и алиасы, второстепенные герои, фракции, названия мест, предметы, термины мира, формы обращения и отдельные стилистические правила. Словарь неполон: он пополняется по мере чтения и вычитки. Поэтому важно вести его в структурированном виде, чтобы легко добавлять новые записи.
Как передавать словарь в запрос и проверять его соблюдение
Два уровня: передавать релевантную выборку терминов вместе с сегментом и отдельно запускать проверку уже собранного текста на варианты написания. Детализированный запрос обычно даёт лучший результат, чем общий, но слишком большой словарь в каждом запросе расходует контекст и токены. Релевантность словаря нужно подбирать по главе, персонажам и сцене. Например, для главы с битвой нужны термины оружия и магии, для диалога - обращения и имена.
Необходимость словаря подтверждается данными PII-TRACE о важности согласованного покрытия повторяющихся сущностей в длинном контексте. В переводе книги сущности - это персонажи, места, предметы. Если их переводы дрейфуют, читатель теряет нить.
Скорость локального перевода: почему контекст и модель важнее красивых цифр токенов в секунду
Скорость обработки книги зависит от всей цепочки, а не только от заявленной скорости генерации. Время складывается из чтения и разбора файла, подготовки контекста и словаря, префилла, генерации, валидации JSON, повторных запросов, проверок согласованности, сборки и ручной вычитки. Длинное контекстное окно может уменьшать число потерь связности, но само по себе не гарантирует качество и может увеличивать нагрузку.
Выбор модели: баланс между качеством черновика, контекстом и ресурсами
Критерии выбора: качество перевода нужной языковой пары, следование инструкции, устойчивость формата JSON, доступный контекст, скорость на имеющемся железе, потребление VRAM и стабильность при длинных сериях запросов. Модель и железо нужно оценивать в контексте реального локального сценария, а не по одному параметру. Например, модель с отличным качеством, но медленной генерацией на вашей видеокарте может сделать проект нереалистичным.
Почему короткий тестовый отрывок не предсказывает время на всю книгу
На полной книге появляются повторные проходы, сбои формата, расширение словаря, проблемные диалоги и ручная редактура. Рекомендуется измерять отдельные этапы на нескольких главах разного типа: диалоговой, описательной и терминологически насыщенной. Это даст более реалистичную оценку, чем один отрывок.
Контроль качества: где заканчивается хороший черновик и начинается работа редактора
Автоматические проверки полезны для полноты, структуры, повторов, терминов, орфографии и части пунктуации. Человек нужен для ритма фразы, интонации, подтекста, отличия голосов персонажей, культурных реалий и мест, где буквальный перевод формально верен, но литературно слаб. Поэтому контроль качества делится на автоматический и ручной.
Автоматические проверки должны искать конкретные классы проблем
Технические проверки: пропущенные или дублированные сегменты, невалидные поля JSON, нарушение словаря, разные написания сущностей, оставшийся исходный язык, подозрительные повторы. Языковые проверки: пунктуация, единообразие, орфография. Список проверок не заменяет литературную оценку, но помогает быстро найти системные ошибки. Ориентиром для классификации дефектов может служить подход 24AI, который заявляет восемь групп ошибок, включая орфографию, пунктуацию, логику, единообразие и тон.
Повторная проверка нужна после исправлений, а не только до них
Ручная или автоматическая правка одного места может сломать согласованность в другом. Поэтому цикл такой: проверка выявляет проблему, редактор или модель правит конкретный сегмент, исправление возвращается в сборку, затем запускается повторная проверка связанных терминов и структуры. Это соответствует практике многошаговой редакторской обработки из описания 24AI, где исправленный текст допускается отправить на повторную проверку.
Экономика процесса: как считать токены и не забыть цену редакторского времени
Для локального пайплайна нужно учитывать токены исходного сегмента, системную инструкцию, контекст предыдущих фрагментов, релевантную часть словаря, ответ модели, повторы при ошибках JSON и отдельные QA-проходы. Плюс время GPU, ограничения VRAM, электроэнергию при необходимости и главное - часы редактора. Более дешёвый или быстрый прогон может стать дороже, если создаёт много ручных исправлений.
Какие метрики стоит вести по каждой книге
Журналируйте: число сегментов, объём входа и выхода, повторы, ошибки структурированного вывода, время по стадиям, покрытие словаря, число редакторских правок и долю фрагментов, отправленных на повторную обработку. Целевые значения зависят от языковой пары, жанра, модели, оборудования и требований к чистовому тексту, поэтому не назначайте их заранее. Собирайте данные, чтобы принимать решения на фактах.
Когда локальный пайплайн оправдан, а когда лучше не обещать себе автоматический перевод
Пайплайн особенно осмыслен при повторяющихся задачах, необходимости контролировать данные, готовности поддерживать словарь и наличии времени на настройку. Он может быть невыгоден для разовой книги, очень требовательного литературного перевода или сценария, где нет редактора для финальной вычитки. Зрелость системы определяется контролируемостью, воспроизводимостью и понятными ограничениями, а не тем, насколько убедительно выглядит первый переведённый абзац.
Если вы строите похожий пайплайн, обратите внимание на смежные материалы: почему нейросети для перевода начинают решать задачи, а не переводить и локальная 0.8B-модель для очистки диктовки.