Если конвейер локализации использует retrieval augmented generation, чтобы подмешивать словарные термины в контекстное окно модели, значит, у него есть проблема с полнотой поиска, которую до сих пор никто не измерял.
Схема везде одна и та же: построить эмбеддинг входного текста, выполнить косинусный поиск по термбанку, подставить top-k результатов в промпт. На выходе — грамматически корректный текст. Но терминология неверна. И эту ошибку не заметить, если человек не владеет обоими языками и не знает словарь.
Сначала мы тоже собрали именно такую наивную версию. А потом измерили полноту поиска на продакшен-словарях — и оказалось, что на реальных нагрузках система пропускает большинство релевантных терминов.
| Техника | Локализация с retrieval augmentation (RAL) — обогащение контекста на этапе инференса |
| Ключевое решение | Декомпозиция на n-граммы перед построением эмбеддингов, а не эмбеддинги на уровне предложений |
| Режимы поиска | 3 (skip / preload / vector search), выбор для каждого запроса по мощности словаря |
| Калибровка порога | Непрерывная, еженедельная, по оценкам качества для каждой пары локалей |
| Снижение терминологических ошибок | 17–45% у пяти провайдеров LLM (контролируемое исследование, более 42 000 оценок качества) |
| Оценивание | Независимая кросс-модельная оценка, асинхронно, для каждого запроса |
Почему эмбеддинги предложений пропускают словарные термины?#
Словарный термин — это 1–3 слова. "движок локализации." "Токен доступа." "Конвейер развертывания."
Входной текст — это JSON-объект со значениями от двух слов (подпись на кнопке) до двухсот слов (описание продукта). Когда в эмбеддинг превращается полная строка "Configure the localization engine for production deployment", получившийся вектор отражает семантику всего предложения — что-то про настройку и продакшен-системы. А релевантная для словаря фраза "localization engine" растворяется в представлении на уровне предложения.
Косинусное сходство между этим вектором предложения и словарной записью "localization engine" оказывается в диапазоне 0.6–0.7. Ниже порога поиска. Термин есть во входных данных. Но система поиска его пропускает.
Проблема в уровне детализации: представления на уровне предложений ищут совпадения для целей на уровне фраз. Модель эмбеддингов добросовестно передает смысл предложения целиком. Но входящая в него терминология не получает собственной области в векторном пространстве.
Мы пришли к этому не сразу. На продакшен-нагрузках — вложенных JSON-объектах с 20–50 ключами и значениями разной длины — поиск на уровне предложений пропускал большинство релевантных словарных терминов. Запрос на локализацию завершался успешно. Текст на выходе звучал естественно. Но "localization engine" превращался в "translation tool" — грамматически корректно, семантически близко, терминологически неверно. А конвейер сообщал об успехе.
Как декомпозиция на n-граммы исправляет поиск по словарю?#
Решение оказалось в том, чтобы разбивать входные данные на единицы уровня фраз до построения эмбеддингов. Каждое строковое значение превращается в набор перекрывающихся окон n-грамм:
Input: "Configure the localization engine for production"
1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
engine for, for production]
3-grams: [configure the localization, the localization engine,
localization engine for, engine for production]Каждая n-грамма становится отдельным поисковым запросом. "Localization engine" обращается к словарю как самостоятельная фраза — и находит нужное совпадение с высоким уровнем сходства.
Конвейер декомпозиции:
- Рекурсивно извлечь все строковые значения из вложенных JSON-структур
- Разбить на предложения, удалить HTML и аннотации разметки
- Нормализовать пробелы, убрать внешние кавычки, снять экранирование форматирования
- Сгенерировать из каждого предложения перекрывающиеся 1-граммные, 2-граммные и 3-граммные фразы
Абзац из 50 слов дает примерно 150 n-грамм. Типичная API-нагрузка с 20 ключами дает 1 000–3 000 поисковых фраз. Для каждой фразы независимо строится эмбеддинг, и каждый эмбеддинг выполняет запрос ближайших соседей к векторному индексу словаря.
Мы измерили разницу на тех же продакшен-нагрузках, которые вскрыли исходную проблему. Теперь словарные термины находятся независимо от контекста предложения вокруг них: термин из двух слов, спрятанный в описании продукта на 200 слов, извлекается с той же полнотой, что и отдельная метка.
Как работает адаптивный поиск для словарей разного размера?#
Декомпозиция на n-граммы и пакетное построение эмбеддингов — правильный подход для больших словарей. Для маленьких, как выяснилось, это вычислительно избыточно.
движок локализации, настроенный на 8 словарных терминов, работает быстрее при прямой подстановке: один запрос к базе данных, детерминированно, меньше миллисекунды. движок локализации с 2 000 терминами уже требует векторного поиска — ограничения контекстного окна и размывание релевантности делают полную подстановку невозможной.
Для каждого запроса работает один из трех режимов поиска, который выбирается по мощности словаря для пары локалей:
| Режим | Условие | Поведение |
|---|---|---|
| Skip | Ноль совпадающих элементов | Без эмбеддингов, без поиска, без подстановки |
| Preload | Ниже порога мощности | Один запрос к базе данных загружает все совпадающие элементы; прямая подстановка |
| Search | Выше порога мощности | Полная декомпозиция на n-граммы → пакетное построение эмбеддингов → векторный поиск ближайших соседей |
Порог мощности, который отделяет preload от search, определяется по профилированию задержек на продакшен-трафике и корректируется по мере того, как меняются производительность моделей эмбеддингов, распределение размеров словарей и характеристики инфраструктуры. Начальное значение, которое мы выкатили, продержалось примерно три недели, прежде чем телеметрия показала, что его пора сдвигать. С тех пор мы меняли его несколько раз — оказалось, что оптимальный порог дрейфует по мере того, как движки накапливают словарные термины, а характеристики моделей эмбеддингов меняются от обновления к обновлению у провайдеров.
Задержка поиска масштабируется от сложности словаря, а не от размера нагрузки. движок локализации с 10 терминами укладывается в однозначные миллисекунды независимо от длины входного текста. движок локализации с 500 терминами использует полный конвейер декомпозиции, но все равно остается в пределах бюджета задержки для надежного шага фонового рабочего процесса.
Как калибруется порог сходства для поиска по словарю?#
Каждый эмбеддинг n-граммы запрашивает векторный индекс в поиске ближайших соседей выше заданного порога сходства. Совпадения ниже порога отбрасываются как шум.
Порог одновременно определяет и точность, и полноту поиска:
- Слишком низкий: в промпт просачиваются нерелевантные термины. Модель видит словарный контекст, который не относится к входным данным, и иногда ему следует — в результате в тексте появляется терминология из другой области.
- Слишком высокий: корректные вариантные формулировки и морфологические формы отсекаются. "Deploying" не сопоставляется со словарной записью для "deploy." Полнота падает.
Мы обнаружили, что правильный порог зависит от пары локалей. У English→German распределение сходства отличается от English→Japanese, где морфологическая дистанция между исходными n-граммами и словарными записями устроена иначе. Один глобальный порог давал нестабильную полноту по тем парам локалей, которые мы измеряли.
Теперь порог непрерывно калибруется по оценкам качества для каждой пары локалей из независимого конвейера оценивания. Когда система оценивания фиксирует рост несоблюдения словаря — термины есть во входных данных, но отсутствуют в результате, — это значит, что полнота поиска просела, и порог ослабляется. Когда оценивание показывает, что модель применяет нерелевантную терминологию, значит, выросло число ложноположительных подстановок, и порог ужесточается.
Эта калибровка выполняется еженедельно. Иначе нельзя: поведение моделей эмбеддингов меняется от обновления к обновлению у провайдеров, распределения словарей сдвигаются по мере того, как команды добавляют новые термины, а характеристики входных текстов меняются по мере роста продуктов.
Как найденные словарные термины подставляются в модель локализации?#
Найденные словарные элементы делятся на два класса ограничений, и в системном промпте модели для них действует разная логика применения:
Непереводимые термины — строки на исходном языке, которые должны появиться в целевом тексте без изменений. Названия брендов, технические идентификаторы, названия продуктов. Модель сохраняет их дословно.
Пользовательские переводы — соответствия source→target, которые переопределяют собственное решение модели. "Localization engine" должно стать "moteur de localisation." Модель воспринимает их как обязательные лексические ограничения.
Оба класса подставляются в системный промпт как правила с явным приоритетом над поведением модели по умолчанию. Иерархия промпта заставляет соблюдать словарь выше собственных языковых предпочтений модели.
Это различие важно при оценивании: независимая модель-оценщик проверяет, были ли непереводимые термины сохранены без изменений и были ли пользовательские переводы применены точно. Два критерия проверки для двух типов ограничений. Мы рано поняли, что если смешать их в одну категорию "словарь", оценивание становится ненадежным — термин, сохраненный дословно там, где его нужно было перевести (или наоборот), при единой проверке засчитывался бы как корректный.
Как проверять качество локализации на языках, которыми вы не владеете?#
Весь конвейер поиска и локализации может отработать без единой ошибки и при этом выдать терминологически неверный результат. Пропущенный словарный термин не создает сигнала об ошибке. Неправильно примененный пользовательский перевод возвращает 200. Конвейер успешен. Результат неверен.
Это и есть разрыв в наблюдаемости локализации, который большинство команд так и не закрывает.
Поиск связан с независимым асинхронным оцениванием. После завершения запроса на локализацию отдельные модели оценивания проверяют результат на соответствие конфигурации движка локализации:
- Соблюдение словаря — сохранены ли непереводимые термины? Применены ли пользовательские переводы точно?
- Соблюдение инструкций — выполнены ли правила, специфичные для локали?
- Пользовательские критерии оценивания — параметры качества для каждого движка, заданные командой локализации
Модели оценки работают на отдельной инфраструктуре от модели локализации. Они запускаются асинхронно в фоновых рабочих процессах после каждого запроса, проходящего через движок локализации со включённой оценкой. Одна модель выполняет локализацию, другая — выставляет оценку. Межмодельная оценка устраняет проблему самооценки.
Результаты оценки затем используются для калибровки retrieval:
- Оценка фиксирует рост числа случаев несоблюдения глоссария для пары локалей
- Проверка показывает, что полнота retrieval снизилась — порог сместился относительно текущего распределения глоссария
- Порог корректируется; полнота восстанавливается; показатели соблюдения стабилизируются
Именно этот цикл делает систему самокорректирующейся. Оценка даёт ту наблюдаемость, которой не хватает одному лишь retrieval. Без неё команды выпускают локализованный контент на языках, которыми не владеют, не имея никакого сигнала о том, применяется ли вообще созданный ими глоссарий.
Почему полнота retrieval со временем даёт накопительный эффект?#
Каждый запрос на локализацию, в котором термины глоссария применяются корректно, укрепляет терминологическую согласованность во всём продукте. Каждый запрос, в котором термин пропущен, вносит дрейф: на одном экране написано "движок локализации", на другом — "инструмент локализации", на третьем — "модуль локализации". В 30 локалях и при еженедельных релизах эти расхождения накапливаются.
Разница между высокой и низкой полнотой retrieval — не в качестве отдельного запроса. Это накопительный механизм согласованности. Высокая полнота означает, что глоссарий обеспечивает единообразие на каждом экране, в каждой локали, в каждом релизе. Низкая полнота означает, что глоссарий срабатывает лишь время от времени — то есть структурно это почти то же самое, что и отсутствие глоссария, просто деградация происходит медленнее.
Что это значит для инженерии локализации#
Описанная здесь проблема retrieval не привязана к какой-то одной реализации. Она структурна для любой системы, которая пытается выполнять локализацию с учётом глоссария через поиск на основе эмбеддингов. Несоответствие гранулярности между представлениями входных данных на уровне предложений и целями глоссария на уровне фраз существует независимо от того, какая модель эмбеддингов используется, какая векторная база данных выбрана или какая LLM генерирует результат.
Команды, создающие автоматизацию локализации, стоят перед выбором: принять retrieval на уровне предложений с его невидимым провалом в полноте или выстроить инфраструктуру декомпозиции и калибровки, которая этот провал закрывает. Второй путь требует трёх систем — декомпозиции на n-граммы, адаптивного retrieval и цикла оценки, который передаёт данные обратно в управление порогом. У каждой системы свой операционный ритм: логика декомпозиции развивается по мере изменения форматов входных данных, пороги retrieval сдвигаются по мере роста глоссариев, а критерии оценки уточняются по мере того, как команды локализации понимают, какие параметры важны для их контента.
Локализация с retrieval augmentation производственного уровня — это непрерывная инженерная практика: систему нужно постоянно выстраивать, инструментировать, наблюдать и настраивать. Формирующаяся вокруг этой работы дисциплина инженерии локализации отражает операционную реальность: инфраструктура локализации требует такого же постоянного внимания, как backend-сервисы, CI/CD-конвейеры и стеки наблюдаемости.
Что дальше#
FAQ#
Что такое retrieval augmented localization (RAL)? Retrieval augmented localization обогащает каждый запрос на локализацию терминами глоссария, правилами тональности бренда и инструкциями для конкретной локали на этапе инференса — это тот же шаблон retrieve-inject, что и в RAG, только применённый к локализации. В контролируемом исследовании с участием пяти провайдеров LLM и пяти европейских языков RAL снизил количество терминологических ошибок на 17–45% по сравнению с теми же моделями без обогащения контекстом.
Почему эмбеддинги на уровне предложений пропускают термины глоссария? Термины глоссария обычно состоят из 1–3 слов. Когда они встраиваются как часть полного предложения, они растворяются в семантическом векторе предложения. Эмбеддинг отражает смысл предложения в целом — "движок локализации" внутри "Настройте движок локализации для production" не фиксируется как отдельный сигнал. Косинусное сходство между вектором предложения и записью глоссария оказывается ниже порога retrieval.
Как декомпозиция на n-граммы повышает полноту retrieval? Вместо того чтобы встраивать полные входные строки, система перед созданием эмбеддингов разбивает текст на перекрывающиеся фразы из 1-грамм, 2-грамм и 3-грамм. Каждая фраза становится отдельным запросом retrieval. Двухсловный термин глоссария, скрытый в абзаце из 200 слов, получает ту же полноту совпадения, что и отдельная метка, — потому что запрашивается независимо от окружающего контекста.
Сколько режимов retrieval использует система? Три. Skip (ноль элементов глоссария — retrieval не нужен), preload (ниже порога кардинальности — все элементы загружаются напрямую) и vector search (выше порога — полная декомпозиция на n-граммы и создание эмбеддингов). Режим выбирается для каждого запроса на основе кардинальности глоссария для конкретной пары локалей.
Как поддерживается порог сходства? Порог еженедельно калибруется по показателям качества для каждой пары локалей из независимого конвейера оценки. Когда растёт число случаев несоблюдения глоссария, порог снижают, чтобы повысить полноту. Когда в промпты начинают попадать нерелевантные термины, порог повышают. Для разных пар локалей требуются разные пороги из-за различий в морфологической дистанции.
Как работает межмодельная оценка качества локализации? После завершения каждого запроса на локализацию отдельная модель, работающая на другой инфраструктуре, оценивает, были ли корректно применены термины глоссария, соблюдены ли инструкции для конкретной локали и выполнены ли пользовательские критерии качества. Одна модель выполняет локализацию, другая — выставляет оценку. Это устраняет смещение самооценки и даёт ту наблюдаемость, которой не хватает одному лишь retrieval.
Что происходит, когда полнота retrieval глоссария низкая? Низкая полнота retrieval означает, что глоссарий срабатывает непоследовательно: на одном экране используется правильный термин, на другом — нет. В 30+ локалях и при еженедельных релизах эти расхождения накапливаются и превращаются в терминологический дрейф. Глоссарий существует, но не обеспечивает единообразия. Через несколько месяцев это структурно эквивалентно отсутствию глоссария.
Что такое разрыв наблюдаемости в локализации? Конвейер локализации может отработать без ошибок и при этом выдать терминологически некорректный результат. Пропущенные термины глоссария не создают сигнала об ошибке — API возвращает 200, перевод грамматически корректен. Разрыв наблюдаемости — это пространство между "конвейер успешно отработал" и "терминология корректна". Независимая оценка закрывает этот разрыв, измеряя соблюдение глоссария в каждом запросе.
