Ошибка мультиязычного поиска редко выглядит как авария. Интерфейс открывается, английские запросы работают лучше, выпуск кажется успешным. Но пользователи другого языка получают меньше совпадений, неверный маршрут или пустую выдачу.
Причина часто находится ниже модели
Поиск объединяет нормализацию, разбиение текста, сопоставление, ранжирование, пороги и маршрутизацию. Изменение любого слоя влияет на результат. Новая граница слова, ограниченный набор символов или порог, настроенный на одном языке, способны незаметно снизить полноту на другом.
Рекомендация Unicode по сегментации текста описывает стандартные границы слов и других элементов для разных письменностей. Она напоминает: английская фраза с пробелами не является универсальной моделью языка. Продукту нужен осознанный способ сегментации.
Пользователь видит плохой ответ и может решить, что ошиблась модель. Разбор почему RAG не работает предлагает сначала проверить найденные данные. Если нужный материал не дошёл до ранжирования, настройка промпта его не вернёт.
Зафиксируйте языковой контракт
Определите поддерживаемые языки и письменности. Документируйте нормализацию, разбиение, сопоставление, транслитерацию и ранжирование. Формулировка о поддержке Unicode слишком общая: система может правильно хранить текст, но поисковое выражение всё равно превратит буквы в разделители.
Документация Python объясняет, как режим ASCII меняет поведение распространённых классов символов и границ. Похожие переключатели есть в других библиотеках. Незаметный флаг способен сократить фактическую языковую поверхность маршрутизатора.
- Нормализация: задайте правила регистра, составных знаков, пунктуации и пробелов.
- Сегментация: проверьте письменности, которые не следуют английской схеме.
- Алиасы: включите родные термины, переводы, транслитерации и смешанные запросы.
- Ранжирование: оценивайте релевантность, а не только наличие любого результата.
- Запасной путь: показывайте неопределённость вместо тихого неверного маршрута.
Соберите тесты из реальной речи
Набор должен содержать реальные намерения на каждом поддерживаемом языке. Добавьте короткие запросы, словоформы, составные слова, пунктуацию, скопированный текст, смешение письменностей и обычные опечатки. Для каждого примера укажите ожидаемый маршрут и нужный результат.
Ошибка теста должна объяснять слой проблемы. Показывайте нормализованный ввод, полученные токены, кандидатов, оценки, выбранный маршрут и причину запасного пути. Так команда не станет подстраивать конечный порог под дефект сегментации.
Материал о контроле фактов ИИ-агентов полезен как общий принцип: качество подтверждают независимым результатом. А разбор о том, почему ИИ ошибается уверенно, показывает опасность правдоподобного ответа без достаточного основания.
Сравнивайте языки отдельно
Средняя метрика может скрыть сильное падение у меньшей языковой группы. Отчёт должен разделять поддерживаемые языки или письменности и задавать приемлемый минимум для каждой. Общий рост не должен оправдывать потерю целой аудитории.
Запускайте набор при изменении сегментации, регулярных выражений, ранжирования, алиасов, эмбеддингов, маршрутизации и зависимостей. Подтверждённый сбой превращайте в постоянный тест. После выпуска следите за пустой выдачей и изменением маршрутов по языкам.
Для каждого языка назначьте владельца качества, который понимает реальные запросы пользователей, а не только структуру теста. Он проверяет, что ожидаемый результат по-прежнему полезен и что перевод не исказил намерение. Такая проверка особенно важна для профессиональной лексики, сокращений и слов, которые меняют смысл в зависимости от отрасли.
Тестовый набор стоит разделить на базовый контракт и наблюдаемые проблемы. Базовая часть защищает ключевые маршруты продукта. Вторая растёт из обращений поддержки и подтверждённых сбоев. Обе части должны запускаться одинаково, но их происхождение полезно сохранять: так команда видит, какое реальное поведение защищает конкретный пример.
Не ограничивайтесь совпадением маршрута. Проверьте, что найденный материал понятен пользователю на его языке, а запасной ответ не предлагает перейти на английский без необходимости. Если язык не поддерживается полностью, сообщите об этом явно и предложите безопасный следующий шаг. Честная граница лучше уверенной неверной выдачи.
Перед выпуском сравните новую и предыдущую версии на одном наборе запросов. Просмотрите не только ухудшения, но и неожиданные крупные улучшения: они могут указывать на слишком широкий маршрут. После выпуска сопоставьте наблюдение с тестом и добавьте новый пример, если реальная проблема ещё не воспроизводится.
Частые вопросы
Это ухудшение поиска или маршрутизации для одного из поддерживаемых языков после изменения, которое может не влиять на работу продукта для остальных пользователей.
Классы символов и границы слов зависят от режима библиотеки. Правило, ориентированное на ASCII, может перестать распознавать буквы или границы другой письменности.
Нужны реальный запрос, намерение пользователя, ожидаемый маршрут или результат и диагностика нормализации, токенов, кандидатов, оценок и запасного поведения.
Измеряйте языковые группы отдельно, задайте минимум качества для каждой, запускайте набор при связанных изменениях и наблюдайте за маршрутами и пустой выдачей после выпуска.
Исправление должно быть узким: восстановить контракт, добавить воспроизводящий тест и проверить соседние письменности. Продукт становится мультиязычным не тогда, когда поле принимает текст, а когда весь путь до полезного результата проверяется. Для независимой оценки можно обратиться в «Открытый путь».
