textmachine/docs/research/12-architecture-as-antipattern.md

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’а.

Коммерческие сервисы редко раскрывают внутреннюю реализацию, поэтому ниже не аудит конкретного продукта, а разбор типичных архитектур:

parser
  → chunker
  → translator LLM
  → book summary / glossary / character bible
  → critic agents
  → editor LLM
  → global consistency pass
  → formatter

Главная ошибка таких систем:

LLM используется не как генератор кандидатов и детектор гипотез, а как надёжный редактор, валидатор, база знаний и арбитр одновременно.

В результате одна вероятностная модель генерирует текст, сама оценивает его, сама исправляет и сама сообщает, что всё стало лучше.

1. «Редактор» на самом деле не исправляет ошибки

Типичный prompt:

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.

То есть редактор думает не так:

В предложении 14 потеряно отрицание.
Заменить span [41:58].

А скорее так:

Как бы я написал весь этот абзац более естественно?

Конкретные последствия

• Исправляется предложение, которое уже было правильным.
• Меняется синтаксис соседних предложений.
• Удаляются намеренные повторы.
• Реплика персонажа становится «красивее».
• Добавляются связки и пояснения.
• Снижается буквальная точность.
• Меняется эмоциональная интенсивность.
• Изменения невозможно однозначно привязать к найденной ошибке.

Особенно опасен monolingual polish, когда редактору показывают только перевод без оригинала. В опубликованных результатах такие проходы регулярно улучшали fluency, одновременно снижая accuracy; в некоторых конфигурациях падение точности после нескольких проходов достигало нескольких и даже более десяти пунктов по использованной метрике.

Как должен выглядеть нормальный редактор

Не:

{
  "revised_translation": "полностью переписанный абзац"
}

А:

