«Смотря какой fabric, смотря сколько details». Как и почему LLM оказались не в состоянии перевести текст

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

За эти месяцы в процессе разработки постоянно всплывали проблемы. Что-то было связано косяками с моей стороны, а что-то — с особенностями работы LLM. 

Об одной из таких проблем, достаточно абсурдной и при этом с трудом поддающейся решению, я расскажу отдельно.

Суть проблемы

Еще на ранних этапах разработки я запустил конвейер по написанию (точнее, рерайтингу) новостей.

Для понимания — кратко о том, как работает новостной пайплайн: 

1. поиск новостей по определенному запросу — в данном случае из англоязычных источников (в силу тематики),

2. парсинг текста выбранных новостей из первоисточника,

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

4. финальная редактура, расстановка ссылок, парсинг картинок, и т.д. вплоть до постинга на сайт.

Сначала все это более-менее работало — тексты, хоть и требовали небольшой редактуры, выходили нормальными.

Но буквально в один день эти тексты как будто стала писать Зоя Вексельштейн:

То есть, в итоговом тексте были рандомно разбросаны непереведенные слова. Не только сложные технические термины, но и достаточно простые слова. В пайплайне генерации статей эта проблема тоже встречалась.

Поиск показал, что проблему Not-Translated Words в машинном переводе пытались решить уже давно. Вот материал от 1998 года — правда, там авторы 45% таких случаев списывали на недостаточный лексикон систем перевода:

Учитывая объемы данных, на которых обучаются LLM, здесь дело было явно не в отсутствии слова в словаре.

Простое решение

Когда проблема только появилась, я списал ее на недостаточно проработанный системный промпт. Поэтому и решение на первом этапе искал внутри этого промпта.

К слову говоря, процентов 20 всего времени в процессе разработки я тратил именно на промпты. Я себе запилил систему версионирования промптов + A/B тесты, где после обновления промпта прогонял его по бенчмарку 10-20 раз для более значимой статистической выборки. И, если промпт давал желаемый результат без регрессии, принимал его.

Само собой все принципы промпт-инжиниринга также использовал. Роль, задача, контекст и т.д. Для ризонинг моделей — дополнительные примочки.

Результат = не вышло. И пришлось задуматься о смене модели или создании дополнительного слоя «переводчика». Но ни того ни другого по очевидным причинам не хотелось.

Меняем модель

Раз внутри промпта проблема не решалась, значит проблема была в самой LLM. Поэтому следующим шагом я сменил модель, которая отвечала за написание. Сменил Gemini 2.5 flash на DeepSeek (какой там был актуальным осенью прошлого года). Обе модели +/- были в одном ценовом диапазоне.

После этого в тексте, наравне с инглишем, появились иероглифы. При том, что первоисточники всегда были англоязычными, и китайского текста в них точно не было:

В общем, характерной чертой Дипсика оказались иероглифы — либо из-за артефактов обучения на китайских датасетах, либо из-за того, что DeepSeek R1 «думал» на китайском, даже если запрос был на другом языке. 

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

В конечном итоге мне не подошли обе модели — выбор был между иероглифами и «fabric» c «details». Ставить написание новостей на поток с такими вводными было нельзя.

Пришлось ставить еще один слой

Третьей попыткой я решил добавить дополнительный слой, так как других альтернатив я не видел. Брать более дорогие модели не хотел, а все остальные, что были в том же ценовом диапазоне не справлялись с базовыми задачами. Дело было даже не в иероглифах.

Задачей LLM на этом этапе было найти непереведенные слова и перевести их. С оговоркой что переводим только те слова, у которых есть общепринятый русскоязычный вариант.

Это решило проблему на 95%. То есть, текст выходил более-менее нормальным, но было две проблемы.

Первая — дополнительный этап часто игнорировал вторую часть и дословно переводил (а то и транскрибировал) даже непереводимую игру слов. Например: 

Можно выделить три основных подхода к локальному запуску. Олл-ин-ван решения вроде LM Studio или GPT4All предлагают максимально простой старт — устанавливаете программу, скачиваете модель через встроенный каталог и начинаете работу.

Причем в некоторых материалах гиперрусификация соседствовала с недопереводом:

А вторая проблема — это было дорого. Даже с учетом кеширования рост расходов был неприятным, а изначальной целью всего проекта было радикально снизить стоимость создания контента.

В попытках хоть как-то сбалансировать алгоритм я экспериментальным путем пришел к временной схеме. В ней система определяла все более-менее специфические слова и термины, переводила их на русский, но сохраняла исходный вариант рядом в скобках:

Выглядело это более академично, хотя и сильно увеличивало затраты времени на финальную редактуру материала.

Как все в итоге решилось

А решилось все само собой. Когда Google выпустил модель Gemini 3 Flash, я заменил DeepSeek и Gemini 2.5 на третью версию. Инглиш исчез, термины переводятся корректно, общее качество текста тоже стало выше.

Мораль этой истории такая: если для решения какой-то задачи с LLM текущего поколения нужно танцевать с бубном, не расстраивайтесь. Есть вероятность, что следующее поколение моделей будет решать эту проблему нативно (чем перечеркнет смысл ваших многомесячных трудов).

И касается это не только перевода.

Почему LLM так себя ведут?

В попытках решить проблему, я пытался понять, почему она вообще возникала. Проблема, кстати, была не только у меня — на Gemini версий от 1.5 до 2.5 жаловались особенно часто.

Причин нашлось несколько, все они так или иначе уходят корнями в обучение LLM:

• В текстах, на которых обучалась модель, есть много мест, где исходные слова оставлены намеренно — имена, бренды, сленг или термины в технической документации. В итоге модель уверена, что копировать исходные слова в переведенный текст допустимо.

• Модели склонны пропускать в исходном виде слова с высокой энтропией перевода (то есть, у которых множество вариантов перевода в разных контекстах). При обучении модели пропуск такого слова в исходном виде приносил меньший штраф, чем использование неверного варианта перевода. Для менее мощных LLM выбор правильного перевода для такого слова — еще и слишком «дорогая» операция с точки зрения расхода токенов, и дешевле оставить его как есть.

• Какие-то слова для моделей могут быть мало знакомы — то есть, они редко встречались при обучении или у них слишком неоднозначная статистика включений. Тогда для модели тоже проще не переводить это слово вообще.

• Вкрапления слов на третьих языках (как в нашем варианте — на китайском) появляются, потому что модель явно не штрафовали за токены на «неправильном» языке, если эти токены подходили по смыслу. Ну и обучение на смешанных документах тоже в этом виновато (достаточно 2% многоязычных данных, чтобы перевод потом ломался).

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

В моем случае это произошло при переходе от Gemini 2.5 к Gemini 3.0. С тех пор ошибочно переведенные или оставленные без перевода слова практически не встречаются.