# 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"