{
  "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 часто делает несколько проходов:

translation
→ accuracy editor
→ literary editor
→ dialogue editor
→ style editor
→ final polish

Каждый проход выглядит разумно отдельно. Но каждый агент получает право полностью перегенерировать текст.

Получается итеративный drift:

оригинал
  ↓
перевод
  ↓ немного ближе к стилю редактора №1
  ↓ ещё ближе к стилю редактора №2
  ↓ нормализовано редактором диалогов
  ↓ отполировано финальным редактором

В итоге пятый вариант может быть очень гладким, но уже заметно дальше от оригинала, чем первый.

Исследование refinement также обнаружило два ограничения:

• ceiling effect — итоговое качество ограничено способностями редактора;
• anchor effect — редактор остаётся привязан к исходному переводу и не всегда способен обнаружить его скрытую смысловую ошибку.

Там же сильный перевод, переданный слабому редактору, заметно деградировал: оценка снижалась примерно с 85,7 до диапазона около 76–78. Обратная комбинация — слабый перевод и сильный редактор — давала большой рост. Это означает, что добавление ещё одного агента само по себе ничего не гарантирует: слабый refiner способен испортить сильного translator’а.

Архитектурный анти-паттерн

for editor in editors:
    text = editor.rewrite(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 может отправлять модели:

Вот вся книга.
Вот текущая глава.
Переведи её с учётом всей книги.

Формально книга помещается в context window. Но это не значит, что модель действительно использует нужный фрагмент.

Исследование document-level translation проверяло модели, подменяя правильный контекст случайным или испорченным. Многие LLM оказались подозрительно устойчивы к такой подмене: качество почти не менялось, что указывает на слабое фактическое использование контекста. Особенно это проявлялось при разрешении местоимений.

Иными словами:

Контекст присутствует в prompt, но это не означает, что он участвует в решении.

Что происходит внутри backend’а

В книге на 150 000 слов полезный факт может находиться за 80 000 слов до текущей сцены:

• настоящее имя персонажа;
• его пол;
• принятый вариант прозвища;
• скрытая родственная связь;
• манера обращения к конкретному собеседнику;
• значение термина, объяснённое один раз;
• факт, что герой намеренно притворяется неграмотным.

На фоне всей книги этот факт — редкий слабый сигнал.

Исследователи document-level MT описывают дилемму:

• положить максимально длинный context и потерять нужную зависимость в шуме;
• дать короткий локальный context и вообще не показать нужный факт.

Поэтому специальные retrieval-механизмы для дальнего контекста улучшают согласованность относительно простого добавления большого блока текста. (ACL Anthology)

Конкретный симптом

Book bible содержит:

Мира — женщина, 32 года, говорит формально.

Но в конкретной сцене важно другое:

С Томасом Мира с главы 19 перешла на «ты»,
а формальный стиль сохраняет только при свидетелях.

Глобальная карточка персонажа не содержит relationship state. Модель получает правильный, но недостаточный контекст и переводит сцену неверно.

4. Путаница голосов персонажей

Это одна из самых недооценённых backend-проблем.

Обычно система хранит персонажа примерно так:

{
  "name": "Mira",
  "age": 32,
  "personality": ["reserved", "sarcastic", "intelligent"],
  "speech_style": "formal and concise"
}

Для сохранения голоса этого почти недостаточно.

Голос — не набор прилагательных

Речь персонажа определяется как минимум:

• средней длиной реплики;
• длиной синтаксических конструкций;
• частотой обрывов;
• формой отрицаний;
• употреблением вводных слов;
• характерными междометиями;
• уровнем лексики;
• частотой метафор;
• склонностью отвечать вопросом;
• использованием эвфемизмов;
• отношением к мату;
• обращением к каждому конкретному персонажу;
• изменением речи под стрессом;
• изменением речи при лжи;
• публичной и приватной манерой речи.

formal and concise не кодирует ничего из этого.

Исследования персонализированного перевода показывают, что LLM всё ещё трудно воспроизводить стиль, когда он задан не явными правилами, а примерами текста конкретного автора или переводчика. Даже при наличии нескольких примеров style imitation остаётся отдельной нерешённой задачей.

Как backend смешивает голоса

Шаг 1. Translator нормализует

У персонажей разные исходные голоса:

A: You don't know that.
B: Ah, but therein lies the problem, my dear fellow.
C: Dunno. Wasn't there.

Переводчик выдаёт:

A: Ты этого не знаешь.
B: Но именно в этом и заключается проблема, мой дорогой друг.
C: Не знаю. Меня там не было.

У C уже исчезла просторечность.

Шаг 2. Dialogue editor «делает естественнее»

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)

5. Global style guide уничтожает локальные стили

Backend часто генерирует один документ:

Translation style:
- elegant literary Russian
- natural dialogue
- avoid repetitions
- prefer concise sentences
- maintain emotional intensity

После этого guide применяется ко всей книге.

Проблема в том, что книга может намеренно содержать:

• сухие главы одного рассказчика;
• витиеватые главы другого;
• письма;
• детскую речь;
• дневниковые записи;
• протоколы;
• сны;
• ненадёжное повествование;
• главы, написанные под разных авторов.

Один global style prompt превращает всё это в один регистр.

Особенно опасные инструкции:

avoid repetition
improve readability
make dialogue natural
maintain consistent style
remove awkward phrasing

В художественном тексте:

• повтор может быть мотивом;
• неудобочитаемость может передавать психическое состояние;
• неестественная реплика может быть характеристикой героя;
• inconsistency может быть намеренным переключением регистра;
• awkward phrasing может быть авторским приёмом.

Сравнение человеческих и LLM-переводов показывает, что машинные варианты склонны быть более буквальными и менее разнообразными. Автоматические метрики при этом плохо отличают профессиональный перевод от гладкого машинного текста.

Отдельный препринт 2026 года также обнаружил model-specific emotional fingerprints: разные LLM систематически сдвигали эмоциональный профиль перевода, что ограничивало сохранение авторского голоса. Это пока не окончательное доказательство для всех моделей и языков, но хорошо иллюстрирует проблему: модель приносит в текст собственный устойчивый эмоциональный стиль. (arXiv)

6. Book bible может отравить всю книгу

Современный backend часто сначала просит LLM извлечь:

characters
relationships
timeline
terms
locations
style rules

Это кажется хорошей архитектурой. Но результат анализа обычно принимается как истина.

Poisoned memory

Допустим, аналитик ошибочно записал:

{
  "entity": "Ash",
  "type": "male character"
}

Хотя Ash:

• женщина;
• организация;
• бесполое существо;
• фамилия;
• намеренно неопределённый персонаж.

Теперь эта ошибка попадает:

• в translator prompt;
• в pronoun resolver;
• в glossary;
• в consistency checker;
• в редактора;
• в финальный validator.

Каждый следующий агент видит не исходную неопределённость, а уверенную структурированную запись.

Это создаёт error amplification through shared state.

Почему несколько агентов не спасают

Все агенты получают одну и ту же ложную память:

Translator: Ash is male.
Editor: Ash is male.
Validator: Ash is male.

Три агента «согласны», но их согласие не независимо.

Правильная память должна хранить не только значение, но и происхождение:

{
  "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:

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:

current scene → top-k semantically similar passages

Для технического текста это часто приемлемо. Для романа — не всегда.

Пример

Текущая реплика:

You came back.

Retrieval может найти:

• другую сцену возвращения;
• реплику другого персонажа;
• флешбэк;
• сон;
• символическое употребление;
• позднейшую сцену после изменения отношений.

Семантически фрагменты похожи, но переводческое решение зависит от:

• говорящего;
• адресата;
• времени;
• отношения персонажей;
• реальности сцены;
• narrative layer.

Поэтому retrieval должен фильтроваться не только по embedding similarity, но и по:

speaker
addressee
timeline
scene type
POV
entity IDs
relationship state
term family
narrative layer

Работы по self-retrieval для document-level MT исходят именно из того, что дальние зависимости редки и распределены по документу, а простой большой context не умеет надёжно выделять релевантные участки. (ACL Anthology)

9. Параллельная обработка глав создаёт race conditions

Для скорости backend может переводить 30 глав одновременно.

chapter 1 ─┐
chapter 2 ─┼─ parallel
chapter 3 ─┤
...
chapter 30 ┘

В этот момент у системы ещё нет устойчивых решений по:

• именам;
• прозвищам;
• обращениям;
• терминам;
• названиям организаций;
• речи героев.

Глава 2 выбирает:

Order of Ash → Орден Пепла

Глава 17:

Order of Ash → Пепельный орден

Глава 25:

Order of Ash → Орден Эша

Потом global consistency editor выбирает один вариант. Но он может выбрать:

• наиболее частый;
• наиболее естественный;
• вариант из первой главы;
• вариант, предпочитаемый самой моделью.

Ни один из этих критериев не гарантирует правильность с учётом будущего раскрытия термина.

Правильнее

Некоторые решения должны быть синхронными:

analyze
→ identify unstable terms
→ translate representative occurrences
→ commit terminology decisions
→ translate dependent chapters

Либо нужен versioned decision store:

{
  "term_id": "order_of_ash",
  "version": 4,
  "target": "Орден Пепла",
  "effective_from": "chapter_01",
  "evidence": [...],
  "locked": true
}

И при изменении решения backend обязан инвалидировать зависимые главы.

10. Несколько агентов создают ложную независимость

Часто marketing-схема выглядит так:

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)

Плохой consensus

3 из 4 агентов считают перевод правильным.

Это ничего не доказывает, если:

• все получили одну ложную summary;
• все принадлежат одной model family;
• все предпочитают гладкий текст;
• все не заметили одно отрицание;
• все используют одинаковый rubric.

11. Агенты теряют информацию между этапами

Multi-agent backend должен передавать между ролями:

• текст;
• source alignment;
• обнаруженные ошибки;
• доказательства;
• ограничения;
• unresolved questions;
• version state.

Но часто передаётся только свободный текст:

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)

