Claude (backend session) f14eff45dc Commit owner's V1-V3 brief additions and two externally sourced failure-mode notes with provenance headers pending origin confirmation

2026-07-09 16:16:11 +03:00

45 KiB

Raw Blame History

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 ожидает, что модель:

найдёт ошибку;
поймёт её причину;
изменит только неправильный фрагмент;
сохранит всё остальное.

На деле модель часто выполняет другую операцию:

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

Систематическое исследование литературного 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-анти-паттерны

В порядке практической опасности:

Полная перегенерация текста каждым редактором.
Target-only polish без оригинала.
Один и тот же model family для translation, critique и validation.
Один global style guide для всех голосов.
Book bible без evidence и uncertainty.
Параллельный перевод глав до фиксации терминологии.
LLM-оценка одним общим score.
Отсутствие hard gates для критических ошибок.
Финальный polish после последней валидации.
Свободный текст между агентами вместо structured issues.
Семантический RAG без speaker/time/POV filters.
Проверка consistency как требования полной одинаковости.
Хранение голоса персонажа тремя прилагательными.
Отсутствие stable IDs и source-target alignment.
Невозможность модели ответить 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.

45 KiB Raw Blame History Unescape Escape