В multilingual RAG риск утечки PII зависит от этапа, а не языка

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

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

Добавление LLM-проверки входного запроса меняет картину: остаточные утечки сохраняются уже для Arabic и Swahili. Обратный перевод запроса не устраняет разрыв, но это нельзя считать доказательством того, что проблема именно в языке: переводчик, judge и генератор во всей системе — одна и та же модель Qwen2.5-7B.

Практический смысл простой: тестировать multilingual RAG нужно не вопросом «какой язык самый опасный?», а поэтапно. Отдельно проверять запрос, перевод, поиск, решение judge и финальный ответ — иначе одна усреднённая метрика скроет место, где реально возникает утечка.

Есть и любопытный диагностический результат. Если приложить к input judge правильный документ из корпуса, он блокирует 15 из 17 остаточных ячеек на отдельном наборе многоязычных атакующих запросов. Но это не готовая защита: использовался oracle retrieval, проверялись только adversarial-запросы, а влияние на обычные запросы и полезность ответов не измеряли.

Ограничения существенные: корпус синтетический, все ключевые компоненты построены на Qwen2.5-7B, а независимая проверка с другим переводчиком, judge и запросами от носителей языка ещё нужна. Поэтому результаты говорят не о врождённой «опасности» языков, а о поведении конкретного pipeline.

Если вы проверяете собственный RAG, стали бы вы искать уязвимый язык или сначала разложили бы утечку по этапам конвейера? Источник: cs.CL updates on arXiv.org