В переводческом backend это выглядит так

Critic:

The character's tone is too formal in several places.

Editor:

• не знает, в каких местах;
• не знает, какой персонаж;
• не знает, с кем он разговаривает;
• не знает, какой register ожидался;
• переписывает все реплики менее формально.

Нужен structured issue protocol, а не литературное эссе от critic agent.

12. Coordinator усредняет несопоставимые оценки

Некоторые multi-agent evaluators вычисляют общий score:

overall =
    0.3 * terminology +
    0.3 * narrative +
    0.4 * style

Проблема: критическая смысловая ошибка может компенсироваться высоким style score.

accuracy:    0.40
terminology: 0.95
style:       0.98
overall:     0.80

Система сообщает: «качество хорошее».

Но если перепутан убийца и жертва, итоговый текст непригоден независимо от красоты языка.

Опубликованный MAS-LitEval действительно использует специализированных агентов по терминологии, narrative perspective и стилю, а coordinator объединяет оценки взвешенным средним. Авторы сами указывают ограничения: субъективность style scoring, возможные LLM biases, тестирование лишь на двух произведениях и отсутствие подтверждения экспертной человеческой оценкой. (arXiv)

Правильная агрегация

Не одно число, а hard gates:

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 получает оригинал и перевод и отвечает:

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 обычно ищет:

