diff --git a/START_PROMT.MD b/START_PROMT.MD index 3dbcfbf..c493101 100644 --- a/START_PROMT.MD +++ b/START_PROMT.MD @@ -1,10 +1,11 @@ -Стартуем новый проект. Идея у меня такая: реализовать бэкенд c фронтендом переводов крупных текстов, то есть книг (прицелюсь пока что в японские/китайские/английские ранобэ и вебновеллы), который будет ходить в ИИ апи для того чтобы переводить поп культурный текст. +Идея у меня такая: реализовать бэкенд c фронтендом переводов крупных текстов, то есть книг (прицелюсь пока что в японские/китайские/английские ранобэ и вебновеллы), который будет ходить в ИИ апи для того чтобы переводить поп культурный текст. -Значит я хочу в целом анализ этого рынка отдельно, чтобы понять перспективы, мои идеи, возможность продать такой софт и нужен ли он вообще хоть кому-то и какой на него спрос. +Я хочу в целом анализ этого рынка отдельно, чтобы понять перспективы моих идеи, возможность продать такой софт и нужен ли он вообще хоть кому-то и какой на него спрос, ну и понять маржинальность. -Главная цель -- максимальное качество и решение проблемы "нехудожественности" ИИ-переводов, стоит подойти креативно к вопросу, возможно применить какие-то мльные математические подходы дообучения под конкретную книгу, интернет ресерча для перевеода конкретной книги, сосдених бэкендов которые будут выполнять какую то совсем другую работу и тп. +Главная цель проекта -- максимальное качество и решение проблемы "нехудожественности" ИИ-переводов используя ИИ-перевод (вот так противоречиво, да), стоит подойти креативно к вопросу, возможно применить какие-то мльные математические подходы дообучения под конкретную книгу, интернет ресерча для перевеода конкретной книги, соседних бэкенду тулзов, которые будут выполнять какую то совсем другую работу по переводу, возможно вызов каких-то скиллов как у агентов и тп. + +Набор немного разрозненных идей V0 -Набор немного разрозненных идей таков: 1) построить пайплайн из разных агентов 2) агенты будут выступать в разных ролях: судьи, переводчики, редакторы, консультанты поп культуры, писатели, языковые анализаторы и другие возможны роли если ты понимаешь в этом лучше меня 3) построить пайплайн из дешевых агентов, чтоб перевод книги не превращался в дикую стоимость по цене @@ -46,4 +47,37 @@ hello my dear 36) я за переиспользуемые решения, по тому же решению банка памяти или глоссария использовать что то готовое или перетянуть готовое решение вроде MemPalace или его форкнуть, допилить, оценить 37) тебе доступны вообще все тулзы на этом компьютере: вебфетч, gh, просмотр репозиториев, клонирование в /tmp и так далее, делай что захочешь чтоб достигнуть цели -Мысли получились довольно сумбурные, плюс я накидывал по мере вдохновения, возможно я где-то мог ошибиться, можешь меня поправлять. В целом я тебя нигде и ни в чем не ограничиваю, полная творческая свобода с учетом задачи, выслушаю предложения, гипотезы, твои сомнения и критику, можешь сам дополнить перечисленные пункты, перефразировать их, синтезировать и придумать свои, так же я думаю стоит выделать некоторые пункты жирным курсивом и уделить им максимум внимания, потому что какие-то из них будут определять или могут неожиданным образом определить качество таких переводов. Сам промт у меня получился довольно большой и очень много задач, которые возможно будут решаться аж несколькими сессиями воркфлоу, которые я могу в принципе запустить и отдельно в отдельных окнах vs code. Ты на данный момент центральный судья с которого вообще весь проект стартует как гипотеза. Думаю по мере исследований стоит завести в проекте отдельную папку где будет сохранятся какой-то прогресс аля документация, возможно первое форкфлоу стоит отдать приоритетным пунктам MVP а по ходу мне ты можешь выдать промт где я в другом окне стартану другую сессию которая будет в эти же доки параллельно контрибьютить или последовательно можем передать эти дела, в общем как тебе удобно чтоб не забивать контекст так как он у тебя ограничен. Но в целом у нас тут стартует для начала такая MVP-сессия прицел в подобное приложение и перспективы его продажи на рынки ru/en переводчиков, копирайтеров и редакторов. \ No newline at end of file +Мысли получились довольно сумбурные, плюс я накидывал по мере вдохновения, возможно я где-то мог ошибиться, можешь меня поправлять. В целом я тебя нигде и ни в чем не ограничиваю, полная творческая свобода с учетом задачи, выслушаю предложения, гипотезы, твои сомнения и критику, можешь сам дополнить перечисленные пункты, перефразировать их, синтезировать и придумать свои, так же я думаю стоит выделать некоторые пункты жирным курсивом и уделить им максимум внимания, потому что какие-то из них будут определять или могут неожиданным образом определить качество таких переводов. Сам промт у меня получился довольно большой и очень много задач, которые возможно будут решаться аж несколькими сессиями воркфлоу, которые я могу в принципе запустить и отдельно в отдельных окнах vs code. Ты на данный момент центральный судья с которого вообще весь проект стартует как гипотеза. Думаю по мере исследований стоит завести в проекте отдельную папку где будет сохранятся какой-то прогресс аля документация, возможно первое форкфлоу стоит отдать приоритетным пунктам MVP а по ходу мне ты можешь выдать промт где я в другом окне стартану другую сессию которая будет в эти же доки параллельно контрибьютить или последовательно можем передать эти дела, в общем как тебе удобно чтоб не забивать контекст так как он у тебя ограничен. Но в целом у нас тут стартует для начала такая MVP-сессия прицел в подобное приложение и перспективы его продажи на рынки ru/en переводчиков, копирайтеров и редакторов. + +Идеи которые возникли постфактум V1, 06.07.2025 + +1) что человечество и академическая среда знает об математическом и лингвистическом анализе книг? Например поможет ли нам какой-то без ллмный анализатор книги перевод? Для банка памяти? Что мы тут обсчитать можем, например количество слов, глав, абзацев. Можем посчитать количество повторяемых слов например сколько упоминается раз то или иное имя. Могут ли нам помочь эти данные в переводе (банк памяти)? В валидации перевода когда бэкенд полностью отработал? Не пропустили ли мы какую то главу? И так далее, это всего лишь примеры, если тут можно найти какое-то совершенно другое применения или другие примеры -- то стоит попробовать +2) как лучше всего промтить в модели? При переводе будет залетать наверное в модель сам оригинальный текст, какие-то референсы из банка памяти и так далее. Так вот как лучше всего составить промт чтоб модель не галлюцинировала, все запомнила и ничего не выкинула? Возможно стоит исследовать фронтир промтинга, рекомендации конкретных провайдеров, гайды и находки юзеров. Опять же академические исследования промтинга в большие модели? Для перевода текста? Ну вот например в модель загружают чанк для перевода монолог рассказчика, возможно какие-то диалоги между персонажами, в целом из куска который загружен в модель довольно трудно понять как перевести соблюдая контекст, который есть у читателя (те же голоса персонажей), стоит вот тут как либо определять личность персонажа в банке памяти, вызывать нейросеть с этой метадатой, короче говоря банк памяти -- это просто словарь переведенных слов? или уже нечто большее для качественного перевода при чанковании? +3) как валидировать качество перевода и его художественность? Очевидно нужно как-то понимать влияние технических решений, например того же промтинга или занесения в банк памяти на само качество перевода. Что если какое то техническое решение наоборот ухудшает, а не улучшает качество? +4) что академия знает и что мы от них перетащили в качестве знаний о языках и их стиле письма? Ну привожу пример: часто в китайских новеллах главы пишутся короткими и в особенности абзацы, у европейских языков такой традиции нет, европейские книги пишутся не построчно как китайские иероглифы, а нормальными крупными абзацами и структурироваными диалогами. Что мы тут должны делать и как переводить так чтобы текст становился более читаемым для привычных структур и языковых кострукций других языковых культур? +5) что делать если сам оригинальный текст написан очень слабо с художественной точки зрения и мысли? Стоил ли ее подправлять и справятся ли с этим модели? +6) тест моделей на редактуру и художественный стиль бы уже проведен. Но есть вопрос: сравнивались популярные тексты, что если эти крупные модели уже его и так знали, видели и понимали как переводить? Как разные модели будут переводить и редактировать совершенно им незнакомый текст? Но самое интересное как они переведут какое-нибудь вообще новое выдуманное или составленное слово самим автором? Или соединенное из разных других слов? Может быть взятые из другого языка? Или которое является исковерконным словом другого языка, скажем более древнего? Этот пункт возможно стоит занести в документацию где юзеры жалуются на ИИ перевод. +7) какие филосовские исследования есть на тему ответов модели и промтинга в нее? Это в тему решения проблемы художественной составляющей перевода. Как заставить модель сотворить что-то что подобно человеческой мысли и пониманию. Есть ли тут лингвофилосовские исследования последние? +8) что насчет параметров моделей при запросе? В текущей вариации реализации eval сессия тестировала разные параметры и как они влияют главным образом на художественность перевода? Хватило ли нам тестов? +9) что мы знаем насчет эры до ии перевода и его качества? до этого многие текста переводились обычными алгоритмами, можем ли мы применить оттуда какое-то решение? только за этим нужно внимательно следить, чтобы оно не уронило качество + +Выше дополненые пукнты содержат много примеров. На примерах не надо зацикливаться и это крайне важный поинт всего проекта и затеи. Понятное дело что сложные системы состоят из многих решений, которые закрывают конкретные проблемы и пробелы друг друга. Но речь о том чтобы не зацикливаться на конкретных примерах потому что их вспомнил я, а есть куча других примеров которых я не вспомнил, не понимаю или не вижу еще пачку другую проблем и поэтому не могу привести по ним примеры. Поэтому было бы неплохо если бы ты помог мне в классификации или сам додумался до проблемных мест перевода меж двумя языками. Считаю это приоритетом идей V1. Так же насчет научных исследований -- научные статьи это хорошо, но мы практики, и нам нужны практические решения, которые работают, так что возможно академия для нас может быть вредна, но это надо еще доказать или проверить гипотезы которые они выдвигают, возможно уже в планах строить бэкенд так, чтобы иметь возможность проводить АБ тесты (но это наверное на сильное будущее) + +Идеи V2 не касающиеся самого перевода + +1) что касается бэкенда у нас планируется какая-то функциональность которая предотвращает абъюз моделей? Очевидно что у нас цель переводить книги и текста на другие языки, будет досадно если в книгу кто-то вставит абузивный промт или атаку. Особенно досадно если прямо под самый конец, жечь токены ради абъюза не хочется. Есть ли какой то вариант не тратя токены понять что нас миссюзают (делают что-то заточенное не на перевод, например написать код) или атакуют? Желательно дешевый и крайне точный с минимум false positive. +2) ну и насчет генерации книги, думаю стоит так же предусмотреть вариант остановки всего пайплайна, не знаю предусмотрено это где то в планах по бэкенду. по разным причинам, будь то команда от юзера или сигнал какой-то изнутри самого пайплайна перевода. и как остановка так и кнопка продолжения (разумеется абъзивный промт нельзя продолжить) +3) так же есть ли у нас ограничения по входу? очевидно что загружать 4 тома войны и мир, хотя это не много наверное, в общем тут надо в бэкенде какую то настроечку сделать, может котороая будет считать входные токены для книги + +Идеи V3 пайплайна перевода + +1) как мы можем понять что вышеперечисленные идеи и пункты или приемы в ходе реализации улучшают, а не ухудшают качество перевода? стоит ли что-нибудь пересмотреть или кардинально протестировать чтобы отсеять мусор? docs/research/12-architecture-as-antipattern.md +2) как мы будем самоулучшаться? очевидно что при переводах больших книг количество текстов просто огромно, и разбираться в нем и тратить редакторский ресурс человека дорого, может приводить к ошибкам и так далее +3) из пункта 2 у меня следует крайнее радикальное предложение: так как бэкенд ориентирован в основном на дешевые модели и судью среднего качество, что если мы встроем в часть пайплайна фронтир модель которая очень много знает? вероятным кандидатом мне видится или дорогой гемини или чатгпт, сами модели в переводе учавствовать не будут, но вот возможно проанализировать перевод и просигнализировать нам в лог или отдельный отчет по генерации книги вполне себе могут, из этого отчета можно вытаскивать буллеты и точечно понимать фиксы для пайплайна, тут я думаю остается только маневр для выбора модели и режима ее размышлений (chathpt 5.5?), плюс промт ей нужен качественный который погрузит в основные механизмы, так чтобы она понимала что и откуда идет. поэтому это будет не модель судья, а модель судья над судьей и пайплайном в целом. оцени эту идею, как тебе она? +4) Отдельно стоит отметить распространенные проблемы docs/research/12-common-failures.md ИИ-перевода, нужно придумать какими + +Выводы проекта. Считаю что надо отметить две центральные ранее озвученные не просто идеи к которым мы стремимся, а это считай все ради чего мы затеяли это все. +1) устранить потерю контекста при переводе, с этим нам поможет банк памяти (тут на самом деле вообще не важно что нам поможет в этом), так вот решение вокруг "банка памяти" должно быть крайне точным, так как даже 1 ошибка в переводе текста может быть для читателя фатальной чтоб закрыть перевод перевод книги и сочти решение не зрелым +2) художественность и смыслы, понятное дело что оценить художественность довольно трудно, но неполноценность ИИ-переводов обосновать можно: у ИИ просто напросто нет всего контекста, модели не могут додумать то чего не знаю или попытаться понять, иногда написанное в книге лежит за пределами самой книги и модель не может сложить воедино паззл, так вот помимо валидатора пайплайна который вызывается редко чтоб оценить перевод, возможно стоит так же редко вызывать модель на крайне узком специализированном участке перевода который и будет решать 1 раз за книгу эту диллему. но это лишь предложение и примеры, всегда к ним можно критически отнестись или предложить что то другое более эффективное +Возможно две перечисленные основные задачи стоит поставить eval сессии чтоб она точками выдернула механизмы пайплайна и верифицировала их и оценила влияние, так же нужно чтоб валидировалось не только положительное но и пагубное влияние каких то решений. + diff --git a/docs/ADAPTIVE_MEMORY_RESEARCH_PROMPT.md b/docs/archive/prompts/ADAPTIVE_MEMORY_RESEARCH_PROMPT.md similarity index 100% rename from docs/ADAPTIVE_MEMORY_RESEARCH_PROMPT.md rename to docs/archive/prompts/ADAPTIVE_MEMORY_RESEARCH_PROMPT.md diff --git a/docs/prompts/done/BACKEND_SESSION_PROMPT.md b/docs/archive/prompts/BACKEND_SESSION_PROMPT.md similarity index 100% rename from docs/prompts/done/BACKEND_SESSION_PROMPT.md rename to docs/archive/prompts/BACKEND_SESSION_PROMPT.md diff --git a/docs/prompts/done/BACKEND_SESSION_PROMPT_CHUNKER.md b/docs/archive/prompts/BACKEND_SESSION_PROMPT_CHUNKER.md similarity index 100% rename from docs/prompts/done/BACKEND_SESSION_PROMPT_CHUNKER.md rename to docs/archive/prompts/BACKEND_SESSION_PROMPT_CHUNKER.md diff --git a/docs/BACKEND_SESSION_PROMPT_CONSOLIDATION.md b/docs/archive/prompts/BACKEND_SESSION_PROMPT_CONSOLIDATION.md similarity index 100% rename from docs/BACKEND_SESSION_PROMPT_CONSOLIDATION.md rename to docs/archive/prompts/BACKEND_SESSION_PROMPT_CONSOLIDATION.md diff --git a/docs/prompts/done/BACKEND_SESSION_PROMPT_MEMORY.md b/docs/archive/prompts/BACKEND_SESSION_PROMPT_MEMORY.md similarity index 100% rename from docs/prompts/done/BACKEND_SESSION_PROMPT_MEMORY.md rename to docs/archive/prompts/BACKEND_SESSION_PROMPT_MEMORY.md diff --git a/docs/prompts/done/BACKEND_SESSION_PROMPT_SILENT_REFUSALS.md b/docs/archive/prompts/BACKEND_SESSION_PROMPT_SILENT_REFUSALS.md similarity index 100% rename from docs/prompts/done/BACKEND_SESSION_PROMPT_SILENT_REFUSALS.md rename to docs/archive/prompts/BACKEND_SESSION_PROMPT_SILENT_REFUSALS.md diff --git a/docs/prompts/done/MEMORY_RESEARCH_SESSION_PROMPT.md b/docs/archive/prompts/MEMORY_RESEARCH_SESSION_PROMPT.md similarity index 100% rename from docs/prompts/done/MEMORY_RESEARCH_SESSION_PROMPT.md rename to docs/archive/prompts/MEMORY_RESEARCH_SESSION_PROMPT.md diff --git a/docs/prompts/done/PARALLEL_SESSION_PROMPT.md b/docs/archive/prompts/PARALLEL_SESSION_PROMPT.md similarity index 100% rename from docs/prompts/done/PARALLEL_SESSION_PROMPT.md rename to docs/archive/prompts/PARALLEL_SESSION_PROMPT.md diff --git a/docs/POLYGON_SESSION_PROMPT_CONSOLIDATION.md b/docs/archive/prompts/POLYGON_SESSION_PROMPT_CONSOLIDATION.md similarity index 100% rename from docs/POLYGON_SESSION_PROMPT_CONSOLIDATION.md rename to docs/archive/prompts/POLYGON_SESSION_PROMPT_CONSOLIDATION.md diff --git a/docs/POLYGON_SESSION_PROMPT_PHASE2.md b/docs/archive/prompts/POLYGON_SESSION_PROMPT_PHASE2.md similarity index 100% rename from docs/POLYGON_SESSION_PROMPT_PHASE2.md rename to docs/archive/prompts/POLYGON_SESSION_PROMPT_PHASE2.md diff --git a/docs/STRATEGIC_REVIEW_SESSION_PROMPT.md b/docs/archive/prompts/STRATEGIC_REVIEW_SESSION_PROMPT.md similarity index 100% rename from docs/STRATEGIC_REVIEW_SESSION_PROMPT.md rename to docs/archive/prompts/STRATEGIC_REVIEW_SESSION_PROMPT.md diff --git a/docs/research/12-architecture-as-antipattern.md b/docs/research/12-architecture-as-antipattern.md new file mode 100644 index 0000000..d4e4ebb --- /dev/null +++ b/docs/research/12-architecture-as-antipattern.md @@ -0,0 +1,1077 @@ +# 12-architecture-as-antipattern. Как пайплайн усиливает ошибки модели (внешний материал) + +> ⚠ **ПРОВЕНАНС НЕ ЗАФИКСИРОВАН (шапка добавлена оркестратором 09.07.2026).** Текст ниже — вставленный ответ внешней LLM, полученный владельцем (модель/промпт/дан ли контекст проекта — не записано; **владельцу: уточнить** — если модель видела контекст проекта, «конвергенция» с нашими решениями частично циркулярна и не считается независимым подтверждением). Верификационный статус (`../architecture/07-strategic-review.md` §4.1): большинство тезисов конвергентно уже принятым решениям (hard gates ≈ детерминированные гейты, versioned store ≈ glossary_revisions, uncertainty ≈ disposition, спойлер-окна ≈ since/until, ре-валидация ≈ post-check финала); центральный тезис §1–2 (monolingual polish теряет accuracy) **независимо подтверждён по первоисточнику arXiv:2605.13368** → пилот-арм D13.1; непроцитированные числа («85,7→76–78» и пр.) — НЕ факты до верификации. Реальные точки напряжения: моно-редактор D1 (→D17), rewrite-vs-patch (решает пилот C0–C3), self-preference Gemini-апекс/судья (→second-opinion судья, план Ф2). + +Да. Тут есть отдельный класс проблем: **backend не просто наследует ошибки модели, а усиливает их архитектурой pipeline’а**. + +Коммерческие сервисы редко раскрывают внутреннюю реализацию, поэтому ниже не аудит конкретного продукта, а разбор типичных архитектур: + +```text +parser + → chunker + → translator LLM + → book summary / glossary / character bible + → critic agents + → editor LLM + → global consistency pass + → formatter +``` + +Главная ошибка таких систем: + +> LLM используется не как генератор кандидатов и детектор гипотез, а как надёжный редактор, валидатор, база знаний и арбитр одновременно. + +В результате одна вероятностная модель генерирует текст, сама оценивает его, сама исправляет и сама сообщает, что всё стало лучше. + +# 1. «Редактор» на самом деле не исправляет ошибки + +Типичный prompt: + +```text +Improve this translation. +Make it more natural, accurate and literary. +Preserve the author's style. +``` + +Backend ожидает, что модель: + +1. найдёт ошибку; +2. поймёт её причину; +3. изменит только неправильный фрагмент; +4. сохранит всё остальное. + +На деле модель часто выполняет другую операцию: + +> генерирует новую версию текста, которая сильнее похожа на предпочитаемый ею тип прозы. + +Систематическое исследование литературного document-level refinement показало, что улучшения идут преимущественно по fluency, style и terminology, а улучшения смысловой точности заметно слабее и нестабильнее. Авторы описывают поведение модели как **projection toward the refiner’s distribution**, а не как локальный locate-and-fix. + +То есть редактор думает не так: + +```text +В предложении 14 потеряно отрицание. +Заменить span [41:58]. +``` + +А скорее так: + +```text +Как бы я написал весь этот абзац более естественно? +``` + +## Конкретные последствия + +* Исправляется предложение, которое уже было правильным. +* Меняется синтаксис соседних предложений. +* Удаляются намеренные повторы. +* Реплика персонажа становится «красивее». +* Добавляются связки и пояснения. +* Снижается буквальная точность. +* Меняется эмоциональная интенсивность. +* Изменения невозможно однозначно привязать к найденной ошибке. + +Особенно опасен **monolingual polish**, когда редактору показывают только перевод без оригинала. В опубликованных результатах такие проходы регулярно улучшали fluency, одновременно снижая accuracy; в некоторых конфигурациях падение точности после нескольких проходов достигало нескольких и даже более десяти пунктов по использованной метрике. + +## Как должен выглядеть нормальный редактор + +Не: + +```json +{ + "revised_translation": "полностью переписанный абзац" +} +``` + +А: + +```json +{ + "issues": [ + { + "source_span_id": "chapter_04.p_117.s_3", + "target_span": "Он, кажется, удивился", + "type": "lost_negation", + "severity": "critical", + "evidence": "Source contains 'did not seem surprised'", + "proposed_replacement": "Он, похоже, не удивился", + "confidence": 0.97 + } + ] +} +``` + +И только после этого отдельный patcher применяет минимальное изменение. + +# 2. Повторная редактура создаёт drift + +Backend часто делает несколько проходов: + +```text +translation +→ accuracy editor +→ literary editor +→ dialogue editor +→ style editor +→ final polish +``` + +Каждый проход выглядит разумно отдельно. Но каждый агент получает право полностью перегенерировать текст. + +Получается **итеративный drift**: + +```text +оригинал + ↓ +перевод + ↓ немного ближе к стилю редактора №1 + ↓ ещё ближе к стилю редактора №2 + ↓ нормализовано редактором диалогов + ↓ отполировано финальным редактором +``` + +В итоге пятый вариант может быть очень гладким, но уже заметно дальше от оригинала, чем первый. + +Исследование refinement также обнаружило два ограничения: + +* **ceiling effect** — итоговое качество ограничено способностями редактора; +* **anchor effect** — редактор остаётся привязан к исходному переводу и не всегда способен обнаружить его скрытую смысловую ошибку. + +Там же сильный перевод, переданный слабому редактору, заметно деградировал: оценка снижалась примерно с 85,7 до диапазона около 76–78. Обратная комбинация — слабый перевод и сильный редактор — давала большой рост. Это означает, что добавление ещё одного агента само по себе ничего не гарантирует: **слабый refiner способен испортить сильного translator’а**. + +## Архитектурный анти-паттерн + +```text +for editor in editors: + text = editor.rewrite(text) +``` + +## Более безопасная схема + +```text +candidate = translation + +issues = detect(candidate, source) +verified_issues = independently_verify(issues, source) + +for issue in verified_issues: + candidate = apply_minimal_patch(candidate, issue) + +rerun_invariants(candidate) +``` + +Редактор должен иметь: + +* edit budget; +* список разрешённых типов изменений; +* обязательное доказательство; +* привязку к source span; +* запрет на изменение соседнего текста; +* режим `NO_CHANGE`; +* повторную проверку после patch. + +# 3. Иллюзия, что длинный context означает понимание всей книги + +Backend может отправлять модели: + +```text +Вот вся книга. +Вот текущая глава. +Переведи её с учётом всей книги. +``` + +Формально книга помещается в context window. Но это не значит, что модель действительно использует нужный фрагмент. + +Исследование document-level translation проверяло модели, подменяя правильный контекст случайным или испорченным. Многие LLM оказались подозрительно устойчивы к такой подмене: качество почти не менялось, что указывает на слабое фактическое использование контекста. Особенно это проявлялось при разрешении местоимений. + +Иными словами: + +> Контекст присутствует в prompt, но это не означает, что он участвует в решении. + +## Что происходит внутри backend’а + +В книге на 150 000 слов полезный факт может находиться за 80 000 слов до текущей сцены: + +* настоящее имя персонажа; +* его пол; +* принятый вариант прозвища; +* скрытая родственная связь; +* манера обращения к конкретному собеседнику; +* значение термина, объяснённое один раз; +* факт, что герой намеренно притворяется неграмотным. + +На фоне всей книги этот факт — редкий слабый сигнал. + +Исследователи document-level MT описывают дилемму: + +* положить максимально длинный context и потерять нужную зависимость в шуме; +* дать короткий локальный context и вообще не показать нужный факт. + +Поэтому специальные retrieval-механизмы для дальнего контекста улучшают согласованность относительно простого добавления большого блока текста. ([ACL Anthology][1]) + +## Конкретный симптом + +Book bible содержит: + +```text +Мира — женщина, 32 года, говорит формально. +``` + +Но в конкретной сцене важно другое: + +```text +С Томасом Мира с главы 19 перешла на «ты», +а формальный стиль сохраняет только при свидетелях. +``` + +Глобальная карточка персонажа не содержит relationship state. Модель получает правильный, но недостаточный контекст и переводит сцену неверно. + +# 4. Путаница голосов персонажей + +Это одна из самых недооценённых backend-проблем. + +Обычно система хранит персонажа примерно так: + +```json +{ + "name": "Mira", + "age": 32, + "personality": ["reserved", "sarcastic", "intelligent"], + "speech_style": "formal and concise" +} +``` + +Для сохранения голоса этого почти недостаточно. + +## Голос — не набор прилагательных + +Речь персонажа определяется как минимум: + +* средней длиной реплики; +* длиной синтаксических конструкций; +* частотой обрывов; +* формой отрицаний; +* употреблением вводных слов; +* характерными междометиями; +* уровнем лексики; +* частотой метафор; +* склонностью отвечать вопросом; +* использованием эвфемизмов; +* отношением к мату; +* обращением к каждому конкретному персонажу; +* изменением речи под стрессом; +* изменением речи при лжи; +* публичной и приватной манерой речи. + +`formal and concise` не кодирует ничего из этого. + +Исследования персонализированного перевода показывают, что LLM всё ещё трудно воспроизводить стиль, когда он задан не явными правилами, а примерами текста конкретного автора или переводчика. Даже при наличии нескольких примеров style imitation остаётся отдельной нерешённой задачей. + +## Как backend смешивает голоса + +### Шаг 1. Translator нормализует + +У персонажей разные исходные голоса: + +```text +A: You don't know that. +B: Ah, but therein lies the problem, my dear fellow. +C: Dunno. Wasn't there. +``` + +Переводчик выдаёт: + +```text +A: Ты этого не знаешь. +B: Но именно в этом и заключается проблема, мой дорогой друг. +C: Не знаю. Меня там не было. +``` + +У C уже исчезла просторечность. + +### Шаг 2. Dialogue editor «делает естественнее» + +```text +A: Откуда тебе знать? +B: Но, мой дорогой друг, именно в этом и заключается проблема. +C: Откуда мне знать? Меня там не было. +``` + +Теперь A и C используют одинаковую конструкцию. + +### Шаг 3. Consistency editor видит вариативность + +Он решает, что повторяющиеся идеи должны быть оформлены одинаково, и ещё сильнее унифицирует реплики. + +### Шаг 4. Final polish убирает шероховатости + +Именно шероховатости часто и были голосом персонажа. + +## Что ещё ломает голоса + +* Все главы обрабатываются одним и тем же style prompt. +* Один editor переписывает реплики всех персонажей. +* Характер задаётся описанием, а не реальными speech exemplars. +* Dialogue agent видит только одну сцену. +* Нет данных, кому адресована реплика. +* Нет временного состояния отношений. +* Нет информации, говорит герой искренне или играет роль. +* Прямая речь извлекается без авторских ремарок. +* При chunking реплика отделяется от имени говорящего. +* Не различаются narrator voice и character voice. +* Проверяется «одинаковость» речи персонажа, но не её уместная изменчивость. + +Для языков с развитой системой вежливости проблема становится ещё сложнее: выбор окончания, обращения или honorific зависит от статуса, близости, ситуации и конкретного собеседника. Это выделяется как отдельный критерий литературного перевода, поскольку неправильный register напрямую искажает отношения персонажей. ([arXiv][2]) + +# 5. Global style guide уничтожает локальные стили + +Backend часто генерирует один документ: + +```text +Translation style: +- elegant literary Russian +- natural dialogue +- avoid repetitions +- prefer concise sentences +- maintain emotional intensity +``` + +После этого guide применяется ко всей книге. + +Проблема в том, что книга может намеренно содержать: + +* сухие главы одного рассказчика; +* витиеватые главы другого; +* письма; +* детскую речь; +* дневниковые записи; +* протоколы; +* сны; +* ненадёжное повествование; +* главы, написанные под разных авторов. + +Один global style prompt превращает всё это в один регистр. + +Особенно опасные инструкции: + +```text +avoid repetition +improve readability +make dialogue natural +maintain consistent style +remove awkward phrasing +``` + +В художественном тексте: + +* повтор может быть мотивом; +* неудобочитаемость может передавать психическое состояние; +* неестественная реплика может быть характеристикой героя; +* inconsistency может быть намеренным переключением регистра; +* awkward phrasing может быть авторским приёмом. + +Сравнение человеческих и LLM-переводов показывает, что машинные варианты склонны быть более буквальными и менее разнообразными. Автоматические метрики при этом плохо отличают профессиональный перевод от гладкого машинного текста. + +Отдельный препринт 2026 года также обнаружил model-specific emotional fingerprints: разные LLM систематически сдвигали эмоциональный профиль перевода, что ограничивало сохранение авторского голоса. Это пока не окончательное доказательство для всех моделей и языков, но хорошо иллюстрирует проблему: модель приносит в текст собственный устойчивый эмоциональный стиль. ([arXiv][3]) + +# 6. Book bible может отравить всю книгу + +Современный backend часто сначала просит LLM извлечь: + +```text +characters +relationships +timeline +terms +locations +style rules +``` + +Это кажется хорошей архитектурой. Но результат анализа обычно принимается как истина. + +## Poisoned memory + +Допустим, аналитик ошибочно записал: + +```json +{ + "entity": "Ash", + "type": "male character" +} +``` + +Хотя Ash: + +* женщина; +* организация; +* бесполое существо; +* фамилия; +* намеренно неопределённый персонаж. + +Теперь эта ошибка попадает: + +* в translator prompt; +* в pronoun resolver; +* в glossary; +* в consistency checker; +* в редактора; +* в финальный validator. + +Каждый следующий агент видит не исходную неопределённость, а уверенную структурированную запись. + +Это создаёт **error amplification through shared state**. + +## Почему несколько агентов не спасают + +Все агенты получают одну и ту же ложную память: + +```text +Translator: Ash is male. +Editor: Ash is male. +Validator: Ash is male. +``` + +Три агента «согласны», но их согласие не независимо. + +Правильная память должна хранить не только значение, но и происхождение: + +```json +{ + "entity": "Ash", + "gender": { + "value": "unknown", + "evidence": [ + "chapter_01.p_14", + "chapter_07.p_91" + ], + "first_explicit_resolution": null, + "confidence": 0.42 + } +} +``` + +Для любого inferred fact нужны: + +* evidence spans; +* уровень уверенности; +* область действия; +* момент книги, с которого факт известен читателю; +* distinction между авторским фактом и догадкой модели. + +Последний пункт особенно важен. Backend не должен давать переводчику спойлер из главы 40, если в главе 3 автор намеренно сохраняет неопределённость. + +# 7. Summary memory теряет самое важное + +Чтобы не класть всю книгу в prompt, backend создаёт summary: + +```text +Chapter 12: +Mira confronts Tomas and learns he lied. +Their relationship deteriorates. +``` + +Но для перевода могут быть важны детали: + +* она узнала не точно, а лишь заподозрила; +* она притворилась, что поверила; +* он не соврал напрямую, а уклонился; +* внешне отношения не изменились; +* она после этого продолжает обращаться к нему формально; +* читатель пока не знает, что она всё поняла. + +Summary оптимизируется под передачу событий, а не под переводческие зависимости. + +## Потерянные классы информации + +* epistemic state: кто что знает; +* reader state: что известно читателю; +* deception state: кто кому врёт; +* relationship state; +* register state; +* narrative distance; +* unresolved ambiguity; +* recurring imagery; +* синтаксические паттерны; +* speech habits; +* скрытые параллели между сценами. + +Поэтому «summary всей книги» не является полноценной памятью для литературного перевода. + +# 8. RAG достаёт похожий, но неправильный контекст + +Наивный retrieval делает embedding search: + +```text +current scene → top-k semantically similar passages +``` + +Для технического текста это часто приемлемо. Для романа — не всегда. + +## Пример + +Текущая реплика: + +```text +You came back. +``` + +Retrieval может найти: + +* другую сцену возвращения; +* реплику другого персонажа; +* флешбэк; +* сон; +* символическое употребление; +* позднейшую сцену после изменения отношений. + +Семантически фрагменты похожи, но переводческое решение зависит от: + +* говорящего; +* адресата; +* времени; +* отношения персонажей; +* реальности сцены; +* narrative layer. + +Поэтому retrieval должен фильтроваться не только по embedding similarity, но и по: + +```text +speaker +addressee +timeline +scene type +POV +entity IDs +relationship state +term family +narrative layer +``` + +Работы по self-retrieval для document-level MT исходят именно из того, что дальние зависимости редки и распределены по документу, а простой большой context не умеет надёжно выделять релевантные участки. ([ACL Anthology][1]) + +# 9. Параллельная обработка глав создаёт race conditions + +Для скорости backend может переводить 30 глав одновременно. + +```text +chapter 1 ─┐ +chapter 2 ─┼─ parallel +chapter 3 ─┤ +... +chapter 30 ┘ +``` + +В этот момент у системы ещё нет устойчивых решений по: + +* именам; +* прозвищам; +* обращениям; +* терминам; +* названиям организаций; +* речи героев. + +Глава 2 выбирает: + +```text +Order of Ash → Орден Пепла +``` + +Глава 17: + +```text +Order of Ash → Пепельный орден +``` + +Глава 25: + +```text +Order of Ash → Орден Эша +``` + +Потом global consistency editor выбирает один вариант. Но он может выбрать: + +* наиболее частый; +* наиболее естественный; +* вариант из первой главы; +* вариант, предпочитаемый самой моделью. + +Ни один из этих критериев не гарантирует правильность с учётом будущего раскрытия термина. + +## Правильнее + +Некоторые решения должны быть синхронными: + +```text +analyze +→ identify unstable terms +→ translate representative occurrences +→ commit terminology decisions +→ translate dependent chapters +``` + +Либо нужен versioned decision store: + +```json +{ + "term_id": "order_of_ash", + "version": 4, + "target": "Орден Пепла", + "effective_from": "chapter_01", + "evidence": [...], + "locked": true +} +``` + +И при изменении решения backend обязан инвалидировать зависимые главы. + +# 10. Несколько агентов создают ложную независимость + +Часто marketing-схема выглядит так: + +```text +Translator agent +Critic agent +Style agent +Consistency agent +Chief editor +``` + +Но все пять ролей могут быть: + +* одной моделью; +* моделями одного семейства; +* с почти одинаковыми system prompts; +* с одинаковой book bible; +* с одним и тем же исходным ошибочным переводом. + +Назначение разных ролей не превращает их в независимых экспертов. + +Исследования self-refinement выявили self-bias: модели склонны предпочитать собственные генерации, а повторная самооценка способна усиливать эту предвзятость. При этом fluency может улучшаться, хотя целевая ошибка остаётся или появляется ложное исправление. + +Отдельная работа по correlated errors показывает, что ошибки LLM существенно коррелируют; модели одного поставщика или архитектурного семейства ошибаются особенно похоже. В исследованных задачах пары моделей, когда обе ошибались, в среднем выбирали одинаковый неправильный ответ примерно в 60% случаев. Это не литературный benchmark, поэтому число нельзя напрямую переносить на перевод, но механизм важен для multi-agent backend’ов: **несколько моделей не равны нескольким независимым свидетельствам**. ([arXiv][4]) + +## Плохой consensus + +```text +3 из 4 агентов считают перевод правильным. +``` + +Это ничего не доказывает, если: + +* все получили одну ложную summary; +* все принадлежат одной model family; +* все предпочитают гладкий текст; +* все не заметили одно отрицание; +* все используют одинаковый rubric. + +# 11. Агенты теряют информацию между этапами + +Multi-agent backend должен передавать между ролями: + +* текст; +* source alignment; +* обнаруженные ошибки; +* доказательства; +* ограничения; +* unresolved questions; +* version state. + +Но часто передаётся только свободный текст: + +```text +The translation is mostly good, but dialogue should be more natural +and terminology should be more consistent. +``` + +Editor должен сам восстановить, о каких местах речь. + +Исследование failure modes multi-agent systems выделяет отдельные классы: + +* context loss; +* игнорирование входа другого агента; +* неверные предположения; +* task derailment; +* withholding critical information; +* mismatch между reasoning и выполненным действием. + +Авторы подчёркивают, что многие сбои возникают из-за architecture, prompt specification и state management, а не только из-за слабости базовой модели. ([arXiv][5]) + +## В переводческом backend это выглядит так + +Critic: + +```text +The character's tone is too formal in several places. +``` + +Editor: + +* не знает, в каких местах; +* не знает, какой персонаж; +* не знает, с кем он разговаривает; +* не знает, какой register ожидался; +* переписывает все реплики менее формально. + +Нужен structured issue protocol, а не литературное эссе от critic agent. + +# 12. Coordinator усредняет несопоставимые оценки + +Некоторые multi-agent evaluators вычисляют общий score: + +```text +overall = + 0.3 * terminology + + 0.3 * narrative + + 0.4 * style +``` + +Проблема: критическая смысловая ошибка может компенсироваться высоким style score. + +```text +accuracy: 0.40 +terminology: 0.95 +style: 0.98 +overall: 0.80 +``` + +Система сообщает: «качество хорошее». + +Но если перепутан убийца и жертва, итоговый текст непригоден независимо от красоты языка. + +Опубликованный MAS-LitEval действительно использует специализированных агентов по терминологии, narrative perspective и стилю, а coordinator объединяет оценки взвешенным средним. Авторы сами указывают ограничения: субъективность style scoring, возможные LLM biases, тестирование лишь на двух произведениях и отсутствие подтверждения экспертной человеческой оценкой. ([arXiv][6]) + +## Правильная агрегация + +Не одно число, а hard gates: + +```text +critical omission → FAIL +wrong participant → FAIL +spoiler introduction → FAIL +lost negation → FAIL +unresolved terminology → REVIEW +style deviation → WARNING +minor fluency issue → PASS_WITH_WARNING +``` + +Некоторые категории нельзя усреднять. + +# 13. LLM-validator проверяет «похожесть на хороший перевод», а не истинность + +Validator получает оригинал и перевод и отвечает: + +```text +The translation is accurate, natural and preserves the tone. +Score: 9/10. +``` + +Почему он может пропустить ошибку: + +* перевод звучит правдоподобно; +* неправильная причинная связь всё равно логична; +* потерянное ограничение маленькое; +* смысловая ошибка находится далеко от проверяемого span; +* validator не знает будущего раскрытия; +* язык перевода для него слабее английского; +* rubric слишком общий; +* ответ оценивается целиком, а не атомарно. + +Исследования multilingual LLM-as-a-judge показывают, что один и тот же judge может давать непоследовательные оценки в разных языках; особенно хуже результаты для low-resource languages. + +Для литературного перевода проблема ещё глубже: стандартные автоматические метрики и даже сложная человеческая MQM-разметка плохо выделяли профессиональные человеческие переводы. В одном исследовании автоматические метрики распознавали превосходство человеческого перевода не более чем примерно в 20% случаев, тогда как более подходящая схема экспертного сравнения давала намного более уверенное предпочтение человеческим версиям. + +# 14. Проверка consistency легко превращается в вредную унификацию + +Consistency checker обычно ищет: + +```text +одинаковый source term → одинаковый target term +один персонаж → одинаковая манера речи +одна сущность → одно название +``` + +Но в художественном тексте вариативность может быть намеренной. + +## Примеры + +Один персонаж называется: + +* официальным именем; +* семейным прозвищем; +* оскорбительным прозвищем; +* титулом; +* кодовым именем. + +Один термин: + +* официально называется одним образом; +* в народе — другим; +* врагами — третьим. + +Один персонаж: + +* с начальником говорит формально; +* с другом сокращённо; +* в панике теряет грамотность; +* публично использует другой акцент. + +Наивный consistency agent увидит рассогласование и исправит его. + +## Нужно различать + +```text +inconsistency +variation +alias +register-dependent form +speaker-dependent form +time-dependent form +deliberate deviation +``` + +Без этого «улучшение согласованности» уничтожает социальную структуру книги. + +# 15. Backend не различает голос автора, рассказчика и героя + +В романе могут одновременно существовать: + +```text +authorial style +narrator style +POV character perception +spoken character dialogue +quoted document style +translator style +``` + +Наивный backend имеет один параметр: + +```json +{ + "style": "dark, poetic, concise" +} +``` + +Он применяет его ко всему. + +В результате: + +* рассказчик начинает говорить как главный герой; +* внутренний монолог становится похож на диалог; +* письма звучат как основной narrative; +* разные POV-главы унифицируются; +* стиль переводчика замещает стиль автора; +* речь второстепенных персонажей получает общую «литературность». + +Правильная модель состояния должна быть иерархической: + +```text +Book + ├─ authorial constraints + ├─ narrator A + │ ├─ POV chapter state + │ └─ narrative distance + ├─ narrator B + ├─ character Mira + │ ├─ public voice + │ ├─ private voice + │ ├─ voice with Tomas + │ └─ stress-state voice + └─ embedded documents +``` + +# 16. Финальный polish инвалидирует все предыдущие проверки + +Типичный pipeline: + +```text +translation +→ validation +→ fixes +→ final literary polish +→ export +``` + +Это логическая ошибка. + +Validator проверил версию `v7`, но публикуется `v8`, которую никто не проверил. + +Final polish может: + +* удалить отрицание; +* переставить субъект; +* изменить обращение; +* объединить предложения; +* вернуть старый термин; +* испортить markup; +* удалить намеренный повтор. + +После **любого генеративного изменения** должны повторно выполняться: + +* alignment check; +* coverage check; +* entity check; +* negation check; +* number/date check; +* terminology check; +* dialogue attribution check; +* source-aware semantic validation. + +# 17. Регенерация вместо patch ломает воспроизводимость + +Модель получает просьбу: + +```text +Исправь только второе предложение. +``` + +Но API возвращает весь абзац. + +Даже при низкой temperature она может изменить: + +* пунктуацию; +* слова-связки; +* порядок частей; +* кавычки; +* соседнюю реплику. + +Backend затем сохраняет весь новый абзац, потому что не умеет надёжно выделить intended patch. + +Это создаёт: + +* новые незамеченные изменения; +* diff noise; +* невозможность нормального code review; +* неповторяемость результата; +* каскад повторных проверок; +* конфликт с translation memory. + +Надёжнее требовать операции: + +```json +{ + "operation": "replace", + "target_block_id": "ch04.p17.s2", + "expected_old_hash": "8f30...", + "old_text": "...", + "new_text": "...", + "reason": "lost negation" +} +``` + +Если hash не совпадает, patch отвергается. + +# 18. Нет настоящего понятия «не уверен» + +LLM обычно вынуждают выбрать перевод: + +```text +Translate the passage. +``` + +Даже если: + +* пол персонажа неизвестен; +* термин двусмыслен; +* reference непонятен; +* рукопись повреждена; +* неизвестно, имя это или обычное слово. + +Модель выдаёт уверенный вариант, который попадает в glossary и становится canon. + +Нормальный backend должен разрешать: + +```json +{ + "status": "ambiguous", + "alternatives": [ + {"text": "...", "interpretation": "..."}, + {"text": "...", "interpretation": "..."} + ], + "resolution_required_by": "chapter_18", + "temporary_strategy": "preserve ambiguity" +} +``` + +То есть uncertainty должна быть объектом системы, а не скрытым внутренним ощущением модели. + +# 19. Самые опасные backend-анти-паттерны + +В порядке практической опасности: + +1. **Полная перегенерация текста каждым редактором.** +2. **Target-only polish без оригинала.** +3. **Один и тот же model family для translation, critique и validation.** +4. **Один global style guide для всех голосов.** +5. **Book bible без evidence и uncertainty.** +6. **Параллельный перевод глав до фиксации терминологии.** +7. **LLM-оценка одним общим score.** +8. **Отсутствие hard gates для критических ошибок.** +9. **Финальный polish после последней валидации.** +10. **Свободный текст между агентами вместо structured issues.** +11. **Семантический RAG без speaker/time/POV filters.** +12. **Проверка consistency как требования полной одинаковости.** +13. **Хранение голоса персонажа тремя прилагательными.** +14. **Отсутствие stable IDs и source-target alignment.** +15. **Невозможность модели ответить `NO_CHANGE` или `AMBIGUOUS`.** + +# Как выглядел бы действительно сильный backend + +```text +1. Parse + └─ immutable source blocks with stable IDs + +2. Analyze + ├─ entity graph with evidence + ├─ timeline + ├─ knowledge states + ├─ relationship states + ├─ terminology candidates + └─ voice exemplars + +3. Translate + ├─ local source context + ├─ retrieved distant evidence + ├─ speaker/addressee state + └─ locked terminology decisions + +4. Detect + ├─ deterministic invariants + ├─ semantic issue agents + └─ voice deviation detectors + +5. Verify + ├─ independent model/provider + ├─ blind to translator rationale + └─ source-span evidence required + +6. Patch + ├─ minimal edits only + ├─ hash-protected spans + └─ no unrelated rewrites + +7. Revalidate + ├─ coverage + ├─ entities + ├─ dialogue attribution + ├─ terminology + ├─ voice + └─ formatting + +8. Publish + └─ exact trace of every modification +``` + +Ключевой принцип: + +> Генеративная модель должна предлагать перевод или конкретный patch. Она не должна сама бесконтрольно переписывать собственный результат, сама выставлять ему итоговую оценку и сама объявлять работу завершённой. + +И именно здесь, на мой взгляд, сейчас находится наиболее интересная коммерческая ниша: не ещё один «пятиагентный переводчик», а **translation backend с нормальной инженерией состояния, доказуемыми изменениями, character-state tracking и source-grounded validation**. + +Можно поставить ежемесячный мониторинг новых исследований именно по book-level translation pipelines, refinement drift, character voice и LLM-validation. + +[1]: https://aclanthology.org/anthology-files/pdf/wmt.real/2025.wmt-1.104.pdf "Self-Retrieval from Distant Contexts for Document-Level Machine Translation" +[2]: https://arxiv.org/html/2412.01340v1 "A 2-step Framework for Automated Literary Translation Evaluation: Its Promises and Pitfalls" +[3]: https://arxiv.org/abs/2606.10113 "Emotion Profiling in LLM-Based Literary Translation: Systematic Shifts Across MT and Post-Editing" +[4]: https://arxiv.org/html/2506.07962v1 "Correlated Errors in Large Language Models" +[5]: https://arxiv.org/pdf/2503.13657 "Why Do Multi-Agent LLM Systems Fail?" +[6]: https://arxiv.org/html/2506.14199v1 "MAS-LitEval : Multi-Agent System for Literary Translation Quality Assessment" diff --git a/docs/research/12-common-failures.md b/docs/research/12-common-failures.md new file mode 100644 index 0000000..27fa5ba --- /dev/null +++ b/docs/research/12-common-failures.md @@ -0,0 +1,393 @@ +# 12-common-failures. Классы ошибок автоматического перевода больших текстов (внешний материал) + +> ⚠ **ПРОВЕНАНС НЕ ЗАФИКСИРОВАН (шапка добавлена оркестратором 09.07.2026).** Текст ниже — вставленный ответ внешней LLM, полученный владельцем (модель/промпт/дан ли контекст проекта — не записано; **владельцу: уточнить**). Ноль ссылок на источники — числа и категоричные формулировки НЕ абсорбировать как факты без верификации. Разбор против нашей карты отказов — `../architecture/07-strategic-review.md` §4.1: ~85% дублирует заземлённые каталоги `12-failure-modes-*`; уникально ценное: §16 «особо опасные для публикации» (готовый чек-лист golden-кейсов регрессионного сьюта — принят в план Ф2) и §13 (структурные потери EPUB: сноски/стихи/ссылки). + +Ниже именно **конкретные классы ошибок**, которые возникают при полностью автоматическом переводе больших художественных текстов. + +## 1. Потеря смысла + +* **Пропуск фразы или части предложения.** + Модель может не перевести короткое уточнение, отрицание, вводную конструкцию или реплику внутри длинного абзаца. + +* **Потеря отрицания.** + `He did not seem surprised` превращается в «Он, кажется, удивился». + +* **Ослабление или усиление утверждения.** + `might`, `perhaps`, `almost`, `barely`, `apparently` переводятся как уверенные факты. + +* **Подмена причинно-следственной связи.** + «Он ушёл, потому что испугался» может превратиться в «Он испугался после того, как ушёл». + +* **Неверное разрешение местоимений.** + Модель неправильно определяет, к кому относятся `he`, `she`, `it`, `they`, особенно если в сцене несколько персонажей. + +* **Перепутанный субъект действия.** + В оригинале ударил Иван, а в переводе — Пётр. + +* **Перепутанная последовательность действий.** + Особенно часто в сценах боя, погони, секса, сложной хореографии или флешбэках. + +* **Потеря двойного смысла.** + Модель выбирает одно толкование там, где автор намеренно оставляет двусмысленность. + +* **«Исправление» сюжетной нелогичности.** + Если автор намеренно вводит читателя в заблуждение, модель может сделать текст более логичным и тем самым раньше времени раскрыть интригу. + +## 2. Несогласованность на дистанции книги + +* **Имя переводится по-разному в разных главах.** + Например: Джон Сноу / Джон Сно / Иоанн Сноу. + +* **Меняется транслитерация.** + `Xia` становится то «Ся», то «Сиа», то «Ксиа». + +* **Плавают титулы и обращения.** + Один персонаж называется «господин», «сэр», «мастер», «учитель» без сюжетной причины. + +* **Меняется род персонажа.** + Особенно в языках, где пол долго не указан явно. + +* **Персонажи внезапно переходят с «ты» на «вы» и обратно.** + +* **Термины мира переводятся по-разному.** + Название заклинания, организации или артефакта в каждой главе получает новый вариант. + +* **Забывается ранее принятое решение.** + В первой главе прозвище оставили без перевода, в пятой начали переводить. + +* **Нарушается терминология серии.** + В новом томе используются названия, несовместимые с предыдущими переводами. + +* **Путаются родственные связи.** + Дядя становится братом, сводная сестра — двоюродной. + +* **Путается хронология.** + «Три года назад» в одной главе и «два года назад» в другой, хотя в оригинале значение одинаковое. + +## 3. Потеря голосов персонажей + +* **Все персонажи начинают говорить одинаково.** + Старик, ребёнок, солдат и аристократ получают один нейтрально-литературный голос. + +* **Исчезают речевые дефекты.** + Заикание, просторечие, ошибки, обрывки фраз и неправильная грамматика «исправляются». + +* **Стираются социальные различия.** + Бедный рабочий и университетский профессор используют одинаковую лексику. + +* **Пропадает индивидуальная манера речи.** + Один персонаж всегда говорит коротко, другой многословно — перевод это усредняет. + +* **Меняется степень грубости.** + Резкая реплика становится вежливой или, наоборот, нейтральная — агрессивной. + +* **Неправильно передаётся субтекст.** + Сарказм переводится как искреннее утверждение. + +* **Ирония объясняется напрямую.** + Там, где читатель должен догадаться, перевод делает смысл явным. + +## 4. «Сглаживание» авторского стиля + +* **Сложный текст становится проще.** + +* **Короткие рубленые фразы объединяются в нормальные предложения.** + +* **Длинные тяжёлые предложения разбиваются и становятся удобнее для чтения.** + +* **Намеренные повторы удаляются как стилистическая ошибка.** + +* **Необычный порядок слов нормализуется.** + +* **Грубый или неуклюжий авторский стиль становится красивым.** + +* **Исчезает ритм прозы.** + +* **Метафоры заменяются более очевидными.** + +* **Редкие слова заменяются распространёнными.** + +* **Слишком часто добавляются стандартные связки:** + «тем временем», «однако», «внезапно», «поэтому», которых не было в оригинале. + +Итог — текст звучит гладко, но **не как конкретный автор**, а как качественная усреднённая LLM-проза. + +## 5. Галлюцинации + +* **Добавляется объяснение, отсутствующее в оригинале.** + +* **Модель вставляет эмоцию:** + «сердито сказал он», хотя в оригинале только `he said`. + +* **Добавляется причина действия.** + +* **Добавляется субъект, которого автор намеренно не назвал.** + +* **Восстанавливается якобы пропущенная информация.** + +* **Неизвестная реалия заменяется выдуманной.** + +* **Непонятная фраза переводится правдоподобно, но фактически неверно.** + +Особенно опасно, что такие ошибки обычно **грамматически идеальны** и не выглядят подозрительно. + +## 6. Диалоги + +* **Теряется информация о том, кто говорит.** + +* **Неправильно расставляется прямая речь.** + +* **Реплики двух персонажей объединяются.** + +* **Одна реплика разбивается на две.** + +* **Меняются тире, кавычки и абзацы так, что нарушается структура сцены.** + +* **Внутренняя речь превращается в произнесённую вслух.** + +* **Авторская ремарка включается в реплику.** + +* **Прерывание речи переводится как законченное предложение.** + +* **Многоточие, паузы и недоговорённость исчезают.** + +## 7. Юмор, каламбуры и культурные отсылки + +* **Каламбур переводится буквально и перестаёт быть шуткой.** + +* **Шутка сохраняется по смыслу, но не работает на целевом языке.** + +* **Модель придумывает новую шутку, которая меняет характеристику персонажа.** + +* **Теряется отсылка к фильму, книге, песне или политическому событию.** + +* **Отсылка ошибочно воспринимается как обычная фраза.** + +* **Локальная реалия заменяется неподходящим аналогом.** + +* **Слишком агрессивная локализация.** + Американский школьный контекст вдруг становится российским. + +* **Недостаточная локализация.** + Формально правильная фраза остаётся непонятной читателю другого языка. + +* **Идиома переводится дословно.** + +* **Придумывается несуществующая идиома целевого языка.** + +## 8. Диалекты и нестандартная речь + +* **Диалект полностью исчезает.** + +* **Диалект заменяется случайным просторечием.** + +* **Региональный говор передаётся как речь малообразованного человека, хотя это не одно и то же.** + +* **Историческая речь становится современной.** + +* **Архаическая речь превращается в карикатурное «сударь, извольте».** + +* **Сленг быстро устаревает или не соответствует возрасту героя.** + +* **Подросток разговаривает как сорокалетний переводчик.** + +* **Неудачная передача акцента выглядит оскорбительно или комично.** + +## 9. Мир, лор и терминология + +* **Говорящее имя переводится без понимания будущего сюжетного значения.** + +* **Название переводится, хотя позднее выясняется, что это имя собственное.** + +* **Имя собственное оставляется без перевода, хотя оно является важной метафорой.** + +* **Модель не замечает систему образования терминов.** + Например, все названия орденов образованы по одному шаблону, а перевод делает их разнородными. + +* **Разрушается связь между родственными словами.** + В оригинале `Dreamer`, `Dreaming`, `Dreamborn` связаны, а в переводе — три несвязанных термина. + +* **Не учитывается информация из будущих глав.** + Термин в начале книги переводится так, что позднее его смысл уже невозможно корректно раскрыть. + +* **Смешиваются официальные и разговорные названия.** + +* **Не сохраняется намеренная неопределённость пола, природы или статуса существа.** + +## 10. Имена, пол и формы обращения + +* **Неверно определяется пол по имени.** + +* **Нейтральное местоимение насильно превращается в мужское или женское.** + +* **Неправильно склоняются иностранные имена.** + +* **Непоследовательно передаются фамилии и отчества.** + +* **Не распознаётся, что два варианта имени относятся к одному человеку.** + +* **Прозвище принимается за отдельного персонажа.** + +* **Титул принимается за имя.** + +* **Фамильярное обращение становится официальным.** + +* **Исчезает социальная дистанция между героями.** + +## 11. Модальность, эмоции и психология + +* **Предположение превращается в факт.** + +* **Внутреннее сомнение превращается в уверенность.** + +* **Раздражение переводится как гнев.** + +* **Страх — как паника.** + +* **Сдержанная симпатия — как любовь.** + +* **Намеренно холодный тон становится эмоциональным.** + +* **Ненадёжный рассказчик начинает звучать объективно.** + +* **Непрямое описание психологии заменяется прямым:** + вместо поведения героя модель пишет, что он «почувствовал тревогу». + +Это способно изменить восприятие персонажа и всей сцены без единой очевидной фактической ошибки. + +## 12. Цензура и смещение регистра + +* **Мат смягчается.** + +* **Сексуальные сцены становятся менее прямыми.** + +* **Жестокость описывается эвфемистически.** + +* **Оскорбления заменяются нейтральными словами.** + +* **Наоборот, нейтральная грубость может стать чрезмерно вульгарной.** + +* **Политически или культурно чувствительные фразы переформулируются.** + +* **Неприятные взгляды персонажа смягчаются так, будто это позиция переводчика.** + +## 13. Технические ошибки больших документов + +* **Пропускаются сноски.** + +* **Сноска прикрепляется не к тому месту.** + +* **Теряется курсив, который обозначал мысли или интонационное ударение.** + +* **Исчезают разделители сцен.** + +* **Смешиваются текст главы и колонтитулы PDF.** + +* **Номера страниц попадают в текст.** + +* **Подписи к иллюстрациям переводятся как часть повествования.** + +* **Таблицы ломаются.** + +* **Стихи внутри романа превращаются в обычный абзац.** + +* **Письма, дневники и документы теряют особое форматирование.** + +* **Не сохраняются внутренние ссылки EPUB.** + +* **Повторно переводится уже переведённый фрагмент.** + +* **Из-за ошибки chunking одна фраза переводится дважды или не переводится вообще.** + +## 14. Проблемы многоэтапной ИИ-редактуры + +* **Второй агент исправляет правильный перевод.** + +* **Каждый проход немного удаляет текст от оригинала.** + +* **Редактор предпочитает более красивый, но менее точный вариант.** + +* **Один агент восстанавливает ошибку, которую другой уже исправил.** + +* **Разные агенты используют несовместимые словари.** + +* **Глобальная редактура ломает локальный контекст.** + +* **Модель заменяет редкое слово только ради разнообразия.** + +* **При повторной генерации исправляется один дефект, но появляются два новых.** + +* **Финальный polish стирает различия голосов персонажей.** + +То есть много проходов не гарантируют качество. Без детерминированных проверок они могут просто увеличить количество изменений. + +## 15. Проблемы автоматической оценки качества + +* **Гладкий неправильный перевод получает высокую оценку.** + +* **Буквальный перевод оценивается выше литературно точного.** + +* **LLM-критик предпочитает стиль, похожий на собственный.** + +* **Оценщик не замечает пропуск маленького, но сюжетно важного слова.** + +* **Проверка отдельного абзаца не видит противоречия с предыдущей главой.** + +* **Модель может уверенно заявить, что ошибки нет.** + +* **Два оценщика могут согласиться между собой и оба ошибиться.** + +* **Автоматическая метрика не измеряет голос, ритм, юмор и авторскую интонацию.** + +* **Нет надёжного единого числа вида «перевод готов на 97%».** + +## 16. Особо опасные ошибки для публикации + +Наиболее критичны не корявые предложения, а следующие случаи: + +* пропущено отрицание; +* перепутан действующий персонаж; +* раскрыт сюжетный секрет; +* изменена мотивация героя; +* потеряна двусмысленность; +* перепутаны родственные связи; +* изменён пол или титул; +* не переведён абзац; +* добавлен факт, которого нет в оригинале; +* нарушена хронология; +* термин переведён несовместимо с финалом книги; +* внутренняя речь стала прямой; +* сарказм стал искренней репликой; +* авторская намеренная ошибка была «исправлена»; +* в серии изменили уже устоявшийся канон. + +## 17. Где ИИ обычно справляется лучше + +Относительно безопасные категории: + +* простое линейное повествование; +* современный нейтральный язык; +* небольшой состав персонажей; +* отсутствие сложной игры слов; +* прикладной нон-фикшн; +* типовая жанровая проза; +* повторяющаяся терминология при наличии словаря; +* книги с простой структурой EPUB/DOCX. + +## 18. Где полностью автоматический перевод особенно рискован + +* поэзия; +* экспериментальная проза; +* сложный юмор; +* постмодернистская литература; +* поток сознания; +* диалекты; +* историческая стилизация; +* книги с ненадёжным рассказчиком; +* детективы с языковыми подсказками; +* произведения с большим количеством вымышленных терминов; +* длинные циклы; +* книги, где важны ритм и синтаксис; +* тексты с большим количеством цитат и аллюзий. + +Главная проблема ИИ-перевода сегодня: **он чаще производит не плохой текст, а хороший текст с незаметно изменённым смыслом**. Именно поэтому поверхностная вычитка носителем языка недостаточна — проверяющему нужен доступ к оригиналу и инструменты сопоставления фрагментов.