1077 lines
45 KiB
Markdown
1077 lines
45 KiB
Markdown
# 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"
|