одинаковый source term → одинаковый target term
один персонаж → одинаковая манера речи
одна сущность → одно название

Но в художественном тексте вариативность может быть намеренной.

Примеры

Один персонаж называется:

• официальным именем;
• семейным прозвищем;
• оскорбительным прозвищем;
• титулом;
• кодовым именем.

Один термин:

• официально называется одним образом;
• в народе — другим;
• врагами — третьим.

Один персонаж:

• с начальником говорит формально;
• с другом сокращённо;
• в панике теряет грамотность;
• публично использует другой акцент.

Наивный consistency agent увидит рассогласование и исправит его.

Нужно различать

inconsistency
variation
alias
register-dependent form
speaker-dependent form
time-dependent form
deliberate deviation

Без этого «улучшение согласованности» уничтожает социальную структуру книги.

15. Backend не различает голос автора, рассказчика и героя

В романе могут одновременно существовать:

authorial style
narrator style
POV character perception
spoken character dialogue
quoted document style
translator style

Наивный backend имеет один параметр:

{
  "style": "dark, poetic, concise"
}

Он применяет его ко всему.

В результате:

• рассказчик начинает говорить как главный герой;
• внутренний монолог становится похож на диалог;
• письма звучат как основной narrative;
• разные POV-главы унифицируются;
• стиль переводчика замещает стиль автора;
• речь второстепенных персонажей получает общую «литературность».

Правильная модель состояния должна быть иерархической:

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:

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 ломает воспроизводимость

Модель получает просьбу:

Исправь только второе предложение.

Но API возвращает весь абзац.

Даже при низкой temperature она может изменить:

• пунктуацию;
• слова-связки;
• порядок частей;
• кавычки;
• соседнюю реплику.

Backend затем сохраняет весь новый абзац, потому что не умеет надёжно выделить intended patch.

Это создаёт:

• новые незамеченные изменения;
• diff noise;
• невозможность нормального code review;
• неповторяемость результата;
• каскад повторных проверок;
• конфликт с translation memory.

Надёжнее требовать операции:

{
  "operation": "replace",
  "target_block_id": "ch04.p17.s2",
  "expected_old_hash": "8f30...",
  "old_text": "...",
  "new_text": "...",
  "reason": "lost negation"
}

Если hash не совпадает, patch отвергается.

18. Нет настоящего понятия «не уверен»

LLM обычно вынуждают выбрать перевод:

Translate the passage.

Даже если:

• пол персонажа неизвестен;
• термин двусмыслен;
• reference непонятен;
• рукопись повреждена;
• неизвестно, имя это или обычное слово.

Модель выдаёт уверенный вариант, который попадает в glossary и становится canon.

Нормальный backend должен разрешать:

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

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.