Главное за минуту
При попытке перевести датасет синтетических данных с reasoning-трассами модели Gemma 3 и Gemma 4 игнорировали инструкцию на перевод и начинали решать задачи из исходного текста - писать код, доказывать теоремы. Причина - сбой границы между инструкцией и полезной нагрузкой, форма непреднамеренной инъекции промпта. Модель воспринимает фрагменты кода и математические выкладки как команды к исполнению, а не как контент для перевода.
Основные методы борьбы: чанкование (разбиение текста на безопасные фрагменты), защита блоков кода и математических выражений через экранирование или плейсхолдеры, написание парсера для разделения документа на типизированные блоки. Оценка качества усложняется ограничениями метрик вроде COMET-QE по длине контекста - скоры искажаются, требуется взвешивание и выравнивание. Проблема выходит за рамки перевода и затрагивает редактуру, рерайтинг, суммаризацию - любые задачи, где модель-инструкция обрабатывает текст, потенциально содержащий инструкции.
Как мы обнаружили, что нейросеть для перевода решает задачи вместо перевода
Задача формулировалась просто: перевести датасет синтетических данных, содержащий reasoning-трассы - цепочки рассуждений, которые модель генерирует в процессе решения сложных задач. Ожидалось, что Gemma 3 и Gemma 4 выполнят перевод, сохранив структуру и смысл исходного текста. Реальность оказалась неожиданной: вместо перевода модель начинала исполнять то, что было описано в тексте - писала Python-код, доказывала математические теоремы, выстраивала логические цепочки.
Первый признак сбоя проявился на фрагменте, где в исходном тексте шло доказательство теоремы Пифагора с пошаговыми выкладками. Модель проигнорировала системный промпт «переведи следующий текст на русский» и выдала собственное доказательство, дополнив его геометрическими построениями, которых не было в оригинале. Аналогичное поведение повторилось на блоке с кодом сортировки: Gemma 4 не перевела комментарии и названия переменных, а переписала алгоритм с оптимизацией под QuickSort.
Проблема воспроизводилась стабильно на обеих версиях модели, независимо от параметров инференса. Это исключало случайный сбой и указывало на системную уязвимость в обработке инструкций.
Исходные данные: датасет с reasoning-трассами
Reasoning-трассы - это текстовые артефакты, которые современные LLM генерируют при решении задач, требующих многошаговых рассуждений. Они включают три компонента, опасных для моделей-инструкций:
- Императивные конструкции - «вычислим производную», «применим метод подстановки», «рассмотрим случай n=1». Модель-переводчик интерпретирует их как команды, адресованные ей самой.
- Блоки кода - фрагменты на Python, псевдокод, SQL-запросы. Синтаксис языков программирования совпадает с форматом, в котором модель ожидает получить инструкции к действию.
- Формальные доказательства - последовательности логических утверждений с операторами следования. Структура «если A, то B» активирует механизмы логического вывода вместо механизмов перевода.
Когда эти компоненты поступают на вход модели в режиме инструкции, происходит конфликт: системный промпт требует перевода, но содержимое текста требует исполнения. Модель разрешает конфликт в пользу содержимого - и начинает решать задачи. Этот эффект знаком разработчикам, работающим с длинными диалогами: мы разбирали похожий механизм потери контекста на примере Qwen 3.6 27B в связке с Opencode, где модель «забывала» инструкции на длинных диалогах.
Почему это происходит: сбой границы между инструкцией и полезной нагрузкой
Корень проблемы - отсутствие в архитектуре современных LLM жёсткого разделителя между системной инструкцией и пользовательским контентом. Модель обрабатывает всю входную последовательность токенов единообразно, присваивая им веса внимания на основе семантической близости, а не на основе роли в диалоге. Когда в тексте встречается конструкция, семантически близкая к инструкции, модель переключает контекст выполнения.
Этот механизм - прямое следствие обучения на инструктивных датасетах. Модель натренирована реагировать на императивные формулировки действием, а не переводом. В обычном сценарии это корректное поведение: пользователь пишет «напиши функцию сортировки», и модель пишет код. Но когда тот же текст оказывается внутри контента для перевода, модель не может отличить «напиши функцию сортировки» как объект перевода от «напиши функцию сортировки» как команду.
Непреднамеренная инъекция промпта: когда контент становится командой
Классическая инъекция промпта - это намеренная атака, где злоумышленник встраивает инструкцию в пользовательский ввод. Здесь происходит то же самое, но без злого умысла: сам контент датасета содержит паттерны, неотличимые от инструкций.
Пример с Python-кодом внутри текста для перевода:
# Исходный текст для перевода (английский):
# "To solve this, we write a function that takes an array and returns the sorted version:
# def sort_array(arr):
# return sorted(arr)
# This approach has O(n log n) complexity."
# Ожидаемый перевод:
# "Чтобы решить это, мы пишем функцию, которая принимает массив и возвращает отсортированную версию:
# def sort_array(arr):
# return sorted(arr)
# Этот подход имеет сложность O(n log n)."
# Фактический вывод Gemma 4:
# "Вот оптимизированная реализация с использованием Timsort:
# def sort_array(arr):
# arr.sort()
# return arr
# Timsort обеспечивает O(n log n) в худшем случае и O(n) для частично отсортированных данных."Модель не просто перевела комментарий - она восприняла функцию как задание на написание кода и выдала собственную реализацию с анализом алгоритмической сложности. Фрагмент кода выступил как инъекция, переопределившая задачу с «переведи» на «напиши».
С математическими доказательствами механизм аналогичен. Когда модель видит последовательность «Дано: треугольник ABC. Доказать: сумма углов равна 180°», она переходит в режим логического вывода. Структура «Дано - Доказать» совпадает с форматом инструкций из обучающего датасета математических задач, и модель начинает доказывать вместо того, чтобы переводить.
Gemma 3 и Gemma 4 демонстрируют повышенную чувствительность к таким инъекциям по сравнению с некоторыми другими моделями. Это связано с их архитектурной особенностью: модели семейства Gemma имеют сильный индуктивный bias в сторону следования инструкциям, что улучшает показатели на бенчмарках вроде MATH-500 и LiveCodeBench, но делает их уязвимыми к непреднамеренным инъекциям в контенте. Когда мы сравнивали Gemma 3 с Qwen 3.6 в роли агента-кодера, именно эта «исполнительность» Gemma оказалась преимуществом для генерации кода, но здесь она оборачивается проблемой.
Практические методы борьбы: как заставить модель переводить, а не решать
Проблема решается не улучшением промпта, а изменением способа подачи данных. Попытки добавить «НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛНЯЙ КОД, ТОЛЬКО ПЕРЕВОДИ» в системный промпт не дают стабильного результата - модель всё равно срывается на блоках с высокой инструктивной плотностью. Нужны инженерные методы на уровне пайплайна обработки.
Чанкование: делим текст на безопасные части
Принцип чанкования - разрезать исходный документ на фрагменты, каждый из которых модель может обработать без риска инъекции. Ключевой критерий разбиения: в одном чанке не должно быть одновременно системной инструкции и контента, способного её переопределить.
Стратегии разбиения:
- По двойным переводам строки - самый простой метод. Работает для текстов, где код и математика выделены визуально. Недостаток: разрывает связанные рассуждения, если они не разделены пустой строкой.
- По семантическим маркерам - ищем ключевые слова-разделители: «Proof:», «Доказательство:», «def », «import », «\begin{equation}». Разрез выполняется перед маркером, чтобы изолировать потенциально опасный блок.
- По детектору смены модальности - используем небольшую классификационную модель для определения типа каждого абзаца (текст/код/математика) и режем на границах смены типа.
Главный риск чанкования - потеря связности перевода. Если предложение разорвано на границе чанков, модель теряет контекст и может неверно перевести местоимения или термины. Решение: перекрывающиеся чанки с окном в 2-3 предложения и последующая постобработка для удаления дубликатов на стыках.
Защита блоков кода и математических выражений
Метод защиты блоков основан на идее: всё, что может быть воспринято как инструкция, должно быть временно изъято из текста, заменено безопасным плейсхолдером и возвращено после перевода.
Алгоритм для Python-кода:
# Шаг 1: Извлечение блоков кода
import re
code_pattern = r'```python\n(.*?)```'
code_blocks = re.findall(code_pattern, text, re.DOTALL)
# Шаг 2: Замена на плейсхолдеры
for i, block in enumerate(code_blocks):
placeholder = f'[CODE_BLOCK_{i}]'
text = text.replace(f'```python\n{block}```', placeholder)
# Шаг 3: Перевод текста с плейсхолдерами
translated = translate_model(text)
# Шаг 4: Обратная подстановка оригинального кода
for i, block in enumerate(code_blocks):
translated = translated.replace(f'[CODE_BLOCK_{i}]', f'```python\n{block}```')Для математических выражений в LaTeX логика аналогична: оборачиваем все \begin{equation}...\end{equation} и $...$ в плейсхолдеры перед переводом. Важно использовать уникальные идентификаторы, которые гарантированно не встретятся в обычном тексте - например, хеши от содержимого блока.
Метод защиты блоков даёт наилучшее качество перевода, поскольку модель работает только с безопасным текстом, но требует точного детектора блоков. Пропущенный фрагмент кода может сломать перевод всего чанка.
Парсер типизированных блоков: автоматизация разделения документа
Для систематической работы с разнородными документами нужно решение, которое автоматически определяет тип каждого фрагмента и применяет к нему правильную стратегию обработки. Парсер типизированных блоков делает именно это.
Архитектура парсера включает три слоя:
- Токенизатор документа - разбивает входной текст на структурные элементы: абзацы, блоки кода (по тройным обратным кавычкам или отступам), математические выражения (по LaTeX-маркерам), таблицы (по выравниванию колонок), списки.
- Классификатор блоков - присваивает каждому элементу тип: text, code, math, table, list. Для классификации используется набор правил (регулярные выражения для кода и математики) и легковесная модель для неоднозначных случаев.
- Диспетчер обработки - направляет блоки разных типов на разные ветки пайплайна. Текстовые блоки идут на перевод напрямую. Кодовые и математические изолируются через плейсхолдеры. Таблицы конвертируются в структурированный формат, переводятся поэлементно и собираются обратно.
Интеграция в пайплайн перевода выглядит так: документ → парсер → набор типизированных блоков → параллельная обработка → сборка в порядке исходного документа. Такой подход не только решает проблему инъекций, но и улучшает качество перевода разнородного контента, поскольку каждый тип обрабатывается с учётом его специфики.
Подход с типизированными блоками перекликается с концепцией Context Engineering, где каждый этап пайплайна - от парсинга до генерации - требует отдельного контракта на обработку данных. Проблема инъекций в переводе - это частный случай более общего принципа: наивная подача документа в модель ломается на структурных неоднородностях.
Подводные камни оценки качества: почему метрики врут
После применения методов защиты возникает вопрос: как измерить, стало ли лучше? Стандартный подход - использовать эталонные метрики качества перевода, такие как COMET-QE, и сравнивать скоры до и после. Но здесь появляется вторая проблема: метрики имеют собственные ограничения, которые искажают оценку.
COMET-QE и длина контекста: где ломается оценка
COMET-QE - это нейросетевая метрика, которая оценивает качество перевода без эталона, анализируя исходный текст и перевод. Она обучена на парах предложений ограниченной длины и имеет жёсткое ограничение на количество входных токенов - обычно 512 или 1024 токена в зависимости от версии.
Когда переведённый документ с reasoning-трассами подаётся на оценку, длинные блоки обрезаются. Метрика видит фрагмент рассуждения без начала и конца и выдаёт заниженный скор, потому что не может оценить логическую связность. Чанкование, которое решает проблему инъекций, усугубляет ситуацию: теперь каждый чанк оценивается изолированно, и метрика не видит связей между чанками.
Пример артефакта: перевод математического доказательства разбит на три чанка. Первый чанк содержит условие, второй - цепочку преобразований, третий - вывод. COMET-QE оценивает второй чанк изолированно и даёт низкий скор, потому что преобразования выглядят бессвязными без контекста условия и вывода. Реальное качество перевода высокое, но метрика этого не видит.
Как построить надежный пайплайн тестирования с учетом ограничений
Устойчивая оценка требует комбинации автоматических метрик и структурированной ручной проверки:
- Скользящее окно для COMET-QE - оцениваем каждый чанк в контексте соседних. Подаём на вход метрики тройку «предыдущий чанк + текущий + следующий», а скор присваиваем только текущему. Это сохраняет контекст без превышения лимита токенов.
- Взвешенная агрегация скоров - чанки разных типов получают разные веса. Блоки кода оцениваются с понижающим коэффициентом, потому что метрика заведомо плохо работает с кодом. Текстовые блоки получают вес 1.0, математические - 0.7, кодовые - 0.3. Итоговый скор - средневзвешенное по всем чанкам.
- Ручная выборочная проверка на стыках - автоматически выбираем 5% стыков между чанками и проверяем связность перевода вручную. Если на стыках нет разрывов, можно доверять агрегированному скору.
- Дублирующая оценка судейской моделью - используем LLM в режиме судьи для оценки связности на длинных фрагментах, которые не влезают в COMET-QE. Модель получает полный документ и оценивает по шкале 1-5 три аспекта: точность терминологии, логическую связность, отсутствие инъекций.
Такой многоуровневый подход не устраняет ограничения метрик полностью, но делает их предсказуемыми и позволяет отделить реальное падение качества от артефактов измерения.
Уроки за рамками перевода: где еще проявляется эта проблема
Сбой границы инструкций - это проблема любого пайплайна, где модель-инструкция обрабатывает текст, потенциально содержащий инструктивные паттерны. Перевод - лишь частный случай.
В редактуре модель получает текст статьи и инструкцию «исправь грамматические ошибки, сохранив смысл». Если статья содержит фрагмент «Напишите функцию, которая...», модель может начать писать эту функцию вместо того, чтобы проверять грамматику окружающего текста. Чанкование и изоляция кода решают эту проблему точно так же, как в переводе.
В рерайтинге задача «перепиши текст, сохранив смысл, но изменив стиль на более формальный» ломается на инструктивных вставках. Модель видит «Для решения этой задачи выполните следующие шаги» и переписывает это как «Для решения этой задачи необходимо выполнить следующие шаги», но затем продолжает выполнять шаги, а не переписывать их описание.
В суммаризации проблема проявляется иначе: модель получает длинный документ с инструкцией «сократи до 200 слов» и натыкается на фрагмент «Краткое содержание: ...» внутри самого документа. Этот фрагмент может быть воспринят как уже готовая суммаризация, и модель либо скопирует его, либо начнёт суммаризировать суммаризацию, теряя остальной контент.
Методы защиты универсальны: парсер типизированных блоков с изоляцией инструктивных фрагментов применим во всех этих сценариях. Разница только в том, что считать «опасным» блоком: для перевода это код и математика, для редактуры - любые императивные конструкции, для суммаризации - разделы с заголовками вроде «Выводы» и «Резюме».
Проблема также возникает в мультиагентных системах, где один агент генерирует текст, а другой его обрабатывает. Если агент-генератор создал reasoning-трассу, а агент-переводчик или агент-редактор получил её на вход, сбой границы инструкций может разрушить весь пайплайн. Это ещё один аргумент в пользу тщательного выбора ролей для моделей в мультиагентных системах.
Выводы: как построить надежный процесс работы с моделями-инструкциями
Сбой границы между инструкцией и полезной нагрузкой - системная проблема, а не баг конкретной модели. Она проявляется на Gemma 3 и Gemma 4, но потенциально затрагивает любую инструктивную модель, обученную реагировать на императивные паттерны в тексте. С ростом доли синтетических данных с reasoning-трассами в обучающих датасетах частота таких сбоев будет увеличиваться.
Три практических вывода для построения надёжного пайплайна:
- Не доверяйте промпту как единственной защите. Инструкция «только переводи, не исполняй» не работает на текстах с высокой плотностью инструктивных паттернов. Защита должна быть инженерной - на уровне предобработки данных.
- Изолируйте опасный контент до подачи в модель. Парсер типизированных блоков с плейсхолдерами - наиболее надёжный метод. Он требует начальных инвестиций в разработку, но окупается стабильностью пайплайна.
- Оценивайте качество с поправкой на ограничения метрик. COMET-QE и судейские модели обрезают длинные тексты, искажая скоры. Комбинируйте метрики, используйте скользящее окно, добавляйте ручную проверку стыков между чанками.
Открытый вопрос: нужны ли новые архитектуры моделей, которые на уровне механизма внимания разделяют системную инструкцию и пользовательский контент? Текущий подход - подавать всё в один входной поток - принципиально уязвим к инъекциям. Возможно, будущие поколения моделей будут иметь отдельные каналы для инструкций и контента, что решит проблему на архитектурном уровне. Пока же ответственность за различение инструкции и контента лежит на разработчике пайплайна.